Der Business Builder ist ein Werkzeug in SAP Datasphere, das die fachliche Sicht auf Daten definiert, also festlegt, was Begriffe wie „Umsatz", „Kunde" oder „Region" für die Auswertung bedeuten. Er baut auf den technisch bereitgestellten Tabellen und Sichten (Views) auf und erzeugt daraus Dimensionen (Beschreibungs-Merkmale wie Kunde oder Produkt), Business Entities (wiederverwendbare Geschäftsobjekte) und Fact-Modelle (Kennzahlen mit ihren Bezügen). Diese Modelle werden dann in SAP Analytics Cloud (SAC) und anderen Auswertungs-Werkzeugen (Business Intelligence, BI) konsumiert.
Was ist der Business Builder?
Der Business Builder ist eines der beiden zentralen Modellierungs-Werkzeuge in SAP Datasphere und steht in jedem Arbeitsbereich (Datasphere-Space) neben dem Data Builder zur Verfügung. Die beiden Werkzeuge trennen die technische Ebene (physische Tabellen, Sichten auf die Daten, Aufbereitungs-Schritte im Stil klassischer ETL-Strecken) von der fachlichen Ebene (Geschäftsobjekte, verbindliche Kennzahl-Definitionen, Hierarchien für die Endanwendersicht). Damit ist der Business Builder die Stelle, an der eine SAP-Datasphere-Landschaft ihre einheitliche Geschäftssprache durchsetzt.
Der Business Builder arbeitet mit einem festen Set an Objekttypen. Dimensionen definieren Beschreibungsattribute und Hierarchien für Stammdaten wie Kunde, Produkt, Zeit oder Region. Business Entities kapseln komplexere Sachverhalte als wiederverwendbare Geschäftsobjekte. Fact-Modelle verbinden Kennzahlen mit Dimensionen. Consumption Models bündeln Fakten und Dimensionen zu einem konsumierbaren Modell für BI-Werkzeuge. Perspektiven schränken ein Modell für bestimmte Nutzergruppen ein.
Business-Builder-Objekte bauen technisch auf Data-Builder-Objekten auf. Eine Dimension basiert auf einer im Data Builder modellierten View. Ein Fact-Modell konsumiert eine oder mehrere Fact-Views und verbindet sie mit Dimensionen. Diese Trennung erlaubt getrennte Verantwortungen: technische Datenmodellierung (Was ist die Quelle, wie sieht die Struktur aus?) auf der einen Seite, semantische Modellierung (Was ist die Bedeutung, welche Kennzahl-Definition gilt?) auf der anderen.
Die Ergebnisse aus dem Business Builder werden in SAP Analytics Cloud als Datenmodell konsumiert, für externe Werkzeuge als Analytic Model veröffentlicht oder in Federation-Szenarien mit Databricks, Microsoft Fabric und Snowflake genutzt. Ein Modell aus dem Business Builder wird dabei nicht als Cube materialisiert. Es wird virtuell aufgelöst und im Query-Kontext gegen die zugrundeliegenden Quellen ausgeführt.
Abgrenzung zu verwandten Werkzeugen und Konzepten
Der wichtigste Kontrast ist der zum Data Builder in derselben Datasphere-Instanz. Weiterreichende Abgrenzungen betreffen Legacy-HANA-Modellierung, produkt-fremde Semantic-Layer und Nachbar-Objekttypen innerhalb von Datasphere selbst.
| Begriff | Rolle | Kernunterschied |
|---|---|---|
| Data Builder | Technische Modellierung in Datasphere | Data Builder liefert physische Objekte (Local/Remote Tables, SQL/Graphical Views, Data Flows) und ETL-nahe Transformationen; Business Builder ergänzt darauf die Geschäftssemantik. |
| Analytic Model | Objekttyp | Ein Analytic Model ist das konsumierbare Modell, das für BI-Werkzeuge veröffentlicht wird; der Business Builder ist das Werkzeug, in dem Consumption Models und semantische Modelle modelliert werden. |
| HANA Calculation Views | Legacy-Modellierung | Calculation Views sind der semantische Layer in klassischen HANA-Systemen (HANA Native, BW/4HANA); der Business Builder übernimmt diese Rolle im Kontext der SAP Business Data Cloud mit anderer Nomenklatur und Space-Governance. |
| Power BI Semantic Model, LookML, Cube.js | Produkt-fremde Semantic Layer | Funktional vergleichbar (Kennzahlen, Dimensionen, Hierarchien), aber außerhalb des SAP-Stacks; der Business Builder ist die SAP-eigene Variante, integriert in BDC-Governance und SAC-Konsumation. |
| Business Semantics (Unity Catalog) | Databricks-Nachbar | Unity-Catalog-seitige Metric Views und Business Metadata; wer BDC und Databricks federiert, muss beide Semantik-Layer bewusst trennen. |
Zusätzlich lohnt sich die Abgrenzung innerhalb von Datasphere: Seit der Modellierungs-Modernisierung ab 2023 können Analytic Models auch direkt im Data Builder erstellt werden. Die Werkzeug-Trennung Business Builder vs. Data Builder bleibt bestehen; die Objekt-Zuordnung wird flexibler.
Beispiel: Konzern-Vertriebsmodell im Business Builder
Ein Konzern-Controlling betreibt eine SAP Datasphere für die gruppenweite Vertriebs- und Finanzsicht. Im Data Builder liegen replizierte Fact-Views aus S/4HANA (Belege, Bewegungen) und Stammdaten-Views aus BW/4HANA (Kunde, Produkt, Kostenstelle).
Im Business Builder entstehen darauf Dimensionen mit Hierarchien: Land nach Region nach Vertriebsbüro, Produkt nach Sparte nach Konzern-Sortiment, Kostenstelle nach Kostenstellen-Hierarchie. Ein Fact-Modell „Konzernumsatz" verbindet die Umsatz-Bewegungen mit diesen Dimensionen. Ein Consumption Model bündelt die Kennzahlen „Umsatz", „Deckungsbeitrag" und „Auftragseingang" mit ihren Dimensionen. Zwei Perspektiven filtern das Modell für die Nutzergruppen „Konzern-Controlling" (Vollzugriff) und „Regional-Reporting" (Land-Filter, feldbasierte Einschränkung).
SAP Analytics Cloud konsumiert das Consumption Model direkt für das gruppenweite Umsatz-Dashboard. Ein daneben laufender Databricks-Workspace zieht dieselben Fact-Views über Delta Sharing und modelliert dort einen eigenen Metric View für ML-Features. Die verbindliche Geschäftsdefinition von „Umsatz" und „Deckungsbeitrag" bleibt aber im Business Builder verankert und wird von dort aus konsistent an SAC und an das föderierte Databricks-Umfeld übergeben.
Business Builder im eigenen Unternehmen umsetzen?
Wir zeigen, wie sich das in deiner Systemlandschaft konkret abbilden lässt.