DataStore-Objekte in SAP Business Intelligence

DataStore Objekte in SAP Business Intelligence
DataStore-Objekte in SAP Business Intelligence
4.6 Sterne
12 Bewertungen

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:

So erleichtern Sie die Entscheidungsfindung und gewinnen einen umfassenden Überblick über Ihr Geschäft! Mit meinem neuen Buch lernen Sie, SAP für die Unternehmensplanung einzurichten, zu nutzen und zu erweitern.

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

DSO Einstellungen

Einstellungen eines DataStore Objekts

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 Acitvation 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.

Activation Queue

Activation Queue

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


Unternehmensplanung mit SAP BPC

Planung mit SAP Business Planning and Consolidation leicht gemacht!

Mit diesem Buch lernen Sie, SAP BPC für die Unternehmensplanung einzurichten, zu nutzen und zu erweitern. Ich beantworte die zentralen Fragen von Projektteams, Beratern, IT und Anwendern – immer mit dem Blick auf die Anforderungen der Praxis.


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.

Einstellungen schreiboptimiertes DSO

Einstellungen schreiboptimiertes DSO

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.

Planungsmodus ab BW 7.3 möglich

DSO für direktes Schreiben Einstellungen

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

Ihre User beklagen sich über langsame Berichte?

  • In meinem Newsletter lernen Sie, wie Sie Abhilfe schaffen.
  • Entdecken Sie die Möglichkeiten der Performanceoptimierung.
  • Praktische Anleitungen ermöglichen Ihnen schnelle Erfolge bei der Optimierung von SAP Systemen.
  • Viele Tipps und Tricks zu SAP BI Themen.
  • Holen Sie die maximale Performance aus Ihrem SAP BI!
  • Bei der Anmeldung zu meinem Newsletter erhalten Sie das Buch „High Performance SAP BI“ als Willkommensgeschenk.
Fordere SAP Performance Tricks an

Jetzt anfordern!

* Pflichtfeld
 
Kein SPAM. Ich hasse Spam genau so wie du.

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.

Denis Reis ist Business Intelligence Consultant und gibt als Buchautor sein Wissen rund um den SAP Projektalltag weiter. Wenn Sie tatkräftige Unterstützung bei Ihren SAP BI Projekten benötigen, können Sie ihn über Xing, LinkedIn oder Facebook kontaktieren.
Des Weiteren unterrichtet er Projektmanagement und Controlling an der Wiesbaden Business School. Der aus Düsseldorf stammende Familienmensch zählt zu denjenigen, die auf komplizierte Darstellungen verzichten und das Ganze auf den Punkt bringen.

2 Kommentare

Trackbacks & Pingbacks

  1. […] Beispiel möchten wir den Inhalt des DSOs FIAR_O06 als Flatfile ausgeben. Die Werte in der aktiven Tabelle des DSOs sehen wie folgt […]

  2. […] einzurichten, zu nutzen und zu erweitern. Betrachten wir das folgende Beispiel. Wir haben ein Data Store Objekt um flexibel Berechtigungen pro Buchungskreis anzulegen. Der technische Name lautet […]

Dein Kommentar

Want to join the discussion?
Feel free to contribute!

Kommentar verfassen