Neben Planung auf InfoCube-ähnlichen aDSOs hat auch die Planung auf direkter Fortschreibung ihre Berechtigung. In diesem Beitrag erkläre ich den Aufbau dieser aDSO-Art und erläutere die möglichen Einsatzgebiete.
Zuvor müssen wir uns jedoch mit dem generellen Aufbau von aDSOs auseinandersetzen. Während das Advanced DataStore-Objekt nach außen als eine flache Tabelle erscheint, existieren im Hintergrund drei wichtige Tabellen. Daneben werden automatisch Views für Extraktion und Reporting angelegt. Ein aDSO besteht also immer aus fünf Tabellen. Je nach gesetzten Einstellungen und dem aDSO-Typ werden jedoch manche Tabellen nicht genutzt.
Die drei wichtigsten Tabellen sind die Inbound Tabelle, die Tabelle der aktiven Daten und die Change Log-Tabelle. In der Inbound-Tabelle werden alle Datensätze mit einem technischen Schlüssel abgelegt. Diese entspricht der Aktivierungs-Queue bei den klassischen DSOs und ist mit der nicht komprimierten Faktentabelle eines InfoCubes vergleichbar. Im Planungsszenario enthält diese Tabelle vor der Aktivierung der Requests die Delta-Sätze.
Daneben generiert das System eine Tabelle für die aktiven Daten (Aktive Daten). Diese enthält, genau wie beim klassischen DSO, die aktuellen Werte nach der Aktivierung. Als Schlüssel der Tabelle dient der im DSO definierte Schlüssel. Sie ist mit der komprimierten Faktentabelle eines InfoCubes vergleichbar.
Planungstools im Vergleich - SAP BW IP vs. BPC vs. SAC
Die dritte Tabelle, das Change Log, entspricht dem eines klassischen DSOs. Diese Tabelle speichert die Unterschiede zwischen der Inbound-Tabelle und der Tabelle der aktiven Daten. Das Change Log wird für die Delta-Erstellung benötigt. Im Planungsumfeld ist diese Tabelle jedoch vernachlässigbar.
Während ein aDSO mit der Einstellung Planung auf InfoCube-ähnlich (engl. Planning on Cube-like) über eine Inbound und eine aktive Tabelle verfügt, werden bei einem aDSO mit der Einstellung Planung auf direkter Fortschreibung (engl. Planning on Direct Update) die Daten direkt in die aktive Tabelle geschrieben.
Und während bei einem InfoCube-ähnlichen aDSO alle Merkmale als Schlüssel definiert sind, müssen bei einem aDSO mit direkter Aktualisierung die Schlüssel manuell definiert werden.
Dabei ist es wichtig zu wissen, dass alle Felder, die nicht als Schlüssel gekennzeichnet sind, überschrieben werden. Durch diese Eigenschaft eignen sich aDSOs auf direkter Fortschreibung besonders für die Speicherung von Kommentaren, wobei solche Merkmale als Kennzahlen zu handhaben sind.
Da die aDSO auf direkter Fortschreibung nur über eine aktive Tabelle verfügen, ist es, im Gegensatz zu InfoCube-ähnlichen aDSO, nicht möglich, einzelne Requests zu löschen. Allerdings ist es dadurch möglich, Daten über eine API direkt in die aktive Tabelle zu schreiben.
Am Rande sei zu erwähnen, dass es bei diesem aDSO Typ nun möglich ist, Daten auch über ein Datentransferprozess (DTP) zu laden. Bei einem klassischen DSO für direktes Schreiben war dies nicht möglich. Dabei steht jedoch nur die Option Überschreiben zur Verfügung. Die Summation von Kennzahlen in der Transformation ist nicht möglich.
Wenn Sie Kennzahlen mit dem Aggregationsverhalten NO2 (Keine Aggregation) einsetzen möchten, führt kein Weg an aDSOs mit direkter Fortschreibung vorbei. Zum Beispiel bei der Preisplanung oder dem Setzen von aktiv/inaktiv Flags. Bei Modellierung mit diesen Kennzahlen müssen Sie nämlich diesen aDSO Typ einsetzen. Die Verwendung von InfoCube-ähnlichen aDSOs ist nicht möglich.
Bildquelle: Photo by gdtography from Pexels
