Transitive Attributes as Navigation Attributes
If a characteristic was included in an InfoCube as a navigation attribute, it can be used for navigating in queries. This characteristic can itself have further navigation attributes, called transitive attributes. These attributes are not automatically available for navigation in the query. However, this procedure describes how you can display the transitive attributes in the query via modeling.
An InfoCube contains InfoObject 0COSTCENTER (cost center). This InfoObject has navigation attribute 0COMP_CODE (company code). This characteristic in turn has navigation attribute 0COMPANY (company for the company code). In this case 0COMPANY is a transitive attribute that you can switch on as navigation attribute.
In the following procedure, we assume a simple scenario with InfoCube IC containing characteristic A, with navigation attribute B and transitive navigation attribute T2, which does not exist in InfoCube IC as a characteristic. You want to display navigation attribute T2 in the query.
Creating Characteristics
Create a new characteristic dA (denormalized A) which has the transitive attributes requested in the query as navigation attributes (for example T2) and which has the same technical settings for the key field as characteristic A.
After creating and saving characteristic dA, go to transaction SE16, select the entry for this characteristic from table RSDCHA (CHANM = <characteristic name> and OBJVERS = 'M') and set field CHANAV to 2 and field CHASEL to 4. This renders characteristic dA invisible in queries. This is not technically necessary, but improves readability in the query definition since the characteristic does not appear here.
Start transaction RSD1 (InfoObject maintenance) again and activate the characteristic.
Including Characteristics in the InfoCube
Include characteristic dA in InfoCube IC. Switch on its navigation attribute T2. The transitive navigation attributes T2 are now available in the query.
Modifying Transformation Rules
Now modify the transformation rules for InfoCube IC so that the newly included characteristic dA is calculated in exactly the same way as the existing characteristic A. The values of A and dA in the InfoCube must be identical.
Creating InfoSources
Create a new InfoSource. Assign the DataSource of characteristic A to the InfoSource.
Loading Data
Technical explanation of the load process:
The DataSource of characteristic A must define the master data table of characteristic A as well as of characteristic dA. In this example the DataSource delivers key field A and attribute B. A and B must be updated to the master data table of characteristic A.
A is also updated to the master data table of dA (namely in field dA) and B is only used to determine transitive attribute T2, which is read from the updated master data table of characteristic B and written to the master data table of characteristic dA.
Since the values of attribute T2 are copied to the master data table of characteristic dA, this results in the following dependency, which must be taken into consideration during modeling:
If a record of characteristic A changes, it is transferred from the source system when it is uploaded into the BW system. If a record of characteristic B changes it is transferred from the source system when it is uploaded into the BW system. However, since attribute T2 of characteristic B is read and copied when characteristic A is uploaded, a data record of characteristic A might not be transferred to the BW system during a delta upload of characteristic A because it has not changed. However, the transitive dependent attribute T2 might have changed for this record only but the attribute would not be updated for dA.
The structure of a scenario for loading data depends on whether or not the extractor of DataSource A is delta enabled.
Loading process:
Scenario for non-delta-enabled extractor
If the extractor for DataSource A is not delta enabled, the data is updated to the two different InfoProviders (master data table of characteristics A and dA) using an InfoSource and two different transformation rules.
Scenario for delta-enabled extractor
If it is a delta-enabled extractor, a DataStore object from which you can always execute a full update in the master data table of characteristic dA is used. With this solution, the data is also updated to two different InfoProviders (master data table of characteristic A and new DataStore object which has the same structure as characteristic A) in a delta update using a new InfoSource and two different transformation rules. Transformation rules from the DataStore object are also used to write the master data table of characteristic dA with a full update.
For both solutions, the transformation rules in the InfoProvider master data table of characteristic dA must cause attribute T2 to be read. For complicated scenarios in which you read from several levels, function modules will be retrieved that execute this service.
It is better for the coding for reading the transitive attributes (in the transformation rules) if you include the attributes to be read in the InfoSource right from the beginning. This means that you only have transformation rules that perform one-to-one mapping. The additional attributes that are included in the InfoSource are not filled in the transfer rules. They are only computed in the transformation rules in a start routine, which must be created. The advantage of this is that the coding for reading the attributes (which can be quite complex) is stored in one place in the transformation rules.
In both cases the order at load time must be adhered to and must be implemented either organizationally or using a process chain. It is essential that the master data to be read (in our case the master data of characteristic B) already exists in the master data tables in the system when the data providing the DataSource of characteristic A is loaded.
Change the master data from characteristic B so that it is also visible with the next load into A / dA.