Hierarchies 

Purpose

In SAP NetWeaver Business Intelligence there are different options for modeling hierarchical structures. The following table gives you an overview:

Hierarchy Type	Description
Hierarchy definition for characteristics
Characteristic hierarchy	Characteristic values of a characteristic in a tree structure. Characteristic hierarchies are stored in their own data tables. Like master data, they can be used in all InfoProviders. Example: Hierarchy of cost centers that are assembled in cost center groups.
Determining hierarchical structures in InfoCube modeling
In the dimensions of an InfoCube	Example: Time dimension. The definitions of InfoObjects 0CALDAY, 0CALMONTH, and 0CALYEAR form a hierarchy. Example: 04.09.2003 → 04.2003 → 2003
Specification of hierarchical structures in InfoCube maintenance
In the attributes of a characteristic	Example: The definitions of InfoObjects 0MATERIAL, 0MATL_GROUP, 0MATL_TYPE, and 0IND_SECTOR form a hierarchy. To use attributes in the query as hierarchy levels, they have to be defined as navigation attributes.

The most appropriate type of modeling depends on the individual case. The modeling types differ, for example, with regard to how data is stored in the source system, performance, authorization checks, the use of aggregates, or whether parameters can be set for the query. You can find a comparison of the three types of hierarchy modeling under Options for Hierarchical Modeling.

In addition, you can organize the elements of a structure hierarchically in query definition. Hierarchies for characteristics are not required for these functions.

You can display one or both axes (rows and columns) as a hierarchy.

For more information about the Structures with Hierarchical Display and Display as Hierarchy (Universal Display Hierarchy) functions for the BEx Analyzer, see Working with Hierarchies.

You can use the Display as Hierarchy function to display the different ways of modeling hierarchical structures (named in the table above) in essentially the same format in the query.

The following sections deal exclusively with the maintenance of characteristic hierarchies.

Avoid grouping properties that belong to semantically different “dimensions” such as “Time”, “Product”, “Customer”, and “Countries” in one artificial characteristic.

Example: Distribution Channel and Product Group in artificial characteristic Profit Center.

If you want to define characteristic hierarchies to use in reporting to display different views, we do not recommend that you code separate dimensions in one artificial characteristic. This has the following drawbacks:

●        The hierarchies are unnecessarily large. System performance is negatively affected during reporting. (A hierarchy can include at most 50,000 – 100,000 leaves, see Creating Hierarchiessap.)

●        Comprehensive change runs occur too frequently.

Characteristic hierarchies also allow you to create queries for reporting in several ways. In the Query Designer you can use characteristic hierarchies in the following ways:

●      As a display hierarchy for a characteristic, if this needs to be displayed as a hierarchy (see Characteristic Propertiessa)

●      As a selection for specific characteristic values, if a characteristic needs to be restricted to a hierarchy or to hierarchy nodes (see Restricting Characteristics: Hierarchiessa)

Integration

In InfoObject maintenance you have to specify whether a characteristic can have hierarchies (see Creating InfoObjects: Characteristic). A characteristic of this type is called a hierarchy basic characteristic.

Hierarchies have to (and can only) be created for hierarchy basic characteristics. All characteristics that reference a hierarchy basic characteristic automatically inherit the corresponding hierarchies. A hierarchy basic characteristic can have as many hierarchies as required.

An example of a hierarchy basic characteristic is 0COSTCENTER.

In InfoObject maintenance, the properties of all the hierarchies for the respective characteristic are defined (see Hierarchy Properties).

Features

Loading hierarchies

You can load characteristic hierarchies into your BI system:

●      From a source system

○       Using the scheduler in the Data Warehousing Workbench (see Loading Hierarchiess)

○       Using a process chain (see Loading Hierarchies Using Process Chainssa)

●      From or into another BI system

○       Using the data mart interface. You cannot transport hierarchies into another BI system because hierarchies are data (see Using the Data Mart Interfacesap).

Creating hierarchies

You can create characteristic hierarchies in your BI system.

Note that the size of the hierarchy influences performance (see Creating Hierarchies).

Editing hierarchies

In hierarchy maintenance for the BI system, you can change, copy, delete, or set reporting-relevant hierarchy attributes in characteristic hierarchies (see Editing Hierarchies).

Activating hierarchies

To use hierarchies in reporting, you have to activate your hierarchies (see Editing Hierarchies).

The BI system predefines all useful hierarchies for time characteristics. Activate a useful selection from the complete list of proposals (see Activating Virtual Time Hierarchies).

Modifying hierarchy changes

When you create or load new hierarchies you also need to create the corresponding aggregates. When you change a hierarchy or activate a changed hierarchy, all existing aggregates are modified automatically (see System Response Upon Changes to Master Data and Hierarchies).

The system likewise modifies BI accelerator indexes during hierarchy and attribute change runs (see System Response Upon Changes to Data: BI Accelerator Index).