10. Juni 2026

Semantic LayerData MartsSemantic Layer und Data MartsDefinitionen von KennzahlenBusiness Glossaryeinheitliche DatenbasisZersplitterung von Kennzahlen

Semantic Layer und klassische Data Marts im Vergleich

Der Semantic Layer und der klassische Data Mart sind zwei Antworten auf dieselbe dauerhafte Frage: Wie geben Sie den Fachbereichen einheitliche, verständliche und analysefertige Daten? Der Data Mart war die klassische Antwort, nämlich für jedes Team eine kuratierte, fachlich zugeschnittene Teilmenge des Warehouse zu bauen. Der Semantic Layer ist die zentrale Antwort, nämlich Kennzahlen und fachliche Bedeutung einmal zu definieren, in einer zentralen Schicht, die sich die nutzenden Werkzeuge teilen. Den Unterschied zu verstehen, heißt im Kern zu verstehen, wie die Architektur der Analytik die größte Schwäche unabhängiger Marts zu beheben versucht: uneinheitliche Kennzahlen.

Dieser Vergleich zählt, weil die Wahl darüber entscheidet, ob eine Organisation eine Version der Wahrheit hat oder viele. Beide Ansätze machen Daten nutzbarer; nur einer von ihnen hält die Definitionen im ganzen Unternehmen von sich aus einheitlich. In dem Maß, in dem Unternehmen BI, Augmented Analytics und KI einsetzen, die sich alle darüber einig sein müssen, was „Umsatz“ bedeutet, haben die Grenzen der Marts je Team einen zentralen Semantic Layer deutlich attraktiver gemacht.

TL;DR

Sowohl klassische Data Marts als auch der Semantic Layer gibt es, um den Fachbereichen einheitliche, analysefertige Daten zu geben. Ein Data Mart tut das, indem er physisch je Team eine kuratierte Teilmenge baut, was schnell und autonom ist, wobei jeder Mart seine Kennzahlen aber meist auf eigene Weise definiert und so widersprüchliche Zahlen zwischen den Teams entstehen. Ein Semantic Layer tut es, indem er Kennzahlen und fachliche Bedeutung einmal definiert, in einer zentralen Schicht, die von den angebundenen Werkzeugen für BI und KI abgefragt wird, sodass „Umsatz“ überall dasselbe bedeutet. Ein zentraler Semantic Layer bekämpft unmittelbar die Zersplitterung der Kennzahlen bei unabhängigen Marts. Die beiden schließen sich nicht aus (Marts können unter einem Semantic Layer liegen), doch der Schwerpunkt der Governance hat sich in Richtung Semantic Layer verschoben, und seine Definitionen gehören in ein gesteuertes Business Glossary.

Das Problem, das beide lösen

Rohe Tabellen im Warehouse sind nichts, was eine Analystin direkt abfragen sollte. Sie sind für die Integration modelliert, voller kryptischer Spaltennamen und Join-Logik, und sie enthalten keine vereinbarte Vorstellung davon, was „aktiver Kunde“ oder „Nettoumsatz“ bedeutet. Sich selbst überlassen, schreiben zehn Analysten zehn leicht verschiedene Abfragen für dieselbe Kennzahl und bekommen zehn leicht verschiedene Antworten. Sowohl den Data Mart als auch den Semantic Layer gibt es, um diese Lücke zwischen rohen Daten und vertrauenswürdigen fachlichen Antworten zu schließen, nur schließen sie sie an grundlegend verschiedenen Stellen.

Der klassische Weg über Data Marts

Ein Data Mart schließt die Lücke physisch. Der Ansatz ging aus der dimensionalen Modellierung hervor, die Ralph Kimball 1996 mit The Data Warehouse Toolkit in der Branche einführte. Für jede Funktion, also Vertrieb, Finanzen, Marketing, baut ein Team eine eigene, dimensional modellierte Teilmenge des Warehouse, die nur die Daten dieser Funktion enthält, vorgeformt zu den Tabellen und Kennzahlen, die sie braucht. Die Analystin fragt den Mart ab und nicht das Warehouse und bekommt schnelle, passende, vereinfachte Daten.

Innerhalb eines Teams funktioniert das gut, über Teams hinweg hat es aber einen strukturellen Fehler: Jeder Mart verschlüsselt seine eigenen Definitionen in seinen eigenen physischen Tabellen. Der Mart des Vertriebs berechnet „Umsatz“ auf eine Weise; der Mart der Finanzen berechnet ihn anders. Beide sind in sich stimmig, aber sie widersprechen einander, und weil die Logik in getrennte physische Bauten eingebacken ist, ist das Abgleichen mühsam. Je mehr Marts entstehen, desto mehr überlappende, leicht abweichende Versionen der Wahrheit sammeln sich an. Diese Zersplitterung der Kennzahlen ist die klassische Schwäche unabhängiger Marts. Kimballs eigenes Gegenmittel war die Bus-Architektur, in der konforme Dimensionen einmal gepflegt und über Geschäftsprozesse hinweg wiederverwendet werden, doch das funktioniert nur, wo jedes Team auf dem gemeinsamen Modell aufbaut.

Der Weg über den Semantic Layer

Ein Semantic Layer schließt die Lücke logisch und zentral. Die Idee ist älter, als die heutige Beliebtheit des Begriffs vermuten lässt: Business Objects meldete sein „Universe“ aus Fachbegriffen, die SQL erzeugen, 1991 zum Patent an (US-Patent 5,555,403, erteilt 1996). Statt Definitionen in viele physische Marts einzubacken, definiert er jede Kennzahl, jede Dimension und jeden fachlichen Begriff einmal, in einer zentralen Schicht zwischen dem Warehouse und jedem nutzenden Werkzeug. Wenn ein angebundenes BI-Werkzeug, ein Notebook oder ein KI-Agent nach „Umsatz“ fragt, bekommt es die eine kanonische Definition, einheitlich berechnet, ganz gleich, wer fragt und mit welchem dieser Werkzeuge.

Die Verschiebung geht von der physischen Duplikation zur logischen Wiederverwendung. Es gibt eine Definition je Kennzahl, an einer Stelle gesteuert, und jeder Nutzer erbt sie. Das löst das Problem der Zersplitterung unmittelbar: Es kann keine drei Versionen von „Umsatz“ geben, weil es nur eine Definition gibt, die alle nutzen. Es ist auch der Grund, warum der Semantic Layer für die Analytik mit KI zentral geworden ist: Ein KI-Agent, der Fragen in natürlicher Sprache beantwortet, ist nur dann vertrauenswürdig, wenn er sich auf gesteuerte, einheitliche Definitionen stützt, statt zu raten.

Datenplattformen und BI-Werkzeuge bringen inzwischen eigene Semantic Layer mit. Der dbt Semantic Layer läuft auf MetricFlow, das dbt Labs im Oktober 2025 unter der Apache-2.0-Lizenz bereitgestellt hat. Snowflake legt Kennzahlen, Dimensionen und Fakten in Semantic Views ab, Databricks definiert sie in Metric Views in Unity Catalog, Looker nutzt LookML, und Berichte in Power BI laufen auf Semantikmodellen. Im September 2025 kündigten Snowflake, Salesforce, dbt Labs und weitere Partner die Open Semantic Interchange (OSI) an, um zu vereinheitlichen, wie semantische Metadaten definiert und zwischen Werkzeugen ausgetauscht werden. Jede dieser Schichten definiert Kennzahlen gut für die Plattform oder das Werkzeug, dem sie dient. Wer mehrere davon betreibt, braucht trotzdem einen Ort, an dem die fachliche Bedeutung hinter jeder Definition vereinbart, verantwortet und abgestimmt gehalten wird.

Zum Vergrößern klicken

Direkter Vergleich

Die beiden Ansätze unterscheiden sich in genau den Dimensionen, die für vertrauenswürdige Analytik am meisten zählen:

Wo die Logik liegt. Mart: physisch, in Tabellen je Team. Semantic Layer: logisch, in einer zentralen Definition.
Einheitlichkeit. Mart: anfällig für widersprüchliche Kennzahlen zwischen Teams. Semantic Layer: eine Definition, überall einheitlich, und das ist seine Kernstärke.
Duplikation. Mart: Daten und Logik je Mart dupliziert. Semantic Layer: einmal definieren, wiederverwenden.
Autonomie gegen Governance. Mart: hohe Autonomie der Teams, schwache zentrale Governance. Semantic Layer: starke zentrale Governance, gemeinsame Standards.
Bereitschaft für KI. Mart: Die KI muss raten, welche Definition welches Marts die richtige ist. Semantic Layer: Die KI stützt sich auf eine gesteuerte Definition, was deutlich verlässlicher ist.

Wichtig ist, dass die beiden kein striktes Entweder-oder sind: Data Marts können weiterhin als ausliefernde Schicht unter einem Semantic Layer bestehen, und viele reale Architekturen mischen sie. Doch der Schwerpunkt der Governance hat sich in Richtung Semantic Layer verschoben, weil Einheitlichkeit im großen Maßstab das ist, was unabhängige Marts selten geliefert haben.

Wie Dawiso es angeht

Ein Semantic Layer ist nur so vertrauenswürdig wie die Definitionen darin, und diese Definitionen sind Einträge im Business Glossary, also die vereinbarte, gesteuerte Bedeutung von „Umsatz“, „aktiver Kunde“ und „Abwanderung“. Genau hier fügt sich Dawiso in die Geschichte von Semantic Layer und Marts ein. Im Business Glossary von Dawiso trägt ein Business Indicator seine Beschreibung, seine Berechnung, einen Owner und einen Steward (Attribute und Komponenten), und ein Workflow führt jede Definition durch Prüfung und Freigabe. Begriffe aus dem Glossar werden automatisch erkannt und verknüpft, wo immer sie im Inhalt eines Objekts vorkommen, sodass die Dokumentation eines Marts auf die Definition zurückverweist, die er umsetzen soll. Die interaktive Data Lineage zeigt dann, soweit die Lineage erfasst ist, welche Tabellen, Views und Berichte einen bestimmten Mart oder ein Dashboard speisen, sodass ein Steward vergleichen kann, was der Mart berechnet und was die freigegebene Definition sagt. Aus „wessen Umsatz stimmt?“ wird damit eine nachvollziehbare, beantwortbare Frage. KI-Agenten können diese Definitionen, Objektdetails und die Lineage über den Dawiso MCP-Server abrufen. Ob Ihre ausliefernde Schicht nun aus Marts besteht, aus dem Semantic Layer einer Plattform oder aus beidem: Gesteuerte Definitionen sind das, was die Zahlen zur Deckung bringt.

Fazit

Der Weg von klassischen Data Marts zum Semantic Layer ist die Geschichte davon, wie die Analytik gelernt hat, ihre Definitionen einheitlich zu halten. Unabhängige Marts gaben den Teams schnellen, autonomen Zugang, ließen aber jedes Team still seine eigene Version der Wahrheit erfinden; der Semantic Layer beantwortet denselben Bedarf und definiert jede Kennzahl einmal für jedes angebundene Werkzeug, sodass das Unternehmen und jeder KI-Agent, der daraus liest, dieselbe Bedeutung von „Umsatz“ teilen. Beide können nebeneinander bestehen, doch das Muster ist klar: Einheitlichkeit kommt daher, dass Definitionen zentral gesteuert werden, und nicht daher, dass Logik je Team dupliziert wird. Legen Sie die Definitionen in ein gesteuertes Business Glossary, verbinden Sie sie über die Lineage mit den Daten, und widersprüchliche Zahlen lassen sich weit leichter finden und beheben.