Hierarchies
In SAP Business Warehouse there are different options for modeling hierarchical structures. The following table provides 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: |
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. For a comparison of the three types of hierarchy modeling, see Options for Hierarchical Modeling.
In addition, you can organize the elements of a structure hierarchically in the 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 functions Structures with Hierarchical Display and Display as Hierarchy ( Universal Display Hierarchy) for the BEx Analyzer, see Working with Hierarchies in the BEx Analyzer documentation.
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 recommend that you do not 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 no more than 50,000 -100,000 leaves, see Creating Hierarchies.)
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 presentation hierarchy for a characteristic, if this needs to be displayed as a hierarchy (see Characteristic Properties)
As a selection for specific characteristic values, if a characteristic needs to be restricted to a hierarchy or to hierarchy nodes (see Restricting Characteristics: Hierarchies)
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).
Loading hierarchies
You can load characteristic hierarchies into your BW system:
From a source system
Using the scheduler in the Data Warehousing Workbench (see Loading Hierarchies)
Using a process chain (see Loading Hierarchies Using a Process Chain)
from or into another BW system
Using the data mart interface. You cannot transport hierarchies into another BW system because hierarchies are data (see Using the Data Mart Interface).
Creating Hierarchies
You can create characteristic hierarchies in your BW system.
Note that the size of the hierarchy influences performance (see Creating Hierarchies).
Editing Hierarchies
In hierarchy maintenance for the BW 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 BW 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 also modifies BW Accelerator indexes during hierarchy and attribute change runs (see System Response Upon Changes to Data).
Modeling Data Flows for Hierarchies with Direct Access
The structure of a hierarchy with direct access is read in the source system at runtime. As with all other hierarchies, you can also use a hierarchy with direct access in the query (see Modeling Data Flows for Hierarchies with Direct Access).