Ein einziger nicht konvertierbarer Wert — ein Datum im falschen Format, eine Zahl mit dem falschen Dezimaltrennzeichen — und der ganze ETL-Lauf bricht ab. Datenqualität in einem ETL-Prozess heißt: solche Fehler proaktiv erkennen, protokollieren und isolieren, bevor sie das Zielsystem erreichen. Dieser Artikel ist der Einstieg in eine Serie, die genau das als Design Pattern umsetzt.
TL;DR — was dieser Artikel zeigt:
- Technische vs. fachliche Datenqualität — die zwei Aspekte, die jeder ETL-Prozess getrennt behandeln muss.
- Die fünf Kernaufgaben — technisch prüfen, fachlich prüfen, protokollieren, markieren, ausschließen.
- Das
WHERE-Klausel-Prinzip — wie sich Datenfehler mit regelbasierten Abfragen systematisch finden lassen. - Einordnung ins Gesamt-Pattern — wie dieser Überblick mit der Architektur und der Protokollierung zusammenspielt.
Voraussetzung. Grundverständnis von ETL-Prozessen. Konzeptueller Artikel — kein Schritt-für-Schritt-Tutorial. Die konkreten Code-Bausteine liefern die verlinkten Schwester-Artikel der Serie.
Inhalt
- Überblick: Was Datenqualität im ETL-Prozess bedeutet
- Technische Datenqualität prüfen
- Fachliche Datenqualität prüfen
- Einordnung ins ETL-Design-Pattern
- FAQ
- Verwandte Artikel
Überblick: Was Datenqualität im ETL-Prozess bedeutet
Zum Thema Datenqualität gibt es viel gute Fachliteratur. Viele Darstellungen konzentrieren sich dabei auf Qualitätsdimensionen und Definitionen. Wie sich die Prüfung und Behandlung schlechter Daten konkret in einen ETL-Prozess integrieren lässt, bleibt dagegen häufig offen. Diese Serie schließt die Lücke: Dieser Artikel definiert die Prüfklassen und das grundlegende Vorgehen. Die konkrete Implementierung liefern die verlinkten Schwester-Artikel.
Das Design Pattern dieser Serie teilt Datenqualitätsprüfungen pragmatisch in zwei Klassen ein — ein bewusstes Arbeitsmodell, keine allgemeine Taxonomie der Datenqualität:
- Technisch ist zunächst zu prüfen, ob die extrahierten Daten in die Datentypen des Zielsystems konvertiert werden können und formalen Beschränkungen wie Wertebereichen und Schreibweise entsprechen.
- Fachlich geht es beispielsweise darum, die Vollständigkeit, Konsistenz und Aktualität der Daten sicherzustellen. Diese und weitere Qualitätsmerkmale beschreiben auch formale Datenqualitätsmodelle wie ISO/IEC 25012 (15 Merkmale).
Der Artikel fasst die beiden Klassen unter den Begriffen technische Datenqualität und fachliche Datenqualität zusammen.
Die Prüfung beider reduziert das Risiko, dass fehlerhafte Daten beim Laden Laufzeitfehler auslösen — im schlimmsten Fall bricht der ETL-Prozess ab — oder unbemerkt fachlich falsche Werte in das Zielsystem gelangen. Ein ETL-Prozess sollte deshalb so entwickelt sein, dass technische und fachliche Datenfehler proaktiv identifiziert, protokolliert und behandelt werden. Als fehlerhaft erkannte Daten werden nicht in das Zielsystem übernommen. Daraus ergeben sich fünf Kernaufgaben:
- Prüfung der technischen Datenqualität — ist der Wert in den Zieldatentyp konvertierbar?
- Prüfung der fachlichen Datenqualität — ist der Wert vollständig, konsistent und plausibel?
- Protokollierung aller gefundenen Fehler in einer Fehlertabelle.
- Markierung fehlerhaft gelieferter Datensätze.
- Ausschluss der markierten Datensätze von der weiteren Verarbeitung.
Damit wird aus einer abstrakten Datenqualitätsanforderung eine reproduzierbare Verarbeitungskette: Regel definieren, Verletzung erkennen, Fehler protokollieren, Datensatz markieren, fehlerhafte Daten vom Zielsystem fernhalten.
Dieser Artikel konzentriert sich auf die beiden Prüfaufgaben. Wie Protokollierung, Markierung und Ausschluss konkret umgesetzt werden, vertiefen die Schwester-Artikel der Serie (siehe Einordnung ins ETL-Design-Pattern). Die technischen Grundlagen des Patterns beschreibt der Artikel Design Pattern // Architektur eines ETL-Prozesses.
Technische Datenqualität prüfen
Die Prüfung der technischen Datenqualität stellt fest, ob sich die zu verarbeitenden Daten in die jeweiligen Zieldatentypen konvertieren lassen. Das ist insbesondere dann notwendig, wenn die Daten untypisiert aus einer Textdatei (CSV, XML, JSON) oder aus Excel gelesen werden müssen. Voraussetzung ist eine sichere Typ-Konvertierung: Funktionen wie TRY_CONVERT liefern für nicht interpretierbare Werte NULL statt eines Laufzeitfehlers und fangen damit die erwartbaren Konvertierungsfehler ab. Nicht jeden Fehler fangen sie ab — explizit unzulässige Typ-Kombinationen lösen auch bei TRY_CONVERT einen Laufzeitfehler aus. Eine allgemeine Fehlerbehandlung ersetzen die Funktionen ebenfalls nicht: Sie entschärfen gezielt die Typ-Konvertierung, keine anderen Fehlerquellen. Gleichzeitig soll das Ergebnis der Konvertierung eine proaktive Identifikation von Problemen ermöglichen.
Die Grundlagen der sicheren Typ-Konvertierung sind in den TRY_CONVERT-Artikeln beschrieben. Die eigentliche Prüfung läuft dann über regelbasierte Abfragen auf den konvertierten Daten: Jede Prüfregel wird als Bedingung einer WHERE-Klausel formuliert — in der einfachsten Form eine Abfrage pro konvertierter Spalte. Mehrere Regeln lassen sich aber auch in einer Abfrage bündeln. Liefert die Abfrage Datensätze zurück, handelt es sich um Konvertierungsfehler. Alle gefundenen Fehler werden in einer Fehlertabelle protokolliert.
Ein minimales Beispiel — die Staging-Tabelle hält den gelieferten Rohwert, geprüft wird die Konvertierung in den Zieldatentyp date:
1: SELECT
2: raw_birth_date
3: FROM
4: staging.customer
5: WHERE
6: raw_birth_date IS NOT NULL
7: AND TRY_CONVERT(date, raw_birth_date, 104) IS NULL;
Die Bedingung in Zeile 6 schließt genau die Quell-NULL-Werte aus: Ein NULL in der Quelle ist kein Konvertierungsfehler, sondern ein Fall für die Pflichtfeld-Prüfung. Ein leerer String ('') ist davon unabhängig: IS NOT NULL lässt ihn passieren, und SQL Server konvertiert ihn still zu 1900-01-01. Die Abfrage meldet ihn also nicht als Fehler. Ob der Leerstring als fehlender Wert gilt oder gesondert geprüft wird, legt das Pattern deshalb vorab als Konvention fest. Zeile 7 findet die Werte, die sich nicht in ein date wandeln lassen. Der Style-Code 104 steht dabei für das deutsche Datumsformat dd.mm.yyyy.
Typische Prüfungen auf technischer Ebene:
- Konvertierbarkeit in den Zieldatentyp (
date,decimal,int, …). - Wertebereich — passt die Zahl in den Zieltyp, ohne überzulaufen?
- Schreibweise/Format — etwa Telefonnummern oder Postleitzahlen nach einem definierten Muster.
- Pflichtfeld — wurde überhaupt ein Wert geliefert, wo einer erwartet wird?
Schreibweise und Pflichtfeld liegen dabei an der Grenze zur fachlichen Prüfung: Die Regel selbst ist eine fachliche Vorgabe der Datenquelle oder Domäne, prüfen lässt sie sich aber als formale Eigenschaft des einzelnen Werts. Dieses Pattern ordnet beide aus praktischen Gründen der technischen Ebene zu — als Konvention dieses Patterns, nicht als allgemeingültige Einordnung.
Fachliche Datenqualität prüfen
Die Prüfung der fachlichen Datenqualität ist grundsätzlich eine komplexe Aufgabe. Die Qualität lässt sich aber bereits mit einfachen Maßnahmen deutlich verbessern. Eine erste Prüfung kann direkt auf den extrahierten Daten laufen. Weitere Prüfungen folgen nach der Transformation der Daten.
Auch hier greift die oben beschriebene Vorgehensweise — Identifikation über WHERE-Klauseln und Protokollierung der Datenfehler. Typische fachliche Prüfungen:
- Dubletten — kommt ein laut Liefervertrag eindeutiger Schlüssel mehrfach vor?
- Fremdschlüssel-Plausibilität — existiert der referenzierte Wert überhaupt?
- Business-Logik — ein Geburtsdatum darf nicht in der Zukunft liegen, ein Auftragswert nicht negativ sein.
- Konsistenz über Felder hinweg — passen abhängige Werte zueinander?
- Aktualität — liegt der Liefer- oder Buchungszeitpunkt im erwarteten Zeitfenster, oder ist der Datensatz veraltet?
Das WHERE-Muster bleibt dabei dasselbe — hier für die fachliche Regel „ein Geburtsdatum darf nicht in der Zukunft liegen“:
1: SELECT
2: birth_date
3: FROM
4: staging.customer
5: WHERE
6: birth_date > CAST(GETDATE() AS date);
Die technische Konvertierung ist an dieser Stelle bereits abgeschlossen und geprüft — die fachliche Regel arbeitet auf der typisierten Spalte birth_date, nicht auf dem Rohwert.
Der Übergang zwischen technischer und fachlicher Prüfung ist fließend und letztlich Definitionssache. Entscheidend ist, dass beide Klassen von Fehlern getrennt erkannt, protokolliert und behandelt werden.
Einordnung ins ETL-Design-Pattern
Dieser Artikel ist der Ausgangspunkt einer Serie, die das Thema schrittweise vertieft:
- Datenqualität (dieser Artikel) — warum und was: die zwei Aspekte, die fünf Kernaufgaben, das
WHERE-Klausel-Prinzip. - Architektur eines ETL-Prozesses — wie: Arbeitspakete, Schema-Schichtung E0–L2, an welcher Schema-Grenze welche Prüfung greift.
- Protokollierung eines ETL-Prozesses — womit: dreistufige Logging-Tabellen und Stored Procedures, die Lauf, Komponente und Aktion auswertbar machen.
- Sichere Typ-Konvertierung — der konkrete Code-Baustein für die technische Prüfung (siehe TRY_CONVERT-Reihe unten).
Wer den ETL-Prozess von Grund auf robust bauen will, liest die Serie in dieser Reihenfolge.
FAQ
Die technische Datenqualität prüft, ob ein gelieferter Wert überhaupt in den Zieldatentyp konvertierbar ist und formale Beschränkungen wie Wertebereich oder Schreibweise einhält — das ist eine reine Eigenschaft des einzelnen Werts. Die fachliche Datenqualität prüft darüber hinaus, ob der Wert inhaltlich plausibel, vollständig und konsistent ist (z. B. ein Geburtsdatum, das nicht in der Zukunft liegt). Beide Klassen werden getrennt erkannt und protokolliert, weil sie unterschiedliche Ursachen und unterschiedliche Korrekturen haben.
Ein pragmatischer Einstieg ist die technische Prüfung: Typ- und Formatfehler lassen sich deterministisch und mit wenig Aufwand automatisiert finden. Eine sichere Typ-Konvertierung plus eine WHERE-Klausel pro konvertierter Spalte fängt bereits die häufigsten Abbruch-Ursachen ab. Die fachlichen Prüfungen kommen danach, beginnend mit einfacher Business-Logik wie Pflichtfeld- und Plausibilitätsprüfungen.
WHERE-Klausel-Prinzip konkret? Nach der Konvertierung steht pro Spalte sowohl der Rohwert als auch der konvertierte Wert zur Verfügung. Eine WHERE-Klausel sucht die Datensätze, bei denen der Rohwert einen Wert enthält, die Konvertierung aber NULL liefert — genau dann ist die Konvertierung fehlgeschlagen. Ein bereits als NULL oder leer gelieferter Rohwert zählt nicht dazu, er ist ein Fall für die Pflichtfeld-Prüfung. Nach demselben Muster lassen sich auch fachliche Bedingungen prüfen. Jeder Treffer ist eine Regelverletzung und wird in eine Fehlertabelle geschrieben. Details und Beispiele liefert die TRY_CONVERT-Reihe.
Das Prinzip ist datenbankunabhängig — sichere Konvertierung, WHERE-Klausel-Prüfung und Fehlerprotokollierung lassen sich in jeder relationalen Datenbank umsetzen. Die konkrete Implementierung unterscheidet sich aber je Engine. Der Code dieser Serie ist T-SQL (TRY_CONVERT, SSIS). Postgres hat kein eingebautes try_cast — auch Postgres 18 nicht. Eine mögliche Umsetzung ist eine selbst geschriebene Wrapper-Funktion mit Exception-Handling, wie sie die Postgres-Brücken der TRY_CONVERT-Artikel zeigen. Bei großen Datenmengen ist deren Performance gesondert zu bewerten, weil zeilenweises Exception-Handling Kosten hat. Das übergeordnete Muster bleibt identisch.
Datenqualität beschreibt, wie gut Daten für ihren Verwendungszweck geeignet sind. Formale Modelle wie ISO/IEC 25012 fassen darunter Dimensionen wie Genauigkeit, Vollständigkeit, Konsistenz und Aktualität. Datenintegrität bezeichnet dagegen die Unversehrtheit und Widerspruchsfreiheit gespeicherter Daten, wie sie eine Datenbank über Constraints, Schlüssel und Transaktionen absichert. Die fachlichen Prüfungen dieses Patterns adressieren Qualitätsdimensionen — sie ersetzen keine Integritätsmechanismen der Datenbank.
Verwandte Artikel
Grundlagen
- Design Pattern // Architektur eines ETL-Prozesses
- Design Pattern // Protokollierung eines ETL-Prozesses mit SQL
- Design Pattern // Sichere Typ-Konvertierung mit T-SQL
- Datenqualität // Grundlagen der Typ-Konvertierung mit T-SQL
- ETL vs. ELT — woran du erkennst, welches Muster du wirklich gebaut hast
- Datenqualität mit SQL prüfen — ein konfigurierbares Framework — der Implementierungs-Sub-Hub: das Wie zu diesem Was, generische Prüfung schlechter Daten via Dynamic SQL.