Characteristic Relationships
Characteristic relationships are used to define a relationship between characteristics with matching contents. You can use characteristic relationships to define rules for checking permitted combinations of characteristic values for each InfoProvider, which is suitable for planning. 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).
An InfoProvider can either be used as a storage for transaction data for planning, or it can be used for modeling the permitted combination of characteristics. We recommend that you do not mix these roles.
If you use a DataStore object for direct updates in planning mode, in order to store permitted characteristic combinations, this has the advantage that you can configure this DataStore object in an input-ready query directly.
You should make sure that you do not mix these InfoProvider roles for the storage of plan data and for the storage of plan data rules. However, if these roles are mixed during a user session, then the following rules apply:
- If an InfoProvider named A is used as the InfoProvider for the planning, other InfoProviders, which use A in a characteristic relationship, are not input-ready.
- If the InfoProvider A is used first in a characteristic relationship and then used as an InfoProvider for planning, the planning provider is not input-ready.
- If the InfoProvider A is used in a MultiProvider or CompositeProvider as a PartProvider and used in a characteristic relationship of a different PartProvider at the same time, the PartProvider A is not input-ready.
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 an InfoProvider, which is suitable for planning. The system applies the characteristic relationships to all planning-relevant InfoProviders that reference this InfoProvider.
Every 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 real-time InfoCube and for the local provider in the BW workspace) 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 suitable for planning InfoProviders. 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. Therefore the hierarchy cannot contain the same leaf or 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, for a DataStore object for direct updates in planning mode, or for a local provider in BW Workspace. A characteristic relationship is made up of a set of relations (steps), which link characteristics and which 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, to make sure that the relations actually represent the smallest unit of the characteristic relationships.
At runtime, the system determines which relations of the characteristic relationships are used in the InfoProviders relevant for planning.
Combination check: A relation is only used in an aggregation level if every characteristic of the relation occurs on 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 be used as sources in the subsequent steps. 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:
Type |
More Information |
|---|---|
Attribute |
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. |
Hierarchy |
All characteristics that you set flagged as External Characteristics in Hierarchy are available as source or target characteristics in the InfoObject maintenance screen. 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. |
DataStore |
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; the restricted part is then used for the combination check or derivation. The restrictions can be parameterized with variables that must be replaceable without a dialog box. We recommend that you use only small DataStore objects (with few characteristics and few records). |
Exit |
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'. Then you only need 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 in the comments of the template class: 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. However, since Profit Center can be derived from Cost Center, the reverse situation produces an invalid combination.
For more information on defining characteristic relationships in Planning Modeler, see Defining Characteristic Relationships.