Fortgeschrittene dimensionale Modellierung
Stand 2026-09-03
Fortgeschrittene dimensionale Modellierung ist die Entscheidung, die bestimmt, ob ein SAC-Bericht für ein Unternehmen mit 500 Mio. € Umsatz bei 500 Millionen Zeilen weiterhin in Sekunden zurückkommt oder in dem Moment lautlos überzählt, in dem sich zwei Prozesse eine Dimension teilen. Der Einsatz: eine Granularitätsabweichung, die HANA nie melden wird, eine Materialisierungsentscheidung, die entweder ein mehrstündiges Rebuild-Fenster verschwendet oder mehr als 20 gleichzeitige Analysten unterversorgt, sowie eine gemischte SCD-Dimension, die für die Berichterstattung geschlossener Perioden prüfbar bleiben muss. Berater, die diese Entscheidungen verteidigen können — Granularitätsgrenze, Junk-Dimension-Schwelle, rollenspielende Joins, SCD-Typ je Attribut — werden in DACH und den Benelux-Ländern als Senior-Architekten positioniert, nicht zu Sätzen für Umsetzungsanalysten.
Was Sie lernen
- Ein Fact-Constellation-Schema für eine prozessübergreifende SAP-Analytics-Landschaft entwerfen, dabei explizite Granularitätsentscheidungen treffen und Datenprodukt-Grenzen in BDC definieren, die stille prozessübergreifende Granularitäts-Doppelzählungen in SAC-Abfragen verhindern
- Die richtige dimensionale Technik (degenerierte Dimension, Junk-Dimension, Role-Playing-Dimension oder konforme Dimension) für ein gegebenes SAP-Quelldatenmuster auswählen und implementieren, mit einer in HANAs spaltenorientierten Performance-Eigenschaften begründeten Rechtfertigung
- Den Materialisierungs-Trade-off für HANA-residente Aggregattabellen in Datasphere bewerten, unter Anwendung von P90-Latenz-Benchmarks, Delta-Fähigkeits-Einschränkungen und Geschäfts-Aktualitäts-SLA, um die Materialisieren-oder-nicht-Entscheidung zu treffen
- Eine Dimensions-Entität mit gemischten SCD-Typen in Datasphere konstruieren, die Typ-1- (Überschreiben), Typ-2- (versionierter Ersatzschlüssel) und Typ-3-Attribute (Vorwert-Spalte) innerhalb derselben Kunden- oder Organisationsdimension korrekt handhabt, mit einem validierten HANA-Ausführungsplan
Jenseits der Star-Schema-Grundlagen: Was fortgeschrittene dimensionale Modellierung tatsächlich bedeutet
Jedem SAP-Analytics-Berater wurde beigebracht, ein Star-Schema zu bauen. Die Business-Content-ADSOs in BW/4HANA liefern vorgefertigte, star-kompatible Fakten- und Dimensionstabellen. SAC kann ein SAP-Datasphere-Analytic-Model lesen, das einen Star umschließt. Aber die Berater, die die höchsten Honorare verlangen und die erfolgreichsten Migrationen leiten, sind diejenigen, die verstehen, wann das Lehrbuch-Star-Schema versagt, warum es versagt, und welche der fortgeschrittenen Modellierungstechniken das Versagen behebt, während die Query-Performance auf HANAs spaltenorientierter Engine und der In-Memory-Berechnungsschicht von SAC erhalten bleibt.
Dieses Modul schließt die Lücke zwischen „Ich weiß, was ein Star-Schema ist“ und „Ich kann einen Umsatzstrom von 500 Mio. € mit dreißig Analysten in SAC modellieren, ohne dass der Bericht in ein Timeout läuft“.
Galaxy-Schemata, Fact Constellations und die BDC-Datenprodukt-Grenze
Eine Fact Constellation (oder Galaxy-Schema) ist eine Menge von Faktentabellen, die gemeinsame Dimensionstabellen teilen. In einem BW/4HANA- oder Datasphere-Kontext tritt dies auf, wenn mehrere Geschäftsprozesse (Vertrieb, Finanzen, Beschaffung) eine gemeinsame Kundendimension oder einen gemeinsamen Kalender teilen. Die Modellierungsentscheidung: die physische Dimensionstabelle teilen oder prozessspezifische Dimensionsgranularitäten beibehalten?
Voraussetzungen
- Mittlere praktische Erfahrung mit SAP-Analytics-Projekten
- Zunächst folgende Kernkonzepte wiederholen: C087, C083, C047
Lernergebnisse
- Ein realistisches Szenario durcharbeiten: Ein europäischer Industrieausrüstungskonzern konsolidiert die Vertriebs-, Finanz- und Beschaffungsberichterstattung aus drei Legacy-BW-Systemen in eine Datasphere-Landschaft, die SAC speist.
- Das Anti-Pattern erkennen und vermeiden: Die Faktengranularität als „Auftrag“ deklarieren, obwohl die Quelle tatsächlich Positionsebene ist.
- Die Kernentscheidung des Moduls anwenden: Granularitäts-Sharing über Prozessdomänen (Vertrieb, Finanzen, Beschaffung) hinweg — die Wahl fällt darauf, die gemeinsame Dimension als eigenes, separat verwaltetes Datenprodukt mit eigenem SLA zu veröffentlichen.
- Die Beherrschung anhand des KPI verfolgen: Faktenübergreifende Überzählungsvorfälle (Ziel: Null pro Quartal; Warnsignal: jeder auf eine Granularitätsabweichung zurückgeführte Vorfall, der einen Geschäftsbericht erreichte, bevor er entdeckt wurde).
Vollständiges Modul für Mitglieder. Das vollständige Modul ergänzt: den Entscheidungsrahmen · das durchgehende Szenario · die KPI-Scorecard · die Anti-Muster · die Codeblöcke · die Wissenskontrolle · die Schemata.