Analytic Models & Verwendung
Stand 2026-09-03
Analytic Models & Verwendung entscheidet, ob eine Datasphere/SAC-Semantikschicht über den Prototyp hinaus skaliert oder unter Produktionslast zusammenbricht. Die wirkungsvollste Architekturentscheidung ist Star Schema versus flache View: Eine schmale Fact View mit zugeordneten Dimension Views lässt Datasphere Joins pro Abfrage beschneiden, während die Abkürzung über eine einzige breite View in der Demo funktioniert und scheitert, sobald Fact-Tabellen die 10-Mio.-Zeilen-Grenze überschreiten. Zwei Leitplanken trennen einen erfahrenen Aufbau von einem unerfahrenen — eine verpflichtende Filtervariable auf jedem Modell mit über 50 Mio. Zeilen (die häufigste Ursache für SAC-Story-Timeouts in Produktion) sowie berechnete Verhältniskennzahlen, die auf der Analytic-Model-Ebene definiert werden, niemals als zeilenbasierte View-Ausdrücke, damit Prozentwerte auf jeder Drill-Ebene korrekt aggregieren. Wird dieses Muster geliefert, wird aus einem wiederkehrenden Produktionsvorfall ein einzeiliger Design-Review-Kommentar vor dem Go-live.
Was Sie lernen
- Ein mehrdimensionales Analytic Model in SAP Analytics Cloud bauen — Dimensionen, Kennzahlen, berechnete Kennzahlen und zeilenbasierte Datenzugriffskontrollen definieren — und verifizieren, dass die Kennzahlen mit dem Quellsystem abstimmen
- Eine semantische Inkonsistenz in einem veröffentlichten Analytic Model diagnostizieren (filterkontextabhängiges Berechnungsergebnis) und sie auf Modellebene mit dokumentierter Begründung beheben
- Eine Konsumsicht aus einem Analytic Model in einer Story konfigurieren — den richtigen Diagrammtyp wählen, Hierarchienavigation anwenden und validieren, dass die Filterpropagation der beabsichtigten Fachlogik entspricht
- Eine Übergabenotiz zur Modelldefinition erstellen, die es einem anderen Berater erlaubt, die Semantikschicht ohne mündliches Briefing nachzubauen
Analytic Models in SAP Analytics Cloud und Datasphere: Architektur und Verwendung
Das Analytic Model ist das Objekt der Semantikschicht, das zwischen Rohdaten und Fachanwendern steht. Im SAP-Analytics-Stack tritt es in zwei unterschiedlichen Formen auf — das Live-Modell von SAP Analytics Cloud (das direkt mit HANA, Datasphere oder BW-Views verbindet) und das Analytic Model von Datasphere (eine modellierte Semantikschicht, die innerhalb von Datasphere definiert und für SAC, Third-Party-BI und OData-Konsumenten bereitgestellt wird). Architekten, die diese beiden vermischen oder standardmäßig auf einen Ansatz „einfach eine View bauen“ zurückgreifen, ohne die Optimierungsfähigkeiten des Analytic Model zu berücksichtigen, liefern regelmäßig Plattformen, die im großen Maßstab schlecht performen und schwer wartbar sind, sobald sich fachliche Anforderungen weiterentwickeln.
Das Datasphere-Analytic-Model: Architektur
Ein Analytic Model in Datasphere ist ein Design-Time-Artefakt, das auf ein oder mehrere zugrunde liegende Objekte der Datenschicht verweist — Graphical Views, SQL Views, lokale Tabellen oder Remote Tables — und darauf eine semantische, abfrageoptimierte Schicht legt. Es ist das empfohlene Konsumobjekt für SAC-Stories, SAC-Planungsmodelle und OData-API-Konsumenten.
Kernkomponenten eines Analytic Model:
Voraussetzungen
- Zunächst die Kernkonzepte durchgehen: C019, C008, C083
Lernergebnisse
- Ein realistisches Szenario durcharbeiten: Eine europäische Handelsgruppe (15 Buchungskreise) benötigt eine stündlich aktualisierte GuV-SAC-Story mit Drill-down nach Sachkonto und Profitcenter.
- Das Anti-Pattern erkennen und vermeiden: Das Analytic Model auf einer einzigen, nicht optimierten flachen View aufbauen — funktioniert im Prototyp; sobald die Fact-Tabelle rund 10 Mio. Zeilen überschreitet, scannt jede Abfrage die volle Zeilenbreite.
- Die zentrale Entscheidung des Moduls anwenden: Analytic Model, einfache View oder BW CompositeProvider für diesen Konsumbedarf.
- Die Beherrschung mit dem KPI verfolgen: initiale Ladezeit der SAC-Story (Ziel: < 5 Sekunden für einen vollen Geschäftsjahresbereich; Warnsignal: > 10 Sekunden — den Join-Plan auf nicht indizierte Spalten prüfen, bevor Hardware hinzugefügt wird).
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.