8-26 Metadata Repository Builders Guide for Oracle Business Intelligence Enterprise Edition
2.
In the Business Model and Mapping layer, select the fact table and the two dimension tables that are associated with the bridge table Facts, Employee, and
Jobs in our example. Then, right-click the objects and select Business Model Diagram
, and then choose Selected Tables Only. 3.
With the Business Model Diagram displayed, click New Join on the toolbar. Then, select the fact table, and then select the dimension table not currently joined to the
fact table.
4. Click OK in the Logical Join dialog.
Figure 8–9 shows joins between the example logical tables in the Business Model
Diagram.
Figure 8–9 Joins Between the Example Tables in the Business Model Diagram
5.
Double-click the logical table source for the logical table for which you created the logical join Employee in our example.
6. Click the Add button in the upper right corner of the Logical Table Source dialog.
Then, select the bridge table from the Name list Assignment in our example and then click Select.
7. Click the Add button again and select the other associated dimension table Jobs
in our example and then click Select. 8.
Click OK in the Logical Table Source diaog.
Figure 8–10 shows the Logical Table Source dialog for the modified dimension
table source.
Working with Logical Tables, Joins, and Columns 8-27
Figure 8–10 Logical Table Source Dialog for Dimension Table Source
You can now create dimensions based on your logical tables, including both logical tables associated with the bridge table.
8-28 Metadata Repository Builders Guide for Oracle Business Intelligence Enterprise Edition
9
Working with Logical Dimensions 9-1
9
Working with Logical Dimensions
In the Business Model and Mapping layer, a dimension object represents a hierarchical organization of logical columns attributes. One or more logical dimension tables can
be associated with at most one dimension object. Common dimensions might be time periods, products, markets, customers, suppliers, promotion conditions, raw materials,
manufacturing plants, transportation methods, media types, and time of day. Note that dimensions exist in the Business Model and Mapping logical layer and in the
Presentation layer.
In each dimension, you organize logical columns into the structure of the hierarchy. This structure represents the organization rules and reporting needs required by your
business. It also provide the metadata that the Oracle BI Server uses to drill into and across dimensions to get more detailed views of the data.
There are two types of logical dimensions: dimensions with level-based hierarchies structure hierarchies, and dimensions with parent-child hierarchies value
hierarchies. Level-based hierarchies are those in which members are of several types, and members of the same type occur only at a single level. In parent-child hierarchies,
members all have the same type. Oracle Business Intelligence also supports a special type of level-based dimension, called a time dimension, that provides special
functionality for modeling time series data.
Because dimensions for multidimensional data sources are defined in the source, they do not require as much work compared with dimensions in other data sources. For
example, you do not create dimension level keys. A dimension is specific to a particular multidimensional data source it cannot be used by more than one and
cannot be created and manipulated individually. Additionally, each cube in the data source should have at least one dimension and one measure in the Business Model and
Mapping layer.
You can expose logical dimensions to Oracle BI Answers users by creating presentation hierarchy objects that are based on particular logical dimensions.
Creating hierarchies in the Presentation layer enables users to create hierarchy-based queries. See
Working with Presentation Hierarchies and Levels for more information.
Note that you can also expose dimension hierarchies by adding one or more columns from each hierarchy level to a subject area in the Presentation layer. Oracle BI Answers
supports drill-down on these hierarchical columns.
This chapter contains the following topics:
■
Creating and Managing Dimensions with Level-Based Hierarchies
■
Creating and Managing Dimensions with Parent-Child Hierarchies
■
Modeling Time Series Data
9-2 Metadata Repository Builders Guide for Oracle Business Intelligence Enterprise Edition
Creating and Managing Dimensions with Level-Based Hierarchies
Each business model can have one or more dimensions, each dimension can have one or more logical levels, and each logical level has one or more attributes columns
associated with it.
The following sections explain how to create dimensions:
■
About Level-Based Hierarchies
■
Manually Creating Dimensions, Levels, and Keys with Level-Based Hierarchies
■
Automatically Creating Dimensions with Level-Based Hierarchies
■
Populating Logical Level Counts Automatically
About Level-Based Hierarchies
A dimension contains two or more logical levels. The recommended sequence for creating logical levels is to create a Grand Total level and then create child levels,
working down to the lowest level. The following are the parts of a dimension:
■
Grand Total level. A special level representing the grand total for a dimension.
Each dimension can have just one Grand Total level. A Grand Total level does not contain dimensional attributes and does not have a level key. However, you can
associate measures with a Grand Total level. The aggregation level for those measures will always be the grand total for the dimension.
■
Level. All levels, except the Grand Total level, need to have at least one column.
However, it is not necessary to explicitly associate all of the columns from a table with logical levels. Any column that you do not associate with a logical level is
automatically associated with the lowest level in the dimension that corresponds to that dimension table. All logical columns in the same dimension table have to
be associated with the same dimension.
■
Hierarchy. Each dimension contains one or more hierarchies. All hierarchies must
have a common leaf level and a common root all level. For example, a time dimension might contain a fiscal hierarchy and a calendar
hierarchy, with a common leaf level of Day. Day has two named parent levels called Fiscal Year and Calendar Year, which are both children of the All root level.
In the Business Model and Mapping layer, logical hierarchies are not defined as independent metadata objects, unlike hierarchies in the Presentation layer. Rather,
logical hierarchies exist implicitly through the relationships between levels.
■
Level keys. Each logical level except the topmost level defined as a Grand Total
level must have one or more attributes that compose a level key. The level key defines the unique elements in each logical level. The dimension table logical key
has to be associated with the lowest level of a dimension and has to be the level key for that level.
A logical level can have multiple level keys. When that is the case, specify the key that is the primary key of that level. All dimension sources which have an
aggregate content at a specified level need to contain the column that is the primary key of that level. Each logical level should have one level key that is
displayed when an Oracle BI Presentation Services user clicks to drill down. This may or may not be the primary key of the level. To set the level key to display,
select the Use for display option in the Level Key dialog.
Be careful using level keys such as Month whose domain includes the values January, February, and so on or in other words, values that are not unique to a
Working with Logical Dimensions 9-3
particular month, repeating every year. To define Month as a level key, you also need to include an attribute from a higher level for example, Year. To add Year,
click Add in this dialog and select the logical column from the dialog that is presented.
Level keys should be meaningful business keys like Month_name=2010 July rather than generated surrogate keys like time_key=1023793, because surrogate
keys are physical artifacts that only apply to a single instance of a source table. The business name, in contrast, can map to any physical instance for that logical
column. For example, month_name might map to a detailed table, an aggregate table from an aggregate star, and a column in a federated spreadsheet. Note that
the Physical layer still uses the surrogate keys in the joins, so there is no performance or flexibility penalty for using business keys in the business model.
■
Time dimensions and chronological keys. You can identify a dimension as a time
dimension. At least one level of a time dimension must have a chronological key. The following is a list of some guidelines you should use when setting up and
using time dimensions:
– At least one level of a time dimension must have a chronological key. See
Selecting and Sorting Chronological Keys in a Time Dimension for more
information.
– All time series measures using the AGO, TODATE, and PERIODROLLING
functions must be on time levels. AGO, TODATE, and PERIODROLLING aggregates are created as derived logical columns. See
About Time Series Functions
for more information.
– AGO, TODATE, and PERIODROLLING functionality is not supported either on
fragmented dimensional logical table sources, or on fact sources fragmented on the same time dimension. Fact sources may be fragmented on other
dimensions.See About Time Series Functions
for more information.
■
Unbalanced or ragged hierarchy. An unbalanced or ragged hierarchy is a
hierarchy where the leaves members with no children do not necessarily have the same depth. For example, a site can choose to have data for the current month
at the day level, previous months data at the month level, and the previous 5 years data at the quarter level.
User applications can use the ISLEAF function to determine whether to allow drilldown from any particular member. See
ISLEAF for more information.
A missing member is implemented in the data source with a null value for the member value. All computations treat the null value as a unique child within its
parent. Level-based measures and aggregate-by calculations group all missing nodes together.
Note that unbalanced hierarchies are not necessarily the same as parent-child hierarchies. Parent-child hierarchies are unbalanced by nature, but level-based
hierarchies can be unbalanced also.
■
Skip-level hierarchy. A skip-level hierarchy is a hierarchy where there are
members that do not have a value for a particular ancestor level. For example, in a Country-State-City-District hierarchy, the city Washington, D.C. does not belong
to a State. In this case, you can drill down from the Country level USA to the City level Washington, D.C. and below.
In a query, skipped levels are not displayed, and do not affect computations. When sorted hierarchically, members appear under their nearest ancestors.
9-4 Metadata Repository Builders Guide for Oracle Business Intelligence Enterprise Edition
A missing member at a particular level is implemented in the data source with a null value for the member value. All computations treat the null value as a unique
child within its parent. Level-based measures and aggregate-by calculations group all skip-level nodes together.
Figure 9–1 shows a hierarchy with both unbalanced and skip-level characteristics. For
example, A-Brand 4, B-LOB 3, and Type 5 are unbalanced branches, while skips are present between A-Brand 2 and Type 3, B-LOB 2 and Product 6, and others.
Figure 9–1 Hierarchy with Unbalanced and Skip-Level Characteristics
Using Dimension Hierarchy Levels in Level-Based Hierarchies
Dimension hierarchical levels can be used to perform the following actions:
■
Set up aggregate navigation
■
Configure level-based measure calculations refer to Example 9–1
.
■
Determine what attributes appear when Oracle BI Presentation Services users drill down in their data requests
Manually Creating Dimensions, Levels, and Keys with Level-Based Hierarchies
To create and manage dimension hierarchy levels in level-based hierarchies, perform the tasks described in the following sections:
■
Creating Dimensions in Level-Based Hierarchies
Working with Logical Dimensions 9-5
■
Creating Logical Levels in a Dimension
■
Associating a Logical Column and Its Table with a Dimension Level
■
Identifying the Primary Key for a Dimension Level
■
Selecting and Sorting Chronological Keys in a Time Dimension
■
Adding a Dimension Level to the Preferred Drill Path
Creating Dimensions in Level-Based Hierarchies
After creating a dimension, each dimension can be associated with attributes columns from one or more logical dimension tables and level-based measures from
logical fact tables. After you associate logical columns with a dimension level, the tables in which these columns exist appear in the Tables tab of the Dimension dialog.
To create a dimension with a level-based hierarchy: 1.
In the Business Model and Mapping layer of the Administration Tool, right-click a business model and select New Object Logical Dimension Dimension with
Level-Based Hierarchy .
Note that this option is only available when there is at least one dimension table that has no dimension associated with it.
2. In the Logical Dimension dialog, in the General tab, type a name for the
