Klassische DataStore Objekte

Klassische DataStore-Objekte vs. Advanced DataStore-Objekte

Mit SAP BW/4HANA gab es auf Architekturebene viele Änderungen, so zum Beispiel bei der Datenmodellierung.

In diesem Artikel beschäftigen wir uns mit den verschiedenen Funktionen und Möglichkeiten von ADSOs und zeigen dir zudem, wie sie dir dabei helfen können, verschiedene Aufgaben in deiner SAP BW-Umgebung zu optimieren.

Werfen wir aber zuerst einen Blick auf die klassischen DSOs und ihre Funktionen. Danach zeige ich dir noch die Unterschiede zwischen klassischen DSOs und den neu eingeführten ADSOs.

DSO (DataStore Object)

Was ist ein DSO?

Ein DSO ist eine zweidimensionale Speichereinheit, in der hauptsächlich Transaktionsdaten oder Stammdaten mit niedrigster Granularität gespeichert werden. Die Daten werden also mit einem hohen Detailgrad gespeichert.

DSO-Typen

Beim Anlegen eines DSOs musst du zunächst den Typ auswählen:

dso

Wenn wir ein DSO anlegen, legt das System standardmäßig eine System ID über die Option „Erzeugung von SIDs bei Aktivierung“ fest, die du in den Bearbeitungseinstellungen eines DSOs findest. Wird diese Option aktiviert, prüft das System die SID-Werte für alle Merkmale im DSO. Falls es keinen SID-Wert für ein Merkmal gibt, generiert das System die SID. Durch die Erzeugung der SIDs bei Aktivierung wird die Laufzeitperformance der Abfrage verbessert, da die SIDs nicht zur Laufzeit der Abfrage generiert werden müssen. SID-Werte werden grundsätzlich in der SID-Tabelle eines InfoObjects gespeichert. Über die SID wird auf die Attribute und Texte eines Stammdaten-InfoObjects zugegriffen. Die SID-Tabelle ist über den char key mit den dazugehörigen Stammdatentabellen verbunden.

In der folgenden Tabelle findest du eine Übersicht über die Eigenschaften der verschiedenen DSO-Typen und Architekturen:

table DSO types

ADSO (Advanced DataStore Object)

Das Advanced DSO ist in der Lage, all diese Objekte zu ersetzen.

 BW4HANA Modeling Objects

Bevor wir ein ADSO anlegen, müssen wir wissen, dass es 3 Haupttabellen umfasst:

  • Inbound Table
    • Tabelle der Aktivierungs-Queue bei klassischen DSOs
    • Nicht komprimierte Faktentabelle eines nicht-SAP-HANA-optimierten InfoCubes
    • Alle Sätze werden mit einem technischen Schlüssel gespeichert.
  • Tabelle der aktiven Daten
    • Enthält ebenso wie beim klassischen DSO die aktuellen Werte nach Aktivierung. Der Schlüssel der Tabelle ist der DSO-Schlüssel (auf Schlüssel werden wir noch näher eingehen).
    • Komprimierte Faktentabelle eines nicht-SAP-HANA-optimierten InfoCubes.
  • Change Log
    • Entspricht dem eines klassischen DSO.
    • Speichert die Unterschiede zwischen dem Inbound Table und der Tabelle der aktiven Daten.
    • Wird für die Delta-Erstellung benötigt.

Wichtige Schritte beim Anlegen eines ADSO

  • Ein ADSO wird in den BWMT in Eclipse wie jedes andere neue Objekt angelegt (in BW 7.5 besteht die Möglichkeit, auch weiterhin die klassischen Objekte im SAP GUI anzulegen, wohingegen in BW4/HANA nur noch die neuen Objekte in den BWMT angelegt werden können).
  • Auf der Registerkarte „General“ kannst du die Aktivierungseinstellungen und weitere Eigenschaften festlegen. Zunächst muss hier eine Beschreibung angegeben werden. Im Anschluss können wir unter „Model Template“ eine Vorlage auswählen. Dabei kann sich ein ADSO wie je eines der 4 Objekte im klassischen BW verhalten.

template

Acquisition-Schicht

In dieser Schicht lassen sich Objekte für die „schreiboptimierten“ Anwendungsfälle klassischer DSOs anlegen. Sie besteht aus 3 Schichten:

  1. Data-Acquisition-Schicht
    • Entspricht einer Persistent Staging Area (PSA) und dient als Eingangsablage im BW für Daten aus den Quellsystemen.
    • Keine Verwendung der aktiven Tabelle, daher ist eine Aktivierung nicht erforderlich.
    • Requests werden in die Inbound Table geladen und daraus extrahiert.
    • Alle Sätze in der Inbound Table enthalten eine Request-TSN, Datenpaket und Datensatznummer.
    • Auf die Inbound Table (ehemals Tabelle der neuen Daten / Aktivierungs-Queue) wird zum Ausführen einer BEx Query und zur Extraktion zugegriffen.
    • Daten werden nicht aggregiert.
  2. Corporate Memory mit Schwerpunkt auf Kompression
    • Requests werden auch weiterhin in die Inbound Table geladen.
    • Auf Detail-Level nicht mehr benötigte alte Requests können in die Tabelle der aktiven Daten komprimiert werden.
    • Um Speicherplatz zu sparen wird beim CM Compression ADSO auf eine Change-Log-Tabelle verzichtet, es gibt nur eine Inbound Table und eine Tabelle der aktiven Daten.
    • Wird ein Laderequests aktiviert, werden die Daten in die aktive Tabelle geladen und aus der Inbound Table gelöscht.
    • Gibt es 2 Sätze mit dem gleichen Schlüssel, überschreibt BW/4HANA alle Merkmale des Satzes mit denen des zuletzt geladenen Satzes.
  3. Corporate Memory mit Schwerpunkt auf Reporting
    • Der Unterschied zwischen dieser Vorlage und der Vorlage für die „Corporate Memory mit Schwerpunkt auf Kompression“ liegt darin, dass die Daten aus der Inbound Tabelle nicht gelöscht werden. Die Daten bleiben also in der Inbound Table, um zu verhindern, dass technische Informationen verloren gehen.
    • Die Vorlage für CM mit Schwerpunkt auf Reporting verfügt jedoch über keinen Change Log.
    • Ein weiterer Unterschied liegt darin, dass die Daten nicht aus der aktiven Tabelle, sondern aus der Inbound Table extrahiert werden.
    • Da die Daten nach der Aktivierung in der Inbound Table verbleiben, sind diese ADSOs sehr gut geeignet, wenn du zwar Daten speichern möchtest, durch den Wegfall des Change Log aber Speicherplatz eingespart werden soll.

Propagation-Schicht

  • Bildet die Grundlage für die weitere Verteilung und Weiterverwendung der Daten.
  • Entspricht einem Standard-DataStore-Objekt (klassisch).
  • Requests werden auch in die Inbound Table geladen.
  • Für das Reporting muss der Benutzer die geladenen Requests aktivieren.
  • Die Daten werden dann in die Tabelle der aktiven Daten übertragen und das Delta wird im Change Log gespeichert.
  • Das Change Log wird auch für den Rollback bereits aktivierter Requests genutzt.

Reporting-Schicht

  • Dient der Ausführung von Queries zur Analyse.
  • Entspricht einem Standard-InfoCube.
  • Die Inbound Table entspricht der F-Tabelle und die Tabelle der aktiven Daten der E-Tabelle.
  • Es gibt keinen Change Log. Ohne die Change-Log-Tabelle kann der Deltaprozess nicht erfolgen.
  • Nach der Aktivierung ist die Inbound Table leer.
  • Das Reporting erfolgt auf einer Union der beiden Tabellen Inbound Table und aktive Tabelle.

Planungs-Schicht

Sie ist in 2 weitere Schichten aufgeteilt:

  1. Planning on Direct Update
    • Die Daten werden automatisch in die aktive Tabelle geladen, eine Aktivierung ist also nicht erforderlich.
    • Es gibt keinen Change Log und keine Inbound Table.
    • Das Befüllen der aktiven Tabelle kann über eine API erfolgen.
    • Bei diesem ADSO-Typ können Daten können auch über den Datentransferprozess (DTP) geladen werden.
    • Es steht nur die Option Überschreiben zur Verfügung. Keine Summation von Kennzahlen wie beim Planning on Cube-like ADSO.
  2. Planning on Cube-like
    • Es gibt eine Inbound Table und eine aktive Tabelle.
    • Alle Merkmalsfelder sind in der aktiven Tabelle als Schlüsselfelder markiert, was eine Voraussetzung für die Planungseignung ist.
    • Es steht nur die Option Summation zur Verfügung.

Der Prozess der für HANA hoch-optimierten SID-Erzeugung

Zum Zwecke der Leistungsoptimierung ist es in BW/4HANA möglich, Kennzeichen sowohl auf InfoProvider-Ebene als auch einzeln für jedes Merkmal des DSOs zu setzen. Die Prüfung der Datenintegrität erfolgt dann nur für das ausgewählte Merkmal.

InfoObjects/Felder

Als neue Funktion ist es jetzt auch möglich, Felder mit einfachen Datentypen anstelle von InfoObjects zu verwenden. Wähle dazu die Registerkarte „Details“ aus und klicke auf „Add Field“. Unter „Identify with:“ kannst du über das Auswahlmenü festlegen, ob du für die Definition ein InfoObject oder ein Feld verwenden möchtest.

infoObject

In BW kann der Benutzer entscheiden, ob die Modellierung mit InfoObjects oder Feldern erfolgen soll. Das Modellieren von InfoObjects bedeutet zwar einen zusätzlichen Aufwand, andererseits bieten InfoObjects aber auch viele Vorteile. Bevor du dich also für eine dieser Modellierungsoptionen entscheidest, solltest du die jeweiligen Vor- und Nachteile genauesten abwägen.

Im Folgenden gehe ich daher ein wenig auf eben diese Vor- und Nachteile beim Modellieren mit Feldern ein:

Die Vorteile von Feldern

  • Wenn Felder in der Query enthalten sind, kann diese schlüsselbasiert in SAP HANA verarbeitet werden.
  • Wenn kleinere Datenvolumen verarbeitet werden, kann durch die Verwendung von Feldern die Flexibilität und Reichweite des Data Warehouse erhöht werden.

Die Nachteile von Feldern

  • Die Services der InfoObjects (so zum Beispiel Attribute und Hierarchien) stehen für Felder nicht zur Verfügung.
  • Die Gültigkeitsmerkmale bei DataStore-Objekten (advanced) mit Bestandskennzahlen müssen InfoObjects sein.
  • Die InfoObject-Attribute müssen InfoObjects sein.
  • Eine feldbasierte Kennzahl kann keine Ausnahmeaggregation haben.
  • Planungs-Queries auf DataStore-Objekten (advanced) werden mit Feldern nur lesend unterstützt.
  • Wenn Felder in der Query verwendet werden, können die InfoProvider nur sequentiell gelesen werden.
  • In der Query auf einem CompositeProvider werden nicht alle Datentypen für Felder unterstützt (z. B. dürfen Felder nicht länger als 20 Zeichen sein).

Definition von Schlüsseln für ein ADSO

  • In dieser Registerkarte wählen wir auch aus, welche Felder für die Schlüssel unseres ADSO verwendet werden. Klicke zur Definition eines Schlüssels auf „Manage Keys“.

fields adso

Schlüsselfelder

Es gibt 2 Schlüsseltypen: Primärschlüssel und Fremdschlüssel.

Die Vorteile von Schlüsselfeldern:

  • Eindeutige Identifikation eines Satzes in einer Tabelle.
  • Schlüsselfelder können nicht NULL sein.
  • Dient der Verbindung zweier Tabellen.
  • Hauptzweck eines Fremdschlüssels ist die Datenvalidierung.
  • Stammdatennachlesen: Durch die Verwendung des Wertes des Eingabefelds als Schlüssel kannst du das zu einem angegebenen Merkmal zugehörige Attribut des Merkmals auslesen.
  • Auslesen aus dem Advanced DataStore: Durch die Verwendung des/der Werte(s) des Eingabefelds als (geklammerter) Schlüssel, kannst du die Datenfelder eines angegebenen Advanced DataStore-Objekts (ADSO) auslesen.
  • Du möchtest auf jeden Fall vermeiden, dass BW/4HANA für 2 Sätze mit dem gleichen Schlüssel alle Merkmale des Satzes mit denen des zuletzt geladenen Satzes überschreibt.

Die Nachteile beim Verzicht auf Schlüsselfelder:

  • Sätze werden nicht eindeutig identifiziert => so besteht die Möglichkeit doppelter Sätze.
  • Die Performance wird beeinträchtigt.

Die Vorteile des Einsatzes von ADSOs anstelle von klassischen DSOs:

  • Vereinfachung von Objekttypen
    • Kann sich wie 4 Objekte im klassischen BW verhalten.
  • Flexibilität bei der Datenmodellierung
    • Modellierung deines ADSOs über die Einstellungen der Reporting-Schicht.
  • Performance beim Datenladen und der Aktivierung ist HANA-optimiert, da es sich bei ADSOs um native HANA-Objekte handelt.

Quellenangabe der Bilder: SAP SE, Inspiricon AG

Autor dieses Beitrags
Roxana Hategan Associate
Tel.: +49 (0) 7031 714 660 0
E-Mail: cluj@inspiricon.de