Start of Content Area

Component documentation Hierarchies  Locate the document in its SAP Library structure


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

Hierarchy type


Hierarchy definition for characteristics

Characteristic hierarchy

Tree-like structure for the characteristic values for a characteristic. Characteristic hierarchies are stored in their own data tables. Like master data, they can be used in all InfoProviders.

Example: Hierarchy using cost centers that are assembled in cost center groups.

Specification of hierarchical structures in InfoCube modeling

In the dimensions of an InfoCube


Example: Time dimension. The InfoObjects 0CALDAY, 0CALMONTH, and 0CALYEAR create a hierarchy already with their definition.

Example: 04.09.2003 04.2003 2003

Specification of hierarchical structures in InfoCube maintenance

In the characteristic attributes

Example: The InfoObjects 0MATERIAL, 0MATL_GROUP, 0MATL_TYPE, and 0IND_SECTOR create a hierarchy already with their definition.

In order to be able to use attributes in the query as hierarchy levels, they have to be defined as navigation attributes.

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


Furthermore, it is possible to organize the structure elements hierarchically in the query definition. For these functions, no hierarchies are necessary for characteristics.

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

You can find additional information about the functions Structures with Hierarchical Display and Display as Hierarchy (Universal Display Hierarchy) for the BEx Analyzer under Working with Hierarchies.

You can use the function Display as Hierarchy to model hierarchical structures in the table of those types that are displayed as being the same in the query.

The subject of the following sections is exclusively the maintenance of characteristic hierarchies.


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

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

We do not recommend coding such independent dimensions in one artificial characteristic to define characteristic hierarchies and to use these in reporting to display the different views. Such a procedure has the following drawbacks:

         The hierarchies are unnecessarily large. In doing so, the performance in reporting is impaired. (A hierarchy can include, at most, 50,000 – 100,000 leaves, see Creating Hierarchies.)

         Cross-application change runs occur too frequently (see Adjusting Hierarchy and Attribute Changes).

Characteristic hierarchies offer you options to create queries for reporting. In the Query Designer you can set characteristic hierarchies in the following ways:

        As a presentation hierarchy for a characteristic, if this needs to be hierarchically displayed (see Characteristic Properties)

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


In the InfoObject maintenance, you have to specify if a characteristic can have hierarchies (see Creating InfoObjects: Characteristic). Such a characteristic 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 succeed their hierarchies. A hierarchy basic characteristic can have as many hierarchies as you want.


An example of a hierarchy basic characteristic is 0COSTCENTER.

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


Loading Hierarchies

You can load characteristic hierarchies into your BW system:

        From a source system

        Using the scheduler for the Administrator 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 hierarchy size influences the performance (see Creating Hierarchies).

Editing Hierarchies

In the 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

In order to be able to use hierarchies in reporting, you have to then activate your hierarchies (see Editing Hierarchies).

For time characteristics the BW system has already generated all meaningful hierarchies. From the complete list of suggestions, you need to activate a meaningful selection (see Activating Virtual Time Hierarchies).

Adjusting hierarchy changes

If you create or load new hierarchies, you also need to create the corresponding aggregates. If you change a hierarchy or activate a changed hierarchy, all existing aggregates are automatically adjusted (see Adjusting Hierarchy and Attribute Changes).



End of Content Area