E-Book, Deutsch, 508 Seiten
Reihe: SAP Press
Anane Adusei / Rötting / Yamada SAP HANA – Datenmodellierung
1. Auflage 2018
ISBN: 978-3-8362-8185-0
Verlag: Rheinwerk
Format: EPUB
Kopierschutz: 0 - No protection
E-Book, Deutsch, 508 Seiten
Reihe: SAP Press
ISBN: 978-3-8362-8185-0
Verlag: Rheinwerk
Format: EPUB
Kopierschutz: 0 - No protection
So meistern Sie die Datenmodellierung für SAP HANA! Erfahren Sie, welche Modellierungsfunktionen, -objekte und Werkzeuge es gibt und wie Sie diese einsetzen, um für Ihr Unternehmen passende Datenmodelle zu erstellen. Die Autoren zeigen Ihnen an praxisrelevanten Beispielen die Modellierung der Daten für alle SAP-Komponenten : SAP HANA (nativ), SAP BW auf SAP HANA, SAP BW/4HANA, SAP S/4HANA Embedded Analytics oder SAP Vora.
Aus dem Inhalt:
- Calculation Views
- Big Data und SAP Vora
- Modellierungsobjekte für SAP BW auf HANA und SAP BW/4HANA
- LSA++
- Planungsanwendungen modellieren
- Datenhaltung optimieren
- Modellierung für SAP S/4HANA Embedded Analytics
- Business Content
Autoren/Hrsg.
Weitere Infos & Material
Einleitung ... 15
1. Grundlagen der Datenmodellierung ... 19
1.1 ... Paradigmenwechsel in der analytischen Informationsverarbeitung ... 20
1.2 ... Besonderheiten von dispositiven Systemen ... 23
1.3 ... Die klassische Data-Warehouse-Modellierung ... 25
1.4 ... Konzeptionelle multidimensionale Modellierung ... 31
1.5 ... Logische multidimensionale Modellierung ... 39
1.6 ... Der agile Ansatz in der Datenmodellierung: Data Vaults ... 47
1.7 ... Big-Data-Modellierung: Hadoop und Data Lakes ... 48
1.8 ... Fazit ... 51
2. Komponenten für die Informationsverarbeitung mit SAP HANA ... 53
2.1 ... Die nächste Stufe des klassischen Data Warehouse: SAP BW auf SAP HANA ... 53
2.2 ... Die Neuerfindung des Data Warehouse: SAP BW/4HANA ... 55
2.3 ... In-Memory Computing mit SAP HANA ... 65
2.4 ... SAP HANA Data Warehousing Foundation ... 67
2.5 ... Neue Geschäftsprozesse durch neue Technologie: SAP S/4HANA ... 70
2.6 ... Die Brücke zu Big Data: SAP Vora ... 74
2.7 ... Fazit ... 81
3. Einführung in die SAP-HANA-Datenmodellierung ... 83
3.1 ... SAP HANA Studio ... 84
3.2 ... Information Views ... 96
3.3 ... Einfache Calculation Views modellieren ... 101
3.4 ... Fazit ... 120
4. Fortgeschrittene SAP-HANA-Datenmodellierung ... 121
4.1 ... Cube Calculation Views ... 121
4.2 ... Währungsumrechnungen ... 144
4.3 ... Berechnete Spalten ... 150
4.4 ... Ranglisten ... 155
4.5 ... Der Union-Knoten ... 157
4.6 ... Hierarchien ... 159
4.7 ... Zeitbasierte Dimension Calculation Views ... 162
4.8 ... Calculation Views mit Star Join ... 168
4.9 ... Codebasierte Modellierung ... 172
4.10 ... Privilegien ... 180
4.11 ... Fazit ... 185
5. Modellierungsobjekte in SAP BW auf SAP HANA und SAP BW/4HANA ... 187
5.1 ... Versionen von SAP BW auf SAP HANA ... 188
5.2 ... BW-Modellierungswerkzeuge in Eclipse ... 193
5.3 ... InfoObjects ... 195
5.4 ... Klassische DataStore-Objekte ... 207
5.5 ... InfoCubes ... 212
5.6 ... Advanced DataStore-Objekte ... 217
5.7 ... Open ODS Views ... 238
5.8 ... CompositeProvider ... 241
5.9 ... Hybride Modellierung von SAP-HANA- und BW-Objekten ... 251
5.10 ... Semantische Gruppen ... 260
5.11 ... Fazit ... 265
6. Modellierung in SAP Vora ... 267
6.1 ... Installation von SAP Vora auf Amazon Web Services ... 268
6.2 ... Werkzeuge der Developer Edition von SAP Vora ... 291
6.3 ... Engines und Funktionen von SAP Vora ... 293
6.4 ... Fazit ... 299
7. Modellierungsobjekte für SAP S/4HANA Embedded Analytics ... 301
7.1 ... Virtuelle Datenmodelle mit Core Data Services ... 302
7.2 ... Modellierung von CDS Views ... 306
7.3 ... Analysis Path Framework ... 328
7.4 ... Embedded BW ... 330
7.5 ... Embedded BPC für SAP S/4HANA ... 331
7.6 ... Fazit ... 332
8. Business Content ... 335
8.1 ... Grundlagen ... 336
8.2 ... Business Content für SAP S/4HANA ... 341
8.3 ... Business Content für SAP BW/4HANA ... 342
8.4 ... Stammdaten in SAP BW bzw. SAP BW/4HANA ... 345
8.5 ... SAP BW bzw. SAP BW/4HANA im Finanzwesen ... 354
8.6 ... SAP BW bzw. SAP BW/4HANA im Controlling ... 361
8.7 ... SAP BW bzw. SAP BW/4HANA im Vertrieb ... 369
8.8 ... SAP BW bzw. SAP BW/4HANA im Personalwesen ... 376
8.9 ... Klassifikationsdaten ... 379
8.10 ... Aktivierung und Erweiterung ... 380
8.11 ... Fazit ... 385
9. Modellierung des Enterprise Data Warehouse ... 387
9.1 ... Erweiterte Layered Scalable Architecture (LSA++) ... 388
9.2 ... Domänen ... 404
9.3 ... LSA++ und Flexibilität bei Änderungen ... 407
9.4 ... Namenskonventionen ... 408
9.5 ... Fazit ... 409
10. Modellierung von Planungsanwendungen ... 411
10.1 ... Anforderungen an Planungs- und Kontrollsysteme ... 413
10.2 ... Modellierung mit der BW-integrierten Planung und dem Planning Application Kit ... 416
10.3 ... Verwendung von SAP BPC 10.1 Embedded ... 431
10.4 ... Modellierung mit SAP BPC für SAP S/4HANA ... 434
10.5 ... Spezielle Modellierungsfragen ... 436
10.6 ... Fazit ... 442
11. Optimierung der Datenhaltung ... 443
11.1 ... Datenklassifizierung und aktives Datenspeichermanagement ... 444
11.2 ... Optimierung des Datenmodells für SAP BW bzw. SAP BW/4HANA ... 453
11.3 ... Housekeeping ... 463
11.4 ... Fazit ... 465
12. Zusammenfassung und Ausblick ... 467
A. Abkürzungen ... 473
B. Transaktionen ... 481
C. Programme ... 485
D. Tabellen ... 487
E. Glossar ... 489
F. Die Autoren ... 493
Index ... 495
1 Grundlagen der Datenmodellierung
In diesem Kapitel stellen wir Ihnen die wichtigsten Grundlagen und wesentlichen Konzepte der Datenmodellierung vor. Das Hauptaugenmerk liegt dabei immer auf den Möglichkeiten von SAP HANA.
Eine der größten Herausforderungen beim Aufbau von analytischen Anwendungen ist die Datenmodellierung. In diesem Kapitel stellen wir die wichtigsten Grundlagen für die Modellierung von SAP-HANA-basierten Datenanalysesystemen vor. Dazu zählen insbesondere:
-
SAP HANA native
-
SAP BW/4HANA und SAP Business Warehouse (SAP BW) auf SAP HANA
-
SAP S/4HANA Embedded Analytics
-
SAP Vora
Der Einfachheit halber verwenden wir hier den Begriff Data Analytics als Überbegriff für die Anwendungsfälle dieser Systeme.
In einem operativen System muss das Datenmodell lediglich die Daten für die jeweilige Anwendung vorhalten. Darüber hinaus sind in den operativen Systemen hauptsächlich technische Aspekte wie die Normalisierung des Datenbankschemas und die Systemperformance von Bedeutung. In SAP-Standardapplikationen ist das Datenmodell fest definiert, und der Datenmodellierung sind damit enge Grenzen gesetzt, etwa wie Schlüssel vergeben werden oder wie welche Standardobjekte für die konkreten Bedürfnisse einer Organisation verwendet werden sollen. Bei analytischen Anwendungen stellt hingegen das Datenmodell selbst den zentralen Teil der Anwendung dar.
Es muss festgelegt werden, welche Detailebene zu berücksichtigen ist, ob Merkmale historisch wahr oder mit aktuellen Bezügen auszuwerten sind und vieles mehr. In den Gesprächen mit der Fachabteilung nimmt die Frage, welches Datenmodell für den Anwender sinnvoll ist, letztlich viel Raum ein, selbst wenn vordergründig nur einzelne Berichte mit dem Anwender besprochen werden.
Mit dem hohen Stellenwert, den das Datensammeln heute in der gesellschaftlichen Diskussion einnimmt, ist nicht mehr erklärungsbedürftig, dass es bei der Datenmodellierung nicht mehr nur um die Versorgung einer kleinen Sammlung von Berichten geht. Das Datensammeln und daraus resultierend die Datenmodellierung stellen vielmehr einen wesentlichen wirtschaftlichen Wert an sich dar. Daten sind die Basis für neue Geschäftsideen, und in ihrer agilen Analyse erschließen sich Erkenntnisse, die einen wesentlichen Wettbewerbsvorteil mit sich bringen können.
Eine akkurate Datenmodellierung ist auch notwendig, um schnell in einem besonderen Marktumfeld agieren zu können. So hat etwa die Finanzkrise von 2008 einen großen Handlungsbedarf bei Banken aufgezeigt, die Regulierer einfordern – mit zum Teil sehr konkreten Anforderungen an das Datenmanagement. Ein besonders gutes Beispiel hierfür ist der Standard BCBS 239 des Basel Commitee on Banking Supervision, der explizit ein Metadatenmanagement, ein Datenqualitätsmanagement und die Dokumentation der Data Lineage für Risikodaten einfordert.
In diesem Kapitel stellen wir Ihnen nach einem kurzen Einblick in die aktuellen Entwicklungen zuerst die Besonderheiten der klassischen Data-Warehouse-Modellierung dar. Danach zeigen wir die im Datenmodellierungsbereich übliche Aufteilung in die Schichten konzeptionell und logisch. Außerdem stellen wir zwei Darstellungsmethoden vor und behandeln wichtige Themen der beiden Schichten für die Modellierung von analytischen Anwendungen. Diese Themen werden allgemein diskutiert, wobei wir aber immer wieder auch die Spezifika von SAP HANA erläutern.
1.1 Paradigmenwechsel in der analytischen Informationsverarbeitung
Die klassische Welt der analytischen Datenmodellierung ist gekennzeichnet durch die Datensammlung in einem Data Warehouse und die Analyse von Daten in Business Intelligence-(BI-)Werkzeugen auf der Grundlage des Data Warehouse. Die Modellierung im Data Warehouse folgt hierbei etablierten Standards (insbesondere dem Sternschema) auf der Basis von relationalen Datenbanken. BI-Werkzeuge ermöglichen den anwenderfreundlichen Zugriff für die Fachbereiche.
Dieses Vorgehen hat viele Vorteile und war dem Stand der Technik geschuldet. Etwa wurde durch die Trennung von operativen und dispositiven Daten Rechnerlast von den operativen Anwendungen genommen, um den operativen Betrieb nicht zu stören. Die Bewirtschaftung des dispositiven Systems erfolgte in der Regel im Nachtfenster, wodurch sich keine Beeinträchtigung für die operativen Anwendungen ergaben.
In der Regel konsolidierten Data Warehouses Daten aus unterschiedlichen operativen Anwendungen. Im Umfeld von SAP BW war aber oft das SAP-ERP-System die wesentliche Anwendung. Die Konsolidierbarkeit von Daten ist nach wie vor eine wichtige Problemstellung, insbesondere bei Unternehmungen mit einer Historie von Firmenübernahmen und geringem Harmonisierungsgrad.
In den letzten Jahren beschleunigte sich der technologische Wandel und rückten die Daten ins Rampenlicht. Vieles wird unter dem Begriff Big Data zusammengefasst, etwa die Analyse von Sensor- oder Steuerungsdaten in Produktionsmaschinen, die Auswertung von Daten aus sozialen Medien und unstrukturierten Informationen sowie die Nutzbarmachung von Daten aus den unterschiedlichen Elektroniksystemen für Konsumenten, um nur die wichtigsten Use Cases zu nennen.
Bedeutender als diese Use Cases ist aber eine grundsätzliche Änderung in der Vorgehensweise: In der Data-Warehouse-Welt gestaltet man Datenmodelle für die unterschiedlichen Use Cases. Gute Architektur war hierbei durch die Einhaltung einer Richtlinie (z. B. der Scalable Layered Architecture, LSA) zu erreichen, um eine möglichst gute Wiederverwendbarkeit zu erreichen. Wurde das nicht erreicht, spricht man von Stovepipe oder Datensilos. Der Ansatz von Big Data ist dagegen vielmehr, die Daten zu sammeln und erst über Metadaten zu strukturieren. Die Entwicklung von neuen Auswertungen erfolgt zunehmend nicht mehr in IT-Projekten, sondern durch Data Scientists, die agil auf alle Daten im Unternehmen zugreifen können.
[»] Stovepipe
Falls für Anwendungsfälle keine übergreifenden Auswertungen nötig sind, könnte die Entwicklung unabhängiger Data Marts mit eigener Datenversorgung sinnvoll sein. Ralph Kimball prägte hierfür den Begriff Stovepipe, weil Daten ohne Integration sozusagen wie durch ein Ofenrohr geschleust werden. In der Regel ist dieser Ansatz aber historisch bedingt und liefert keine Integration oder Wiederverwendung, sondern nur eine isolierte Insellösung.
Ein guter Indikator für diese Veränderungen ist der BI Magic Quadrant des Marktforschungsinstituts Gartner. Bis 2010 waren hier nur die sieben etablierten Hersteller der alten Data-Warehouse-/BI-Welt als Leader vertreten, also IBM, MicroStrategy, InformationBuilder, SAP, SAS, Microsoft und Oracle. Aus dieser Gruppe konnte sich nur Microsoft als Leader halten. Die weiteren Unternehmen in dieser Gruppe sind mit Qlik und Tableau heute Vertreter einer neuen Generation von BI-Lösungen, die agiler sind.
Die wesentlichen technologischen Fortschritte, die die klassische Data-Warehouse-Architektur in Frage stellen, sind zum einen clusterbasierte Datenspeicherarchitekturen, hier insbesondere Hadoop, und zum anderen die In-Memory-Datenhaltung für hochperformante Auswertungen.
Hinter dem Begriff Hadoop verbirgt sich ein breites Spektrum unterschiedlicher Werkzeuge für die Datenverarbeitung in Hardware-Clustern. Für die Anwendung im BI-/Data-Warehouse-Umfeld sind insbesondere Hive und Spark wichtig. Mit diesen Werkzeugen können Abfragen SQL-ähnlich an das Hadoop-Dateisystem gestellt werden, die über Metadaten interpretiert werden.
Die Cluster-Architektur ist für wesentlich größere Datenmengen geeignet als relationale Datenbanken. Zudem werden auch unstrukturierte Daten unterstützt. Als Datenmodellierungskonzept für ein Hadoop-Cluster hat sich das Konzept des Data Lakes etabliert. Der Data Lake ist eine schemafreie Datensammlung oder Eingangsschicht für ein Data Warehouse, wobei die Struktur der Daten erst über Metadaten bestimmt wird. Diese Metadaten können auch erst im Nachhinein erstellt werden oder unterschiedliche Versionen für dieselben Daten aufweisen.
Die Vorteile eines Data Lakes sind vielfältig:
-
schnelles Datenladen und keine Beeinträchtigung der gleichzeitigen Analyse aufgrund der Clusterarchitektur
-
zunächst geringer Aufwand, da man die Aufbereitung nach hinten verlagert
-
geringe Kosten für Hardware (Cluster mit kostengünstigen Standardrechnern) und Lizenzen (Open Source)
-
Agilität, Bereitstellung der vollen Flexibilität durch unmanipulitierte Rohdaten
Eine weitere wichtige Entwicklung war das Aufkommen der In-Memory-Datenverarbeitung. Der eigentliche Engpass jeder BI-/Data-Warehouse-Architektur ist das Lesen von Massendaten von langsamen Speichermedien. Die meisten Ansätze der analytischen Datenmodellierung sollen dieses Problem in den Griff bekommen. Hält man allerdings alle Daten im...
