About Physical Alias Tables

An Alias table (Alias) is a physical table with the type of Alias. It is a reference to a logical table source, and inherits all its column definitions and some properties from the logical table source. A logical table source shows how the logical objects are mapped to the physical layer and can be mapped to physical tables, stored procedures, and select statements. An alias table can be a reference to any of these logical table source types. For more information, see Creating and Administering the Business Model and Mapping Layer in an Oracle BI Repository.

Alias Tables can be an important part of designing a physical layer. The following is a list of the main reasons to create an alias table:

• To reuse an existing table more than once in your physical layer (without having to import it several times.
• To set up multiple alias tables, each with different keys, names, or joins.
• To help you design sophisticated star or snowflake structures in the business model layer. Alias tables are critical in the process of converting ER Schemas to Dimensional Schemas. For more information, see Identifying the Database Content For The Business Model.

You can allow an alias table to have cache properties that differ from its source table by setting an override flag in the Physical Table dialog box. In alias tables, columns cannot be added, deleted, or modified. Columns are automatically synchronized; no manual intervention is required.

NOTE:  Synchronization makes sure that source tables and their related alias tables have the same column definitions. For example, if you delete a column in the source table the column is automatically removed from the alias table.

You cannot delete source tables unless you delete all its alias tables first. You can change the source table of an alias table, if the new source table is a superset of the current source table. However, this could result in an inconsistent repository if changing the source table deletes columns that are being used. If you attempt to do this, a warning message appears to let you know that this could cause a problem and allows you to cancel the action.

NOTE:  Running a consistency check identifies orphaned aliases.

When you edit a physical table or column in online mode, all alias tables and columns must be checked out. The behavior of online checkout uses the following conventions:

• If a source table or column is checked out, all its alias tables and columns will be checked out.
• If an alias table or column is checked out, its source table and column will be checked out.
• The checkout option is available for online repositories (if not read-only) and for all source and alias tables and columns.

Alias tables inherit some properties from their source tables. A property that is proxied is a value that is always the same as the source table, and cannot be changed. If the source table changes its value for that particular property, the same will be applied on the alias table.

The following is a list of the properties that are proxied:

• IsCacheable (the inherited property can be overridden)
• CacheExpiry (the inherited property can be overridden)
• Row Count
• Last Updated
• Table Type
• External Db Specifications

The following is list of the properties that are not proxied:

• Name
• Description
• Display Folder Containers
• Foreign Keys
• Columns (tables don't share columns, ever. Aliases and sources have distinctly different columns that alias each other)
• Table Keys
• Complex Joins
• Source Connection Pool
• Polling Frequency
• All XML attributes