MCP & KI
Was in einem Semantic Layer wirklich drinsteht
„Ihr braucht einen Semantic Layer“ steht inzwischen in jedem zweiten Vortrag über KI und Daten. Was einer enthält, steht selten dabei. Es ist weniger, als man denkt, und die entscheidende Zeile ist keine Tabelle, sondern eine Regel.
Ein Semantic Layer wird meist als Konzept beschrieben: eine Schicht zwischen den Tabellen und den Fragen, die für gemeinsame Begriffe sorgt. Das stimmt und hilft niemandem beim Bauen. Konkret sind es drei gespeicherte Dinge.
Die drei Teile
| Was | Was gespeichert wird | Wofür |
|---|---|---|
| Kennzahl | Name, Beschriftung, Beschreibung, Katalog, Schema, Tabelle — und ein SQL-Ausdruck | Die Messgröße selbst, etwa eine Summe über eine Spalte |
| Dimension | Name, Beschriftung und ein SQL-Ausdruck, gebunden an genau eine Kennzahl | Die erlaubten Gruppierungen: nach Region, nach Monat, nach Produkt |
| Join | Art (inner oder left), Zieltabelle, Bedingung, Reihenfolge | Erweitert die Basistabelle der Kennzahl — aus einer Kennzahl wird eine semantische Sicht |
Mehr ist es nicht. Eine Kennzahl mit ihren Dimensionen entsteht in einer einzigen Transaktion, damit niemand je eine halbe Kennzahl zu sehen bekommt — eine Messgröße ohne ihre erlaubten Gruppierungen wäre schlimmer als keine.
Die Regel, auf die es ankommt
Messgröße und Dimension sind niemals SQL, das ein Modell geschrieben hat. Es sind exakt die Ausdrücke, die ein Administrator hinterlegt hat, wörtlich eingesetzt. Alles andere — Katalog, Schema, Tabelle, Spaltennamen — läuft durch eine Positivliste und wird in Anführungszeichen gesetzt.
Das ist der Unterschied zwischen einem Semantic Layer und einer Sammlung von Textbausteinen. Wenn das Modell den Ausdruck formulieren darf, hat man kein Rechtemodell, sondern eine Hoffnung. Wenn es ihn nur auswählen darf, ist der schlimmste Fall die falsche Kennzahl — nicht die falsche Abfrage.
Was der Aufrufer trotzdem frei bestimmt
Genau eine Sache: den Filter. Wer fragt, darf eine Bedingung mitgeben — „nur Region Nord“, „nur dieses Quartal“. Das muss frei sein, sonst wäre die Schicht unbrauchbar. Drei Dinge halten es im Rahmen:
- Der Filter läuft unter der delegierten Kennung des Fragenden. Er kann damit nie mehr sehen als im SQL-Arbeitsblatt — dieselben Grants, dieselben Zeilen- und Spaltenrichtlinien entscheiden.
- Er ist begrenzt: Länge, keine Steuerzeichen, kein Anweisungstrenner. Damit lässt sich die eine Anweisung weder zerlegen noch eine zweite einschmuggeln.
- Die Zeilenzahl je Abfrage hat eine harte Obergrenze. Eine Kennzahl ist eine Auswertung, kein Datenexport.
Auch die Join-Art wird dreifach abgesichert: beim Anlegen geprüft, in der Datenbank per Bedingung erzwungen und beim Bauen der Abfrage noch einmal, wo ein unerwarteter Wert einen Fehler auslöst statt ein Schlüsselwort zu erzeugen. Das wirkt übertrieben, bis man sich fragt, was ein manipulierter Datenbestand sonst anrichten könnte.
Warum das mehr ist als eine Namenskonvention
Der eigentliche Gewinn zeigt sich an dem Fall, den jedes Unternehmen kennt: Zwei Abteilungen definieren Umsatz unterschiedlich. Die eine rechnet Retouren heraus, die andere nicht. Beide haben recht, beide haben es in ihrer Arbeitsmappe so gebaut, und in der Sitzung stehen zwei Zahlen auf zwei Folien.
Ohne Semantic Layer ist die Definition an so vielen Stellen kopiert, wie es Berichte gibt. Eine Korrektur muss überall nachgezogen werden, und niemand weiß, wo überall. Mit Semantic Layer ist die Definition eine Zeile. Wer sie ändert, ändert die Antwort im Chat, im Dashboard und im BI-Werkzeug gleichzeitig — weil alle drei dieselbe Zeile lesen und nicht drei Kopien davon.
Das ist auch die Prüffrage für jede Umsetzung, die einem angeboten wird: Entsteht das SQL für Chat, Dashboard und BI aus demselben Baustein? Wenn nicht, hat man drei Semantiken mit einem gemeinsamen Namen.
Was ein Semantic Layer nicht löst
Er macht Zahlen nicht richtig, sondern einheitlich. Wenn die hinterlegte Definition falsch ist, sind alle Antworten gleichermaßen falsch — nur eben konsistent, was die Sache schwerer auffindbar macht. Die Entscheidung, was Umsatz bedeutet, nimmt einem keine Software ab. Sie ist eine Führungsaufgabe, die Software macht sie nur durchsetzbar.
Und er ersetzt keine Datenqualität. Eine saubere Kennzahl über einer Tabelle mit doppelten Zeilen liefert eine saubere falsche Zahl.
Woran man merkt, dass einer fehlt
- Zwei Berichte zur gleichen Sache weichen ab, und die Klärung dauert länger als die Erstellung gedauert hat.
- Auf die Frage, wie eine Kennzahl gerechnet wird, verweist man auf eine Person statt auf eine Stelle.
- Ein KI-Assistent bekommt ein Werkzeug, das SQL entgegennimmt — und niemand kann sagen, welche Abfragen er morgen stellen wird.
- Eine Definition ändert sich, und die Aufgabe lautet: „prüf mal, wo das überall drinsteckt.“
Der dritte Punkt ist der neue. Die anderen drei kennt man seit zwanzig Jahren aus dem Berichtswesen; sie waren lästig und beherrschbar. Ein Agent, der SQL schreiben darf, macht daraus ein Sicherheitsthema — und dann ist die Schicht, über die alle reden, plötzlich keine Frage des Stils mehr.
Quellen
Alle Zahlen in diesem Beitrag sind belegt. Wo keine belastbare Quelle vorliegt, steht keine Zahl.