Single Source of Truth: eine Rechenregel an genau einer Stelle

Die eine Stelle fehlt, wenn dieselbe Kennzahl in zwei Berichten zwei Werte hat und niemand den Unterschied erklären kann. So beginnt der Auftrag in diesem Kapitel. In der Montagsrunde liegen drei Berichte auf dem Tisch. Jeder zeigt für den Auftragseingang im Oktober einen anderen Wert: 4,82, 4,61 und 4,95 Millionen Euro. Das sind Beispielwerte. Jemand fragt den Data & AI Berater, welcher Wert gilt.

Er kann es nicht sagen, und das ist seine erste Auskunft. Jeder der drei Werte ist sauber gerechnet, nur jeder nach einer anderen Rechenregel. Welche Rechenregel gelten soll, weiß der Fachbereich und kein Bericht. Der Berater wählt deshalb keinen Wert aus. Er sucht zuerst alle Stellen, an denen die Rechenregel steht.

Im Beispiel sind es drei, und beschlossen hat das niemand. Zuerst stand die Rechenregel in einer Sicht im Warehouse. Für einen Bericht wurde sie in ein Measure kopiert, später für eine Auswertung in eine Formel in Excel. Am Tag der Kopie stimmten alle Werte überein. Danach wurde das Original zweimal geändert, und die Kopien blieben, wie sie waren.

Die Montagsrunde ist das lauteste Anzeichen. Die leiseren stehen in der Tabelle.

Beides kommt vor, und die Art der Logik entscheidet. Logik, die jeder Abnehmer braucht, gehört in die Datenbank: als Sicht in der obersten Schicht des Warehouse. Logik, die vom Filter eines Berichts abhängt, gehört als Measure in das Semantikmodell. Die Tabelle unter der Kurzantwort ordnet typische Fälle zu.

Der Grund ist die Zahl der Abnehmer. Eine Sicht liest jedes Werkzeug, das SQL spricht: Power BI ebenso wie ein Export oder ein Agent. Ein Measure erreicht nur, wer über dieses eine Semantikmodell liest. Steht die Abgrenzung des Auftragseingangs im Measure, muss jeder andere Abnehmer sie nachbauen. So entstehen Kopien.

Daraus folgt die Regel für den Ort: die unterste Schicht, die alle Abnehmer einer Rechenregel gemeinsam haben. Für eine Kennzahl ist das meist die oberste Schicht, denn von dort lesen die Berichte. In einer Medallion-Architektur heißt sie Gold. Eine Umrechnung, die mehrere Sichten brauchen, steht eine Schicht tiefer.

Der Berater schlägt zuerst eine Sicht vor. Sie ändert kein bestehendes Objekt und lässt sich neben den Kopien prüfen. Das Modell im Warehouse wird nur erweitert, wenn ein Merkmal fehlt, Historie nötig ist oder die Laufzeit es verlangt.

Im Bericht bleibt, was ohne seinen Filter keinen Sinn ergibt: der Vergleich zum Vorjahr, die laufende Summe, der Anteil am Gesamtwert. Solche Measures rechnen auf dem Ergebnis der Sicht weiter und wiederholen deren Rechenregel nicht. Wie Definitionen für Agenten lesbar werden, zeigt das Kapitel Semantic Layer.

Zwei Gruppen von Regeln sichern sie: Regeln zur Rechenlogik und Regeln zu Namen. Jede Regel ist ein Satz mit Zielwert, wie in Datenqualität messen beschrieben. Geprüft wird am Code und nicht an den Daten.

Die Regeln zur Rechenlogik sagen, wo eine Rechenregel stehen darf. Die Regeln zu Namen sorgen dafür, dass sich Kopien finden lassen. Heißt dieselbe Kennzahl an drei Stellen verschieden, läuft jede Suche ins Leere. Trägt ein Spaltenname zwei Herkünfte, vergleicht ein Bericht Dinge, die nicht zusammengehören.

Jede Regel nennt ihren Zweck, den Ort der Prüfung und die Bedingung. Ihr Zielwert bleibt als Vorschlag markiert, bis der Fachbereich ihn bestätigt.

Die Regeln laufen nach jeder Änderung am Code. Dazu kommt ein Abnahmekriterium: Bericht, Berichtssicht und Excel-Export zeigen dieselbe Zahl. Bei der Abnahme vergleicht das Team die drei Werte. Danach wiederholt eine Abfrage im Warehouse den Vergleich von Sicht und Berichtssichten bei jedem Ladelauf. Eine Abweichung fällt so am selben Tag auf und nicht erst in der Montagsrunde.

Ein Graph findet Kopien, weil er SQL-Code und Berichte in einem Netz aus Knoten und Kanten hält. Knoten sind Objekte, Spalten, Measures und Berichte. Kanten sagen, was woraus berechnet wird. So wird aus der Suche nach Kopien eine Abfrage: nach Knoten, die aus denselben Spalten dasselbe rechnen.

Der Berater baut den Graphen in ABIS und beginnt mit einem Export. Ein Notebook in Snowflake liest die Definitionen der Sichten mit einer Leserolle und legt sie als SQL-Dateien ab. ABIS liest diese Dateien und führt selbst nichts auf Snowflake aus. Dazu kommt das Semantikmodell aus Power BI. Beide liegen im selben Graphenmodell.

Ein Overlay legt den Arbeitsbereich mit dem Power-BI-Modell über den Arbeitsbereich mit dem SQL-Code. Es verbindet Knoten, die gleich heißen. Mehr leistet es nicht: Eine automatische Zuordnung von Power-BI-Objekten zu Snowflake-Objekten gibt es in ABIS nicht. Wo die Namen abweichen, ordnet der Berater von Hand zu.

Auf dem verbundenen Graphen sucht er nach fünf Signalen. Jede Abfrage dazu schreibt er für das Projekt, denn einen fertigen Detektor für doppelte Kennzahlen hat ABIS nicht. Das Sprachmodell gibt danach die zweite Meinung zu jedem Treffer und begründet sie in Worten. Ein Treffer bleibt eine These, bis ein Mensch ihn bestätigt.

Ein sechstes Signal steht in keinem Code. Der Berater fragt den Fachbereich, wo zwei Zahlen voneinander abweichen und welche zählt. Die Antworten zeigen, wo die Suche beginnt.

Der Fachbereich entscheidet, und eine benannte Person zeichnet die Entscheidung ab. Die gewählte Rechenregel ist von da an die Referenz. Der Berater bereitet die Entscheidung vor. Er legt die Kopien nebeneinander: wo jede steht, worin sie sich unterscheiden und welcher Bericht welche nutzt. Im Beispiel sind es zwei Unterschiede. Eine Kopie zählt stornierte Aufträge mit, eine kennt einen neuen Status nicht.

Das Datenteam kann die Frage nicht beantworten. Ob ein stornierter Auftrag zum Auftragseingang zählt, steht in keinem Code. Eine Wahrheit für Kennzahlen ist eine Vereinbarung darüber, was das Unternehmen mit einem Wort meint. Deshalb ist dieser Schritt im Schaubild orange.

Nicht jede Abweichung verschwindet. Braucht die Planung den Auftragseingang mit stornierten Aufträgen, ist das eine zweite Kennzahl mit eigenem Namen. Sie bleibt im Katalog, als akzeptiert markiert und ohne Wertung im Score. So unterscheidet sich eine gewollte Variante von einer vergessenen Kopie.

Festgehalten wird die Entscheidung im Kennzahlen-Steckbrief. Kennzahlen einheitlich definieren heißt dort: ein Begriff, ein Eintrag, mit Rechenregel, Einheit, Korn und Verantwortlichem. Synonyme stehen als Alias dabei. Im Zielbild verweisen die Spalte im Warehouse, das Measure und das Feld im Bericht auf diesen Eintrag. Das Glossar wird dann aus den Einträgen erzeugt und nicht daneben gepflegt. Kennzahlen einmal definieren, überall nutzen.

In Snowflake ist die eine Stelle eine Sicht in der obersten Schicht. Die Sicht auftragseingang grenzt ab, rechnet um und liefert je Auftrag einen Betrag. Ihr Kommentar nennt die Rechenregel in einem Satz. Berichtssichten und Exporte lesen von ihr, und keine rechnet neu. Das Beispiel unter der Tabelle zeigt eine solche Sicht.

Für Fragen in natürlicher Sprache kennt Snowflake zusätzlich Semantic Views. Eine Semantic View ist ein Objekt im Schema. Sie beschreibt Tabellen oder Sichten in Fachsprache: mit Fakten, Dimensionen und Kennzahlen, je mit Synonymen und Kommentar. Cortex Analyst liest sie und schreibt aus einer Frage das passende SQL. Auch Cortex Agents und SQL-Abfragen können sie nutzen. So beschreibt es die Dokumentation von Snowflake, Stand November 2026.

Damit gibt es eine weitere Stelle, an der eine Rechenregel stehen könnte. Der Berater hält sie deshalb schlank. Die Kennzahl in der Semantic View summiert eine Spalte der Sicht. Abgrenzung und Umrechnung bleiben in der Sicht. Die Semantic View beschreibt, die Sicht rechnet.

Für Power BI liegt die Definition an einer von zwei Stellen. Was jeder Abnehmer braucht, liest Power BI aus der Sicht in Snowflake. Was vom Filter des Berichts abhängt, steht als Measure im Semantikmodell von Power BI.

Jede dieser Stellen bekommt eine Beschreibung in den Worten des Steckbriefs. Der Grund ist der nächste Abnehmer. Ein Agent liest keine Dashboards, er liest Definitionen. Was dort nicht steht, erfindet er.

Die Grenzen liegen dort, wo der Code endet. Der Graph zeigt, wo eine Rechenregel steht und wer sie kopiert hat. Ob sie fachlich richtig ist, zeigt er nicht. Auch eine einzige Stelle liefert falsche Zahlen, wenn die Daten darunter nicht stimmen. Ein doppelt geladener Auftrag zählt doppelt. Welche Regeln Schlüssel und Historie sichern, zeigt das Kapitel Datenintegrität.

Snowflake ist dabei das Beispiel. Die Regel der untersten gemeinsamen Schicht gilt für jedes Warehouse, das SQL spricht.

• Der Graph sieht, was vorliegt. Eine Formel in einer Arbeitsmappe fehlt, bis jemand die Datei beisteuert. Was die Leserolle nicht sieht, fehlt ebenfalls.
• Ähnlich ist nicht gleich. Zwei Ausdrücke können gleich aussehen und Verschiedenes meinen. Deshalb bestätigt ein Mensch jeden Treffer.
• Eine Stelle heißt nicht: eine Zahl für jeden Zweck. Zwei Abgrenzungen sind zwei Kennzahlen mit zwei Namen. Ausgeschlossen ist nur dieselbe Kennzahl mit zwei Rechenregeln.
• Die Zuordnung zwischen Power BI und Snowflake ist Handarbeit. Das Overlay verbindet gleiche Namen. Alles andere ordnet der Berater zu.
• Geprüft ist der Code, wie er ausgerollt ist. Nach jeder Änderung läuft die Prüfung neu.