A Lookup Table for Each Base Table

15-24 System Administrators Guide for Oracle Business Intelligence Enterprise Edition Handling Non-ISO Type Language Codes If the data has non-ISO type language codes in the tables, then there should be a table that maps ISO language codes to non-ISO language codes. You can use the preexisting WEBLANGUAGE variable that sets the ISO language code when a user logs in. You define a separate LANGUAGE variable whose initialization block runs a query against a mapping table to fetch the non-ISO language code filtered by the value from the WEBLANGUAGE variable. Table 15–3 provides a mapping table for non-ISO language codes. LANGUAGE is a non-ISO language code.

15.6.6 Creating Physical Lookup Tables and Physical Lookup Columns

You can create physical lookup table objects in the business model to define the necessary metadata for translation lookup tables. Physical lookup tables are similar to logical lookup tables in both semantics and usage. Physical lookup tables address the following scenarios that logical lookup tables cannot handle: ■ The lookup table source is fragmented. In this case, use multiple physical lookup tables to hold the values. For example, translation values for fragmented product name data can be distributed in two physical lookup tables called productname_ trans_AtoM and productname_trans_NtoZ. ■ Different levels of translation tables are available. For example, translations are available in both an Essbase data source and a relational data source. It is preferable to use the same source as the base query. Unlike logical lookup tables, which you designate by selecting an option in the Logical Table dialog, you configure physical lookup tables by constructing lookup functions in the logical table source mapping. For example, suppose that you have the following physical tables: ■ A base table called Categories, with columns such as categoryid and categoryname. ■ A translation table called Categories_Trans, with columns such as categoryid, language_key, and categoryname. The translated value of categoryname is determined through a combination of the categoryid and language_key columns. Suppose that you have a logical table called Categories. In that table, you add a new logical column called categoryname_p, which is a translation column that depends on Note: You cannot use a derived logical column that is the result of a LOOKUP function as part of a primary logical level key. This limitation exists because the LOOKUP operation is applied after aggregates are computed, but level key columns must be available before the aggregates are computed because they define the granularity at which the aggregates are calculated. You can use a derived logical column that is the result of a LOOKUP function as a secondary logical level key. Table 15–3 Mapping Table for Non-ISO Language Codes WEBLANGUAGE LANGUAGE LAN_INT en ENG cn CHI 1 fr FRA 1 Localizing Oracle Business Intelligence 15-25 the current language. The column is not derived from any other logical column unlike logical lookup columns. The following procedure explains how to configure a physical lookup translation column using the previous example. To configure a translation column that is derived from a physical lookup table: 1. Open the repository in the Administration Tool. 2. In the Business Model and Mapping layer, create a new logical column by right-clicking the appropriate logical table for example, Categories and selecting New Object , then Logical Column. 3. Provide a name for the logical column for example, categoryname_p. 4. Select the Column Source tab.

5. In the Logical Table Source box under Derived from physical mappings,

double-click the logical table source object that contains the base table column. The Column Mapping tab of the Logical Table Source dialog is displayed.

6. Ensure that Show unmapped columns is selected.

7. In the Expression column for the new logical column for example, categoryname_

p, enter an expression such as the following: INDEXCOLVALUEOFNQ_SESSION.LAN_INT, DB_Name.My_Category.My_Schema.Categories.CategoryName, LOOKUPSPARSE DB_Name.My_Category.My_Schema.CATEGORIES_TRANS.CATEGORYNAME, DB_Name.My_Category.My_Schema.Categories.CategoryName, DB_Name.My_Category.My_Schema.Categories.CategoryID, VALUEOFNQ_SESSION.LANGUAGE You can also use Expression Builder to create the expression.

8. Click OK in the Logical Table Source dialog.

9. Click OK in the Logical Column dialog.

10. Save your changes. The Categories_trans physical translation table does not need to be incorporated into the logical table source. The INDEXCOL function checks that if the LAN_INT session variable is 0, then the categoryname column is fetched from the base table. Note the following about the LOOKUP function: ■ The physical LOOKUP function works the same as a logical LOOKUP function. The only difference is that all the references to logical tables and columns are replaced by physical tables and columns. ■ The first column of the LOOKUP function is a value column, which is a translation value column from a translation table. The second column is the base value column, if a sparse lookup exists. The remaining columns are columns or values to be joined to the physical translation table, which is the table that is implied by the value column of the LOOKUP function. Because you cannot use a dialog to configure a physical lookup table, you must ensure that the order of the join columns and values is compatible with the column sequence that is displayed in the Physical Table dialog for the physical translation table. For example, on the Keys tab of the Physical Table dialog for the Categories_trans table, the primary key is composed of the CategoryID and Language_Key columns. The columns that are specified in the LOOKUP function correspond to these columns: