Was ist Datenvalidierung? Definition, Methoden und Beispiele

Wie sich Datenvalidierung von Testing, Observability und Bereinigung unterscheidet, die vier Methoden, die fast jede reale Prüfung abdecken, und wo jede davon läuft.

2026-09-10 · 7 min read

Datenvalidierung ist der Vorgang, zu prüfen, ob Daten einem definierten Satz von Erwartungen entsprechen — ihrer Struktur, ihren Typen, ihren erlaubten Werten, ihren Beziehungen und ihrer Aktualität —, bevor diesen Daten vertraut oder mit ihnen gearbeitet wird. Jede Erwartung wird im Voraus formuliert, gegen die tatsächlichen Daten ausgewertet und liefert ein Bestehen oder Scheitern samt der Anzahl der Datensätze, die dagegen verstoßen haben. Validierung repariert nichts; ihre Aufgabe ist es zu entscheiden, ob die Daten für den Zweck taugen, für den sie gleich verwendet werden, und präzise zu benennen, was nicht stimmt, wenn sie es nicht tun.

Diese Definition hat drei tragende Teile. Erwartungen werden im Voraus deklariert — das unterscheidet Validierung davon, ein Problem erst zu bemerken, wenn ein Dashboard seltsam aussieht. Die Prüfung wird gegen echte Daten ausgewertet, nicht gegen eine Stichprobe oder eine Beschreibung der Daten. Und das Ergebnis ist eine Entscheidung — dieser Stapel ist akzeptabel oder nicht — und kein Bericht, den irgendwann jemand liest.

Was Datenvalidierung nicht ist

Das Wort wird lose für vier verschiedene Tätigkeiten verwendet. Klarheit über die Grenzen macht es deutlich leichter zu entscheiden, welches Werkzeug Sie tatsächlich brauchen.

Aktivität	Frage, die sie beantwortet	Erwartungen	Typisches Ergebnis
Datenvalidierung	Erfüllen diese Daten die vereinbarten Regeln?	Explizit und im Voraus deklariert	pass/fail je Regel, Anzahl der Verstöße
Daten-Testing	Verhält sich dieser Pipeline-Code korrekt?	Von Entwicklern geschriebene Assertions	Der Build besteht oder scheitert
Data Observability	Hat sich etwas unerwartet verändert?	Aus der Historie gelernt, statistisch	Anomalie-Alarme, Trendlinien
Datenbereinigung	Können wir die fehlerhaften Datensätze reparieren?	Entfällt — eine Transformation	Veränderte Daten

Die Unterschiede sind praktisch relevant:

Validierung vs. Testing. Ein dbt-Test ist eine Validierungsregel, die zufällig innerhalb eines Builds läuft. Der Unterschied liegt in Reichweite und Verantwortung: Tests decken die Modelle ab, die der Pipeline gehören, und laufen, wenn die Pipeline läuft; Validierung deckt die Zusagen eines Datasets ab, unabhängig davon, welche Pipeline es heute erzeugt hat, und läuft nach einem eigenen Zeitplan. Eine Tabelle, die von Fivetran geladen, von dbt transformiert und von einem selbstgebauten Python-Job ergänzt wird, hat einen Satz Zusagen und drei Pipelines.
Validierung vs. Observability. Observability arbeitet unüberwacht — sie beobachtet Zeilenzahlen, NULL-Quoten und Verteilungen und schlägt Alarm, wenn heute anders aussieht als vergangene Woche. Sie findet Probleme, nach denen Sie gar nicht gesucht hätten, und sie schlägt auch dann an, wenn sich das Geschäft legitim verändert. Validierung arbeitet überwacht: Sie haben gesagt, status müsse einer von vier Werten sein, und entweder ist er es oder nicht. Observability liefert Ihnen Recall, Validierung liefert Ihnen Precision. Reife Teams betreiben beides.
Validierung vs. Bereinigung. Bereinigung verändert Daten — Leerzeichen kürzen, Typen umwandeln, Duplikate entfernen, Werte imputieren. Validierung ist per Design ausschließlich lesend. Die beiden zu vermischen ist der Weg zu stiller Korruption: Ein Umwandlungsschritt, der "N/A" zu 0 macht, lässt eine Validierungsregel bestehen und die Zahl falsch werden.

Die vier Methoden der Datenvalidierung

Fast jede Prüfung in der Produktion fällt in eine von vier Familien.

1. Schema- und Typprüfungen

Hat das Dataset die Spalten, die es haben soll, in den Typen, die es haben soll, mit korrekt deklarierter Nullbarkeit? Das sind die billigsten Prüfungen, und sie fangen die störendsten Fehler ab — eine umbenannte Spalte, ein von integer auf text erweiterter Typ, eine Spalte, die eine vorgelagerte Migration stillschweigend entfernt hat. Schema-Drift bricht Konsumenten sofort und laut, weshalb es sich lohnt, sie an der Grenze abzufangen statt in einem Dashboard.

2. Constraint-Prüfungen

Regeln auf Zeilenebene, die ein einzelner Datensatz entweder erfüllt oder verletzt: Eine Pflichtspalte ist nicht NULL, ein Schlüssel ist eindeutig, ein Wert gehört zu einer erlaubten Menge, eine Zahl liegt in einem plausiblen Bereich, eine Zeichenkette passt zu einem Muster, ein Fremdschlüssel löst auf. Diese Familie deckt den Großteil realer Regeln ab, und jede einzelne kompiliert zu einer einzigen Aggregatabfrage, die eine Anzahl von Verstößen zurückgibt.

SELECT
    count(*) FILTER (WHERE order_id IS NULL)                       AS null_ids,
    count(*) FILTER (WHERE total_amount < 0 OR total_amount > 1e5) AS bad_amounts,
    count(*) FILTER (
        WHERE status IS NOT NULL
          AND status NOT IN ('pending', 'paid', 'shipped', 'refunded')
    )                                                              AS bad_status
FROM sales.orders;

Beachten Sie die Absicherung status IS NOT NULL. Der Vergleich eines NULL mit irgendetwas ergibt NULL, nie true; ein ungesichertes NOT IN schließt also stillschweigend jede NULL-Zeile aus der eigenen Verstoßzählung aus. Eine so geschriebene Constraint-Prüfung bleibt grün, während die Spalte leerläuft — das ist das stehende Argument dafür, jede Constraint-Regel mit einer Vollständigkeitsregel auf derselben Spalte zu paaren.

3. Statistische Prüfungen

Aggregierte Eigenschaften statt einzelner Zeilen: Zeilenzahl innerhalb eines Bandes, NULL-Quote unter einem Prozentsatz, Mittelwert oder Median in einem Bereich, stabile Kardinalität, Verteilung über Kategorien ungefähr wie erwartet. Diese fangen Fehler ab, die keine Regel auf Zeilenebene sehen kann — etwa einen unvollständigen Ladevorgang, bei dem jede erhaltene Zeile für sich gültig ist, aber ein Drittel der Daten fehlt.

4. Prüfungen von Geschäftsregeln

Spalten- oder tabellenübergreifende Logik, die eine fachliche Invariante kodiert: shipped_at liegt nie vor ordered_at, die Positionen einer Rechnung summieren sich zu ihrem Gesamtbetrag, eine Rückerstattung übersteigt nie die ursprüngliche Zahlung, jedes aktive Abonnement hat ein Abrechnungskonto. Das sind die Regeln, die echte Geschäftsfehler abfangen statt bloßer Installationsfehler, und sie sind üblicherweise die, die ein Validierungswerkzeug als eigenes SQL ausdrückt.

Wo Validierung läuft

Dieselbe Regel bedeutet je nach Ort etwas anderes, und die meisten Teams brauchen mehr als einen.

Bei der Erfassung. Validieren Sie an der Grenze, bevor Daten in einer gemeinsam genutzten Tabelle landen. Hier weisen Sie eine fehlerhafte CSV zurück, ein JSON-Payload ohne ein Pflichtfeld oder eine API-Antwort mit unerwartetem Schema. Hier zu scheitern ist billig: Nachgelagert wurde noch nichts berechnet, und den Stapel in Quarantäne zu stellen kostet Sie einen erneuten Versuch.

Im Data Warehouse, nach dem Laden. Validieren Sie die gelandete Tabelle selbst, nach einem Zeitplan, der am Ladevorgang hängt und nicht an einem glatten Cron-Zeitpunkt. Hier findet das meiste Datenqualitäts-Monitoring statt, denn es ist der einzige Ort, der die Daten so sieht, wie Konsumenten sie tatsächlich sehen — nachdem jede Pipeline, jedes Merge und jede verspätete Korrektur ihren Beitrag geleistet haben. Eine Tagestabelle, die um 06:00 Uhr validiert wird, während der Ladevorgang um 06:40 Uhr fertig wird, scheitert jeden Morgen aus Gründen, die nichts mit Qualität zu tun haben.

Beim Konsum. Validieren Sie unmittelbar vor einer Verwendung mit hohem Einsatz — einem aufsichtsrechtlichen Bericht, einer kundenseitig sichtbaren Kennzahl, einem Trainingsdatensatz für ein Modell. Diese Prüfungen sind enger und strenger als die allgemeinen, denn die Toleranz ist eine andere: Eine NULL-Quote von 0,1 % mag für ein internes Dashboard in Ordnung sein und für eine Finanzmeldung inakzeptabel.

Eine praktische Regel: Bei der Erfassung zurückweisen, im Data Warehouse überwachen, beim Konsum als Tor nutzen.

Von Ad-hoc-Prüfungen zu versionierten Erwartungen

Handgeschriebenes Validierungs-SQL funktioniert, bis es vierzig Regeln über ein Dutzend Tabellen sind — dann stellen sich die üblichen Probleme ein. Die Regeln driften von den Schemas weg, die sie prüfen. Niemand kann „Was sagen wir über diese Tabelle eigentlich zu?" beantworten, ohne ein Skript zu lesen. Eine Schwellenwertänderung hinterlässt keine Spur, wer sie vorgenommen hat und warum.

Die Lösung besteht darin, die Erwartungen zu einem deklarativen Artefakt zu machen statt zu Code — einem Dokument, das festhält, was das Dataset zusagt, versioniert im selben Repository wie alles andere und von einem Runner nach SQL kompiliert. Dieses Dokument ist ein Data Contract, und der Open Data Contract Standard ist das offene Format, um einen solchen zu schreiben. Catalyst geht diesen Weg: Regeln sind ODCS-YAML, das YAML ist die Quelle der Wahrheit, und jede Regel kompiliert zu dem engine-spezifischen SQL von oben.

Regeln nach Datenqualitätsdimension zu ordnen — Vollständigkeit, Eindeutigkeit, Gültigkeit, Konsistenz, Genauigkeit, Aktualität — ist das, was aus einem Haufen Prüfungen eine Abdeckungsansicht macht. Für die Mechanik des Schreibens und Planens der Prüfungen selbst siehe den Leitfaden zur Datenvalidierung.

Häufig gestellte Fragen

Was ist Datenvalidierung, einfach gesagt?

Datenvalidierung ist die Prüfung, ob Daten den Regeln entsprechen, die Sie für sie festgelegt haben — die richtigen Spalten und Typen, keine fehlenden Werte dort, wo sie Pflicht sind, keine doppelten Schlüssel, Werte innerhalb der erlaubten Menge oder des erlaubten Bereichs, und Daten, die aktuell genug sind, um nützlich zu sein. Jede Regel wird gegen die echten Daten geprüft und liefert ein Bestehen oder Scheitern samt der Anzahl der betroffenen Datensätze.

Was ist der Unterschied zwischen Datenvalidierung und Datenverifikation?

Validierung fragt, ob die Daten die für sie definierten Regeln erfüllen — sind sie strukturell und semantisch akzeptabel? Verifikation fragt, ob die Daten ihrer Quelle getreu entsprechen — sind sie unversehrt und unverändert angekommen, etwa geprüft über einen Vergleich von Zeilenzahlen oder Prüfsummen zwischen Quellsystem und Ziel. Ein Datensatz kann perfekt verifiziert sein und trotzdem die Validierung nicht bestehen, wenn die Quelle selbst fehlerhafte Werte enthielt.

Welche Arten der Datenvalidierung gibt es?

Vier Familien decken fast alles ab: Schema- und Typprüfungen (die richtigen Spalten in den richtigen Typen), Constraint-Prüfungen (nicht NULL, eindeutig, erlaubte Werte, Bereiche, Muster, referenzielle Integrität), statistische Prüfungen (Zeilenzahlen, NULL-Quoten, Verteilungen) und Prüfungen von Geschäftsregeln (spalten- und tabellenübergreifende Invarianten Ihrer Fachdomäne).

Wann sollte Datenvalidierung laufen?

An drei Punkten, aus jeweils eigenen Gründen. Bei der Erfassung, um fehlerhafte Daten an der Grenze zurückzuweisen, bevor sie landen. Im Data Warehouse nach dem Laden, nach einem vom Ladevorgang ausgelösten Zeitplan, um die Tabellen zu überwachen, die Konsumenten tatsächlich abfragen. Und beim Konsum, als strengeres Tor vor einer Verwendung mit hohem Einsatz, etwa einem aufsichtsrechtlichen Bericht oder einem Modelltraining.

Verändert Datenvalidierung meine Daten?

Nein. Eine Validierungsprüfung ist eine ausschließlich lesende Abfrage, die eine Anzahl von Verstößen zurückgibt. Datensätze zu verändern ist Datenbereinigung — ein eigener Schritt, der erfolgen sollte, nachdem die Validierung Ihnen gesagt hat, was nicht stimmt, und nie als Nebeneffekt der Prüfung selbst, denn das würde das Problem verbergen statt es sichtbar zu machen.