Characteristic Relationships 

Use

You use characteristic relationships to link characteristics that have similar content. You can use characteristic relationships to define rules to check permitted combinations of characteristic values for real-time InfoCubes. You can also define rules for the system to use to derive values from one characteristic for another characteristic. 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).

Integration

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

You create characteristic relationships for a real-time InfoCube.

 The system applies the characteristic relationships to all planning-relevant InfoProviders that reference the InfoCube.

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

●      In an input-ready query, this means that cells of invalid characteristic combinations are not input ready and new data records that have invalid characteristic combinations cannot be created.

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

Where possible, the system derives characteristics when it determines the delta records in the delta buffer. Possible source characteristics are characteristics in the real-time InfoCube that are filled by characteristics from the relevant aggregation levels. If characteristic relationships are changed, the data records in the InfoCube have to adapted to the new structure. You use the Reposting Characteristic Relationships planning function for this purpose.

Prerequisites

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

●      The InfoProvider must be a real-time InfoCube. The characteristic relationships defined for a real-time InfoCube are also valid in the MultiProviders that contain the real-time InfoCube. See InfoProvider.

●      In characteristic relationships of type attribute, the target characteristic must be defined as an attribute of the basic characteristic and must itself be contained in the InfoCube.

●      In characteristic relationships of type hierarchy, the target characteristic must be contained in a hierarchy and in the InfoCube. 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.

Features

Defining Characteristic Relationships

You create characteristic relationships for real-time InfoCubes. A characteristic relationship comprises a set of 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 you define a relation. If the targets of one relation are the sources of another relation, you can link several relations of type Derivation. Redundancy should be avoided here so that the relations actually represent the smallest unit of the characteristic relationships.

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

●      Combination check: A relation is only used in an aggregation level if each 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; the system only performs a combination check.

●      Characteristic derivation: Derivation does not take place within one aggregation level. Derivation is only performed for the records of the real-time InfoCube. First the system determines the set S of characteristics that are filled by the relevant aggregation level. If all the source characteristics are included 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. Thus the system performs the maximum possible derivation in the InfoCube. If characteristic values that were already derived are changed again in subsequent steps, the derivation is incorrect. The system produces 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 (for example, the characteristic currency is an attribute of the characteristic controlling area). The existing combinations of characteristics and attribute values are always permitted combinations.
Hierarchy	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 (here the 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 one step, you derive a characteristic that is 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. Depending on the property of the hierarchy, the hierarchies that you use can be parameterized with the appropriate variables.
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 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).
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 the interface 'IF_RSPLS_CR_EXIT'. Only these types of classes are offered for editing in maintenance. We recommend that you derive your own class from the example class 'CL_RSPLS_CR_EXIT_BASE'. You then only have to implement the methods ‘CHECK’, ‘DERIVE’ and ‘CREATE’. The class 'CL_RSPLS_CR_EXIT_BASE' itself can be used directly, but it does not execute an action. Note also the example source code given in the template class; an infrastructure for buffering is provided there, for example.

As well as the characteristic relationships listed above which you can edit, characteristic relationships for BI time characteristics are also active in the system (see Characteristic Relationships for Time Characteristics).

Within a relation, note that the initial characteristic value (# not assigned) plays a special role. 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 that contain Product but not Assortment, Assortment is updated with the initial value. These types of combinations are always valid; they cannot be forbidden. The same applies to combinations that have 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 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.

Activities

...

       1.      You are in the Planning Modeler on the InfoProvider  tab page. Choose the required InfoProvider (type real-time InfoCube). In the lower screen area, the system displays the tab pages Characteristic Relationships, Data Slices and Settings.

       2.      To create or change characteristic relationships for the selected InfoProvider, choose Change.

       3.      You specify whether you want the system to perform combination checks and proposals only, or whether you also want the system to derive the target characteristic from the basic characteristic. For each step, choose with or without derivation.

       4.      Select the type of characteristic relationship.

       5.      Specify the basis of the relationship. This is different for each type of relationship:

○       Attribute: a master-data bearing characteristic

○       Hierarchy: the hierarchy basic characteristic

○       DataStore: a DataStore object

○       Exit: an exit class

       6.      The system shows further settings options depending on the relationship type selected. Depending on the type of step, you select the check characteristics or source and target characteristics.

○       If you are using attribute or hierarchy relationships or DataStore objects, you can select check characteristics.

○       If you are using an exit class, you can select source and target characteristics.

       7.      On the Characteristic Relationships tab page, the system automatically completes your entries. Before you select another InfoProvider or leave the tab page, save the defined characteristic relationship.