Repository Modeling – Tips , Key points etc.,

When Complex Join in Physical Layer ?

You can use the Physical Diagram feature to create joins between physical table objects. Note that complex joins can be used in this layer to express the relationships that do not involve a primary key–foreign key relationship. When you create a complex join in the Physical layer, you can specify expressions and the specific columns on which to create the join. When you create a complex join in the Business Model and Mapping layer, you do not specify expressions.
Why Complex Join in Logical Layer needed ?
- Logical complex joins are used to define join relationships in the BMM layer. A complex join tells Oracle BI Server that it can make the best decision about what exact Physical SQL to generate based on a logical query request. This is in contrast to a foreign key join in the BMM layer, which forces the server to use only that single physical join path between the two tables, even when a different path would be far more efficient.
-  The capability to create logical foreign key joins in the BMM layer is in the Administration Tool to provide backward compatibility with previous releases of the product.
Presentation Layer in RPD:
Organize and simplify the business model for a set of users
Single catalog must be populated with content from a single
business model; cannot span business models.
- Multiple catalogs can reference the same business model.
Aliases in Presentation Layer:
- An Aliases tab appears on the Presentation Catalog, Presentation Table, and Presentation Column property dialog boxes. If you modify a Presentation layer object, this tab keeps track of any prior names. Aliases are used to maintain compatibility with previously written queries after an object has been modified. You also can use this tab to specify or delete an alias for the Presentation layer objects.
- Best practice is to rename objects in the Business Model and Mapping layer and to minimize renaming in the Presentation layer.
 Why Validating a Repository is a necessary:
• All logical columns are mapped directly or indirectly to one or more physical columns.
• All logical dimension tables have a logical key.
• All logical tables have a logical join relationship to another logical table.
• There are at least two logical tables in the business model:
a logical fact table and a logical dimension table. Both can map to the same physical table.
• There are no circular logical join relationships.
• A presentation catalog exists for the business model.
 What is the use of Dimension Hierarchies ?
• Introduce formal hierarchies into a business model
• Establish levels for data groupings and calculations
• Provide paths for drill down 
 Why is Implicit Fact Column needed?
Dimension-only queries with columns from more than one dimension may not return the desired results.
• In a business model with conforming dimensions, many fact tables may join to the same dimensions.
• For dimension-only queries across multiple dimensions, Oracle BI Server picks the most economical fact table source based on the number and levels of joined dimensions.
Alternate for Connection Pool:
Logons
To specify specific database logon IDs for one or more databases, enter the appropriate user IDs and passwords for the user in the Logons tab of the User dialog box. When the connection pool omits the username, these usernames and passwords are used. Otherwise, these entries are ignored.
Administrator Account
• Is a default, permanent user account in every Oracle BI Server repository
• Cannot be deleted or modified other than to change the password and logging level. Any query issued from the Administrator account has complete access to the data; no restrictions apply to any objects.
Security Group Inheritance:
• Privileges granted explicitly to a user have precedence over privileges granted through groups.
• Privileges granted explicitly to a group take precedence over any privileges granted through other groups.
• If security attributes conflict, a user or group is granted the least restrictive security attribute.

 

View the original article here