Datenvalidierung: Regeln als Tests bei jedem Lauf

Weil jeder Ladelauf neue Daten bringt und eine Messung nur den Tag zeigt, an dem sie lief. Ein Data & AI Berater hat für ein Team das Warehouse ausgemappt und gemessen, so wie es Datenqualität messen beschreibt. Das Ergebnis im Beispiel: 81 von 100 Punkten, 19 Punkte bis zum Ziel. Das Team kennt jetzt seine Lücken und hat eine Reihenfolge.

Kurz darauf hat das Team die nächste Bitte. Die Regeln sollen nicht bis zur nächsten Messung warten, sie sollen bei jedem Ladelauf mitlaufen. Denn ein leeres Pflichtfeld entsteht nicht im Projekt. Es kommt an einem gewöhnlichen Dienstag mit der Lieferung aus dem Quellsystem, und der Bericht zeigt am Mittwoch trotzdem eine Zahl.

Der Berater macht deshalb aus jeder Regel einen Test. Die Regel bleibt ein Satz mit Zielwert. Der Test ist derselbe Satz als Abfrage: Sie zählt bei jedem Lauf, wie viele Zeilen die Regel einhalten. So fällt ein falscher Wert am Tag der Lieferung auf und nicht erst, wenn jemand im Bericht darüber stolpert.

Dabei braucht nicht jede Regel denselben Takt. Regeln für die Daten laufen mit dem Ladelauf, Regeln für den Code nach jeder Änderung am Code. Die Tabelle zeigt, wann welcher Test läuft.

Eine Plausibilitätsprüfung prüft, ob ein Wert möglich ist: ein Datum im erwartbaren Fenster, ein Betrag im erwartbaren Bereich, zwei Daten in der richtigen Reihenfolge. Ob der Wert stimmt, prüft sie nicht. Ein Lieferdatum von gestern kann falsch sein und ist trotzdem plausibel.

Der Berater beginnt mit Vollständigkeit und Plausibilität, weil der Fachbereich diese Regeln ohne Vorwissen beurteilen kann. Niemand muss SQL lesen, um zu sagen, ob ein Auftrag ohne Betrag sein darf. Schlüssel, Eindeutigkeit und Historie kommen danach. Die Regeln dafür stehen in Datenintegrität.

Jede Regel schreibt er als Abfrage, die nur zählt. Sie gibt drei Dinge zurück: geprüfte Zeilen, verletzte Zeilen und den Anteil. Einzelne Datensätze liest sie nicht. Dafür genügt eine Rolle, die lesen darf.

Nicht jede Regel verlangt 100 %. Ein Fenster für Datumswerte verträgt wenige Ausreißer, etwa aus einer alten Datenübernahme. Ein technischer Platzhalter in einer Kennzahl verträgt keinen. Die Zielwerte der Tabelle sind Beispielwerte. Welcher Wert gilt, entscheidet der Fachbereich.

dbt-Tests und Data Metric Functions prüfen Daten, Regeln im Graphen prüfen den Code. Welcher Weg für die Daten passt, hängt am Team. Der Berater fragt deshalb zuerst, womit es lädt und baut. Ein Test gehört dorthin, wo er ohnehin mitläuft. Ein zweites Werkzeug für dieselbe Regel liefert nur zwei Ergebnisse, die sich widersprechen können.

Baut das Team mit dbt, liegen die Tests neben dem Modell. Ein dbt-Test ist eine Abfrage, die verletzte Zeilen zurückgibt. Liefert sie keine Zeile, ist er bestanden. Vier Tests bringt dbt mit: unique, not_null, accepted_values und relationships. Jede weitere Regel schreibt das Team als eigene Abfrage.

Snowflake bringt einen eigenen Weg mit, das Data Quality Monitoring. Eine Data Metric Function misst einen Wert an einer Tabelle oder Sicht, zum Beispiel die Zahl leerer Felder. Sie läuft nach einem Zeitplan, der an der Tabelle hängt. Ob der Messwert ein Problem ist, sagt erst eine Erwartung, die das Team dazu festlegt. Funktion, Zeitplan und Erwartung richtet das Team mit ALTER an der Tabelle ein, nicht der Berater mit seiner Leserolle. Das Beispiel am Ende des Abschnitts zeigt beide Anweisungen.

Beide Wege sehen Zeilen und Werte. Ob eine Sicht an einer Schicht vorbeiliest, steht in keiner Zeile, es steht im Code. Dafür entsteht in ABIS aus den exportierten Definitionen ein Graph, und die Regel wird eine Abfrage auf diesem Graphen. Umgekehrt sieht der Graph keine Zeile. Ob ein Pflichtfeld gefüllt ist, weiß er nicht. Die Tabelle unter der Kurzantwort stellt die Wege gegenüber. Ihre Angaben folgen der Dokumentation der Hersteller, Stand November 2026.

Jede Regel läuft dort, wo ihr Gegenstand liegt: Regeln über Daten im Warehouse, Regeln über Code auf dem Graphen. Der Berater geht den Katalog Regel für Regel durch. Zu jeder trägt er zwei Dinge ein: was sie prüft, Daten oder Code, und als was sie läuft.

Die Spalte „Läuft als“ zeigt den Aufwand. Ein Pflichtfeld ist in dbt eine Zeile in einer YAML-Datei. Ein Datum im Fenster braucht eine eigene Abfrage mit Zielwert. Für die Schichten braucht es den Graphen. Die letzte Zeile ist ein Sonderfall: Ob eine Beschreibung verständlich ist, lässt sich nicht abfragen.

Weil ein Test dasselbe Ergebnis liefern muss, solange sich nichts geändert hat. Eine Abfrage oder ein Muster tut das. Ein Sprachmodell kann dieselbe Regel je nach Wortlaut anders beurteilen. Dann wüsste niemand, ob sich die Daten geändert haben oder nur das Urteil.

Deshalb entscheidet die feste Prüfung: eine Abfrage im Warehouse, eine Abfrage auf dem Graphen oder ein Skript über den Code. Das Sprachmodell kommt danach, als zweite Meinung. Es erklärt einen Verstoß in Worten und schlägt die Korrektur vor. Dieselbe Aufteilung beschreibt die Prüfweise in Datenqualität messen.

ABIS liefert dafür den Graphen und die zweite Meinung. Das Sprachmodell prüft dort als Richter je Aufruf einen Knoten des Graphen, zum Beispiel eine Sicht. Zu jeder Regel gibt es eines von drei Urteilen zurück: erfüllt, verletzt oder nicht anwendbar, dazu eine Wahrscheinlichkeit. Liegt sie unter dem Mindestwert, zeigt ABIS das Urteil als ungeprüft. Jedes Urteil bleibt in einer Historie.

Weichen feste Prüfung und zweite Meinung voneinander ab, bleibt das Urteil offen. Dann sieht sich ein Mensch die Fundstelle an. Auch der Start liegt beim Menschen. Fragt ein Agent einen Scan an, startet der Scan erst, wenn ein Mensch ihn in ABIS mit einer PIN freigibt. Wie solche Freigaben aufgebaut sind, zeigt Human in the Loop.

Der Fachbereich bestätigt ihn, genauer die Person, die den Prozess hinter den Daten verantwortet. Der Berater schlägt den Zielwert nur vor. Bis zur Bestätigung steht er im Katalog als Vorschlag. Denn ein Zielwert ist eine fachliche Aussage: Er sagt, wie viele Aufträge ohne Betrag das Geschäft verträgt.

Das Gespräch dazu führt der Berater mit Zahlen. Er bringt je Regel den gemessenen Anteil mit, aufgeteilt nach Währung oder Region. Der Fachbereich sagt, was davon ein Fehler ist und was Absicht. Aus manchem vermeintlichen Fehler wird so eine Ausnahme, die bleiben darf.

Dafür trägt jede Regel einen Zustand. Ohne ihn kennt ein Test nur bestanden oder gescheitert. Scheitert er an einer bekannten Ausnahme, bleibt dem Team nur, ihn abzuschalten. Mit dem Zustand „akzeptiert“ bleibt die Ausnahme im Katalog sichtbar und zählt nicht gegen den Score.

Im Score zählt eine aktive Regel mit ihrem erreichten Anteil am Zielwert, höchstens mit 100. Ein Beispiel: Sind 90 % erreicht und 95 % das Ziel, zählt die Regel knapp 95 Punkte.

Das Team behandelt den Regelkatalog wie Code: Er ist versioniert, jede Regel hat dieselben Pflichtangaben und eigene Prüffälle. Sonst senkt jemand still einen Zielwert, und der Score steigt, obwohl sich an den Daten nichts getan hat.

Drei Gewohnheiten tragen das. Erstens entstehen die Prüffälle vor der Regel: Beispiele mit typischen Fehlerbildern, die die Regel finden muss. Zweitens schwächt niemand eine Regel nachträglich ab. Wer einen Zielwert senken will, braucht die Bestätigung des Fachbereichs und eine neue Version des Katalogs. Drittens friert das Team den Katalog ein, bevor es misst.

Der dritte Punkt entscheidet über den Vergleich. Zwei Läufe lassen sich nur vergleichen, wenn Regeln und Zielwerte gleich geblieben sind. Deshalb trägt jeder Lauf die Version des Katalogs. Neben dem Score steht, wie viele Regeln von allen in die Wertung eingehen.

Zu jedem Kriterium schreibt der Lauf einen Nachweis. Wer ein Ergebnis anzweifelt, rechnet es am selben Datenstand nach. Wie aus den Ergebnissen vieler Läufe ein Verlauf wird, zeigt Datenqualität überwachen.

Ein Test zeigt, ob Daten und Code die vereinbarten Regeln einhalten. Ob die Regel selbst richtig ist, klärt weiter der Fachbereich. Snowflake ist dabei das Beispiel: Eine Abfrage mit Zielwert läuft in jeder Datenbank, die SQL spricht. Sechs Grenzen sollte ein Team kennen, bevor es sich auf bestandene Tests verlässt. In einem Power-BI-Modell läuft dieselbe Regel als DAX-Abfrage, wie Datenqualität in Power BI prüfen zeigt.

• Plausibel ist nicht richtig. Ein Wert im erlaubten Bereich kann falsch sein. Die Plausibilitätsprüfung findet das Unmögliche, nicht das Falsche.
• dbt-Tests und Data Metric Functions prüfen Daten, nicht den Aufbau. Sie sehen Zeilen und Werte. Ob eine Sicht die Regeln für die Schichten einhält, zeigt erst der Graph.
• Der Graph sieht keine Zeilen. Er kennt Definitionen und Abhängigkeiten. Ob ein Feld gefüllt ist, misst nur eine Abfrage im Warehouse.
• Data Metric Functions brauchen die Enterprise Edition. Laufen sie nach Zeitplan, verbrauchen sie Rechenzeit, die Snowflake abrechnet (Stand November 2026).
• ABIS liest Definitionen, keine Testergebnisse. Die Ergebnisse von dbt-Tests und Data Metric Functions bleiben im Warehouse. In die Auswertung kommen sie von dort.
• Die Rolle begrenzt die Sicht. Was die Leserolle nicht sehen darf, prüft kein Test, und kein Ergebnis weist darauf hin.