Kernelement der persistenten Datenhaltung ist auf SAP BS4/HANA neben den Stammdaten der Attribute innerhalb der InfoObjecte, Typ Merkmal ausschließlich das advanced DataStore-Object. Während in den InfoObjecten Stammdaten handelt werden im aDSO vornehmlich Bewegungsdaten gespeichert. Durch die Optionen beim Tabellenaufbau auf einer SAP-HANA Datenbank entfällt die Notwendigkeit zum Sternschema, wie er beim InfoCube in der Welt des klassischen SAP BW verwendet wurde. Durch den flexibleren Aufbau kann das aDSO alle Aufgaben im Datenfluss der Bewegungsdaten übernehmen.
Beschreibung
Für die Benutzung sind die ersten drei Tabellen relevant:
- Eingangstabelle
- Aktive Daten
- Change Log
Die Nutzung ergibt sich aus der jeweiligen Modellierungsvariante. Die anderen Tabellen und Views sind von technischem Interesse.
Tabellen und Views
| Tabelle / View | Inhalt | Namenskonvention | Anmerkung |
|---|---|---|---|
| 1 (Tabelle) | Eingangstabelle | /BIC/A<technischer Name> 1 | |
| 2 (Tabelle) | Aktive Daten | /BIC/A<technischer Name> 2 | |
| 3 (Tabelle) | Change Log | /BIC/A<technischer Name> 3 | |
| 4 (Tabelle) | Validitätstabelle | /BIC/A<technischer Name> 4 | |
| 5 (Tabelle) | Referenzpunkte | /BIC/A<technischer Name> 5 | |
| 6 (View) | Sicht für Extraktion | /BIC/A<technischer Name> 6 | |
| 7 (View) | Sicht für Reporting | /BIC/A<technischer Name> 7 | |
| 8 (View) | Externer Zugriff | /BIC/A<technischer Name> 8 | Neu in SAP BW/4HANA 2.0 |
Change Log
Der Change Log ermöglicht eine nachvollziehbare Beladung eines aDSO innerhalb einer Deltabeladung. Hierzu werden die Datensätze des Request bei der Aktivierung zusammen mit technischen Informationen über den Request in die Tabelle des Change Log geschrieben.
Der Change Log ermöglicht die Rücknahme der Beladung (Löschung) aus dem Datenbestand eines aDSO ohne das Objekt neu extern beladen zu müssen.
Active Data
Die Trennung der Daten zwischen Aktivierten Daten und der Datenbeladung erhöht die und Nachvollziehbarkeit / Reproduzierbarkeit der Abfrageergebnisse und damit die Konsistenz
SnapShot
Der SnapShot ist eine Variante des aDSO, bei dem die Requests von Vollständigen Beladungen (FULL Load) nachvollziehbar gespeichert werden und die Daten zur Ladezeit nicht mehr in der Quelle reproduzierbar sind.
Sinnvoll um bei Open ODS – Views Persistenz herzustellen,
Modellierungsvarianten
Verwendung ist abhängig von den jeweiligen Anforderungen an das DWH, so können an einer Stelle im Datenfluss durchaus unterschiedliche Varianten zur Anwendung kommen.
Standard aDSO
Die Daten werden bei der Beladung zunächst in die Eingangstabelle geschrieben und anschließend bei der Aktivierung in die Tabelle mit den aktiven Daten fortgeschrieben. Das Reporting findet auf Basis der Aktiven Daten statt.
Das Standard aDSO hat die Optionen:
- Change Log schreiben (s. Standard aDSO mit ChangeLog)
- Snapshot – Unterstützung (s. Standard aDSO mit Snaphot)
- Eindeutige Datensätze
Standard aDSO mit ChangeLog
Durch die Verwendung des ChangeLog werden bei Deltabeladungen einzelne Beladungsvorgänge identifizierbar und können im Bedarfsfall zurückgerollt werden
Standard aDSO mit Snapshot
Verwendung:
Staging aDSO
Bei einem Staging aDSO wird nur die Inbound Tabelle vom DTP beschrieben. Eine Aktivierung der Daten ist nicht notwendig.
- Staging ohne Reporting
- Open Operational Data Store
- EDW Propagation Layer
- Corporate Memory
Staging aDSO mit Reporting
Verwendung:
- Staging mit Reporting
Staging aDSO mit Kompression
Verwendung:
Data-Tiering
Der Speicherplatz in einem HANA-System ist durch die Größe des Arbeitsspeichers begrenzt. Es muss immer ausreichend Speicher für dynamische Vorgänge (Abfragen) bereitgehalten werden.
Nicht alle Daten müssen permanent für einen Abfrageprozess im Arbeitspeicher gehalten werden. Diese können auf einen schnellen externen Datenspeicher ausgelagert werden. Im Bedarfsfall werden diese Daten automatisch zurück in den Arbeitsspeicher geladen. Dieses erhöht die Latenz der Abfragen etwas.
SAP hat ein System mit drei Wärmezohnen
| Rot | Heiße Daten | Daten, die permanent abgefragt werden |
| Gelb | Warme Daten | Daten, die regelmäßig, aber nicht dauernd abgefragt werden |
| Grün | Kalte Daten | Daten die nur selten in Abgefragt werden |
Semantische Partionierung
aDSO können partioniert werden.
aDSO können maximal 2 Mrd. Datensätze aufnehmen, müssen mehr Datensätze gespeichert werden, muss das aDSO partioniert werden.
Administration
Anlage
Kontextmenu einer InfoArea: Neu – DataStore – Objekt (advanced)
Notwendige Angaben:
- BW – Projekt
- Paket
- InfoArea
- Technischer Name
- Beschreibung (Text)
Als Vorlage für die Einrichtung eines aDSO können dienen:
- DataSources
- InfoProvider
- InfoObjects
- InfoSources