Business Layer: Dimensionen & Fakten
Stand 2026-09-03
Ein falsch angelegter Business Layer zeigt sich nie als Fehlermeldung — er zeigt sich als Umsatzsumme in SAC, die still und leise niedriger ausfällt als der eigene Bericht des Finance-Teams, weil ein Inner Join jede unklassifizierte Bestellung verworfen hat. Dieses Modul dreht sich um die vier Entscheidungen, die darüber bestimmen: Star vs. Snowflake, Join-Typ je Assoziation, Hierarchietyp und wo die Berechtigung durchgesetzt wird. Der wirkungsvollste Standard ist LEFT OUTER JOIN auf jeder optionalen Dimensionsassoziation, abgesichert durch einen Zwei-Abfragen-Abgleich vor dem Go-live. Berater, die diesen Standard begründen können — und die Diagnose zeigen können, die ihn belegt —, sind diejenigen, denen ein Partner einen Business Layer freigibt, ohne die Zahlen nachzuprüfen.
Was Sie lernen
- Die Kernkonzepte von Business Layer: Dimensionen & Fakten verstehen
- Dimensionen in einem typischen SAP-Analytics-Projekt anwenden
- Die 3-5 häufigsten Fehler erkennen und wissen, wie man sie vermeidet
- Diese Fähigkeit in der eigenen Personal Brand und im TJM-/Honorargespräch positionieren
Business Layer: Dimensionen und Fakten in SAP Datasphere
Datasphere trennt die Modellierung aus gutem Grund in zwei eigenständige Builder: Der Data Builder verwaltet technische Datenobjekte (Tabellen, Views, Remote-Verbindungen, Replikation), während der Business Builder die semantische Modellierung übernimmt — die Schicht, in der aus rohen Spaltendaten dimensionale Geschäftskonzepte werden, die Business-User, SAC-Stories, Excel-Add-ins und Power BI abfragen können, ohne SQL zu schreiben. Der Business Layer ist die Stelle, an der ein SAP-Analytics-Architekt definiert, was die Daten bedeuten — nicht nur, was sie enthalten.
Ob ein Analytics-Modell wartbar ist, von fachfremden Nutzern abgefragt werden kann und unter dem gesamten Spektrum der Abfragemuster korrekt performt, die SAC und nachgelagerte Konsumenten erzeugen, entscheidet sich maßgeblich am korrekt aufgebauten Business Layer. Wird er falsch aufgebaut — Faktspalten fälschlich als Dimensionen klassifiziert, Snowflake-Joins gebaut, wo ein Sternschema stehen sollte, fehlende Kardinalitätsangaben bei Assoziationen —, entstehen Modelle, die stillschweigend falsche Aggregate liefern, schlecht performen oder bei wachsendem Datenvolumen brechen.
Die drei Objekttypen
Der Business Builder arbeitet mit drei Objekttypen, die ein klassisches dimensionales Data Warehouse widerspiegeln:
Voraussetzungen
- Zunächst die Kernkonzepte durchgehen: C008, C083, C020
Lernergebnisse
- Ein realistisches Szenario durcharbeiten: Ein europäischer Hersteller von Industrieausrüstung betreibt S/4HANA mit Embedded HANA und repliziert Verkaufsauftrags- und Fakturierungsdaten nach Datasphere.
- Das Anti-Pattern erkennen und vermeiden: Fact-Kennzahlen, die in der Dimension gespeichert sind — die Aggregation bricht: Der Business Builder kann ein Dimensionsattribut nicht über Fact-Zeilen hinweg summieren.
- Die zentrale Entscheidung des Moduls anwenden: Sternschema vs. Snowflake für das Dimensionsmodell — die Wahl auf Denormalisierung zu einer flachen, breiten Dimension treffen.
- Die Beherrschung mit dem KPI verfolgen: SAC-Summe vs. Summe im Quellsystem (Abstimmungsdifferenz).
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.