Datenqualität messen: Wie ein Data & AI Berater ein Warehouse ausmappt

„Unsere Daten sind schlecht.“ Diesen Satz hört ein Data & AI Berater in vielen Projekten. Wie schlecht, kann meist niemand sagen. Der Bericht zeigt Zahlen. Ob die Daten dahinter von gestern sind oder vom letzten Monat, sieht man ihm nicht an. Pflichtfelder bleiben leer, und die Auswertung rechnet trotzdem, nur mit der Hälfte der Fälle.

Ohne Messwert gibt es keine Reihenfolge. Dann wird repariert, was zuletzt aufgefallen ist, und nicht das, was am schwersten wiegt. Der Berater beginnt deshalb nicht mit einer Empfehlung. Er mappt das Warehouse aus: jede Schicht, jedes Objekt, jede Spalte und den Code dazwischen.

Gemessen wird in den Schichten des Warehouse. Das gängige Muster dafür ist die Medallion-Architektur, im Deutschen auch Medaillon-Architektur. Sie ist ein Muster und kein Produkt. Databricks hat die Namen Bronze, Silber und Gold bekannt gemacht, Microsoft Fabric beschreibt denselben Aufbau für das Lakehouse, und in Snowflake entsteht er aus einer Datenbank oder einem Schema je Schicht. Ein klassisches Data Warehouse kennt dieselben Stufen als Staging, Core und Data Mart. Jede Schicht soll nur aus der darunter lesen, und mit jeder Stufe soll die Datenqualität steigen.

Viele Warehouses sind nach Data Vault gebaut: Staging, Raw Vault, Business Vault und Marts. Wie diese Schichten zu Bronze, Silber und Gold passen, ist eine Lesart und keine Tatsache. Verbreitet ist es, Raw Vault und Business Vault zu Silber zu zählen. Manche zählen den Raw Vault zu Bronze. Für die Messung zählt deshalb nicht der Name einer Schicht, sondern wer aus wem liest.

Der Berater bekommt, was jede Analystin und jeder Analyst bekommt: eine Rolle, die lesen darf. Mehr braucht er nicht. Ein Notebook befragt die Datenbank über sich selbst. Es führt nur SELECT, SHOW, DESCRIBE und GET_DDL aus und ändert nichts. Jede Abfrage steht mit ihrem Ergebnis in einem Protokoll. Zwei dieser Abfragen zeigt das Beispiel unter der Tabelle.

Gelesen werden Struktur, Code und Metadaten, dazu Zählungen, Anteile und Zeitpunkte. Einzelne Datensätze braucht die Messung nicht. Am Ende liegt das Warehouse als Inventar vor: jedes Objekt mit seiner Definition, jede Spalte mit Typ und Füllgrad, dazwischen die Abhängigkeiten. Was die Rolle nicht sehen darf, fehlt.

Aus dem Inventar entsteht in ABIS ein Graph. Knoten sind Schicht, Objekt und Spalte. Kanten sagen, was wozu gehört und was woraus berechnet wird. So lässt sich jede Spalte eines Berichts bis zu ihrer Quelle zurückverfolgen, Schritt für Schritt durch den Code. Wie das im Werkzeug aussieht, zeigt die Bildfolge aus ABIS Desktop weiter unten.

Der Graph macht zwei Dinge möglich. Eine Regel prüft einen Wert und den Weg dorthin: aus welcher Schicht eine Sicht liest und an wie vielen Stellen dieselbe Formel steht. Und der Berater kann rein- und rauszoomen, von der Wertkette über den Prozess bis zur einzelnen Spalte. Die Lineage sagt, woher eine Zahl kommt. Ob sie die richtige Frage beantwortet, zeigt erst der Prozess.

Ein Agent arbeitet auf diesem Wissensgraphen über einen MCP-Server und nicht auf der Datenbank. Wie ein Agent dagegen Daten in Snowflake abfragt, steht im Kapitel Snowflake MCP Server. Er fragt und bekommt den Ausschnitt, den die Frage braucht, statt den ganzen Bestand zu lesen. Das spart Tokens. Was sie kosten, steht im Kapitel Was Agentic BI kostet, was Data Lineage auf Spaltenebene bedeutet, in Kapitel 1.

Eine Regel ist ein Satz mit Zielwert. Sie sagt, was gelten muss, misst den Anteil der Sätze oder Objekte, die es einhalten, und vergleicht ihn mit dem Ziel. Der Agent schlägt Regeln und Zielwerte vor. Der Fachbereich bestätigt sie. Ein vorgeschlagener Zielwert bleibt als Vorschlag markiert, bis ihn jemand bestätigt.

Gemessen wird zweimal. Die erste Messung gilt den Daten, in sechs Dimensionen. Die zweite gilt dem Code, der aus den Daten die Zahlen im Bericht macht. Saubere Daten helfen nicht, wenn zwei Berichte sie verschieden verrechnen. Die Tabelle unter der Kurzantwort nennt je Dimension eine Beispielregel. Was dahintersteht, erklären die Kapitel Single Source of Truth und Datenintegrität.

Der Katalog wächst mit. Eine neue Regel ist ein Satz und läuft ab dem nächsten Lauf mit.

Jede Regel bekommt ein Ergebnis. Erreicht sie ihren Zielwert, zählt sie 100. Darunter zählt der erreichte Anteil am Ziel. Der Score einer Dimension ist das Mittel ihrer Regeln, gewichtet nach Schwere. Der Gesamtscore ist das Mittel der Dimensionen. Mit anderen Zielwerten ändert sich der Score. Von Lauf zu Lauf bleibt er vergleichbar.

Die Tabelle zeigt, wie ein Ergebnis aussieht. Die Werte sind Beispielwerte und stammen aus keinem Projekt.

Ja, aber anders, als man zuerst denkt. Die Regeln fragen Tatsachen ab: Steht ein Muster im Code einer Sicht, liest eine Sicht aus einer bestimmten Schicht, ist ein Feld gefüllt. Dafür braucht es kein Ermessen. Deshalb entscheidet ein Vergleich oder ein Muster und kein Sprachmodell. Derselbe Graph liefert immer dasselbe Ergebnis. Wie aus solchen Regeln Tests bei jedem Lauf werden, zeigt das Kapitel Datenvalidierung.

Das Sprachmodell kommt danach, als zweite Meinung. Es erklärt einen Verstoß in Worten und schlägt die Korrektur vor. Weichen feste Prüfung und Sprachmodell voneinander ab, gilt das Urteil als offen. In einer Gegenprobe widersprach kein Urteil des Sprachmodells der festen Prüfung.

Der Agent misst, der Mensch entscheidet. Ein Scan startet erst, wenn ein Mensch ihn freigibt, und der Agent sagt vorher, was er prüfen will und warum. Das ist Human in the Loop an der Stelle, an der es zählt. Vier Gründe sprechen für die feste Prüfung:

• Wiederholbar. Gleicher Code, gleiches Ergebnis. Nur so ist der Score von Lauf zu Lauf vergleichbar, und nur so zeigt er, was eine Maßnahme gebracht hat.
• Nachprüfbar. Zu jeder Lücke gibt es die Regel, die Bedingung und die Fundstelle. Jeder kann das Ergebnis nachrechnen.
• Unabhängig vom Wortlaut. Ein Sprachmodell lässt je nach Formulierung einer Regel unterschiedlich viele Urteile offen. Eine feste Bedingung hängt an keiner Formulierung.
• Schnell. Die Prüfungen laufen in Sekunden und lassen sich nach jeder Änderung am Code wiederholen.

Drei Ansichten zeigen den Weg vom Graphen zum Urteil. Die erste ist ein Bildschirmfoto der Zeichenfläche, die Namen sind ausgeblendet. Die beiden anderen sind nach ABIS Desktop nachgebaut, mit neutralen Namen und Beispielwerten. Kein Bild zeigt Daten oder Namen aus einem Projekt.

Der Abstand zum Ziel wird auf Themen verteilt. Jedes Thema hat Punkte und einen Zuständigen, und das Thema mit den meisten Punkten kommt zuerst. So wird aus einem Gefühl eine Liste. Die Werte der Tabelle sind wieder Beispielwerte. Wer zuständig ist und wie ein Fehler an die Quelle zurückgeht, regelt das Datenqualitätsmanagement.

Für die Maßnahmen gilt eine Reihenfolge: erst verlässlich, dann richtig, dann nützlich. Zuerst kommen die Daten pünktlich und vollständig an. Dann wird jede Kennzahl an genau einer Stelle gerechnet. Erst danach lohnen neue Auswertungen. Neue Dashboards vor den ersten beiden Schritten würden falsche Zahlen nur schneller verteilen.

Bevor eine Korrektur gebaut wird, lässt sie sich in ABIS als Projektion über den Graphen legen. Der Vergleich zeigt, welche bestehenden Objekte sie berührt. Jeder Lauf bleibt als Stand erhalten, und der nächste Lauf zeigt, was die Maßnahme gebracht hat. Wie daraus ein Verlauf wird, steht im Kapitel Data Observability.

Ein ausgemapptes Warehouse zeigt, was zu reparieren ist. Es zeigt auch, was ungenutzt bereitliegt. Ein Datenprodukt ist ein Datenbestand, der wie ein Produkt geführt wird: mit einem Verantwortlichen, einer Beschreibung, einer zugesagten Qualität und Nutzern, die sich darauf verlassen.

Der Berater ordnet das Potenzial in Ringen um die oberste Schicht. Je weiter außen, desto weniger ist belegt. Ein Potenzial wird erst zum Vorschlag, wenn der Schlüssel dazu gepflegt ist und der Fachbereich die Frage dazu stellt. Die Ringe und die Stufen beschreibt das Kapitel Datenprodukte finden.

Aus den Ringen entsteht ein Katalog möglicher Berichte in Stufen. Die Stufe sagt, was vorher erledigt sein muss: erst läuft der Ladelauf verlässlich, dann sind die Korrekturen am Code umgesetzt, dann kommen zusätzliche Felder dazu. Die Auswahl trifft der Kunde. Ein Datenprodukt mit zwei bis vier Berichten ist auch der Umfang, mit dem DBI bei Power BI und Snowflake beginnt.

Für Lineage und Katalog gibt es Werkzeuge. Snowflake selbst zeigt die Herkunft bis auf die Spalte, dbt für alles, was dbt baut, Katalog-Plattformen über Systeme hinweg. Das Vorgehen mit ABIS ersetzt keines davon. Es ist der schnelle, gezählte Einstieg: ein Graph, auf dem Regeln laufen und ein Agent arbeitet. Die Angaben der Tabelle folgen der Dokumentation der Hersteller, Stand 12. November 2026.

Der Score zeigt, ob Daten und Code den vereinbarten Regeln folgen. Ob eine Kennzahl fachlich richtig definiert ist, klärt weiter der Fachbereich. Snowflake ist dabei nur das Beispiel. Das Verfahren braucht drei Dinge: Lesezugriff, die Definitionen als Code und einen Regelkatalog. Es lässt sich deshalb auf jede Datenbank übertragen, die SQL spricht, und auf das Semantikmodell in Power BI. Wie das im Modell geht, zeigt Datenqualität in Power BI prüfen.

• Er sieht, was die Rolle sieht. Objekte ohne Leserecht fehlen im Inventar, und zwar ohne Hinweis.
• Geprüft ist der Code, wie er ausgerollt ist. Was im Repository steht, kann davon abweichen.
• Jeder Zielwert ist eine Vereinbarung. Mit anderen Zielwerten ändert sich der Score. Ein Vorschlag des Agenten zählt erst, wenn der Fachbereich ihn bestätigt hat.
• Es ist eine Momentaufnahme. Jeder Lauf trägt einen Zeitstempel. Nach einer Änderung läuft die Messung neu.
• Eine Vorschau mit Beispielwerten liest echte Daten. Sie lässt sich abschalten. Dann bleiben Struktur, Code und Zählungen.