Transitive Attribute als Navigationsattribute 

Verwendung

Wurde ein Merkmal als Navigationsattribut in einen InfoCube aufgenommen, so kann darüber in Queries navigiert werden. Dieses Merkmal kann aber selbst über weitere Navigationsattribute verfügen, sogenannte transitive Attribute. Diese stehen nicht automatisch zur Navigation in der Query zur Verfügung, sondern müssen, wie in dieser Vorgehensweise beschrieben, eingeschaltet werden.

Ein InfoCube enthält das InfoObject 0COSTCENTER (Kostenstelle). Dieses hat u.a. das Navigationsattribut 0COMP_CODE (Buchungskreis). Dieses Merkmal wiederum hat das Navigationsattribut 0COMPANY (Gesellschaft zum Buchungskreis). 0COMPANY wäre in diesem Fall ein transitives Attribut, das man als Navigationsattribut einschalten könnte.

Vorgehensweise

In der folgenden Vorgehensweise wird von einem einfachen Szenario ausgegangen mit InfoCube IC, der das Merkmal A enthält, mit Navigationsattribut B und transitivem Navigationsattribut T2, das als Merkmal nicht im InfoCube IC vorhanden ist. Navigationsattribut T2 soll in der Query zur Anzeige gebracht werden.

1.       Merkmal anlegen

Legen Sie ein neues Merkmal dA (denormalized A) an, welches die in der Query erwünschten transitiven Attribute als Navigationsattribute besitzt (in diesem Beispiel T2) und in den technischen  Einstellungen des Schlüsselfeldes mit dem Merkmal A übereinstimmt.

Nachdem Sie das Merkmal dA angelegt und gesichert haben, gehen Sie Transaktion SE16, wählen aus der Tabelle RSDCHA den Eintrag für dieses Merkmal aus (CHANM = <Merkmalsname> und OBJVERS = 'M') und setzen das Feld CHANAV auf den Wert 2 und das Feld CHASEL auf den Wert 4. Damit wird die Sichtbarkeit des Merkmals dA in Queries ausgeschaltet. Dies ist technisch gesehen nicht notwendig, es verbessert aber die Übersichtlichkeit in der Querydefinition, da hier das Merkmal nicht auftaucht.

Starten Sie die Transaktion RSD1 (InfoObject-Pflege) erneut und aktivieren Sie das Merkmal.

2.       Merkmal in InfoCube aufnehmen

Nehmen Sie das Merkmal dA in den InfoCube IC auf. Schalten Sie dessen Navigationsattribute T2 ein. Dadurch stehen die transitiven Navigationsattribute T2 in der Query zur Verfügung.

3.       Transformationsregeln anpassen

Passen Sie nun die Transformationsregeln zum InfoCube IC so an, so dass das neu aufgenommene Merkmal dA genau so wie das bereits bestehende Merkmal A berechnet wird. Die Werte von A und dA im InfoCube müssen identisch sein.

4.       InfoSource anlegen

Legen Sie eine neue InfoSource an. Weisen Sie ihr die DataSource des Merkmals A zu.

5.       Daten laden

Technische Erläuterung des Ladevorgangs:

Die DataSource des Merkmals A muss die Stammdatentabelle des Merkmals A wie auch des Merkmals dA versorgen. In diesem Beispiel liefert die DataSource das Schlüsselfeld A und das Attribut B. A und B müssen in die Stammdatentabellen des Merkmals A fortgeschrieben werden.

A wird ebenfalls in die Stammdatentabelle von dA (nämlich in das Feld dA) fortgeschrieben und B dient lediglich zur Ermittlung des transitiven Attributs T2, welches aus der bereits fortgeschriebenen Stammdatentabelle des Merkmals B gelesen und in die Stammdatentabelle des Merkmals dA geschrieben wird.

Da die Werte des Attributs T2 in die Stammdatentabelle des Merkmals dA kopiert werden, ergibt sich folgende Abhängigkeit, die bei der Modellierung zu berücksichtigen ist:                                  

Ändert sich ein Satz des Merkmals A, so wird dieser vom Quellsystem beim Upload ins BI-System übertragen. Ändert sich ein Satz des Merkmals B, so wird dieser ebenfalls vom Quellsystem beim Upload ins BI-System übertragen. Da aber das Attribut T2 des Merkmals B beim Upload des Merkmals A gelesen und kopiert wird, ist es bei einem Deltaupload des Merkmals A möglich, dass ein Datensatz des Merkmals A, weil er sich nicht geändert hat, nicht ins BI-System übertragen wird. Aber gerade für diesen Satz könnte sich das transitiv abhängige Attribut T2 geändert haben, welches dann aber für dA nicht aktualisiert wird.                                        

Der Aufbau eines Szenarios zum Laden der Daten hängt davon ab, ob der Extraktor der DataSource A deltafähig ist oder nicht.

Ladeprozess:

1.       Szenario für nicht-deltafähigen Extraktor

Ist der Extraktor, der DataSource A nicht deltafähig, so werden die Daten über eine InfoSource und zwei unterschiedlichen Transformationsregeln in die zwei verschiedenen InfoProvider (Stammdatentabelle des Merkmals A und des Merkmals dA) fortgeschrieben.

2.       Szenario für deltafähigen Extraktor

Handelt es sich um einen deltafähigen Extraktor, so wird ein DataStore-Objekt dazwischengeschaltet, aus welchem man immer einen Fullupdate in die Stammdatentabelle des Merkmals dA ausführen kann. Bei dieser Lösung werden die Daten ebenfalls über eine neue InfoSource und zwei unterschiedliche Transformationsregeln in zwei verschiedene InfoProvider (Stammdatentabelle des Merkmals A und neues DataStore-Objekt, welches die gleiche Struktur wie das Merkmal A hat) über einen Deltaupdate fortgeschrieben. Zusätzlich wird über Transformationsregeln aus dem DataStore-Objekt per Fullupdate in die Stammdatentabelle des Merkmals dA geschrieben.

Bei beiden Lösungen müssen die Transformationsregeln in den InfoProvider Stammdatentabelle des Merkmals dA das Nachlesen des Attributs T2 bewerkstelligen. Für kompliziertere Szenarien, in denen Sie über mehrere Stufen nachlesen, werden in Zukunft Funktionsbausteine bereitgestellt werden, die diesen Service leisten.                                    

Für das Coding zum Nachlesen der transitiven Attributen (in den Transformationsregeln) ist es von Vorteil, wenn man die InfoSource gleich um die Attribute erweitert, die nachgelesen werden sollen. Dann hat man es nämlich mit Transformationsregeln zu tun, welche lediglich ein eins-zu-eins-Mapping vornehmen. Die zusätzlich in die InfoSource aufgenommenen Attribute werden in den Transferregeln nicht gefüllt, sondern erst in den Transformationsregeln in einer anzulegenden Startroutine berechnet. Der Vorteil besteht nun darin, dass das Coding zum Nachlesen der Attribute (welches ja durchaus komplex sein kann) in den Transformationsregeln an einer Stelle abgelegt ist.               

In beiden Fällen muss die Reihenfolge beim Laden ebenfalls beachtet werden und entweder organisatorisch oder über Prozessketten realisiert werden. Es ist unbedingt notwendig, dass beim Laden der Daten, welche die DataSource des Merkmals A liefert, die Stammdaten, welche nachgelesen werden (in unserem Fall die Stammdaten des Merkmals B) bereits im System in den Stammdatentabellen vorhanden sind.                                                                   

Ändern sich die Stammdaten von Merkmal B, so wird dies erst beim nächsten Laden in A / dA auch sichtbar.