Hierarchy: An Introduction

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. There are two types of logical dimensions: 1. 2. Dimensions with level-based hierarchies (structure hierarchies). 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.

Level-Based Hierarchies A dimension contains two or more logical levels. For example, a Time hierarchy might have three levels for Year, Quarter, and Month. Level-based hierarchies can also contain parent-child relationships. 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. Level-based Dimension hierarchy levels allow: to perform aggregate navigation, to configure level-based measure calculations, users from Dashboard and Answers to drill down from one parent to a child level.

The following are the parts of the 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. 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. 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: Unbalanced (or ragged) hierarchy : A hierarchy in which all the lowest-level members do not 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. For example, a Time hierarchy might have data for the current month at the day level, the previous month's data at the month level, and the previous 5 years' data at the quarter level. This type of hierarchy is also known as an unbalanced hierarchy. 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 certain higher levels. . For example, in the United States, the city of Washington in the District of Columbia does not belong to a state. The expectation is that users can still navigate from the country level (United States) to Washington and below without the need for a state.

Hierarchy with Unbalanced and Skip-Level Characteristics

Parent-Child Hierarchies A parent-child hierarchy is a hierarchy of members that all have the same type.It is a value-based hierarchy Consists of values that define the hierarchy in a parent-child relationship and does not

contain named levels. This contrasts with level-based hierarchies, where members of the same type occur only at a single level of the hierarchy. For example, an Employee hierarchy might have no levels, but instead have names of employees who are managed by other employees. Employees can have titles, such as Vice President. Vice Presidents might report to other Vice Presidents and different Vice Presidents can be at different depths in the hierarchy. 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 eg, 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)

Multi-Level Parent-Child Hierarchy 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 parentchild hierarchy, and the depth can change at run time due to new data.

Creating value based hierarchy in 11g :

Let us consider employees table which has Manager -> Employee relationship and model the same. Steps: 1. Importing the source table(Employees) 2. Creating value based hierarchy in BMM layer a. Define parent(Manager_ID) & child(Employee_ID) columns b. Generate parent -child hierarchy table DDL statements

c. Generate parent child hierarchy table DML statements d. Execute DDL & DML and create hierarchy table and insert data into it 3. Pull the BMM model into presentation layer 4. Run answers and check the output. Make sure Employees table has below structure.

1. Importing Employees table into Physical layer

Finally update the row count and test the database connectivity

2. Create value based hierarchy in BMM layer

Drag employee table twice to the BMM (OBIEE requires star model) as shown below

Rename the columns and do the basic cleanup

Right click on the BMM model and join the Employee and Salary Information.

Now right click on Employees logical table and choose for new parent child hierarchy

Choose the member key (by default it will take the primary key) and parent column as shown in the below screenshot.

Then click ok parent- child settings. This is the place where we are going to generate the DDL & DML scripts which we can use to create and populate the hierarchy table which will be used by BI server to report parent child hierarchies.

Click on new hierarchy table (middle one yellow arrow). If you have already generated hierarchy table then click on the select (red arrow) and choose the table. After clicking new give the name for the DDL and DML scripts. This wizard will create the SQL scripts.

Give name for the hierarchy table

Click next and verify the scripts

After finishing you can see the details are mapped now

After finishing the wizard you can see the HierarchyTable got imported automatically.

Now go to the scripts location and run the DDL & DML scripts and commit the changes via SQL command prompt Update the row count and make sure table got created properly

3. Pull the BMM model to presentation layer and create presentation folders. Make sure that Hierarchy inside the Employees folder is visible.

Now we are done with the metadata definition. Save the RPD and make sure there are no consistency errors. Start the WLS and BI services and make sure all of them are running fine. 4. Running answers and verifying the hierarchy

Before logging into answers lets enable the logging so that we can check the physical SQLs that are getting generated while performing drill downs through hierarchy. Open the RPD in online mode and navigate to Manage->Identity and set the log level for Administrator.

Check in the changes and close the RPD. After logging in since we changed the log level in online mode we have to reload the metadata. Click on Administration on the top right

Then click on Reload files and Metadata

Then go to our Analysis like below

Click ok ValueBasedHierarchy Select the Hierarchy column from Employees and the salary measure from the fact.

Then click on results. We are done and can see the hierarchy information like below.

This output just shows the salary for each employee and their manager information. This result set is not an aggregated salary for each level. Since salary information pertains to each employee salary is not aggregated. If you check the Nquery log BI server generates only one query for the any number of operations. Its fully in memory operation.