Die semantische Schicht: Bedeutung, die nicht im Prompt steht.

Eine semantische Schicht ist eine Übersetzungsebene zwischen Datenbank und Mensch. Sie ordnet technischen Tabellen und Feldern Fachbegriffe, Bedeutungen und Beziehungen zu – zum Beispiel, welche Statuswerte eine offene Rechnung ausmachen oder über welchen Weg ein Kunde mit seinen Aufträgen zusammenhängt.

Sie enthält keine Geschäftsdaten, sondern die Beschreibung, wie diese Daten zu lesen sind. Damit ist sie auch keine Kopie Ihres Datenbestands.

Weil ein Sprachmodell, das nur das Schema sieht, die Bedeutung der Daten raten muss – und plausibel falsche Zahlen fallen nicht auf. Eine semantische Schicht macht die Regeln einmal ausdrücklich: Jede Frage wird gegen beschriebene Begriffe geprüft, fehlende Begriffe werden als Lücke benannt statt geraten.

Der zweite Grund ist Nachvollziehbarkeit: Zu jeder Antwort gehören die angewandten Definitionen, und eine Abweichung lässt sich auf eine benennbare Regel zurückführen.

Sie erzeugt einen Vorschlag, und der ist oft überraschend gut: Aus Datenmodell und Sourcecode lassen sich Begriffe, Beziehungen und ein großer Teil der Rechenregeln ableiten, weil die Geschäftslogik dort tatsächlich implementiert ist. Das erspart die Wochen, die eine Beschreibung von Hand kostet.

Fertig ist der Vorschlag damit nicht. Was im Code nicht steht – eine Regel, die nur mündlich gilt, oder eine Definition, die sich letztes Jahr geändert hat –, kann auch nicht abgeleitet werden, und eine abgeleitete Definition kann daneben liegen. Deshalb bestätigt Ihr Fachbereich die Begriffe, bevor damit gerechnet wird.

Die Reihenfolge ist also: automatisch erschlossen, fachlich bestätigt. Ein Modell, das Begriffe ohne diese Bestätigung verwendet, würde plausible Zahlen auf unbestätigten Annahmen liefern – und das ist genau der Fehler, den dieser Aufbau vermeiden soll.

Die Idee ist verwandt, der Einsatzpunkt ist ein anderer. Ein BI-Semantic-Layer beschreibt Kennzahlen und Dimensionen für Auswertungen, deren Form vorher bekannt ist, und setzt meist auf einem bereits aufbereiteten Modell auf.

Hier ist die Ausgangslage ein gewachsenes Produktivschema, und die Frage steht vorher nicht fest. Das Modell muss deshalb nicht nur Kennzahlen kennen, sondern auch Beziehungen erschließen, die im Schema fehlen, und Sonderfälle wie Historisierung tragen. Wenn Sie bereits einen Semantic Layer betreiben, ist das kein Widerspruch – die dort gepflegten Definitionen sind eine gute Vorlage.

Änderungen an Tabellen und Spalten treffen das Modell an den Stellen, die diese Tabellen verwenden. Weil im Modell steht, aus welchen Feldern ein Begriff entsteht, lässt sich benennen, welche Begriffe von einer Änderung betroffen sind.

Betrifft eine Änderung einen beschriebenen Begriff, ist die Beschreibung nachzuziehen. Das ist Pflegeaufwand und wird hier auch so genannt – ein Modell, das sich selbst aktuell hält, gibt es nicht.

Die Beschreibung Ihres Fachmodells liegt in Ihrer Umgebung – in der Datenhaltung des Nowl-Dienstes bei Ihnen. Definitionen und Begriffe sind als Text einsehbar; ein Export in ein offenes Format (z. B. JSON) ist in Arbeit. Wem welche Rechte am Fachmodell zustehen, regeln wir im Pilotvertrag.

Die Richtung ist dabei bewusst gewählt: Der Inhalt dieser Schicht ist genau das Wissen über Ihr System, das heute verstreut in Sourcecode und Köpfen liegt. Es an einen Anbieter zu binden, würde das Problem nur verlagern.

Das hängt davon ab, wie viel Fachlichkeit tatsächlich abgefragt werden soll. Ein vollständiges Schema hat schnell mehrere hundert Attribute, aber nur ein Teil davon wird für Auswertungen gebraucht.

In der Praxis ist es deshalb sinnvoll, mit den Bereichen zu beginnen, zu denen es echte Fragen gibt, und das Modell entlang der tatsächlich gestellten Fragen wachsen zu lassen. Ein Modell, das erst nach Monaten fertig ist, hat bis dahin nichts gezeigt.