Geänderte Anforderungen an moderne Data-Warehouse-Systeme bedeuten, dass Aspekte wie Einfachheit, Flexibilität und Agilität deutlich wichtiger werden, und somit in der Architektur und Modellierung eben solcher Systeme inhärent berücksichtigt werden sollten.
SAPDie SAP SE mit Sitz im baden-württembergischen Walldorf ist ein… bietet mit ihrem Data-Warehouse-Produkt, SAP BW4/HANA, die Möglichkeiten, über eine starre und veraltete Layered Scalable Architecture (LSA) hinaus auch solche modernen Architekturen umzusetzen. SAP empfiehlt dabei eine Architektur, die sich an der LSA++ orientiert. Dieser neue Schichten-Ansatz zeichnet sich besonders durch den Fokus auf virtuelle Objekte aus. VirtualisierungMit Virtualisierung kann man dedizierte Server in kleinere virtuelle Server… bedeutet, dass weniger Kopien von Daten zwischen Architektur-Schichten notwendig sind, wodurch deren Design einfacher, kleiner und schneller wird. Die Data-Warehouse-Architektur soll so möglichst schlank und einfach gestaltet werden.
Inhaltsverzeichnis
1. Virtualisierung der Stammdaten
2. Modellierung der Stammdaten
3. Assoziationsmöglichkeiten und Grenzen
4. Fazit
Weitere Informationen
Lesen Sie hier auch unser Blogartikel zum Thema „Agiles Data Warehousing mit SAP BW/4HANA“
Virtualisierung der Stammdaten
Ein wesentlicher Faktor im Entwurf einer solchen flexiblen Architektur kommt dabei der Modellierung und Verwendung von Stammdaten zu.
Die klassische Modellierung im BW-Umfeld von Stammdaten als InfoObjects (direkt verwendet in den persistierten Bewegungsdaten) sicherte eine hohe Wiederverwendung und Konsistenz, führt jedoch auch dazu, dass die Semantik in der Auswertung schon fest mit in den Bewegungsdaten verbunden ist („Klassisches Star Schema“). Flexibilität und Agilität sind damit deutlich schwerer zu erreichen.
Mit HANA und dem Composite Provider ist das „Dynamic flexible Star Schema“ gekommen. Die Semantik der Daten für die Auswertung kann dabei unabhängig von der Quelle im Composite Provider definiert werden. Das Star Schema wird nicht mehr durch persistente Objekte definiert, sondern nur noch virtuell durch einen Composite Provider oder OpenODS View auf Bewegungsdaten, welche durchaus auch feldbasiert abgebildet sein können. InfoObjects, das heißt weitere beschreibende Informationen und Semantiken, können virtuell bei Bedarf dazu gelesen („assoziiert“) werden.
Eine weitere Variante ist es, InfoObjectsInfoObjects sind betriebswirtschaftliche Auswertungsobjekte, welche sich in Merkmale, Kennzahlen, Einheiten,… durch OpenODS Views (OOV) zu ersetzen. Durch die OOV können die Stammdaten virtualisiert werden. Die Stammdaten, welche über einen OOV bereitgestellt werden, können dabei feldbasiert modelliert werden – InfoObjects sind nicht notwendig. Quellen eines OOV können neben BW eigenen (aDSO) und HANA nativen Quellen (HANA Calculation View), auch per Smart Data Access (SDASmart Data Access, um Quellsysteme mit einer JDBC/ODBC Verbindung an…) angeschlossene Systeme sein. In diesem Fall halt das SAP BW selbst keine Stammdaten.
Das „Dynamic flexible Star Schema“ verändert die Modellierung eines SAP BW wesentlich. Es ist nun möglich, das Star Schema nach Bedarf (dynamisch) um weitere Informationen zu ergänzen, ohne dass schon von Anfang an eine vollständige Dimensions- und Stammdatenmodellierung hätte stattfinden müssen. Stattdessen kann ein Datenmodell iterativ und bedarfsorientiert (weiter-)entwickelt werden, was die Agilität und Flexibilität eines solchen Data WarehouseEin Data Warehouse ist für die Ausführung, Überwachung und Steuerung… deutlich erhöht.
In diesem Artikel sollen die Möglichkeiten und Einschränkungen für die virtuelle Stammdatenmodellierung und Verwendung (via Assoziation im Composite Provider) näher beleuchtet werden.
Modellierung von Stammdaten
Im Dynamic flexible Star Schema stehen mehrere Möglichkeiten zur Modellierung der Stammdaten zur Verfügung:
1) Modellierung der Stammdaten als (gekapselte) InfoObjects
Das InfoObject stellt einen in sich abgeschlossen, durch das InfoObject gekapselten und wiederverwendbaren, Sachverhalt dar. Im Prinzip modelliert das InfoObject eine eigenständige Dimension im Star Schema.
Ein solches InfoObject hat folgende Eigenschaften:
- Modelliert eine vollständige Dimension des Star Schemas
- Stellt für einen Schlüsselwert verschiedene Semantiken bereit: beschreibende Attribute, Texte, Hierarchien
- Hat wenige oder keine Verknüpfungen zu anderen Dimensionen
2) Modellierung der Stammdaten als Satelliten-InfoObjects mit einem Link-InfoObject („Snowflaking“)
Durch die Möglichkeit, auch transitive Navigationsattribute zu verwenden, ergibt sich die Möglichkeit einer Modellierung von Stammdaten als Satelliten-InfoObjects.
Hierbei werden, ähnlich einer Modellierung im Data Vault Modell, separate Sachverhalte auch separat modelliert, und erst durch ein Link-InfoObject miteinander verbunden. Anstatt beispielsweise sämtliche beschreibenden Merkmale eines Kunden in ein InfoObject „Kunde“ zu pressen (und dabei in Kauf zu nehmen, dass Attribute teilweise sparse besetzt sind, oder Schlüssel auf einen gemeinsamen Datentyp harmonisiert werden müssen), wäre eine Modellierung als einzelne Satelliten „Industriekunden“ und „Privatkunden“ denkbar, welche jeweils unterschiedliche, individuelle Attribute aufweisen, und erst über ein Link-Objekt „Kundenstamm“ verbunden werden. Unterschiedliche Datentypen für die Primärschlüssel von Industrie- und Privatkunden stellen dabei kein Problem dar (solange übergreifend eine Eindeutigkeit gegeben ist).
Ein solches InfoObject hat folgende Eigenschaften:
- Modelliert und verbindet mehrere Dimensionen im Star Schema („Snowflaking“)
- Stellt für einen Schlüsselwert verschiedene Semantiken bereit: beschreibende Attribute, Texte, Hierarchien
- Link-Objekt kann flexibel um weitere Satelliten erweitert werden. Die „Entfernung“ eines Satelliten ist dagegen nur schwer möglich (Transitives Attribut „Industriekunden“ entfernen aus Link-InfoObject)
- Satelliten können flexibel um weitere Attribute erweitert werden, nicht jedoch ihrerseits wieder Satelliten beinhalten (mehr als 2-stufige transitive Attribute mit InfoObjects nicht abbildbar)
3) Modellierung der Stammdaten als OpenODS Views
Ganz ohne InfoObject kommt die Modellierung von Stammdaten als (feldbasierte) OpenODS Views aus. Hierdurch können schnell und einfach beliebige Daten als wiederverwendbare Stammdaten-Dimension zur Verfügung gestellt werden. Im einfachsten Fall verweist der OOV 1:1 auf ein aDSO und ist daran gekoppelt. Auch remote angebundene Stammdaten können so im SAP BW modelliert werden.
Das volle Potential ergibt sich nach unserer Einschätzung jedoch erst durch mixed Modellierung, bei denen der OOV auf einem HANA Calculation View basiert. Komplexes Snowflaking über mehrere Stufen und beliebige Satelliten hinweg (mehr als 2-stufige transitive Attribute) sind durch die Verwendung von HANA Calculation Views (zum Join der entsprechenden Basisdaten) möglich. Darüber hinaus bieten OpenODS Views die Möglichkeit, die gleichen Stammdaten über verschiedene Schlüsselwerte zur Assoziation zur Verfügung zu stellen, ohne dass es zu redundanten Persistenzen kommt.
Ein solcher OpenODS View hat folgenden Eigenschaften:
- Modelliert und verbindet flexibel mehrere Dimensionen im Star Schema („Snowflaking“)
- Feldbasiert, keine Notwendigkeit für Anlage von InfoObjects
- Stellt verschiedene Semantiken bereit: beschreibende Attribute, Texte
- Stellt die gleichen Stammdaten flexibel über mehrere Schlüssel bereit
- Kann flexibel um weitere Attribute und Satelliten erweitert werden, via Calculation Views in beliebiger Tiefe (mehr als 2-stufige transitive Attribute). Durch die Virtualisierung ist man zudem flexibler, falls Attribute entfernt werden sollen.
Verwendet werden diese Stammdaten jeweils via Assoziation mit entsprechenden Bewegungsdaten. Dies erfolgt im Composite Provider.
Assoziationsmöglichkeiten und Grenzen
Im BW/4HANA 2.0, Stand SPS01, sind bei solchen Stammdatenmodellen einige Restriktionen zu beachten:
- Bei Assoziation mit InfoObjects sind nur diejenigen Attribute des InfoObjects im generierten Calculation View des Composite Provider verfügbar, die im InfoObject auch schon als „Navigationsattribut“ deklariert wurden.
Die Verwendung von Anzeigeattributen aus InfoObjects ist in einem Feldbasierten Datenmodell via Assoziation nur BW-seitig möglich, nicht jedoch HANA-seitig – in dem Fall muss schon das InfoObject direkt in der Persistenzschicht verwendet werden (wie in der klassischen Star Schema Modellierung).
- Keine 2-stufige Assoziierung – ein über Assoziation hereingekommenes Nav-Attribut kann nicht selber wieder mit etwas assoziiert werden.
Schon die Modellierungs-UI im Eclipse bietet für Navigationsattribute erst gar nicht die Möglichkeit einer weiteren Assoziation an.Dies lässt sich (zumindest für die BW-seitige Bereitstellung) jedoch umgehen, in dem zuerst ein OpenODS-View vom Typ „Fakten“ die Bewegungsdaten mit den Stammdaten assoziiert.
Wird dieser OpenODS-View in einem Composite Provider verwendet, können die (über den Fakten-OOV hereingekommenen) Attribute zusätzlich nochmals mit InfoObjects assoziiert werden.
Dies funktioniert jedoch nicht, wenn auf dem Composite Provider anschließend noch HANA CalcViews für die HANA-seitige Konsumierung erzeugt werden (Warnung RS2HANA_VIEW151: „Navigationsattribut ist von der externen SAP-HANA-View ausgeschlossen“). Die über diese indirekte Assoziation hereingeholten Felder sind im generierten CalcView dann nicht enthalten.
- Die BW-Reporting-Vorschau auf dem Composite Provider in Eclipse zeigt die via Assoziation aufgenommenen Navigationsattribute nicht an.
In der BW-Cockpit Vorschau und via Frontend-Werkzeug (AfO, SACDie SAP Analytics Cloud (SAC) ist die Cloud-basierte Frontend-Lösung der SAP, welche die…) sind sie jedoch verfügbar.
- Der Datentyp muss exakt kompatibel sein, andernfalls schlägt die Assoziation zum Aktivierungszeitpunkt (Fehlermeldung), oder zur Laufzeit (keine Daten) fehl. Dies umfasst den Grunddatentyp (CHAR, NUMC, …), die Länge und die Alpha-Konvertierung.
- Assoziation mit geklammerten InfoObjects ist nur eingeschränkt möglich. Grundsätzlich kann eine Assoziation nur über ein eindeutiges Feld durchgeführt werden, zusammengesetzte Schlüssel sind nicht möglich. Dies gilt für OpenODS Views als auch InfoObjects. Ausnahmsweise kann jedoch mit einem geklammertem InfoObject (bspw. 0COSTCENTER) auch dann assoziiert werden, wenn das Klammerungsobjekt (hier: 0CO_AREA) schon als InfoObject im Moment der Assoziation (d.h. im Composite Provider oder einem Fakten-OOV) vorliegt. Für ein OpenODS View ist diese Ausnahme nicht möglich.
- Bei der Assoziation kann generell (sowohl für InfoObjects als auch für OpenODS Views) zwischen „Direktverwendung“ und „Systemweit eindeutiger Name“ gewählt werden.
Grundsätzlich:
- Bei der Direktverwendung wird der Name des OOV oder InfoObjects, mit welchem assoziiert wird, als technischer Name verwendet:
- Ursprungsfeldname KST, Assoziiert mit InfoObject 0COSTCENTER→ technischer Name im Composite: 0COSTCENTER
- Daher kann nur ein einziges Feld mit dem OOV oder InfoObject assoziiert werden.
- Gibt es im Datenmodell bspw. die Felder „Sendende Kostenstelle“ (SKST) und „Empfangende Kostenstelle“ (EKST), so ist es nicht möglich beide mittels Direktverwendung mit 0COSTCENTER zu assoziieren, da dies in doppelten technischen Namen resultieren würde.
- Bei der Direktverwendung wird der Name des OOV oder InfoObjects, mit welchem assoziiert wird, als technischer Name verwendet:
- Bei der Verwendung des „Systemweit eindeutigen Namens“ wird ein künstlicher technischer Name erzeugt, welche den Namen des Composite Providers und des Felds enthält:
- Ursprungsfeldname KST, Assoziiert mit InfoObject 0COSTCENTER, Composite ZTEST → technischer Name im Composite: 4ZTEST-KST
- Hierdurch können mehrere Felder mit demselben InfoObject oder OpenODS View assoziiert werden.
- In dem Fall gäbe es jedoch potentielle Namenskollisionen bei den Navigationsattributen, da dann über beide Assoziierungen die gleichen Attribute hinzugezogen werden können, bspw. 0COMP_CODE.
- Daher werden die technischen Namen der Navigationsattribute ergänzt: 0COMP_CODE, 0COMP_CODE_0, 0COMP_CODE_1 etc. Dies kann, insbesondere im HANA-seitigen CalcView, leicht unübersichtlich und verwirrend sein, wenn keine weiteren Unterscheidung über die Beschreibung vorgenommen wird!
Spezielle InfoObjecte:
- Bei der Verwendung des „Systemweit eindeutigen Namens“ wird ein künstlicher technischer Name erzeugt, welche den Namen des Composite Providers und des Felds enthält:
- InfoObjecte mit Navigationsattributen lassen sich in der Regel problemlos sowohl per Direktverwendung als auch per eindeutigem Namen assoziieren.
- InfoObjecte mit transitiven Navigationsattributen („Link-InfoObject mit Satelliten“) können ihre transitiven Attribute nur dann zur Verfügung stellen, wenn:
- A) Das Link-InfoObject schon als InfoObject in den Bewegungsdaten enthalten ist. In dem Fall stehen die transitiven Navigationsattribute der Satelliten sowohl BW-seitig als auch HANA-seitig im CalcView zur Verfügung.
- B) Das Link-InfoObject wird im Composite Proivder assoziiert. In dem Fall stehen die transitiven Navigationsattribute der Satelliten jedoch nur BW-seitig zur Verfügung. Im HANA-seitigen CalcView stehen die Attribute nicht zur Verfügung.
- C) Das Link-InfoObject wird im zuerst in einem Fakten-OpenODS View assoziiert, welcher dann anschließend in einen Composite Proivder einfließt. In dem Fall stehen die transitiven Navigationsattribute der Satelliten sowohl BW-seitig im Composite Provider als auch HANA-seitig im CalcView zur Verfügung.
- A) Link-InfoObject bereits in den persistenten Bewegungsdaten enthalten:
- B) Link-InfoObject wird erst im Composite assoziiert:
- C) Link-InfoObject wird bereits in einem Fakten-OOV assoziiert, welcher dann in einem Composite konsumiert wird:
-
Spezielle OpenODS Views:
- Stammdaten-OpenODS Views können per Verwendung des eindeutigen Namens Probleme bereiten. Dies äußert sich in Fehlermeldung „Navigationsattribute werden nicht unterstützt“ bei der Aktivierung.
- In diesem Fall ist die Vewendung via „Direktverwendung“ zwingend erforderlich.
- Diese Beschränkung besteht schon BW-seitig, ist also unabhängig davon, ob die Konsumierung per Calculation View HANA_seitig oder per Composite Provider BW-seitig erfolgt.
- → In Konsequenz heißt dies dann, dass in einem Composite Provider mit einem OpenODS-View jedoch nur einziges Mal assoziiert werden kann.
- Diese Einschränkung besteht wohl seit SPS02 von BW/4 2.0 nicht mehr, es ist auch mit OpenODS Views damit in der Regel eine Assoziation unter Nutzung des eindeutigen Namens möglich, so dass Szenarien wie „Sendende Kst“ / „Empfangende Kst“ mit Mehrfachassoziation mit dem gleichen OpenODS View umgesetzt werden können.
- Die Assoziation mit Fakten-OpenODS Views ist grundsätzlich nicht möglich.
- Stammdaten-OpenODS Views können per Verwendung des eindeutigen Namens Probleme bereiten. Dies äußert sich in Fehlermeldung „Navigationsattribute werden nicht unterstützt“ bei der Aktivierung.
- Stammdaten-OOV mit Semantik „Text“ bei Konsumierung in HANA CalcViews.
Stammdaten-OOVs können neben Navigationsattributen auch Texte bereitstellen.
Das mit einem solchen OOV assoziierte Feld verfügt dann über eine mit einem InfoObject vergleichbare Semantik, d.h. im Reporting kann zwischen der Anzeige des Feldinhaltes als „Schlüssel“, „Text“ sowie „Schlüssel + Text“ umgeschaltet werden.
Dies funktioniert erstmal jedoch ausschließlich BW-seitig bei Reporting auf dem Composite Provider direkt, oder mittels Query auf dem Composite Provider. Der generierte HANA Calculation View weist diese Semantik nicht auf, d.h. der Mehrwert der Assoziation mit dem Text-OOV geht bei HANA-seitiger Konsumierung verloren.
Als Workaround ist es jedoch möglich, dem OpenODS-View zusätzlich zur Text-Semantik auch die Attribut-Semantik zu geben, und das entsprechende Textfeld als (zusätzliches) Navigationsattribut bei der Assoziation hinzuzunehmen. Anschließend ist HANA-seitig noch eine Zuordnung des Textfelds zum Schlüsselfeld erforderlich („Label“). Dadurch kann im Analytics Frontend auch auf dem HANA CalcView dynamisch zwischen Darstellung als Text und Schlüssel umgeschaltet werden.
Fazit
Eine moderne Architektur ist zum Enablement von agilem Data Warehousing unerlässlich. Die flexible Stammdatenmodellierung unter Nutzung des Dynamic Flexbile Star Schema und von Techniken wie Snowflaking mittels Link-und-Satelliten-Modellierung sind dabei unerlässliche Hilfsmittel.
Die Welt der BW-zentrischen Data Warehouse Modellierung wird damit jedoch ein Stück weit komplexer, der Lösungsraum an möglichen Varianten wird größer. Richtig ist, dass mit BW/4HANA das Thema „Simplification“ als wesentlicher Benefit seitens SAP zitiert wird. Im Sinne der Vereinfachung der Anzahl der Objekte auf einige wenige stimmt dies auch. In der Verwendung ergeben sich jedoch deutlich mehr Freiheiten und damit Möglichkeiten in der Umsetzung.
Umso wichtiger wird daher, die grundsätzlichen Architektur- und Modellierungsansätze bereits frühzeitig im Entwurfsprozess zu berücksichtigen, und die Auswirkungen sowie Restriktionen genau zu kennen und zu bewerten, welche Abbildung am besten zu den vorliegenden Anforderungen passt.
Wesentlich ist hierbei festzuhalten, dass kein Ansatz (InfoObject-basierte Modellierung, InfoObject-basierte Link-Satelliten-Modellierung, Feldbasierte Modellierung mit Snowflaking-CalcViews und OpenODS-Views) einem anderen grundsätzlich überlegen ist, und es damit auch keine seriöse generelle Empfehlung für oder wider eine Modellierung geben kann – die Chancen und Einschränkungen unterscheiden sich jeweils von Szenario zu Szenario und sind individuell, am besten unter Mitwirkung eines Solution Architekten, zu bewerten.
Weitere Informationen
Lesen Sie hier auch unser Blogartikel zum Thema „Moderne und flexible Architektur mit SAP BW/4HANA“
Christopher Kampmann
Senior Manager
SAP Information Management
christopher.kampmann@isr.de
+49 (0) 151 422 05 448
