Working with Logical Dimensions 9-13
1.
In the Administration Tool, open a repository in online mode.
2.
Right-click one or more business models and dimension objects, and select Estimate Levels
.
3. In the Check Out Objects dialog, click Yes to check out the objects that appear in
the list.
If you click No, the action terminates because you must check out items to run Estimate Levels.
In the Administration Tool dialog, a list of the dimension level counts and any errors or warning messages appear.
When you check in the objects, you can check the global consistency of your repository.
Creating and Managing Dimensions with Parent-Child Hierarchies
A parent-child hierarchy is a hierarchy of members that all have the same type. This contrasts with level-based hierarchies, where members of the same type occur only at
a single level of the hierarchy.
This section contains the following topics:
■
About Parent-Child Hierarchies
■
Creating Dimensions with Parent-Child Hierarchies
■
Defining Parent-Child Relationship Tables
About Parent-Child Hierarchies
The most common real-life occurrence of a parent-child hierarchy is an organizational reporting hierarchy chart, where the following all apply:
■
Each individual in the organization is an employee.
■
Each employee, apart from the top-level managers, reports to a single manager.
■
The reporting hierarchy has many levels. These conditions illustrate the basic features that define a parent-child hierarchy,
namely:
■
A parent-child hierarchy is based on a single logical table for example, the Employees table
■
Each row in the table contains two identifying keys, one to identify the member itself, the other to identify the parent of the member for example, Emp_ID and
Mgr_ID
Figure 9–4 shows an example of a multi-level parent-child hierarchy.
9-14 Metadata Repository Builders Guide for Oracle Business Intelligence Enterprise Edition
Figure 9–4 Multi-Level Parent-Child Hierarchy
The following table shows how this parent-child hierarchy could be represented by the rows and key values in an Employees table.
You can expose logical dimensions with parent-child hierarchies to Oracle BI Answers users by creating presentation hierarchies 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. This section contains the following topics:
■
About Levels and Distances in Parent-Child Hierarchies
■
About Parent-Child Relationship Tables
■
About Parent-Child Hierarchies Populated with Preaggregated Data
About Levels and Distances in Parent-Child Hierarchies
Unlike the situation with level-based hierarchies, all the dimension members of a parent-child hierarchy occur in a single logical column. In a parent-child hierarchy, the
parent of a member is in another row in the same logical column, pointed to by the parent key. This is unlike a level-based hierarchy, where the parent of a member is in a
different logical column in the same row. In other words, navigation in a parent-child hierarchy follows data values, while navigation in a level-based hierarchy follows the
metadata structure.
In level-based hierarchies, each level is named, and occupies a position in the hierarchy that corresponds to a real-word attribute or category that is deemed useful
for analysis. Unlike level-based hierarchies, where the number of levels is fixed at design time, there is no limit to the depth of a parent-child hierarchy, and the depth
can change at run time due to new data.
Every Oracle BI Server parent-child hierarchy has two system-generated entities, Total and Detail, that are automatically defined for each parent-child hierarchy
Emp_ID Mgr_ID
Andrew null
Barbara Andrew
Carlos Andrew
Dawn Barbara
Emre Barbara
Working with Logical Dimensions 9-15
when the logical dimension is created. The Detail entity contains all the hierarchy members.
These two system-generated entities are different from the implicit, inter-member levels between ancestors and descendants in a parent-child hierarchy. These implicit
levels are referred to as parent-child hierarchical levels in this section.
Closely associated with levels is the concept of distance in parent-child hierarchies. The distance of one member from another is the number of parent-child hierarchical
levels from the member to an ancestor or to a descendant. For example, the distance from a member to its parent is always 1, and the distance from Andrew to Emre in
Figure 9–4 is 2.
About Parent-Child Relationship Tables
In relational tables, the relationships between different members in a parent-child hierarchy are implicitly defined by the identifier key values in the associated base
table.
However, for each Oracle BI Server parent-child hierarchy defined on a relational table, you must also explicitly define the inter-member relationships in a separate
parent-child relationship table.
The parent-child relationship table must include four columns, as follows:
■
A column that identifies the member
■
A column that identifies an ancestor of the member
■
A distance column that specifies the number of parent-child hierarchical levels from the member to the ancestor
■
A leaf column that indicates if the member is a leaf member 1=Yes, 0=No The column names can be user defined. The data types of the columns must satisfy the
following conditions:
■
The member and ancestor identifier columns have the same data type as the associated columns in the logical table that contains the hierarchy members.
Note that the example shown in Table 9–1
uses text strings for readability, but you normally use integer surrogate keys for member_key and ancestor_key, if they
exist in the source dimension table.
■
The distance and leaf columns are INTEGER columns. Note the following about the rows in a parent-child relationship table:
■
Each member must have a row pointing at itself, with distance zero.
■
Each member must have a row pointing at each of its ancestors. For a root member, this is a termination row with null for the parent and distance values.
Table 9–1 shows an example of a parent-child relationship table with rows that
represent the inter-member relationships for the employees shown in Figure 9–4
.
Note: The ancestor may be the parent of the member, or a
higher-level ancestor.
9-16 Metadata Repository Builders Guide for Oracle Business Intelligence Enterprise Edition
Typically, you generate scripts to create and populate the parent-child relationship table through a wizard that you can invoke when you define the parent-child
hierarchy. Note the following about the create and load scripts:
■
You run the create script only once, to create the parent-child relationship table in the data source.
■
You must run the load script after each time the data changes in the dimension table. Because of this, you typically call the load script in your ETL processing. The
load script reloads the entire parent-child relationship table; it is not incremental.
If you do not choose to use the wizard, then you must create the parent-child relationship table manually and then import it into the Physical layer before
associating it with the parent-child hierarchy. In this latter case, it is also your responsibility to populate the table with the data required to describe the
inter-member relationships in the parent-child hierarchy.
About Parent-Child Hierarchies Populated with Preaggregated Data
Some parent-child hierarchies contain preaggregated data that is populated for all nodes of the hierarchy. For example, a root node might be populated with the
aggregation of the data for all of its descendent nodes. It is important to ensure that queries do not aggregate the members from this dimension to avoid erroneous results.
To correctly model this type of parent-child hierarchy, you must still create a parent-child relationship table to support hierarchical filter functions like IsAncestor
and IsDescendant. However, you can join the parent-child dimension table directly with the fact table rather than joining through the parent-child relationship table.
Doing so ensures that the preaggregated member value is returned, rather than rolling up all the descendants.
Table 9–1 Example Parent-Child Relationship Table
Member_Key Ancestor_Key
Distance Isleaf
Andrew Andrew
Barbara Barbara
Carlos Carlos
Dawn Dawn
Emre Emre
Andrew null
null Barbara
Andrew 1
Carlos Andrew
1 1
Dawn Barbara
1 1
Dawn Andrew
2 1
Emre Barbara
1 1
Emre Andrew
2 1
Note: Do not modify the parent-child relationship table script to only
include the self rows, because doing so would break the IsAncestor and IsDescendant functions.
Working with Logical Dimensions 9-17
To achieve the correct aggregation for dimensions of this type, you must first determine what you want to see as a grand total when the parent-child hierarchy is
aggregated. For example, assume that your hierarchy contains a single root member, and you want to display the preaggregated value for this root member. In this case,
you first create an additional fact logical table source mapped at the Total level of the parent-child hierarchy. Then, in the logical table source, create a WHERE clause filter
that selects only the root member.
With this model in place, for queries that are at the Total level of the parent-child hierarchy, the Oracle BI Server selects the aggregate logical table source and applies
the root member WHERE clause filter. For queries that are at the Detail level, the Oracle BI Server selects the detailed logical table source and returns the preaggregated
member values. In either case, it does not matter how the aggregation rule is set, because there is a preaggregated source at each level.
Note that this approach only works if the queries are either at the Total or Detail level of the parent-child dimension. However, for queries that group by some non-unique
attribute of the parent-child dimension, the aggregation might not be correct. For example, if an Employee dimension has a Location attribute, and a query groups by
Employee.Location, then there will likely be some double counting because an employee often reports to other employees at the same location. Because of this, when
fact tables contain preaggregated member values, you should avoid grouping by non-unique attributes of the parent-child dimension. If grouping by those attributes is
unavoidable, then you should model them as separate dimensions.
Creating Dimensions with Parent-Child Hierarchies
The key elements that you must define for a parent-child hierarchy are the identifier columns for the member and the parent of the member. This basic principle applies to
all parent-child hierarchies, regardless of the data source from which the hierarchy is derived.
Parent-child hierarchies that are based on relational tables must have an accompanying parent-child relationship table. See
About Parent-Child Relationship Tables
for more information.
To create dimensions with a parent-child hierarchy: 1.
In the Business Model and Mapping layer of the Administration Tool, perform one of the following steps:
■
Right-click a business model and select New Object Logical Dimension Dimension with Parent-Child Hierarchy
. Note that this option is only available if there is at least one logical dimension table in the business model
that has no dimension associated with it.
■
Right-click a dimension table that is not associated with any dimension and select Create Logical Dimension, then select Dimension with Parent-Child
Hierarchy .
2.
In the Logical Dimension dialog, in the General tab, type a name for the dimension.
3. Click Browse beside the Member Key field.
