Business Semantics

Business Semantics ist die Übersetzungsschicht direkt am Datenkatalog (dem zentralen Verzeichnis aller Tabellen und Datenobjekte im Unternehmen), die technische Bezeichnungen in verbindliche Geschäftsbegriffe übersetzt. Sie enthält drei Kern-Bausteine: Kennzahlen-Definitionen (wie „Umsatz" berechnet wird), Beziehungen (welches Objekt zu welchem gehört) und Geschäftsregeln (was fachlich zählt und was nicht). Genutzt wird die Schicht von BI-Werkzeugen (Business Intelligence, also Reporting- und Analyse-Tools wie Power BI oder Tableau), SQL-Abfragen und KI-Assistenten.

Was ist Business Semantics?

Business Semantics ist die Sammlung aller Bedeutungs-Informationen, die einer technischen Datenlandschaft eine fachliche Sicht gibt. Sie beantwortet drei Fragen: Was bedeutet ein Datenobjekt (eine Tabelle oder Spalte in der Datenbank) fachlich, also etwa Kunde, Umsatz oder aktiver Vertrag? Wie hängen diese Objekte inhaltlich zusammen, also zum Beispiel: ein Vertragspartner ist ein Kunde, eine Kostenstelle gehört zu einer Region? Und welche Regeln gelten für Berechnung und Interpretation, also zum Beispiel: Umsatz ist Netto ohne Rabatt, aktive Kunden sind Kunden mit einem Vertrag im letzten Quartal?

Klassisch werden diese Informationen in einzelnen BI-Werkzeugen gepflegt, etwa im Power BI Semantic Model, im Tableau Data Model oder in LookML. Der aktuelle Trend verlagert sie in den Datenkatalog selbst, häufig unter Bezeichnungen wie „Contextual Semantic Layer" oder „katalog-native Semantik". Der Vorteil dieser Verlagerung ist Wiederverwendung: Dashboards, SQL-Abfragen und KI-Assistenten greifen auf dieselben Definitionen zu, ohne dass die Semantik parallel in mehreren Werkzeugen gepflegt wird.

Typische Bausteine sind Kommentare und Beschreibungen auf Tabellen, Spalten und Modellen, strukturierte Tags für Klassifikation und Synonyme, Kennzahlen-Definitionen als ausführbare Objekte (Metric Views, Metric Stores), Beziehungs- und Join-Hinweise sowie zusätzlicher Kontext für KI-Assistenten mit Beispielfragen, Synonymen und Business-Regeln. Zusammen bilden diese Bausteine die Übersetzungsschicht zwischen der technischen Datenstruktur und der Sprache der Fachbereiche.

Produktnahe Ausprägungen tragen unterschiedliche Namen. Databricks bündelt das Konzept unter „Unity Catalog Business Semantics": Kommentare, Tags, Metric Views und Genie-Kontext an denselben Assets. SAP nutzt in Datasphere den Begriff „Business Builder" für die entsprechende Modellierungs-Schicht. Snowflake pflegt Semantic Views, dbt einen eigenen Semantic Layer, Cube.js ein API-orientiertes Modell. „Business Semantics" ist der neutrale Sammelbegriff für diese Familie.

Der Nutzen liegt auf vier Ebenen. Einheitliche Definitionen sorgen dafür, dass eine Kennzahl an einer Stelle festgelegt und überall gleich berechnet wird. Governance wird durchgesetzt, weil Zugriffs- und Zeilenfilter auf Semantik-Ebene liegen und in jedem Report gleich wirken. KI-Tauglichkeit steigt, weil natural-language-Query-Werkzeuge und AI-Assistenten den fachlichen Kontext brauchen, den die Semantik-Schicht liefert. Und die Portabilität wächst, weil die Definitionen mit den Daten wandern und nicht mit dem BI-Tool.

Abgrenzung zu verwandten Begriffen

Business Semantics wird häufig mit benachbarten Konzepten verwechselt. Die wichtigsten Trennlinien:

Die zentrale Abgrenzung ist die zum Semantic Layer: Der Begriff „Semantic Layer" beschreibt die Funktion (Abstraktion zwischen Rohdaten und Konsumenten), „Business Semantics" beschreibt den Ort und die Zusammensetzung (im Katalog, aus mehreren Bausteinen). Ein Semantic Layer im BI-Tool ist auf dieses Tool beschränkt; die Business-Semantics-Schicht im Katalog liefert die Grundlage für mehrere Konsumenten gleichzeitig.

Beispiel: Business Semantics in einem Databricks Lakehouse

Ein Handelsunternehmen betreibt ein Databricks Lakehouse mit Vertriebs-, Finance- und Customer-Success-Dashboards. Für dieselbe Kennzahl „Umsatz" zeigen die Dashboards unterschiedliche Werte, weil jeder Bereich eigene Filter, Rabatt-Regeln und Währungsbehandlungen implementiert hat. Business Semantics wird in Unity Catalog aufgebaut, um die Divergenz aufzulösen.

Als Erstes werden Kommentare und Tags auf den relevanten Tabellen und Spalten gepflegt: Signierung des Umsatzes, Behandlung von Retouren, Rabatt-Regel, Währungs-Konvertierung. Anschließend fixiert eine Metric View „Konzernumsatz" die Berechnung als ausführbare Definition mit Filter, Aggregation und den zulässigen Dimensionen (Kunde, Produkt, Zeit, Region). Der zugehörige Genie Space bekommt Beispielfragen, Synonyme (Umsatz, Erlös, Revenue) und Join-Hinweise, damit natürlichsprachige Fragen dieselbe Kennzahl treffen.

Die Konsequenz: Power BI, Databricks SQL und Genie ziehen ihre Umsatz-Zahl aus derselben Metric View. Änderungen an der Definition erfolgen an einer Stelle und wirken für alle Konsumenten gleichermaßen. In einem föderierten SAP-Databricks-Setup bleibt die Databricks-seitige Business Semantics vom SAP-seitigen Business Builder bewusst getrennt: SAP-Kennzahlen aus S/4HANA (Konzernumsatz) verantwortet der Business Builder in Datasphere, Databricks-eigene Analytik-Kennzahlen (Kundenverhalten, ML-Features) verantwortet die Business-Semantics-Schicht in Unity Catalog.