Erklärstück · Datenarchitektur
Semantic Model, Ontology, Knowledge Graph: drei Begriffe, drei Aufgaben
Diese drei Begriffe fallen in jedem zweiten Datenprojekt, und sie meinen jedes Mal etwas anderes. Die Verwirrung kostet echte Zeit. Drei Leute reden über „unser Datenmodell“ und meinen drei verschiedene Ebenen: die Kennzahlen, die Begriffe oder die vernetzten Daten selbst.
Ich habe das in eine Übersicht gepackt. Die Grafik unten stellt die drei nebeneinander, mit einer Analogie aus dem Restaurant, einem Vergleichsraster und dem, was ich aus Projekten dazu sagen würde.
Alle drei geben Daten Bedeutung. Aber nur einer rechnet, nur einer definiert, und nur einer kennt die Zusammenhänge.
- 01 Semantic ModelRechnet
Definiert Kennzahlen wie Umsatz, aktiver Kunde und Marge einmal, für alle Berichte gleich. Die Speisekarte der Daten.
- 02 OntologieDefiniert
Legt formal fest, was ein Begriff bedeutet und welche Regeln daraus folgen, maschinenlesbar. Die Rezeptlogik.
- 03 Knowledge GraphVerknüpft
Macht konkrete Entitäten und ihre Beziehungen über Systemgrenzen hinweg abfragbar. Der volle Gastraum.
01Das Semantic Model ist die Speisekarte
Das Semantic Model ist eine Schicht über dem Data Warehouse. Dort wird einmal festgelegt, was Umsatz, aktiver Kunde oder Marge bedeuten, und diese Definition gilt dann für alle: für das Dashboard im Controlling, für den Export ins Marketing und für die Frage an den KI-Assistenten. In der Restaurant-Analogie ist das die Speisekarte. Der Gast bestellt Risotto, nicht Rundkornreis aus Regal 3. Die Karte übersetzt die Küche in Begriffe, die jede und jeder am Tisch versteht.
Die Bausteine sind überschaubar. Measures sind die Kennzahlen selbst, Dimensionen die Achsen, nach denen geschnitten wird, und Joins legen fest, wie Tabellen zusammenhängen.
Typisch dbt Semantic Layer, Cube, LookML, Power BI, AtScale
Die Grenze liegt in der Konstruktion. Ein Semantic Model kennt nur die Beziehungen, die als Join modelliert sind. Was darüber hinausgeht, etwa wie ein Lieferant mit einer Reklamation zusammenhängt, sieht es nicht.
02Die Ontologie ist die Rezeptlogik
Eine Ontologie ist ein formales Modell aus Klassen, Beziehungen und Regeln. Formal heißt: maschinenlesbar, sodass Systeme daraus Schlüsse ziehen können, ohne dass ein Mensch jeden Fall vorher ausbuchstabiert. In der Analogie ist das die Rezeptlogik. Es geht nicht um ein bestimmtes Gericht, sondern um das Prinzip dahinter. Ein Risotto braucht Reis, Fett und Brühe. Wer das weiß, erkennt auch ein Risotto, das nicht auf der Karte steht.
Typisch RDFS, OWL, SHACL für Constraints, Modellierung in Protégé
Ein Punkt, bei dem ich genau bleiben will: OWL kann Kardinalitäten ausdrücken. Eine Regel wie „Kunde mit mindestens drei Bestellungen ist Stammkunde“ ist also abbildbar. Zeitfenster wie „in den letzten zwölf Monaten“ kann OWL dagegen nicht ausdrücken, dafür braucht es Regeln außerhalb der Ontologie.
Die Grenze ist organisatorisch. Bis sich Fachbereiche auf Begriffe geeinigt haben, vergehen Monate. Und ohne angebundene Daten bleibt die schönste Ontologie Theorie.
03Der Knowledge Graph ist der volle Gastraum
Der Knowledge Graph enthält die Daten selbst. Echte Entitäten werden zu Knoten, echte Beziehungen zu Kanten, und das über Systemgrenzen hinweg. In der Analogie ist das der volle Gastraum: Tisch 7 hat das Risotto bestellt, der Reis kam von Lieferant Nord, der Gast war schon viermal da und verträgt keine Nüsse. Alles ist verbunden und lässt sich abfragen, nicht nur innerhalb einer Tabelle.
Typisch Property-Graphs wie Neo4j und TigerGraph, RDF-Stores, SPARQL
Property-Graphs speichern Knoten und Kanten mit Attributen und sind schnell im Einstieg. RDF-Stores speichern Tripel aus Subjekt, Prädikat und Objekt, werden mit SPARQL abgefragt und passen direkt zu einer Ontologie.
Die Stärke liegt im Kontext. Ein Knowledge Graph liefert KI-Anwendungen und Suche genau die Zusammenhänge, die in einzelnen Tabellen fehlen. Die Grenze ist die Datenqualität. Steht derselbe Kunde in drei Systemen unter drei IDs, entstehen drei Knoten statt einem, und jede Abfrage darauf führt in die Irre.
Aus der Praxis
Die saubere Dreiteilung ist ein Lehrmodell, kein Architekturbild. In echten Projekten überlappen Semantic Layer und Ontologie erheblich. Beide definieren Begriffe, nur mit unterschiedlicher Formalität: Der Semantic Layer sagt, wie aktiver Kunde berechnet wird, die Ontologie sagt, was ein Kunde ist und womit er in Beziehung steht. Wer beides getrennt baut, mit getrennten Teams und getrennten Glossaren, pflegt am Ende zwei Wahrheiten. Ich frage deshalb immer zuerst, wo Begriffe führend definiert werden, und leite den Rest daraus ab.
Die Aussage aus dem Vergleichsraster, ein Semantic Model werde pro Tool neu gebaut und drifte, hat ein Haltbarkeitsdatum. MetricFlow, die Engine hinter dem dbt Semantic Layer, ist seit Coalesce 2025 unter Apache 2.0 offen. Snowflake, Salesforce und dbt Labs standardisieren Metrik-Definitionen unter dem Dach der Open Semantic Interchange, damit sie zwischen Tools austauschbar werden. Heute stimmt der Satz noch. In zwölf Monaten kann diese Grenze deutlich kleiner sein.
Häufige Fragen
Was ist der Unterschied zwischen Semantic Model und Ontologie?
Ein Semantic Model legt fest, wie Kennzahlen wie Umsatz oder Marge berechnet werden, und sitzt als Schicht über dem Data Warehouse. Eine Ontologie beschreibt formal, was Begriffe bedeuten und wie sie zusammenhängen, mit Klassen, Beziehungen und Regeln in Standards wie OWL. Das Semantic Model rechnet, die Ontologie definiert Bedeutung so, dass Maschinen daraus Schlüsse ziehen können.
Braucht ein Knowledge Graph zwingend eine Ontologie?
Technisch nicht. Ein Knowledge Graph lässt sich auch ohne formale Ontologie aufbauen, etwa als Property-Graph in Neo4j mit frei vergebenen Knoten- und Kantentypen. In der Praxis wird er ohne gemeinsames Schema aber schnell beliebig, weil jedes Team Beziehungen anders benennt. Eine schlanke Ontologie sorgt dafür, dass Knoten und Kanten über Systeme hinweg dasselbe bedeuten.
Was davon brauche ich für KI-Anwendungen?
Das hängt von der Frage ab, die die KI beantworten soll. Für verlässliche Zahlen braucht ein KI-Assistent ein Semantic Model, damit Umsatz überall gleich berechnet wird. Für Kontext über Systeme hinweg, etwa bei Suche oder Retrieval-Augmented Generation, hilft ein Knowledge Graph. Eine Ontologie sorgt in beiden Fällen dafür, dass Begriffe eindeutig sind.
Womit fange ich an, wenn ich heute starte?
Mit dem Semantic Model, weil es am schnellsten Nutzen stiftet. Die zehn bis zwanzig wichtigsten Kennzahlen einmal sauber definieren, etwa im dbt Semantic Layer oder in Cube, und alle Berichte darauf umstellen. Nebenbei entsteht ein Glossar, das später zur Ontologie ausgebaut werden kann. Ein Knowledge Graph lohnt sich erst, wenn Begriffe und Datenqualität stehen.