Levels get created when a dimension is created using the Dimension Wizard, Editor or the Cube Editor. The levels can then be maintained and their properties can be set. Measures can be created after the cubes are created. The relationship between the levels, members of a calendar dimension can be illustrated as under:
Levels can be defined in three different ways depending on the variety of the dimension in which the level is defined. In regular dimensions the user can select a dimension from the dimension table to supply the members of the level. In parent child dimensions a distinction needs to be made between the level object and a level in the hierarchy. It contains only one level object but the hierarchy of the dimension usually contains multiple levels. Therefore, it is necessary to select two columns from the dimension table. One column will identify the members of the dimension and the other column will identify the parents of the members. The column that contains the member identifiers supplies all the members of the dimension. In a virtual dimension a member property is selected from another dimension or column in the table of another dimension. This column or member property supplies the members of the level.
The Member Key Column property controls the identification of members. The order of the levels in the dimension’s definition, are controlled by the vertical positions of members within the dimension’s hierarchy in regular or virtual dimensions. The vertical order is matched in the levels’ order in the hierarchy. The member’s horizontal position is determined by the level in which it is included.
In parent-child dimensions the horizontal and vertical positions of the members are defined differently as only a single level can be defined. The Parent key Column and the Root Member If defines the vertical positions and the order by property defines the horizontal position.
The (All) level is a special level that is defined as the highest level in the hierarchy. It contains a single member whose value is the aggregation of the values of the members in the immediately subordinate level.
Levels are subordinate to dimensions in the database or cube. They may be derived from or included in the shared or private dimensions or cubes in the database. Member properties are subordinate to levels.
Analysis Manager identifies levels using icons containing small squares. The number of squares in the icon indicates the level’s position in the dimension definition.
The (All) level icon is displayed only in dialog boxes as
Parent-Child Dimensions
Dimensions which are specially designed to support self referencing dimension tables in data warehouses are called parent child dimensions. Unlike regular dimensions, the level structure does not depend on the number of columns chosen from the underlying dimension tables and the number of columns mapped to a level in the dimension. Two columns from the underlying dimension table can define relationships among the members of the dimension. A single column supplies the unique identifier of the referenced member, and the other column supplies the unique identifier of the parent for the referenced member. As a result an unbalanced hierarchy is produced. An example of an unbalanced hierarchy is produced below.
Employee ID | Name | Parent Employee ID |
1 | Jacob | |
2 | Elaine | 1 |
3 | Jane | 2 |
4 | James | 3 |
5 | Elizabeth | 4 |
6 | Harry | 5 |
Note that all the records do not have a parent employee ID and one record must be at the top. The topmost record or root member is determined by Analysis Services in four ways using the Root Member If property.
Parent Child dimensions also support ragged hierarchies using the Skipped Levels Column property. The property must contain the name of a column in the dimension table that stores the number of skipped levels between the referenced member and its parent member.
The write enablement of the parent child dimension makes it a changing dimension. The hierarchy or properties of members can be changed directly using Analysis Services. This feature is useful in rapid development scenarios or when an established data warehouse does not exist.
The limitations of a Parent Child dimension are that they do not support huge dimensions as they use MOLAP storage. As a result they cannot also support real-time OLAP.
