1. OBIEE has tnsnames.ora file to connect to orcl datasources. Here is a sample location on tnsnames.ora in OBIEE 11G:
C:\MW_HOME\Oracle_BI1\network\admin
In order to be able to connect to Oracle data source to import Physical layer objects in Admin tool, this file should have an entry for the datasource:
(DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = localhost)(PORT = 1522)) (CONNECT_DATA =(SERVER = DEDICATED) (SERVICE_NAME = orcl.domain_name) ) )
ORCL should be used in Admin tool as a data source, with appropriate schema name and password for importing physical table metatdata.
A sample tnsnames.ora entry that can be used in rpd directly:
(DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = localhost)(PORT = 1522)) (CONNECT_DATA =(SERVER = DEDICATED) (SERVICE_NAME = orcl.domain_name) ) )
there shouldn't be any newline character in the above string.
1.1 OBIEE log location:
nqquery.log file contains the queries generated by OBIEE, it's location is:
C:\OBI_MW_HOME\instances\instance1\diagnostics\logs\OracleBIServerComponent\coreapplication_obis1\
2. Aliases are created in Physical layer of rpd to prevent extraneous joins. The fk physical joins which are defined for an alias are not present in the source physical table. for e.g. FACT_D1_ORDERS2 is an alias of D1_ORDERS2. FK physical joins are defined in this alias to other three dimension aliases:
These fk joins are not visible in the source table for this, i.e. D1_ORDERS2:
As shown above these fk physical joins are not displayed in the source physical table.
3. In the BMM layer the logical tables and columns are renamed to more sensible real worldly names rather than names in the physical layer which are more of db friendly. Each logical table has one or more logical table source.
4. Logical table keys: Each logical dimension table must have a logical key, for a business model to be valid.
Logical keys can be composed of one or more logical columns, the logical key defines the most detail level of information of any source in the logical table. If the logical tables are created by dragging and dropping a physical table from physical layer into a business model, they'll be automatically created.
5. For a valid business model logical tables must be joined with logical joins. Cardinality relationships between logical tables is capture by logical joins. Logical Facts will always be at the "many" end of these cardinal relationships. When a query is sent to OBI server, it figures out how to form physical query by examining how the logical model is constructed.
