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.
If you use a DataStore object for direct updates in planning mode or a DataStore object (advanced) with the modeling property "Direct Update”, in order to store permitted characteristic combinations, this has the advantage that you can configure this DataStore object in an input-ready query directly.
We advise not to mix these InfoProvider roles for the storage of plan data and for the storage of plan data rules. If these roles are mixed during a user session however, 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 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 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, PartProvider A is not input-ready.
If characteristic relationships are defined for the attributes or hierarchies of characteristics, the system proposes the attributes and hierarchies created in the BW system for a characteristic.
Characteristic relationships are created for a basis InfoProvider suitable for planning. The system then applies the characteristic relationships to all planning-relevant InfoProviders that reference this basis 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 a basis InfoProvider that is suitable for planning. The defined characteristic relationships also take effect in MultiProviders or CompositeProviders where planning-relevant basis InfoProviders are used.
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 basis InfoProvider.
In characteristic relationships of type hierarchy, the target characteristic must be contained in the selected hierarchy and in the planning-relevant basis 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 the following DataStore objects are permitted:
DataStore object of type standard DataStore object, write-optimized DataStore object or DataStore object for direct writing, on condition that planning mode is set.
DataStore object (advanced) All types are supported as long as the DataStore object has a unique key and does not have modeling property "All Characteristics are Key, Reporting on Union of Inbound and Active Table".
Definition of a characteristic relationship
You can create characteristic relationships are created for a basis InfoProvider that is suitable for planning. 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. New rows in input-ready queries are an exception: The system tries to use derivations to fill characteristic values for other characteristics from known characteristic values. Derivations are only performed for records in the planning-relevant basis 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 basis 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). If the With Subsets flag is set, the relation is also applied if there is a non-empty subset of characteristics of the relation in the aggregation level. In this case, the relation defines precisely the combination of the DataStore object as valid that arises from projection of the records of the DataStore object to the subset. We recommend either including all characteristics in the key of the DataStore object or setting these with a single value as a restriction in the relation. 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. |
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. You then only have to implement methods CHECK, DERIVE, and CREATE. Class CL_RSPLS_CR_EXIT_BASE itself can be run directly, but does not execute an action. For more information, see the documentation about the attributes and values of the class in transaction SE24. If you want to buffer access to data methods that have already been read in methodd CHECK, DERIVE, CREATE, you can pass this task onto the system and do not have to implement it in this exit. To do this, you go to CONSTRUCTOR in the exit class and set attribute N_USE_EXTERNAL_BUFFER in interface IF_RSPLS_CHAR_RELATION. Note that you should always implement method CREATE, as the system always calls this method if combinations should be created on the basis of the characteristic relationships. This is the case for example in input-ready queries (Access Type for Result Values, input help in dynamic filters or in new rows) and in certain planning function types. |
As well as the characteristic relationships listed above, characteristic relationships for BW time characteristics are also permanently activated in the system.
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.
The special combinations listed in the example above with the initial values are known as automatically valid combinations. In the case of relations of type Exit, methods CHECK and DERIVE are not called for automatically valid combinations. The system still creates the automatically valid combinations, even if these are not returned in method CREATE. To prevent this from happening in a characteristic relationship, you can set the EXCL # = X flag. In this case, methods CHECK and DERIVE are also called for automatically valid combinations. The system does not add the automatically valid combinations to combinations created in CREATE.
Note that characteristic relationhips do not act as a further implicit filter for the transaction data to be read. The system reads the transaction data specified by the filter of the query or planning function (regardless of whether this is valid or invalid according to the characteristic relationship) and then possibly also creates further combinations in accordance with the rules described above.