Transitive Attributes as Navigation
Attributes
Use
If a characteristic was included in an InfoCube as a navigation attribute, it can be used for navigating in queries. This characteristic can have further navigation attributes of its own. These are known as transitive attributes. They cannot automatically be navigated in in the query. This section explains how you can display transitive attributes in the query by using a workaround in modeling.
An InfoCube contains InfoObject 0COSTCENTER (cost center). This InfoObject has navigation attribute 0COMP_CODE (company code). This characteristic has navigation attribute 0COMPANY (company for the company code). 0COMPANY is a transitive attribute that you can activate as a navigation attribute.
Procedure
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.
1. Creating Characteristics
Create a new characteristic dA (denormalized A) with the transitive attributes requested in the query as navigation attributes (for example T2) and the same technical settings for the key field as characteristic A.
After creating and saving characteristic dA, call 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 strictly 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.
2. Including Characteristics in the InfoCube
Include characteristic dA in InfoCube IC. Activate its navigation attribute T2. The transitive T2 navigation attributes are now available in the query.
3. 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.
4. Creating InfoSources
Create a new InfoSource. Assign the DataSource of characteristic A to the InfoSource.
5. Loading Data
Technical explanation of the load process:
The DataSource for characteristic A must define the master data table for both characteristic A and 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 for characteristic A.
A is also updated to the master data table for dA (namely in field dA) and B is only used to determine transitive attribute T2, which is read from the updated master data table for characteristic B and written to the master data table for characteristic dA.
Since the values of attribute T2 are copied to the master data table for 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 BI system. If a record of characteristic B changes, it is transferred from the source system when it is uploaded into the BI 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 BÍ system during a delta upload of characteristic A because it has not changed. But 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:
1. 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.
2. Scenario for delta-enabled extractor
If the extractor is delta-enabled, a DataStore object is used that you can always make a full update in the master data table for characteristic dA from. With this solution, the data is also updated to two different InfoProviders (master data table for characteristic A and new DataStore object with 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 for characteristic dA with a full update.
For both solutions, the transformation rules in the InfoProvider master data table for 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 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 (the master data for characteristic B in this case) already exists in the master data tables in the system when the data providing the DataSource for characteristic A is loaded.
Change the master data from characteristic B so that it is also visible with the next load into A / dA.