AGILE DATENMODELLIERUNG MIT SAP BW/4HANA

Beitrag teilen

Share on xing
Share on linkedin
Share on facebook
Share on twitter

SAP BW bedeutet unflexibler, träger und teurer Monolith? Das muss nicht sein! Mit SAP BW/4HANA kann die Data Warehouse 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! 

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 unten stehenden 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 InfoObjekt 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 InfoObjekte 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 InfoObjekte 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 InfoObjekten bestehen. 

Virtualisierung der Stammdaten

Eine weitere Variante wäre es zusätzlich Info Objekte 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 Flexiblität für die Zukunft sicherzustellen. Werden Hierarchien benötigt, müssen diese weiterhin mit InfoObjekten 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 InfoObjekt 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 InfoObjekte 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 InfoObjekte 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 InfoObjekte modellieren wäre ein möglicher Ausweg die Bildung eines sog. „Link“ InfoObjekts. Hierbei werden die jeweiligen InfoObjekte als Attribute in ein zentrales InfoObjekt Lieferant eingefügt. Im Composite Provider können die Attribute der „verlinkten“ InfoObjekte als transitive Attribute aktiviert werden. Den Gewinn an Transparenz erkauft man sich jedoch mit etwas weniger Flexibilität. Auf transitive Attribute der verlinkten InfoObjekte 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:

  1. Feldbasiert first, Entkoppelung von Persistenz und Semantik
  2. Vermeide unnötige Redundanzen, Virtualization first
  3. IOBJ nur wenn notwendig
  4. Modelliere Satelliten wo möglich
 

Sollten nun alle Datenmodelle nur noch virtualisiert werden? Sind InfoObjekte (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. 

SAP_Kamp

KONTAKT

Christopher Kampmann
Senior Manager
SAP Information Management

christopher.kampmann@isr.de
+49 151 422 05 411

Über ISR

Die ISR Information Products AG ist Ihr Experte für Analytics, Prozess-Digitalisierung und Application Management. Mit Blick auf die Bedürfnisse namhafter Kunden konzipieren, modernisieren, implementieren und betreuen ca. 200 Mitarbeiter an sechs Standorten IT-Architekturen, Software-Lösungen und IT-Infrastrukturen. Das Ziel: Unseren Kunden die wirtschaftliche Nutzung von Daten zu ermöglichen.
News Kategorien
News Archiv

News nach Autoren

Zuletzt erschienen

Nächste ISR Events

Do 13

DWC – Das Ende von SAP BW?

13. August um 10:0010:45

ISR Facebook Feed

Facebook

Mit dem Laden des Beitrags akzeptieren Sie die Datenschutzerklärung von Facebook.
Mehr erfahren

Beitrag laden