OBIEE RPD - Physical Layer design standards
OBIEE RPD consists of three layers - Physical, Business Model & Mapping (BMM), and Presentation.
Physical layer is where information about physical data sources are stored.
BMM layer is where measurements and terms used in business are mapped to physical sources.
Presentation layer is where business model is customized for end users.
As per Oracle standards/recommendation we use Import Wizard for creating a new repository file and import metadata.
Connection Type used in Import Wizards:
Connection type is nothing but drivers/native Application Programming Interface (API) used for accessing different databases. Some databases may be accessed using native APIs, some using ODBC.
Database Object - Connection Pool
Connection pool regulate access to data source. Every data source must have at least one connection pool. Connection pool provide connections to multiple concurrent queries (data source requests) immediately because of enable connection pooling. This feature allows a single database connection to remain open for a specified time for use by future queries. This saves the overhead of opening and closing a new connection for every query.
Database Object - Features
This determines the SQL that Oracle BI Server will issue to the used database. This features table is set to the database's default values during schema import process. We can turn off any of these features if there is a reason to do so.
Using update row counts and view data
It is a good idea to update row counts or view data after an import to verify connectivity. Viewing data or updating row count, if successful, tells us that everything is configured properly.
Alias
Using aliases frequently in Physical layer removes unwanted joins.
It includes best practice naming conventions for physical tables.
Aliases also eliminate the circular joins.
Insert, update and delete for alias columns and datatypes is controlled by Base physical table on which alias is built.
Above all reusability is the principle for aliasing.
Joins
We can have physical joins as well as complex join in physical layer.
Physical Join/Foreign Join is by default INNER join.
We provide the expressions for it.
Complex Join is used when we have expressions using operators <,>,<>,<=,>= etc.
We can avoid using Complex Join in physical layer by using WHERE filters in logical layer CONTENT tab.
Opaque Views (Select Table type)
We use an opaque view as a Physical layer table that consists of a SELECT statement. This solution
is only recommended when there is no other solution. Opaque views cause big performance hindrance.
We can avoid using Opaque views in physical layer by using WHERE filters in logical layer CONTENT tab.
Physical layer is where information about physical data sources are stored.
BMM layer is where measurements and terms used in business are mapped to physical sources.
Presentation layer is where business model is customized for end users.
As per Oracle standards/recommendation we use Import Wizard for creating a new repository file and import metadata.
Connection Type used in Import Wizards:
Connection type is nothing but drivers/native Application Programming Interface (API) used for accessing different databases. Some databases may be accessed using native APIs, some using ODBC.
Database Object - Connection Pool
Connection pool regulate access to data source. Every data source must have at least one connection pool. Connection pool provide connections to multiple concurrent queries (data source requests) immediately because of enable connection pooling. This feature allows a single database connection to remain open for a specified time for use by future queries. This saves the overhead of opening and closing a new connection for every query.
Database Object - Features
This determines the SQL that Oracle BI Server will issue to the used database. This features table is set to the database's default values during schema import process. We can turn off any of these features if there is a reason to do so.
Using update row counts and view data
It is a good idea to update row counts or view data after an import to verify connectivity. Viewing data or updating row count, if successful, tells us that everything is configured properly.
Alias
Using aliases frequently in Physical layer removes unwanted joins.
It includes best practice naming conventions for physical tables.
Aliases also eliminate the circular joins.
Insert, update and delete for alias columns and datatypes is controlled by Base physical table on which alias is built.
Above all reusability is the principle for aliasing.
Joins
We can have physical joins as well as complex join in physical layer.
Physical Join/Foreign Join is by default INNER join.
We provide the expressions for it.
Complex Join is used when we have expressions using operators <,>,<>,<=,>= etc.
We can avoid using Complex Join in physical layer by using WHERE filters in logical layer CONTENT tab.
Opaque Views (Select Table type)
We use an opaque view as a Physical layer table that consists of a SELECT statement. This solution
is only recommended when there is no other solution. Opaque views cause big performance hindrance.
We can avoid using Opaque views in physical layer by using WHERE filters in logical layer CONTENT tab.
Comments