Datenqualitäts-Checks als fester Bestandteil der Datenpipeline

1. Warum Datenqualität ein kontinuierlicher Prozess sein muss

Ein einmaliges Datenqualitäts-Audit liefert nur eine Momentaufnahme. Schon der nächste Import, die nächste Schema-Änderung oder eine fehlerhafte Anwendungslogik kann neue Qualitätsprobleme einführen, die vom letzten Audit nicht mehr erfasst werden. Systeme, die auf wiederkehrende, manuelle Prüfungen setzen, entdecken solche Probleme in der Praxis meist erst dann, wenn ein Fachbereich eine offensichtlich falsche Auswertung meldet, was oft Wochen nach der eigentlichen Ursache liegt.

Automatisierte, kontinuierlich laufende Checks verschieben diesen Entdeckungszeitpunkt so nah wie möglich an die eigentliche Ursache, idealerweise noch bevor fehlerhafte Daten überhaupt in ein produktives System gelangen. Das reduziert nicht nur den Schaden, sondern auch den Aufwand für die spätere Fehlersuche erheblich, weil der zeitliche und fachliche Kontext der Ursache noch unmittelbar nachvollziehbar ist.

2. Kategorien von SQL-basierten Datenqualitäts-Checks

In der Praxis lassen sich die meisten relevanten Checks in wenige Kategorien einteilen: NULL-Anteile in Spalten, die eigentlich immer befüllt sein sollten, Wertebereichsprüfungen für Zahlen- und Datumsfelder, referenzielle Konsistenz zwischen abhängigen Tabellen, Eindeutigkeit dort, wo fachlich keine Duplikate erlaubt sind, sowie Aktualität, also ob eine Tabelle innerhalb der erwarteten Zeitspanne überhaupt neue Daten erhalten hat.

Jede dieser Kategorien lässt sich mit reinem SQL abbilden, ohne zusätzliche Spezialwerkzeuge, was den Einstieg deutlich erleichtert. Der entscheidende Unterschied zu einer einmaligen Ad-hoc-Abfrage ist, dass jeder dieser Checks als eigenständige, wiederholt ausführbare Abfrage mit einem klar definierten erwarteten Ergebnis formuliert wird, das sich automatisiert auswerten lässt.

3. Praxisbeispiel: NULL-Anteil als Schwellenwert-Check

Ein NULL-Anteil-Check berechnet den prozentualen Anteil leerer Werte in einer eigentlich pflichtfeldartigen Spalte und vergleicht diesen Anteil gegen einen definierten Schwellenwert. Ein solcher Check ist deutlich robuster als eine reine Existenzprüfung, weil er auch schleichende Verschlechterungen erkennt, etwa wenn eine neue Integration schrittweise beginnt, ein Pflichtfeld immer häufiger leer zu lassen, ohne dass ein einzelner Fehlerfall sofort auffällt.

Der Schwellenwert selbst sollte fachlich begründet und nicht willkürlich gewählt sein: Ein historisch stabiler NULL-Anteil von unter einem Prozent rechtfertigt einen deutlich strengeren Schwellenwert als ein Feld, das schon immer bei gelegentlichen Import-Quellen unvollständig befüllt wurde.

SELECT
    COUNT(*) AS total_rows,
    SUM(CASE WHEN email IS NULL THEN 1 ELSE 0 END) AS null_rows,
    ROUND(
        100.0 * SUM(CASE WHEN email IS NULL THEN 1 ELSE 0 END) / COUNT(*),
        2
    ) AS null_percentage
FROM customers
WHERE created_at >= CURRENT_DATE - INTERVAL '1 day';

4. Wertebereichsprüfungen für Zahlen- und Datumsfelder

Wertebereichsprüfungen decken Fälle ab, in denen ein Wert zwar technisch gültig, fachlich aber offensichtlich falsch ist, etwa ein negativer Bestellbetrag, ein Rabatt über einhundert Prozent oder ein Geburtsdatum in der Zukunft. Solche Fehler entstehen typischerweise durch fehlerhafte Anwendungslogik, unvalidierte externe Eingaben oder eine falsche Vorzeichenbehandlung bei einer Währungsumrechnung.

Der Vorteil einer datenbankseitigen Prüfung gegenüber einer reinen Anwendungsvalidierung liegt darin, dass sie unabhängig davon greift, über welchen Weg die Daten letztlich in die Tabelle gelangt sind, sei es über die eigentliche Anwendung, einen direkten Import oder eine manuelle Korrektur durch einen Administrator, die sonst leicht an der Anwendungsvalidierung vorbeigeht.

5. Schwellenwert-basiertes Alerting statt binärem Pass/Fail

Ein binärer Pass/Fail-Check, der bei jedem einzelnen fehlerhaften Datensatz sofort einen kritischen Alarm auslöst, führt in der Praxis schnell zu Alert-Müdigkeit, weil einzelne Ausreisser in großen Datenmengen fast unvermeidlich sind. Sinnvoller ist ein mehrstufiges Schwellenwert-Modell mit einer Warnstufe, die auf eine allmähliche Verschlechterung hinweist, und einer kritischen Stufe, die tatsächlich eingreift.

Noch aussagekräftiger wird ein solcher Check, wenn er nicht nur den aktuellen Wert, sondern den Trend über mehrere vergangene Läufe berücksichtigt: Ein einzelner Ausreisser um zwei Prozentpunkte ist weniger besorgniserregend als ein Wert, der sich über die letzten zehn Läufe kontinuierlich in dieselbe Richtung bewegt, selbst wenn der absolute Wert noch innerhalb des Schwellenwerts liegt.

6. Integration in CI/CD- und ETL-Pipelines

Die konkrete technische Integration hängt vom eingesetzten Werkzeug ab, folgt aber überall demselben Grundmuster: Nach jedem relevanten Pipeline-Schritt, etwa einem ETL-Ladelauf oder einer Schema-Migration, wird eine Reihe definierter SQL-Checks ausgeführt, deren Ergebnis den weiteren Ablauf der Pipeline steuert. Werkzeuge für Transformationspipelines bieten dafür oft eine eigene Testschicht, während sich dieselbe Logik in klassischen CI/CD-Systemen ebenso gut mit reinen SQL-Skripten und einem einfachen Exit-Code umsetzen lässt.

Entscheidend ist, dass ein fehlgeschlagener Check nicht nur eine Benachrichtigung erzeugt, sondern tatsächlich in der Lage ist, den weiteren Ablauf zu stoppen, wenn die kritische Schwelle überschritten wurde. Ohne diese blockierende Wirkung bleibt ein Qualitäts-Check ein reines Informationsangebot statt eines echten Schutzmechanismus für nachgelagerte Systeme.

7. Praxisbeispiel: Ein Check, der vor fehlerhaften Deployments warnt

Ein konkretes Beispiel ist ein Check, der vor jedem Deployment prüft, ob die referenzielle Konsistenz zwischen zwei zentralen Tabellen innerhalb der erwarteten Grenzen liegt. Liefert die Prüfung einen Wert oberhalb der kritischen Schwelle, wird das Deployment-Skript so konfiguriert, dass es mit einem entsprechenden Fehlercode abbricht, statt eine möglicherweise bereits fehlerhafte Datenbasis in Produktion zu übernehmen.

Dieses Muster lässt sich auf beliebig viele Checks erweitern, indem jeder einzelne Check als eigene Abfrage mit klar definiertem Schwellenwert in ein gemeinsames Prüfskript eingebunden wird, das am Ende aller Einzelchecks einen Gesamtstatus zurückgibt. So bleibt jeder Check einzeln nachvollziehbar und wartbar, während die Pipeline insgesamt nur einen einzigen, klaren Erfolgs- oder Fehlerstatus auswerten muss.

-- Pipeline-Gate: referenzielle Konsistenz vor dem Deployment prüfen
SELECT COUNT(*) AS broken_references
FROM order_items oi
LEFT JOIN products p ON oi.product_id = p.id
WHERE p.id IS NULL;
-- Deployment-Skript bricht ab, wenn broken_references > 0

8. Historisierung der Check-Ergebnisse für Trend-Analysen

Ein einzelner Check-Lauf ohne historischen Kontext beantwortet nur die Frage, ob der aktuelle Zustand innerhalb der Grenzen liegt, nicht aber, ob sich die Datenqualität insgesamt verbessert oder verschlechtert. Eine eigene Tabelle, die jeden Check-Lauf mit Zeitstempel, geprüfter Metrik und Ergebnis speichert, macht diese Entwicklung über die Zeit sichtbar und liefert die Grundlage für das eingangs beschriebene trendbasierte Alerting.

Diese Historisierung eignet sich zudem hervorragend als Grundlage für ein eigenes Datenqualitäts-Dashboard, das Fachbereiche und technische Teams gemeinsam nutzen können, um die Entwicklung zentraler Qualitätsmetriken über Wochen und Monate zu beobachten, statt sich ausschließlich auf punktuelle Alarme zu verlassen.

9. Organisatorische Verantwortung: Data Contracts und Owner

Technische Checks allein lösen das Problem nicht, wenn niemand für das Ergebnis verantwortlich ist. Jede Tabelle mit definierten Qualitäts-Checks sollte deshalb einen klar benannten fachlichen Owner haben, der über Verschlechterungen informiert wird und die Befugnis hat, über die nächsten Schritte zu entscheiden, statt dass ein Alarm im allgemeinen Benachrichtigungsrauschen untergeht.

Ein formalisierter Data Contract, der für jede zentrale Tabelle explizit festlegt, welche Qualitätsanforderungen gelten, wer bei einer Verletzung informiert wird und welche Eskalationsstufen greifen, macht diese Verantwortung nicht nur nachvollziehbar, sondern auch prüfbar. Ohne einen solchen Contract bleibt Datenqualität trotz technisch perfekter Checks organisatorisch unverankert.

10. Zusammenfassung

11. FAQ: Datenqualitäts-Checks: Das Wichtigste auf einen Blick