Show TOC

Characteristic RelationshipsLocate this document in the navigation structure


Characteristic relationships are used to define a relationship between characteristics with matching contents. You can use characteristic relationships to define rules to check permitted combinations of characteristic values for each real-time InfoCube or each DataStore object for direct updates in planning mode. You can also define rules for the system to use to derive values from one characteristic for another. This is useful for example if you want the derivable characteristics to be available for further analysis.

You can define characteristic relationships for the master data of a characteristic (type attribute), a hierarchy (type hierarchy), a DataStore object (type DataStore) or an exit class (type exit).

Unlike an InfoCube, a DataStore object for direct updates in planning mode has a key. Using BW-integrated planning, you can add or change data records. In each case, the key needs to be filled. Characteristic relationships can be used to derive key fields from other characteristics; this avoids the need for every aggregation level to always contain all the characteristics of the key.


If you define characteristic relationships for the attributes or hierarchies of characteristics, the system proposes the attributes or hierarchies that you created in the BW system for a characteristic (see Tab Page: Attributes, Tab Page: Hierarchy and Hierarchy).

Characteristic relationships are created for a real-time InfoCube or a DataStore object for direct updates in planning mode. The system applies the characteristic relationships to all planning-relevant InfoProviders that reference this InfoProvider.

Each input-ready query and planning function automatically takes the characteristic relationships into account:

  • In an input-ready query, cells for invalid characteristic combinations are not input ready, and new data records with invalid characteristic combinations cannot be created.

  • Planning functions use the characteristic relationships to constantly check whether new characteristic combinations are valid. If it finds invalid combinations, the system produces an error message.

The system derives the characteristics when it identifies the delta records in the delta buffer (for the InfoCube) or in the after image buffer (for the DataStore object). Possible source characteristics include characteristics in the planning-relevant InfoProvider that are filled by characteristics from the relevant aggregation levels. If characteristic relationships are changed, the data records in the planning-relevant InfoProvider might also have to be adapted to the new structure. You use the Reposting Characteristic Relationships planning function for this purpose.


Before you can define characteristic relationships, the following prerequisites must be met:

  • The InfoProvider must be a real-time InfoCube or a DataStore object for direct updates in planning mode. The defined characteristic relationships also take effect in MultiProviders where planning-relevant InfoProviders are used. More information: InfoProviders.

  • In characteristic relationships of type attribute, the target characteristic must be defined as an attribute of the basic characteristic and it must be contained in the planning-relevant InfoProvider.

  • In characteristic relationships of type hierarchy, the target characteristic must be contained in the selected hierarchy and in the planning-relevant InfoProvider. The hierarchy is mainly intended for modeling a derivation relationship; thus the hierarchy cannot contain a leaf or an inner node more than once. Link nodes are also not permitted.

  • With characteristic relationships of type DataStore, only standard DataStore objects are permitted. You can use all the managing and monitoring methods that are available in the Data Warehousing Workbench.


Definition of a Characteristic Relationship

You can create characteristic relationships for a real-time InfoCube or a DataStore object for direct updates in planning mode. A characteristic relationship is made up of a set of relations (steps) that link characteristics and are numbered sequentially. Each of these relations links a set of characteristics. These relations represent the smallest units of a characteristic relationship.

Behavior of Combination Checks With and Without Derivation

You can only use relations to check characteristic combinations or derive characteristics. You specify this behavior when defining a relation. You can link several relations of type Derivation if the targets of one relation are the sources of another relation. Redundancy should be avoided here so that the relations actually represent the smallest unit of the characteristic relationships.

At runtime, the system determines the relationships in the planning-relevant InfoProviders that are used.

  • Combination check: A relation is only used in an aggregation level if every characteristic of the relation occurs in the aggregation level. With derivations, these are the source and target characteristics. In this case, no characteristics are derived, and the system just performs a combination check.

  • Characteristic derivation: Derivation is not performed in an aggregation level. Derivation is only performed for records in the planning-relevant InfoProvider. The system first determines the set (S) of characteristics that are filled by the relevant aggregation level. If all the source characteristics are in set S, the system applies the derivation relations in the next step. The target characteristics of these derivations can then serve as sources in the steps that follow. This means that the system performs the maximum possible derivation in the planning-relevant InfoProvider. If previously derived characteristic values are changed again in subsequent steps, the derivation is incorrect. The system posts an error message.

Types of Characteristic Relationships

The following types of characteristic relationships exist:


More information


You can select an attribute of the basic characteristic as the target characteristic (characteristic currency is an attribute of characteristic controlling area for example).

The existing combinations of characteristics and attribute values are always interpreted as valid combinations.


Characteristics are available as source or target characteristics if you marked them as External Characteristics in Hierarchy in InfoObject maintenance. In addition to the hierarchy basic characteristic, the hierarchy must include at least one other characteristic.

Only one characteristic is permitted as a source and/or target characteristic (higher-level characteristics are not counted in compound characteristics).

The permitted combinations are taken from the hierarchy structure. A hierarchy can be used in multiple relations: in step one, you derive a characteristic on the next level up from the hierarchy basic characteristic; in the second step you take the derived characteristic and derive the characteristic on the next level.

The hierarchies can be parameterized with suitable variables in accordance with the property of the hierarchy.


The data records located in the DataStore define the valid characteristic combinations and are used for characteristic derivation.

Only combination check: You can select all InfoObjects from the DataStore object (except for key figures).

With Derivation: You have to select the keys of the DataStore object as source characteristics.

Target characteristics can be InfoObjects from the data part of the DataStore object (except for key figures).

The keys for the DataStore objects can be restricted in any case; the restricted part is then used for the combination check or derivation. The restrictions can be parameterized with variables that must be replaceable without the dialog.

We recommend that you use only small DataStore objects (with few characteristics, few records).


The valid characteristic combinations and derivable characteristic values are defined by the customer-specific implementation of the specified exit class.

The exit class must implement interface IF_RSPLS_CR_EXIT. Only these types of classes can be edited in maintenance. We recommend deriving your class from the example class CL_RSPLS_CR_EXIT_BASE. You then only have to implement methods 'CHECK', 'DERIVE' and 'CREATE'. Class 'CL_RSPLS_CR_EXIT_BASE' is executable, but does not execute any actions.

Note the example source code given in the template class too: An infrastructure for buffering can be provided here.


As well as the characteristic relationships listed above, characteristic relationships for BW time characteristics are also permanently activated in the system (see Characteristic Relationships for Time Characteristics).

The initial characteristic value # not assigned) has a special role in a relation. Characteristics that do not occur in an aggregation level (and cannot be derived) are updated with the initial value.

  • Combination check without derivation:

There is a relation between the characteristics Product and Assortment; usually there is no derivation relationship between the two. In aggregation levels with Product but without Assortment, Assortment is therefore updated with the initial value. These types of combinations are always valid and they cannot be forbidden. This also applies to combinations with the initial value for Product.

  • Combination check with derivation:

There is a relation between the characteristics Cost Center and Profit Center; Profit Center can be derived from Cost Center. In an aggregation level that contains Profit Center but not Cost Center, Cost Center is also updated with the initial value. Combinations of this sort cannot be forbidden. Since Profit Center can be derived from Cost Center however, the reverse situation produces an invalid combination.


For more information on defining characteristic relationships in Planning Modeler, see Defining Characteristic Relationships.