DataStore-Objekte in SAP Business Intelligence

DataStore-Objekte (DSOs) sind ein essenzieller Teil des SAP Business Warehouse. DSOs sind mit einer Datenbanktabelle vergleichbar und bilden eine flache Struktur die verschiedene Felder enthält. Es können drei DataStore-Typen unterschieden werden:

• Standard-DSO
• Schreiboptimiertes DSO
• DSO für direktes Schreiben

Standardmäßig erzeugt das System bei der Neuanlage ein Standard-DSO. Den Typ können Sie in den Einstellungen des DSOs ändern.

Weitere Einstellungen sind:
Erzeugung von SIDs bei Aktivierung – die Deaktivierung dieser Einstellung ermöglicht es, Daten schneller zu laden. Sollten Sie jedoch diret auf dem DSO reporten wollen, müssen Sie beachten, dass hierdurch die Performance leidet, weil die SID-Werte zur Laufzeit der Abfrage generiert werden müssen.
Eindeutige Datensätze – diese Einstellung kann die Performance bei der Aktivierung der Daten erhöhen. Allerdings müssen Sie darauf achten, dass wirklich alle neu geladenen Daten eine eindeutige Schlüsselkombination haben.
Qualitätsstatus automatisch auf o.k. setzen, Daten automatisch aktivieren, Daten automatisch fortschreiben – diese Einstellungen zur Ladesteuerung sind nur in Verbindung mit dem alten 3.x-Ladeverfahren relevant. Unter 7.x sollten Sie die entsprechende Funktionalität über Prozessketten abbilden.

Standard DSO

Standard DSO sind die am häufigsten eingesetzten Typen. Während nach außen das DataStore-Objekt als eine flache Tabelle erscheint existieren im Hintergrund drei Tabellen. Das System generiert zum einen eine Tabelle für die aktiven Daten (Aktive Daten). Diese stehen dem Reporting aktuell zur Verfügung. Daneben wird eine Tabelle für die neu hinzugekommenen Daten (Neue Daten oft auch als Activation Queue bezeichnet), die erst duch Aktivierung in aktive Daten übernommen werden, sowie eine Change Log Tabelle generiert. Diese Tabellen können Sie in der Administration der DataSource, Reiter Inhalt, einsehen. Die Tabelle mit den aktiven Daten ist entsprechend der DataStore-Objekt-Definition aufgebaut, das heißt Schlüsselfelder und Datenfelder werden bei der Definition des DataStore-Objektes festgelegt. Die Tabelle für neue Daten (Aktivierungs-Queue) und Change Log sind in ihrer Struktur fast gleich: die Aktivierungs-Queue hat als Schlüssel eine SID, die Package ID und die Datensatznummer, das Change Log hat als Schlüssel die Request ID, die Package ID und die Datensatznummer.
Dieser Aufbau ermöglicht über einen Vergleich von alten mit neuen Inhalten Delta Informationen zu erzeugen.
In der folgenden Abbildung sehen Sie die einzelnen Teilschritte des Datenladens in ein Standard DSO.

Im ersten Schritt (1) können die Daten aus verschiedenen Quellen parallel geladen werden. Dabei können verschiedene Deltaverfahren gleichzeitig zum Einsatz kommen. Die noch zu aktivierenden Daten werden in der Tabelle für Neue Daten (Activation Queue) gespeichert (Schritt 2). Während des Aktivierungsprozesses werden die aktiven Daten angepasst (Schritt 3). Wenn die Generierung von SIDs in den Einstellung aktiv ist, werden auch SID-Werte für alle neuen Merkmalsausprägungen erzeugt (Schritt 5). Gleichzeitig werden während des Aktivierungsprozesses die Change Log Informationen generiert (Schritt 4). Das Change Log kann dazu dienen, weitere InfoProvider (z.B. InfoCubes) mit Delta-Informationen zu versorgen (Schritt 6).
Schauen wir uns ein praktisches Beispiel an.
In unser DSO werden folgende Daten geladen:

Buchungskreis	Jahr	Betrag
1000	2012	100

Die Tabelle für aktive Daten und das Change Log sind zunächst leer.
In der Tabelle für neue Daten sehen wir neben der SID, der Datenpaket ID und der Datensatznummer unsere Daten:

Buchungskreis	Jahr	Betrag
1000	2012	100

Nun aktivieren wir den Request.
Die Daten werden in die Tabelle für aktiven Daten und das Change Log geschrieben. Gleichzeitig werden die Werte aus der Tabelle für neue Daten (Activation Queue) gelöscht.
Schauen wir in die Tabelle für aktive Daten.

Buchungskreis	Jahr	Betrag
1000	2012	100

Das selbe steht in der Change Log Tabelle. Zusammen mit der Request ID, der Package ID, der Datensatznummer und dem Recordmode N (für New-Image).

Buchungskreis	Jahr	Betrag	Change Log
1000	2012	100	N

Aus der Change Log Tabelle werden die Daten in den Cube geladen. Folgende Daten sind nach dem Ladeprozess im Cube zu finden:

Buchungskreis	Jahr	Betrag
1000	2012	100

Nun ändern sich die Daten in der Quelle. Statt 100 EUR wird nun ein Betrag von 150 EUR übergeben. Diese Daten werden in das DSO geladen.
In der Tabelle für neue Daten steht nun 150.

Buchungskreis	Jahr	Betrag
1000	2012	150

Nach der Aktivierung werden die Tabellen für aktive Daten und das Change Log angepasst. Die Werte werden aus der Tabelle für neue Daten gelöscht.
Die Tabelle für aktive Daten sieht nun so aus:

Buchungskreis	Jahr	Betrag
1000	2012	150

Interessanter ist da die Change Log Tabelle:

Buchungskreis	Jahr	Betrag	Change Log
1000	2012	100	N
1000	2012	-100	X
1000	2012	150

Mit dem Recordmode „X“ (Before-Image) wird der Zustand vor einer Änderung oder vor dem Löschen übertragen. Dabei werden alle summierbaren Attribute des Satzes mit umgekehrtem Vorzeichen übertragen. Der Betrag von 100 wurde also storniert. Als Nächstes wird ein neuer Datensatz (150) mit dem Recordmode “ “ (After-Image) eingefügt. Damit wird der Zustand nach einer Änderung oder nach dem Einfügen übertragen. Dieser Satz darf nur dann direkt in einen InfoCube fortgeschrieben werden, wenn es im Request das entsprechende Before-Image gibt.
Nun laden wir die Daten in den Cube. Es werden die zwei neuen Datensätze übertragen. Einmal -100 mit Recordmode „X“ und einmal 150 mit Recordmode “ „. Da der Cube nur summieren kann, werden den 100 weitere 50  ( -100 + 150 = 50 ) EUR hinzugefügt.

Buchungskreis	Jahr	Betrag
1000	2012	100
1000	2012	50

Schreiboptimiertes DSO

Ein schreiboptimiertes DSO ist für die Speicherung von extrahierten Rohdaten bestimmt. Im Gegensatz zu Standard-DSOs besteht dieses nur aus der aktiven Tabelle. Da keine Aktivierung nötig ist, können die Daten schneller gespeichert und sofort weiterverarbeitet werden.
Zusätzlich zum semantischen Schlüssel, der auch bei Standard-DSOs existiert, verfügt das schreiboptimierte DSO über einen zweiten, automatisch generierten, technischen Schlüssel. Dieser setzt sich aus Request GUID (0REQUEST), Datenpaket (0DATAPAKID) und Datensatznummer (0RECORD). Zu diesem Schlüssel werden immer nur neue Datensätze geladen. Damit wird verhindert, dass zwei gleiche Schlüsselwerte geladen werden können und Datensätze durch nachfolgende Datensätze überschrieben werden.
Indem Sie in den Einstellungen die Option Eindeutigkeit der Daten nicht prüfen auswählen, können Sie diese Prüfung deaktivieren. In diesem Fall können im DSO mehrere Sätze mit demselben semantischen Schlüssel enthalten sein.

Da das schreiboptimierte DSO nur eine aktive Tabelle und kein Change Log besitzt, werden keine Deltas im Sinne von Before- und After-Images generiert. Beim Fortschreiben der Daten in angeschlossene InfoProvider werden nur Requests fortgeschrieben, die dort noch nicht verbucht sind. Zur Weitergabe der Delta-Informationen können Sie das Feld 0RECORDMODE in das schreiboptimierte DSO aufnehmen.
Schreiboptimierte DSOs werden hauptsächlich in Pass-through-Szenarien und als Corporate Memory eingesetzt.
Da die Aktivierungszeit entfällt, können die Daten schnell durchgeladen werden. Die Zwischenspeicherung in einem schreiboptimierten DSO dient dabei der Kontrolle und kann genutzt werden, um vor dem Weiterleiten die Daten anzureichern oder zu überprüfen. Da die schreiboptimierten DSOs die Änderungshistorie vollständig und exakt abbilden, können diese die Analyse erleichtern. Bedenken Sie jedoch, dass der Einsatz von schreiboptimierten DSOs zu einem erhöhten Datenvolumen führen kann.
Beim Pass-through-Szenario werden die Datensätze anschließend gelöscht. Wenn Sie jedoch das DataStore-Objekt als Teil der Konsistenzschicht einsetzen, dürfen bereits fortgeschriebene Daten nicht gelöscht werden. Andernfalls kann es zu Inkonsistenzen der Daten in Quelle und Ziel kommen. Die Option Delta-Konsistenz prüfen in den Einstellungen verhindert, dass ein bereits per Delta abgeholter Request gelöscht wird.

DSO für direktes Schreiben

Wie auch das schreiboptimierte DSO besteht das DSO für direktes Schreiben nur aus der aktiven Tabelle. Außerdem ist das Laden von Daten per DTP nicht möglich. Die Daten können über einen Funktionsbaustein oder mit dem Analyseprozess-Designer reingeschrieben werden. Ab 7.3 können Sie außerdem das DSO in der integrierten Planung benutzen.

Wenn Sie ein eigenes Programm entwickeln, können Sie auf die folgenden RFC-fähigen Funktionsbausteine zum Einfügen, Aktualisieren, Verändern und Löschen von Daten zurückgreifen. Diese können auch systemübergreifend aufgerufen werden und verfügen über eine Sperrverwaltung:

• RSDRI_ODSO_INSERT_RFC
• RSDRI_ODSO_UPDATE_RFC
• RSDRI_ODSO_MODIFY_RFC
• RSDRI_ODSO_DELETE_RFC

Quellen:
Frank Wolf, Stefan Yamada (2010): Datenmodellierung in SAP NetWeaver BW, 1. Auflage, Bonn
SAP Hilfe – Standard DataStore-Objekt
SAP Hilfe – Beispiel für die Aktivierung und das Fortschreiben von Daten
SAP Hilfe – Schreiboptimiertes DataStore-Objekt
SAP Hilfe – Einsatzszenario für schreiboptimierte DataStore-Objekte
SAP Hilfe – DataStore-Objekt für direktes Schreiben

Falls Ihnen dieser Beitrag weitergeholfen hat, wäre es eine sehr nette Anerkennung meiner Arbeit wenn Sie z.B. Ihre Bücher über Amazon bestellen würden. Wenn Sie ein Produkt kaufen, erhalte ich dafür eine Provision. Für Sie ändert sich am Preis des Produktes gar nichts. Ich möchte mich an dieser Stelle jetzt schon für Ihre Unterstützung bedanken.