Drei Schweregrade statt pass/fail — und warum der Schweregrad entscheidet, wo die Regel steht

Die meisten Datenqualitäts-Systeme sterben nicht an schlechten Prüfungen, sondern an einem fehlenden Feld im Regel-Modell: dem Schweregrad. Ein fehlendes Länderkürzel in drei von 80.000 Zeilen blockiert den Nacht-Load, jemand schaltet die Prüfung „vorübergehend“ ab, und ab da läuft alles ungeprüft. Wer Datenqualität mit Schweregraden statt mit binärem pass/fail steuert, entkommt dieser Falle. Und der Schweregrad kann noch … Weiterlesen

Prüfregeln aus dem Schema ableiten — was die Metadaten schon wissen

Die Regel „country_code ist Pflicht“ steht zweimal in der Datenbank: einmal als NOT NULL im Schema der Zieltabelle, einmal als handgetippte Zeile in der Prüf-Konfiguration. Beim nächsten ALTER TABLE ändert sich nur eine der beiden Stellen, und die Prüfung wird still falsch. Wer Prüfregeln ableiten kann, statt sie zu tippen, muss diese Wiederholung nicht mehr pflegen: Die Metadaten wissen längst, welche Spalten … Weiterlesen

Datenqualität: Dimensionen und Fehlerklassen — der Theorie-Rahmen hinter den SQL-Prüfungen

Über Datenqualität wird viel geschrieben und wenig gemessen. Allein das deutschsprachige Praxis-Standardwerk zum Thema listet sechzig mögliche Qualitätskriterien — von Aktualität bis Zuverlässigkeit —, und selbst die knappen Modelle kommen noch auf sechs bis fünfzehn Dimensionen. Dabei ist der Kern erstaunlich handfest: Ein Datenfehler, der beim Laden abgefangen wird, kostet eine Meldung. Derselbe Fehler, der … Weiterlesen

Datenqualität mit SQL prüfen — ein konfigurierbares Framework, das schlechte Daten generisch aufspürt

Ein Fremdschlüssel ins Leere ist schnell beschrieben — ein country_code, zu dem es keinen Eintrag in den Stammdaten gibt — und überraschend leicht falsch geprüft. Die intuitivste Formulierung ist ausgerechnet die gefährlichste: NOT IN (SELECT …) liest sich wie deutsche Prosa, kippt aber lautlos um, sobald die Referenzspalte einen einzigen NULL enthält. Dann meldet die Prüfung null verwaiste Sätze, läuft grün durch und … Weiterlesen

Duplikate finden mit SQL — von COUNT(*) > 1 bis zusammengesetzte Schlüssel

GROUP BY … HAVING count(*) > 1 ist vielleicht das meistgetippte SQL-Snippet der Welt — und trotzdem stolpert es an zwei Stellen, die kaum jemand auf dem Schirm hat: bei zusammengesetzten Schlüsseln und bei NULL. Ausgerechnet beim Umgang mit fehlenden Werten in einer eindeutigen Spalte sind sich SQL Server und Postgres nämlich uneinig — der eine erlaubt … Weiterlesen

Daten mit SQL validieren — Wertebereiche, Pflichtfelder und die NULL-Falle

Eine Wertebereichsprüfung, die grün durchläuft, ist kein Beweis für saubere Daten. Wer WHERE alter < 0 OR alter > 120 schreibt, um unplausible Altersangaben zu finden, übersieht stillschweigend jede Zeile, in der alter gar keinen Wert hat — denn ein Vergleich mit NULL ergibt in SQL weder wahr noch falsch, sondern unbekannt. Genau dieser fehlende Pflichtwert kippt später den Load ins strikt modellierte Ziel. Daten mit … Weiterlesen

Migration verifizieren — Datenqualität und Zeilen-Abgleich nach dem Umzug

Die Zeilenzahlen stimmen — Tabelle für Tabelle, Quelle gegen Ziel, alles grün. Und trotzdem ist die Migration nicht fertig. In einer Spalte sind aus NULL-Werten leere Strings geworden, in einer anderen hat der Umweg über eine CSV-Datei die letzte Nachkommastelle eines Betrags gerundet, und ein paar Umlaute sind zu Fragezeichen zerfallen. Gleiche Anzahl ist nicht gleiche Daten — … Weiterlesen

Datenqualität mit SQL prüfen — ein konfigurierbares Framework, das schlechte Daten generisch aufspürt

Schlechte Daten kündigen sich nicht an. Ein Alter von 200 Jahren, eine doppelte Kundennummer, ein Ländercode, den es nicht gibt — im Quellsystem fällt das niemandem auf. Erst wenn der ETL-Lauf die Sätze in die strikt modellierte Zielschicht schieben will, bricht der Load ab: an einem CHECK, an einem UNIQUE-Index, an einem Fremdschlüssel. Datenqualität mit SQL prüfen heißt, genau … Weiterlesen

Datenqualität in SQL Server // TRY_CONVERT für date, datetime, datetime2 und time sicher anwenden

Wer einmal eine CSV-Spalte mit gemischten Datums-Formaten in eine datetime-Spalte importieren musste, weiß: An der Typ-Konvertierung entscheidet sich, ob fehlerhafte Datumswerte auffallen oder unbemerkt in die Pipeline gelangen. SQL Server lässt einen mit style-Codes alleine, sobald das Format vom Standard abweicht — TRY_CONVERT deckt die dokumentierten style-Formate ab, für alles andere braucht es eine eigene Parsing-Strategie. Das nimmst du mit: Voraussetzung: SQL Server … Weiterlesen

Datenqualität in SQL Server // TRY_CONVERT für bit sicher anwenden — Ja/Nein-Werte konvertieren

Wer einmal eine Ja/Nein-Spalte aus einem Legacy-Export übernommen hat, kennt den Befund: Die Quelle liefert ‚J‘, ‚ON‘ oder ein schlichtes ‚x‘, und TRY_CONVERT(bit, N’J‘) quittiert die deutsche Notation mit NULL. Eingebaut versteht SQL Server beim bit-Ziel nur Integer-Strings und die Literale ‚true’/’false‘ — jede andere Yes/No-Notation braucht eine eigene Zuordnung. Auf einen Blick: Voraussetzung: TRY_CONVERT existiert seit SQL Server 2012. Die Funktion fn_convert_bit nutzt TRIM und braucht daher SQL Server 2017+ … Weiterlesen