SAP Datasphere
SAP Datasphere ist die neue Generation des Cloud-Products der SAP für den Bereich Data Warehousing, welches im März 2023 veröffentlicht wurde. Es ist der Nachfolger der SAP Data Warehouse Cloud (DWC) und stellt somit das Gegenstück zu den etablierten on premise Produkten SAP BW on HANA und SAP BW/4HANA dar. Der Funktionsumfang ist noch etwas eingeschränkt, wächst jedoch stetig an, so dass die Datasphere für mehr und mehr Unternehmen als Analytics-Produkt in Frage kommt.
Die SAP betrachtet die Datasphere als das zukünftige Produkt im Analytics-Umfeld, auf das spätestens 2040, zum geplanten Ende des Supports für BW/4HANA, alle Kunden migrieren sollen. Ob es tatsächlich so kommen wird, bleibt abzuwarten.
Das Analytic Model und seine Positionierung
Der Data Builder bekommt mit dem Analytic Model ein neues Modellierungsobjekt, das die Funktionen von bestehenden Objekten zusammenfasst und von der SAP als „THE go-to analytic consumption entity for both Data Layer & Business Layer“ (Quelle: SAP) bezeichnet wird.
Der Data Builder besteht im Wesentlichen aus Tabellen und Views, denen eine semantische Verwendung zugeordnet wird. Die Semantik „Analytical Dataset“ beschreibt dabei die Verwendung für analytisches Reporting, z. B. mit Reportinganwendungen, wie der SAC. Das „Relational Dataset“ ist dagegen als reine Tabelle für die Verwendung in anderen Modellen bzw. zur Weitergabe an externe Systeme anzusehen. Während das Relational Dataset weiterhin existiert, werden die Funktionen des Analytical Dataset in das neue „Analytic Model“ überführt und das Analytical Dataset damit in absehbarer Zeit obsolet.
Der Business Builder ist gedacht, um bestimmten Fachbereichsanwendern mit technischem Know How das Anlegen und Bearbeiten von Datenmodellen zu ermöglichen und zentrale Unternehmensdaten mit eigenen Daten zu kombinieren. Objekte des Business Builders basieren dabei in der Regel auf Objekten des Data Builders. Momentan stehen die folgenden Objekte zur Verfügung: Dimension, Analytical Dataset (nicht zu verwechseln mit der Semantik Analytical Dataset im Data Builder), Fact Model, Consumption Model und Perspective. Hiervon werden Fact Model und Consumption Model in das neue Analytic Model überführt und diese Objekte somit in absehbarer Zeit ebenfalls obsolet. Die Perspective als Schnittstelle zum Reporting wird ebenfalls durch das Analytic Model abgelöst.
Das neue Analytic Model ist somit der Nachfolger für insgesamt vier Objekttypen im Data Builder und Business Bilder.
Das Analytic Model wird im Data Builder angelegt und kann dessen Objekte zusammenführen. Es ist jedoch geplant, dass zukünftig auch Objekte des Business Builders als Quelle verwendet werden können. Damit wird die bisherige Architektur, die den Business Builder über dem Data Builder sieht, insofern aufgelöst, dass Objekte des Business Builders wiederum im Data Builder verwendet werden können. Es bleibt abzuwarten, wie sich das auf das angedachte Szenario auswirkt, dass Fachbereichsanwender Objekte im Business Builder bearbeiten. Wenn jede Änderung im Business Builder eine Anpassung der IT im entsprechenden Analytic Model zur Folge hat, fördert das nicht die propagierte Agilität und schränkt den Self-Service erheblich ein.
Die Funktionen des Analytic Models
In diesem Kapitel wird zunächst auf die wesentlichen Funktionen des Analytic Models eingegangen und deren Funktion veranschaulicht.
1. Definition von eingeschränkten und berechneten Kennzahlen
Berechnete Spalten sind eine oft genutzte Modellierungsoption und in grafischen und SQL Views aller Arten verfügbar. Im Vergleich zu den Views im Data Builder erfolgt die Berechnung im Analytic Model jedoch nicht auf Einzelsatzebene, sondern auf Basis der aggregierten Daten, je nach Aufriss und ggf. eingestellter Ausnahmeaggregation. In Abhängigkeit von dem konkreten Datenmodell kann das zu unterschiedlichen Ergebnissen führen, so dass beim Design genau geprüft werden sollte, wo welche Berechnung ausgeführt wird. Die Möglichkeit eingeschränkte Kennzahlen zu definieren, ist im Data Builder gänzlich neu.
Für Nutzer des Business Builders sind die eingeschränkten und berechneten Kennzahlen dagegen nichts neues, hier gab und gibt es diese Funktionalität bereits.
2. Analytische Datenvorschau im gewohnten Layout des SAC Data Analyzer
In Views des Data Builders gibt es die Möglichkeit einer Datenvorschau. Bei grafischen Views sogar an jedem einzelnen Knoten. Diese Vorschau ist jedoch immer auf Einzelsatzebene ohne Aggregationsmöglichkeit. Die Datenvorschau im Analytic Model basiert dagegen auf dem aus der SAC bekannten Data Analyzer und eignet sich für die Vorschau aggregierter Daten, wobei auch ein Drilldown bis auf Einzelsätze möglich ist.
Im Business Builder gibt es bereits die Möglichkeit der Vorschau aggregierter Daten, wobei diese im Vergleich zum neuen Analytic Model sehr eingeschränkt ist. Hier bietet das Analytic Model einen echten Vorteil zu den bisherigen Objekten.
3. Join mit Texten und Attributen, über mehrere Stufen hinweg und mit Zeitabhängigkeit
Über so genannte Assoziationen ist es möglich einem Feld in den Bewegungsdaten ein Stammdatenobjekt (Dimension bzw. Text) zuzuordnen und somit Texte und Attribute für die Analyse bereitzustellen. Dies entspricht der Verwendung von Info Objekten mit Texten und Attributen in SAP BW Systemen und war bereits bei den bestehenden Objekten des Data Builders und Business Builders möglich. Neu ist jedoch, dass auch Assoziationen für Felder einer assoziierten Dimension als Attribute verfügbar sind. Dies ist über mehrere Stufen hinweg möglich und somit ein deutlicher Vorteil zu den bisherigen DWC-Objekten und sogar zum SAP BW, welches dies nur über zwei Stufen in Form von transitiven Attributen ermöglicht. Die folgende Abbildung zeigt zum Beispiel eine Faktentabelle „SalesView Test“, bei der die Dimension Products über das Feld PRODUCTID assoziiert ist. Die Product-Dimension hat dann wiederum zum Feld CREATEDBY und CHANGEDBY die Dimension mit User mit Stammdaten zum Benutzer assoziiert.
Texte und Attribute können zeitabhängig mit entsprechenden Gültigkeitsintervallen angelegt werden. Der Gültigkeitstag wird bei Berichtsausführung über eine entsprechende Variable definiert.
Leider ist es bislang noch nicht möglich die Felder umzubenennen, so dass das Beispiel die Felder „Vorname“ und „Nachname“ doppelt enthält: Einmal für den Ersteller und einmal für den letzten Änderer.
- Data Pruning assoziierter Dimensionen: Nur tatsächlich benötigte Joins werde ausgeführt
Auch dies ist eine aus dem Business Builder bekannte Funktion, die nun auch im Data Builder verfügbar ist. Unabhängig davon, welche Dimensionen, ggf. über viele Stufen hinweg, im Datenmodell assoziiert sind, werden beim Lesen der Daten nur die Tabellen derjenigen Dimensionen tatsächlich gelesen und mit den Bewegungsdaten verknüpft, die für den angefragten Aufriss erforderlich sind.
Im Data Builder führten viele assoziierte Dimensionen insbesondere bei großen Datenmengen schnell zu einer schlechten Performance, weil alle Dimensionen stets mit geladen wurden.
Da das Analytic Model in der MDS-Engine ausgeführt wird, lässt sich leider in der Entwicklungsumgebung nicht so einfach ein SQL-Statement erzeugen und analysieren, wie das bei Views der Fall ist. Über den Datenbankexplorer sind jedoch verschiedene Calculation Views sichtbar, die das Analytic Model abbilden und die für Performanceanalysen genutzt werden können (vgl. Abbildung 4). Alternativ kann der SQL-Funktion SYS.EXECUTE_MDS das entsprechende JSON-Statement als Parameter übergeben und dann das Ergebnis analysiert werden.
Zum Testen der Pruning Funktionalität wird zunächst eine Abfrage erstellt, die lediglich den Bruttowert pro Periode anzeigt. Die zugehörige PlanViz-Datei bestätigt, dass nur die Tabellen SalesOrders und SalesOrderItems gelesen werden (vgl. Abbildung 5).
Erst wenn Attribute der assoziierten Dimensionen in die Abfrage mit einbezogen werden, wird auch die Produkt- bzw. Benutzertabelle gelesen.
Somit bestätigt es sich, dass tatsächlich nur auf die wirklich benötigten Dimensionen zugegriffen wird und es im Gegensatz zu den bisherigen Objekten des Data Builders nicht mehr schädlich ist sämtliche Quellen miteinander zu assoziieren.
Anhand der vier wesentlichen Funktionen wurde gezeigt, dass das Analytic Model viele neue Funktionen für den Data Builder bringt. Verglichen mit dem Business Builder sind die Vorteile jedoch sehr begrenzt und die Nachteile in Form von fehlenden Funktionen durchaus elementar. Dessen ist sich die SAP bewusst und plant sämtliche Funktionen des Consumption Models in das Analytic Model zu integrieren, um nach dem Analytical Dataset des Data Builders auch Fact and Consumption Model des Business Builders abzulösen.
Fehlende Funktionen sind derzeit unter anderem:
- Mehrere Datenquellen für Bewegungsdaten einzubinden
- Das Analytic Model als Quelle für weitere Analytic Models zu verwenden
- Das Analytic Model mit anderen Spaces zu teilen
Spätestens wenn das Analytic Model alle Funktionen der Business Layer Objekte abdeckt, wird es das zentrale Objekt fürs Reporting sein. Um spätere Migrationsaufwände möglichst gering zu halten, sollte bereits jetzt überlegt werden neue Datenmodelle mittels Analytic Model umzusetzen.
Und was wird nun aus dem Business Builder?
Die Frage kann an dieser Stelle nicht abschließend beantwortet werden. Nach Meinung des Autors stärkt das Analytic Model den Data Builder enorm und hinterlässt beim Business Builder viele Fragezeichen. Der Funktionsumfang der Business Builder Objekte wird in naher Zukunft vollständig im Analytic Model verfügbar sein, so dass Datenmodelle auch ohne Business Builder umsetzbar sind. Dann bleibt noch der Vorteil der Unterscheidung in der Zuständigkeit zwischen IT und Fachbereich. Aber welchen Vorteil bringt es den Fachbereich Dimensions und Analytical Datasets anlegen zu lassen, wenn jede Strukturänderung anschließend im Analytic Model von der IT aktualisiert werden muss? Eher vorstellbar ist ein separater Space, in dessen Data Builder der Fachbereich auf Basis von der IT geteilten Analytic Models eigene Analytic Models mit fachspezifischen Logiken erstellt. Daher erscheint das Ende des Business Builders absehbar.