Teil 11. Datenvalidierung: validation.md

In SDD ist Validierung keine Floskel wie «die Daten sind korrekt». Es ist eine Sammlung von Fakten. In einem Datenprojekt muss ein Fakt die Spezifikation, SQL und einen Beweis miteinander verknüpfen. Wenn ein Fakt sich nicht durch einen Befehl, eine SQL-Abfrage oder einen manuellen Reviewer-Schritt ausführen lässt, ist er noch nicht fertig.

Beispiel für Validierungsfakten

### F1 — Customer 360 grain

- Befehl: `dbt test --profiles-dir . --select mart_customer_360`
- Erwartung: `customer_id` unique und not_null.
- Status: akzeptiert.

### F2 — PII ist nicht in den Mart gelangt

- Befehl: `dbt test --profiles-dir . --select assert_customer_360_no_direct_pii`
- Erwartung: Test gibt 0 Zeilen zurück.
- Status: akzeptiert.

Automatische und manuelle Fakten

Automatische Fakten werden durch einen Befehl ausgeführt. Manuelle Fakten erfordern das Lesen einer Änderung oder eine Bestätigung durch das Business. Beide Arten werden benötigt. dbt weiß nicht, dass ein «aktiver Kunde» korrekt definiert ist, wenn dies nicht in der Spezifikation festgehalten ist.

Ein guter manueller Fakt:

Der Reviewer hat bestätigt, dass das Hinzufügen von `product_code` den grain ändern würde und nicht zu dieser Phase gehört.

Ein schlechter manueller Fakt:

Sieht normal aus.

Wo wird validation gespeichert

Im Lernbeispiel liegen die Validierungsnotizen in specs/validation/. Dies muss nicht der einzige Ort sein, aber die Regel lautet: validation.md muss versionierbar und nach /clear lesbar sein. Wenn ein Fakt nur im Chat lebt, kann er kein Beweis für ein Release sein.

Qwen-Abfrage

Erstelle einen Entwurf für validation.md für mart_customer_360.
Verwende specs/models/mart_customer_360.md, ODCS, ODPS und models/schema.yml.
Ändere keine dbt-Modelle.

Minimale Ausgabe

Eine minimale validation.md für ein Mart sollte enthalten:

• einen Fakt zum grain;
• einen Fakt zu PII;
• einen Fakt zu den Pflichtfeldern des Kontrakts;
• einen Fakt zur Lineage oder eine Liste der Eingabemodelle;
• einen manuellen Fakt: Eine Änderung ändert die Felder des Kontrakts nicht ohne Genehmigung.

Wenn ein Fakt nicht überprüfbar ist, schreiben Sie ihn als Befehl, SQL-Abfrage, dbt-Test oder Reviewer-Schritt neu.

Analyse für den Leser

validation.md ist der Ort, an dem das Lehrbuch absichtlich streng wird. Solange ein Fakt keinen Befehl, keine SQL-Abfrage oder keinen manuellen Reviewer-Schritt hat, bleibt er ein Wunsch. Die Floskel «die Daten sind korrekt» schützt nichts: Ein Agent kann Korrektheit als das Fehlen von Ausführungsfehlern verstehen, ein Analyst als das Fehlen von Nullwerten, ein Produktverantwortlicher als die Erhaltung des grain. Ein Validierungsfakt beseitigt diese Mehrdeutigkeit.

Nicht alle Fakten müssen automatisiert werden. In Daten gibt es Entscheidungen, die das Lesen einer Änderung und das Verstehen des Kontrakts erfordern. Beispielsweise kann dbt beweisen, dass customer_id eindeutig ist, aber es entscheidet nicht, ob das Hinzufügen von product_code zu Customer 360 zulässig ist. Einen solchen Fakt lässt man besser manuell und weist explizit einen Reviewer zu. Manuell bedeutet nicht schwach; schwach wird er erst, wenn nicht angegeben ist, was genau zu lesen ist und welche Schlussfolgerung zu ziehen ist.

Eine gute Validierungsnotiz verbindet mehrere Schichten: die Modellspezifikation, ODCS, models/schema.yml, Singular-Tests und den Reviewer-Bericht. Wenn sich eine der Schichten ändert, sollte validation.md zeigen, welche Fakten überprüft werden müssen. Dies macht eine Datenänderung einem ingenieurmäßigen Prozess ähnlich statt einer Sammlung zusammenhangloser SQL-Patches.

Der Leser sollte sich daran gewöhnen, validation.md vor dem SQL zu schreiben. Das ist nur beim ersten Mal unbequem. Danach beginnen die Validierungsfakten zu helfen: Sie begrenzen den Umfang der Lösung, geben Hinweise, welche Tests nötig sind, und liefern dem Reviewer eine fertige Rubrik. Wenn validation.md nach dem SQL geschrieben wird, wird diese Datei oft zur Rechtfertigung dessen, was bereits gemacht wurde.

Übung

Nehmen Sie einen schwachen Punkt wie «Datenqualität prüfen» und schreiben Sie ihn in drei Formen um: dbt-Befehl, SQL/Singular-Test und manueller Reviewer-Fakt.

Typischer Fehler

«Datenqualität prüfen» schreiben. Das ist kein Fakt. Ein Fakt klingt so: «customer_id ist in mart_customer_360 eindeutig, der Befehl dbt test --select mart_customer_360 gibt den Exit-Code 0 zurück».

Kontrollfragen

1. Was unterscheidet einen Validierungsfakt von einem Wunsch?
2. Welche Fakten lassen sich nicht vollständig automatisieren?
3. Warum sollte ein Reviewer validation.md vor einer Änderung lesen?