Characteristic Relationships 

Use

Characteristic relationships are used to relate characteristics that correspond to each other with regard to content. You can use characteristic relationships to define rules in order to check permitted combinations of characteristic values for each real-time enabled InfoCube. You can also define rules that the system uses to derive values from characteristics for other characteristics. This is useful, for example, when the derivable characteristics are 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 characteristic relationships are defined in relation to attributes and hierarchies, the system offers those attributes and hierarchies that were created in the BI system for a characteristic (see Tab Page: Attribute as well as Tab Page: Hierarchy and Hierarchy).

Characteristic relationships are created on a real-time enabled InfoCube. They then affect all InfoProvider relevant for planning that reference this InfoCube.

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

·        This means that cells for invalid characteristic combinations are not input ready in an input-ready query and new data records with invalid characteristic combinations cannot be created.

·        Planning functions constantly check whether new characteristic combinations are valid according to the characteristic relationships. In case of invalid combinations, the system informs you with an error message.

The possible characteristic derivations take place when the delta records are determined in the delta buffer. The possible source characteristics are the characteristics of the real-time enabled InfoCube that are filled by characteristics from the participating aggregation levels. If characteristic relationships are changed, the data records in the InfoCube have to adapted to the new structure. The planning function Reposting Characteristic Relationships is used for this purpose.

Prerequisites

The following prerequisites must be fulfilled in order to define characteristic relationships:

·        The InfoProvider must be a real-time enabled InfoCube. The characteristic relationships defined for a real-time enabled InfoCube are also effective in the MultiProviders that contain a real-time enabled InfoCube.

·        In characteristic relationships of the 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 the 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. Thus you can use all methods for managing and monitoring available in the Data Warehousing Workbench.

Features

Definition of a Characteristic Relationship

Characteristic relationships are created on a real-time enabled InfoCube. 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

Relations can only be used to check characteristic combinations or can be used for a characteristic derivation. You set this behavior in the definition of 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 which relationships in the InfoProviders that are relevant for planning are used.

·        Combination check: A relation is only used in an aggregation level when every characteristic of the relation occurs in the aggregation level. With derivations, these are the source and target characteristics. In this case, nothing is derived and only a combination check is executed.

·        Characteristic Derivation: Derivation does not take place within one aggregation level. Derivations are only performed for records of the real-time enabled InfoCubes. First the system determines the set S of characteristics that are filled by the aggregation level involved. If all the source characteristics are included in the 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	Each attribute of the basic characteristic can be a 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.
Hierarchies	All characteristics are available as source or target characteristics that were set 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 superordinate characteristics are not counted in compounded 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 higher level 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 used 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: All InfoObjects from the DataStore object (except for key figures) can be selected. With Derivation: The keys of the DataStore object have to be selected 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 result from 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. Also note the commented example source text in the template class; an infrastructure for buffering is provided there, for example.

In addition to the characteristic relationships above, which you can edit, there are other predefined characteristic relationships for the BI time characteristics in the system that are always active: when there are redundant time characteristics in the real-time enabled InfoCube, for example (such as 0FISCPER and the pair 0FISCPER3 and 0FISCYEAR), the system also applies these relations between time characteristics to the combination check or derivation as well, as it does other relations.

Within a relation, note that the initial characteristic value (# not assigned) plays a special role. This has to do with the fact that characteristics that do not occur in an aggregation level (and are not derivable) are updated with the initial value.

·         Combination check without derivation:

Let us assume that there is a relation between the characteristics Product and Assortment; usually there is no derivation relationship between the two. In aggregation levels with Product and without Assortment, Assortment is updated with the initial value. Thus these types of combinations are always valid; they cannot be forbidden. The same goes for combinations with the initial value for Product.

·         Combination check with derivation

Let us assume there is a relation between the characteristics Cost Center and Profit Center; here Profit Center can be derived from Cost Center. In an aggregation level with Profit Center and without Cost Center, however, Cost Center is also updated with the initial value. These combinations cannot be forbidden. The reverse is not valid due to the possible derivation of Profit Center from Cost Center.

Activities

...

       1.      You are in the InfoProvider  tab page of the Planning Modeler. Choose the required InfoProvider of type real-time enabled 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 set whether the system is to perform only combination checks and proposals, or whether a derivation of the target characteristic from the basic characteristic is also to be performed. For each step, choose with or without derivation.

       4.      Select the type of characteristic relationship.

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

¡        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.

¡        In the case of attribute and hierarchy relationships such as DataStore objects, you can select check characteristics.

¡        In the case of an exit class, you can select source and target characteristics.

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