Nachdem wir uns in einem ersten Blogartikel mit dem Begriff der Modellgetriebenen Entwicklung im Allgemeinen und unserem Verständnis des Begriffs im Rahmen des SAPDie SAP SE mit Sitz im baden-württembergischen Walldorf ist ein… HANA SQL Data Warehousing auseinandergesetzt haben, möchten wir in diesem Blog tiefer in die Praxis einsteigen.
Dazu möchten wir das Vorgehen der Modellierung konkreter beleuchten und das Zusammenspiel der Modelle in der grundlegenden Modellstruktur des SAP HANA SQL DWH (Abbildung 1) in SAP PowerdesignerClientbasiertes Modellierungswerkzeug, welches ein Leistungsstarkes Modellierungswerkzeug darstellt. Hierbei können eine… praktisch erläutern.
Konzeptionelles Datenmodell
Das konzeptionelle Datenmodell dient der Aufnahme der fachlichen Anforderungen an das Data WarehouseEin Data Warehouse ist für die Ausführung, Überwachung und Steuerung…. Im Unterschied zu Vorgehensweisen mit Listen und ausformulierten Texten im Sinne von Lasten- und Pflichtenheften, fließen die Anforderungen unmittelbar in das konzeptionelle Datenmodell ein. Dies bietet den Vorteil, dass die Strukturen konkret für den weiteren Modellierungsverlauf aufbereitet und Risiken für Unklarheiten und Interpretationsspielräume minimiert werden.
Das Modellierungstool SAP PowerDesigner, das wir für die Umsetzung des modellgetriebenen Ansatzes empfehlen, bringt für das konzeptionelle Datenmodell einen entsprechenden Modelltyp mit (Conceptual Data Model, kurz CDMKonzeptionelles Daten Model, zur logischen Beschreibung von Business Entitäten (Abhänbgigkeiten,…). In diesem können im Stil eines Entity-Relationship-Model die vom Fachbereich benötigten Informationsstrukturen erarbeitet werden. Dabei sind insbesondere vier Aspekte von Bedeutung:
- Das Identifizieren der geschäftlichen Entitäten/Subjekte, die ausgewertet werden sollen
- Das Identifizieren der Business Keys, mit denen sich Entitäten/Subjekte im Geschäftskontext eindeutig identifizieren lassen
- Das Identifizieren der
- Das Identifizieren der Beziehungen der Entitäten/Subjekte im konkreten geschäftlichen Auswertungskontext
- Das Identifizieren der relevanten Attribute, die zur Auswertung benötigt werden
- Das Identifizieren der relevanten Kennzahlen
- Die Definition der betriebswirtschaftlichen Bedeutung der Entitäten und Kennzahlen
Abbildung 2 zeigt den Ausschnitt eines nach diesen Maßgaben erstellten konzeptionellen Datenmodells in SAP PowerDesigner. Es sind Entitäten eines klassischen Vertriebsszenarios zu sehen, in dem Kunden, Produkte und Verkäufe sowie weitere Entitäten mit den wichtigsten Kontextdaten zueinander in Beziehung gesetzt sind.
Das Modell wirkt daher zunächst simpel. Dies sollte allerdings nicht darüber hinwegtäuschen, dass es sich bei der Erstellung des konzeptionellen Datenmodells mit dem Fachbereich um eine sehr anspruchsvolle und wichtige Aufgabe handelt. Die hier erarbeiteten Definitionen dienen den Entwicklern im weiteren Verlauf als Arbeitsgrundlage und ein sauber ausgearbeitetes Modell vermeidet Unklarheiten im weiteren Verlauf der DWH-Entwicklung.
Datenmodell der Quellsysteme
Einhergehend mit der konzeptionellen Modellierung werden die Quellsysteme, aus denen die Datenstrukturen des konzeptionellen Datenmodells gespeist werden, untersucht und ein oder mehrere Modelle der Quellstrukturen erstellt. In der Regel liegen ein Großteil der benötigten Daten in den Quellsystemen bereits in geordneten Strukturen vor. SAP PowerDesigner bietet hier den Vorteil, dass aus nahezu allen heute üblichen Datenbankmanagementsystemen (DBMS) Modelle automatisch generiert werden können.
In diesem Schritt geht es daher lediglich darum, das DBMS der Quelle zu identifizieren, es mit SAP PowerDesigner zu verbinden und über ein Reverse Engineering die Datenstrukturen im Format des zugrundeliegenden DBMS zu laden sowie gegebenenfalls im generierten grafischen Modell weiter aufzubereiten. Neben dem direkten Zugriff auf Quellsysteme über den Schnittstellenstandard ODBC kann der Import auch über exportierte Skripte, die die Datenstrukturen definieren, oder Aufbereitungen in Excel erfolgen.
Abbildung 3 zeigt ein Beispiel, in dem auf diesem Weg Tabellen eines S4/HANA-Systems in PowerDesigner geladen wurden. In der Baumstruktur auf der linken Seite sind die Tabellen dem Physischen Datenmodell (PDMPhysikalisches Daten Model, zur technischen Beschreibung von Business Entitäten, welche…) „Reverse“ zugeordnet.
Quellgetriebenes Datenmodell
Auf die Modellierung der Quellsysteme folgt grundsätzlich ein weiteres Modell, das zum einen die spezifischen Formate der Quellsysteme in das Zielformat der SAP-HANA-Datenbank überführt und zum anderen leichte inhaltliche Modifizierungen enthält. Dieses quellgetriebene Datenmodell dient der Datenbeschaffung und definiert die Dateneingangsschicht des SAP HANA SQL DWH. In der Regel handelt es sich hierbei um einen Staging-Bereich, in dem Die Daten kurzzeitig gehalten werden, um sie dann in die zentrale Persistenzschicht (nächste Abschnitt Core Datenmodell) zu übernehmen. Bei den Modifizierungen, die hier an der Modellierung der Quellsysteme vorgenommen werden, handelt es sich dementsprechend vornehmlich um Zeitstempel und Angaben zu den Quellsystemen, aus denen die Daten stammen.
Wir empfehlen dieses quellgetriebene Vorgehen, um eine klare Trennung zwischen Dateneingangsseite und Datenausgabeseite im Data Warehouse zu haben. Sowohl die Dateneingangsseite als auch die Datenausgangsseite werden hierdurch robust im Hinblick auf Veränderungen der Datenkonstellationen im Lebenszyklus des DWH. Auf Dateneingangsseite ist zudem die gute Nachverfolgung der Datenlinien und ihrer Veränderungen hervorzuheben.
Die Umsetzung des quellgetriebenen Datenmodells aus dem oder den Modellen der Quellsysteme kann aufgrund der kleinen und schematischen Veränderungen in SAP PowerDesigner automatisiert erfolgen. Das Modell wird wie die eingangs verwendete Abbildung 1 darstellt aus den Quelldarstellungen generiert.
Abbildung 4 zeigt beispielhaft die Umsetzung in SAP PowerDesigner. In der Baumstruktur auf der linken Seite ist das PDM_Stage zu sehen. Durch die Generierung aus dem PDM_Reverse, sind die Tabellen des Quellsystems S4/HANA als Shortcut enthalten. Die aus diesen Quelltabellen generierten Zielobjekte verfügen über das Präfix „ST_“ für Stage und sind im HANA-spezifischen Strukturformat zur Persistierung ausgestaltet. Die Spaltenübersicht zur Entität ST_KNA1 zeigt, dass lediglich drei Attribute hinzugefügt wurden. Diese Anreicherung bereitet den von uns im Core Datenmodell ((mehr dazu im nächsten Abschnitt Core Datenmodell)empfohlenen Modellierungsansatz Data Vault vor und wird schematisch für alle Tabellen des quellgetriebenen Datenmodells vorgenommen. Hier sind jedoch auch andere Vorgehensweisen möglich, die das grundlegende Prinzip unterstützen.
Core Datenmodell
Das Core Datenmodell definiert die zentrale Persistenzschicht des SAP HANA SQL DWH, in der die Daten subjektorientiert, integriert und historisiert gespeichert werden. In dieses Modell fließen daher wesentliche Teile des quellgetriebenen Datenmodells ein, die jedoch anhand der Anforderungen des konzeptionellen Datenmodells zu modifizieren sind. Wie stark diese Modifizierungen ausfallen, hängt vom gewählten Modellierungsansatz ab.
In dem von uns empfohlenen Data-Vault-Ansatz erfolgt im Core Datenmodell eine Unterscheidung zwischen der Persistierung roher Quelldaten im sogenannten Raw Data Vault und einer darauf aufbauenden optionalen Persistierung von transformierten Daten im Business Vault. Dieses Vorgehen dient ebenfalls der zuvor beschriebenen klaren Trennung der Dateneingangs- und Datenausgangsseite des SAP HANA SQL DWH.
Die Objekte des Raw Data Vault können in SAP PowerDesigner aufgrund sehr schematischer Regeln mithilfe des konzeptionellen Datenmodelles aus dem quellgetriebenen Datenmodell generiert werden. Für Objekte des Business Vaults, die Daten nach individuellen Geschäftslogiken (Soft Business Rules) transformieren ist eine händische Modellierung notwendig. Hierbei ist jedoch zu beachten, dass der Business Vault eine Option zur Persistierung individuell transformierter Daten zur Erhöhung der Abfrageperformance darstellt. Grundsätzlich dienen die nachfolgenden analytischen Datenmodellen diesem Zweck, sehen allerdings eine rein virtuelle Abfrage der Daten aus der Core-Schicht vor (mehr dazu im nächsten Abschnitt Analytische Datenmodelle).
Abbildung 5 zeigt ein beispielhaftes PDM_Core. In der Baumstruktur sind die Entitäten des Modells zu erkennen. Sie tragen Präfixe, die zum einen eine Zuordnung zum Raw Data Vault (R) und zum Business Vault (B) möglichen machen sowie eine Unterscheidung der in diesem Modellierungsansatz verwendeten Objekttypen Hubs (H), Links (L) und Satellites (S). Diese Typen sind im grafischen Diagramm darüber hinaus durch unterschiedliche Farben gekennzeichnet.
Analytische Datenmodelle
Der letzte Schritt des modellgetriebenen SAP HANA SQL Data Warehousing besteht darin, die Datenstrukturen auf Datenausgabeseite des DWH zu definieren. Die SAP-HANA-Plattform stellt mit den Calculation Views einen eigenen Standard zur rein virtuellen, grafischen Modellierung zur Verfügung, der hierzu sehr gut genutzt werden kann.
Entsprechend dem Vorgehen in Abbildung 1 werden dazu die Objekte des Core Datenmodells als Quelle der Calcualtion Views verwendet und nach Maßgabe des konzeptionellen Datenmodells die Transformationen und Berechnungen in den Calculation Views vollzogen. Je nach Architektur können die Calculation Views dabei in mehreren aufeinander aufbauenden Modellen, beispielsweise in einer Data-Mart-Bus-Architektur mit einer zentralen Ausgabeschicht, die verschiedene Data Marts bedient, definiert werden.
Die Calculation Views können im SAP PowerDesigner aktuell zwar im Vergleich zur eigentlichen Entwicklungsumgebung SAP Web IDE nur rudimentär modelliert werden. Dennoch ist die Vornahme auch in SAP PowerDesigner zu Dokumentationszwecken ratsam, da nur hier die Datenlinie über den gesamten Prozess des SAP HANA SQL Data Warehousing nachgezeichnet werden kann. Darüber hinaus gehen wir davon aus, dass die Funktionalitäten von SAP PowerDesigner und SAP Web IDE zukünftig auch für die Calculation Views weiter aufeinander abgestimmt werden und eine Vorwärtsmodellierung auch im Bereich der analytischen Modelle möglich wird.
Abbildung 6 zeigt die bespielhafte Aufbereitung eines Data Marts, der sich aus verschiedenen Calculation Views in Form eines Star Schema mit zentraler Faktentabelle (Cube Calculation View) zusammensetzt. In der Baumstruktur am linken Rand ist zu erkennen, dass die Calculation Views in diesem Data MartEin Data Mart umfasst einen Teilausschnitt eines Data Warehouses und… DM nur als Shortcut, also als Verknüpfung angelegt sind. Die eigentliche Modellierung der Calculation Views findet im vorgelagerten zentralen Model PDM_VAL (für Virtual Analytical Layer) statt. Hier werden alle Entitäten des konzeptionellen Datenmodells in Calculation Views umgesetzt und können im Anschluss für unterschiedliche Data Marts genutzt werden.
Fazit
In diesem Blog haben wir Ihnen einen weiteren Einblick in die modellgetriebene Entwicklung des SAP HANA SQL DWH gewährt und das praktische Vorgehen mit SAP PowerDesigner erläutert. Wir haben das Ineinandergreifen der verschiedenen Modelle verdeutlicht und den Ablauf der Modellierung mit Screenshots aus SAP PowerDesigner nachgezeichnet.
Für ein detailliertes Bild empfehlen wir Ihnen unser Buch SQL Data Warehousing mit SAP HANA, dass Sie beim Rheinwerk Verlag oder im Buchhandel erstehen können.
In diesem haben wir neben allgemeinen Informationen eine detaillierte Klickanleitung auf Basis von Beispieldaten für Sie zusammengestellt, mit der Sie den Modellierungsarbeiten in SAP PowerDesigner einmal konkret durchspielen können.
Darüber hinaus stehen wir Ihnen für individuelle Fragen selbstverständlich jederzeit zur Verfügung und freuen uns über Ihre Anfrage.
Autoren: Martin Peitz
Stefan Kahle
Senior Executive Manager
SAP Information Management
stefan.kahle@isr.de
+49 (0) 151 422 05 430
