SAPDie SAP SE mit Sitz im baden-württembergischen Walldorf ist ein… Mehr BW bedeutet unflexibler, träger und teurer Monolith? Das muss nicht sein! Mit SAP BW/4HANASAP BW/4HANA ist die aktuelle Data Warehouse Lösung basierend auf… Mehr kann die Data WarehouseEin Data Warehouse ist für die Ausführung, Überwachung und Steuerung… Mehr Entwicklung wesentlich iterativer erfolgen als bisher.
Gilt also nun: SAP BW/4 HANA = Schlanker, schneller…billiger? Es kommt auf Ihre Architektur an! Mit unserem Beitrag möchten Ihnen einen Eindruck geben warum mit SAP BW/4 HANA (endlich) Datenmodelle ermöglicht, die flexibel auf Änderungen reagieren!
Inhaltsverzeichnis
1. Unser Szenario: Iteration 1
2. Unser Szenario: Iteration 2 und 3
Weitere Informationen
Lesen Sie hier auch unser Blogartikel zum Thema „Agiles Data Warehousing mit SAP BW/4HANA“
Unser Szenario: Iteration 1
Wir möchten Bestellungen auswerten. Das Datenmodell ist in der untenstehenden Abbildung schematisch beschrieben.
Datenmodell: Iteration 1
Abbildungsmöglichkeiten mit SAP BW/4HANA
Klassische SAP BW Datenmodellierung
In bisherigen SAP BW Systemen (ohne HANA) hätte man ein solches Datenmodell im SAP BW in etwa wie folgt abgebildet. Für den Lieferanten, Produkte und Produktgruppe wäre ein InfoObject erstellt und in den InfoCube eingefügt worden. Navigationsattribute etc. hätte man im Cube & MultiProvider aktivieren müssen.
Dynamic flexible Star Schema
Mit HANA und dem Composite Provider ist das dynamic flexible Star Schema gekommen. Die Semantik kann unabhängig von der Quelle im Composite Provider definiert werden.
In dem Quell-aDSO kann auf InfoObjectsInfoObjects sind betriebswirtschaftliche Auswertungsobjekte, welche sich in Merkmale, Kennzahlen, Einheiten,… theoretisch ganz verzichtet werden. Der InfoCube als Aggregat ist ohnehin nicht mehr notwendig. Die Stammdaten werden erst im Composite Provider assoziiert.
aDSO können zudem feldbasiert modelliert werden. Mussten in der Vergangenheit für einfache Flags oder Buchungstexte ebenfalls InfoObjects angelegt werden, obwohl die Felder keine weiteren Stammdaten beinhalten (Top-Down Modellierung), ist dies nun nicht mehr notwendig. Das Reporting kann auf einer Mischung aus Feldern und im Composite Provider assoziierten InfoObjects bestehen.
VirtualisierungMit Virtualisierung kann man dedizierte Server in kleinere virtuelle Server… Mehr der Stammdaten
Eine weitere Variante wäre es zusätzlich InfoObjects durch OpenODS Views (OOV) zu ersetzen. In unserem Beispiel gibt es OOV für den Lieferanten und die Produktattribute mit der Besonderheit, dass zwischen aDSO und OOV ein Calculation View sitzt. Der Calculation View hat zu diesem Zeitpunkt keine Funktion, außer größtmögliche Flexibilität für die Zukunft sicherzustellen. Werden Hierarchien benötigt, müssen diese weiterhin mit InfoObjects modelliert werden. Sofern die Stammdaten persistent im SAP BW gehalten werden sollen sind durch diese Architektur aDSO notwendig, welche die Daten halten. Dies kann feldbasiert erfolgen.
Unser Szenario: Iteration 2 und 3
In den folgenden Iterationen wird unser Szenario erweitert um weitere Informationen zu dem Lieferanten. Dabei kommen die Informationen der Branche und Region jeweils aus anderen Quellen als die bisherigen Stammdaten. Wie werden diese Iterationen in unseren Datenmodellvarianten abgebildet?
Datenmodell: Iteration 2
Datenmodell: Iteration 3
Klassische SAP BW Datenmodellierung
In älteren SAP BW Systemen hätte man das InfoObject Lieferant erweitern müssen, um die Attribute aufzunehmen. Zudem muss man den Cube und MultiProvider anpassen. Über die Zeit wird so ein großes Stammdatenobjekt geschaffen, welches zunehmend unflexibel gegenüber Änderungen wird.
Nicht ohne Grund haftet dem SAP BW der Ruf an unflexibel zu sein und teuer in Bezug auf Änderungen. Zum Glück müssen wir so nicht mehr arbeiten.
Dynamic flexible Star Schema, Dimension Satellites und Snowflaking
Mit dem dynamic flexible Star Schema ist auch die Möglichkeit für Dimension Satellites eingeführt worden. Ein Feld eines aDSO kann im Composite Provider mehrfach assoziiert werden.
In unserem Szenario kommen die Informationen zu Branche und Region aus unterschiedlichen Systemen. Ein direkter technischer Zusammenhang besteht nicht. Es ist sinnvoll, dass die Stammdaten in gekapselten Satelliten abgelegt werden. Wir erhalten drei InfoObjects für den Lieferanten
- Lieferant: Attribute System 1
- Lieferant: Branche
- Lieferant: Region
Durch die virtuelle Assoziierung im Composite Provider muss das persistente Datenmodell für die Bestellungen nicht angepasst werden. Der Vorteil liegt darin, dass wir über die Bildung von Satelliten kleinere Einheiten schaffen, die flexibler auf künftige Änderungen reagieren können. Durch Snowflaking bzw. transitive Attribute ist es zudem möglich die Produktgruppe als zusätzliches Feld in den Composite Provider aufzunehmen. Dabei verhält es sich wie ein eigenes originäres Feld. Navigationsattribute der Produktgruppe können genutzt werden.
Bei der Bildung der Dimension Satellites sollte sicherlich jeweils die Sinnhaftigkeit geprüft werden. Wenn die Branche bspw. ein Feld aus der gleichen Quelltabelle ist, woher auch die übrigen Stammdaten kommen, macht ein extra Satellit keinen Sinn. Kriterien für die Bildung von Satelliten können bspw. die Volatilität des Datenmodells sein (wie häufig kommt es zu Änderungen an Datenmodellstrukturen) oder aber die Änderungshäufigkeit (wie häufig muss ein Satellit beladen werden). In Projekten haben wir Satelliten auch dann gebildet, wenn einige Attribute eine Merkmalsklammierung (z.B. Buchungskreis) benötigt haben und andere Attribute nicht. Durch die Aufteilung auf zwei Satelliten können für geeignete Attribute Summen gebildet werden in Berichten, ohne das ein geklammertes Feld benötigt wird wie in klassischen SAP BW Modellen der Fall gewesen ist.
Die Menge an Dimension Satellites bilden logisch Business Entitäten/Objekte ab. In unserem Beispiel bilden mehrere InfoObjects die Business Entität Lieferant. Dies kann Herausforderungen an die Transparenz des Datenmodells stellen, wenn in Composite Provider an mehr Objekte gedacht werden muss. Möchte man die Stammdaten über InfoObjects modellieren wäre ein möglicher Ausweg die Bildung eines sog. „Link“ InfoObjects. Hierbei werden die jeweiligen InfoObjects als Attribute in ein zentrales InfoObject Lieferant eingefügt. Im Composite Provider können die Attribute der „verlinkten“ InfoObjects als transitive Attribute aktiviert werden. Den Gewinn an Transparenz erkauft man sich jedoch mit etwas weniger Flexibilität. Auf transitive Attribute der verlinkten InfoObjects kann so nicht mehr zugegriffen werden. Zudem wird ein zusätzlicher Join ausgeführt, welcher gerade bei sehr großen Modellen Performancenachteile bringen dürfte.
Möglichkeit für „Link IOBJ“ erläutern bei der mehrere Satelliten IOBJ zu einem IOBJ zusammengefasst werden
Virtualisierung der Stammdaten
Die virtuelle Art der Stammdatenmodellierung ist dann besonders wertvoll, wenn sich Änderungen ergeben. Mag die Modellierung für den Fall nur einer Stammdatentabelle oversized wirken, spielt der Ansatz nun seine Stärken aus.
Der Calculation View unterhalb des OOV lässt sich flexibel erweitern um weitere Satelliten die als aDSO modelliert worden sind. Der virtuelle OOV repräsentiert in diesem Fall die Business Entität Lieferant. Man hat beides: Eine sehr hohe Flexibilität durch Virtualisierung und gleichzeitig eine hohe Transparenz durch ein zentrales Business Objekt. Auch Konstrukte wie Snowflaking etc. lassen sich durch virtuelle Joins im Calculation View flexibel abbilden. Das Datenmodell könnte beliebig weiter skaliert werden. Unsere Analysen zeigen, dass auch große Szenarien performant funktionieren.
Mögliche weitere Iterationen
Weitere denkbare Erweiterungen des Datenmodells können auch in zusätzlichen Bewegungsdaten liegen wie etwa Plandaten zu den getätigten Bestellungen. Auch hier zeigt sich SAP BW/4 HANA flexibel. In dem einfachen Fall von Plandaten kann ein Composite Provider sehr gut via Unions oder einfachen Joins ein einheitliches Bild für das Berichtswesen bilden. Wird es komplexer und möchte man trotzdem auf Persistenzen verzichten eignen sich auch hier hervorragend Calculation Views zur Abbildung komplexer Sachverhalte.
Zusammenfassung
Wir hoffen, dass anhand der ziemlich einfachen Beispiele deutlich geworden ist wie sehr sich die Datenmodellierung durch SAP BW/4 HANA verändert. Neue, wesentlich flexiblere Datenmodelle und Vorgehensmodelle für die Entwicklung werden möglich. Insb. durch virtualisierte Datenmodelle lässt sich sehr gut eine agile und iterative Arbeitsweise bei der Entwicklung des SAP BW basierten Data Warehouse umsetzen.
Wir haben vier Prinzipien formuliert, welche nach unserer Einschätzung entscheidend sind für eine agile SAP BW Modellierung:
- Feldbasiert first, Entkoppelung von Persistenz und Semantik
- Vermeide unnötige Redundanzen, Virtualization first
- IOBJ nur wenn notwendig
- Modelliere Satelliten wo möglich
Sollten nun alle Datenmodelle nur noch virtualisiert werden? Sind InfoObjects (weitgehend) überflüssig? Eine generische Empfehlung für die Modellierung, welche für alle Fälle gilt, gibt es nicht. Die Virtualisierung von Stammdatenmodellen oder Transformationslogiken bieten eine sehr hohe Flexibilität. Werden allerdings lediglich SAP S/4 HANA Finance Daten ausgewertet ist diese i.d.R. gar nicht notwendig. Die Datenmodellierung setzt auf stabilen Strukturen auf, die sich kaum verändern. Zudem liefert der Business Content sofort nutzbare Stammdatenmodelle aus. Gleichzeitig kann es im selben SAP BW System bei anderen Quellen absolut notwendig sein, ein hochgradig virtualisiertes Datenmodell aufzusetzen.
Wie kommen Sie zu einem derartig flexiblen System? Kann Ihr System „migriert“ werden? Vielleicht eignet sich unser Vorgehensmodell für die Road-2-BW/4 HANA.
Christopher Kampmann
Senior Manager
SAP Information Management
christopher.kampmann@isr.de
+49 (0) 151 422 05 448
