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 einfachen 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
Es gibt zahlreiche gute Fachliteratur zum Thema Datenqualität. In der Regel wird das Thema eher theoretisch beschrieben — mit eindrucksvollen Beispielen. Eine konkrete Anleitung jedoch, wie genau die Prüfung und Behandlung schlechter Daten in einem ETL-Prozess zu implementieren ist, ist selten vorhanden. Diese Serie schließt diese Lücke.
Im Wesentlichen gibt es zwei Aspekte, die zu berücksichtigen sind:
- Technisch ist zunächst zu prüfen, ob die extrahierten Daten in die Datentypen des Zielsystems konvertiert werden können und möglichen Beschränkungen wie Wertebereichen und Schreibweise entsprechen.
- Fachlich geht es darum, die Vollständigkeit, Konsistenz und Aktualität der Daten sicherzustellen. Diese Eigenschaften werden oft unter dem Begriff Datenintegrität zusammengefasst.
In Anlehnung an diese Unterscheidung fasse ich die beiden Aspekte unter den Begriffen technische Datenqualität und fachliche Datenqualität zusammen.
Die Prüfung beider stellt sicher, dass die gelieferten Daten sicher verarbeitet und in das Zielsystem übernommen werden können. Technische und fachliche Fehler können beim Laden zu einem Fehler und im schlimmsten Fall zum Abbruch eines ETL-Prozesses führen. Ein ETL-Prozess sollte deshalb so entwickelt sein, dass technische und fachliche Datenfehler proaktiv identifiziert, protokolliert und behandelt werden. Im Zweifel werden fehlerhafte Daten 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.
Mit dieser Artikelserie stelle ich ein Design Pattern für einen ETL-Prozess vor, in dem diese Aufgaben mit vertretbarem Aufwand erledigt werden können. Die technischen Grundlagen sind im Artikel Design Pattern // Architektur eines ETL-Prozesses beschrieben.
Technische Datenqualität prüfen
Bei der Prüfung der technischen Datenqualität geht es darum sicherzustellen, dass die zu verarbeitenden Daten in die jeweiligen Zieldatentypen konvertiert werden können. Das ist insbesondere dann notwendig, wenn die Daten — untypisiert — aus einer Text-Datei (CSV, XML, JSON) oder aus EXCEL gelesen werden müssen. Voraussetzung ist eine sichere Typ-Konvertierung, die nicht zu einem Abbruch des ETL-Prozesses führt. 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 erfolgt dann durch einfache Abfragen auf den konvertierten Daten: Auf jeder Spalte, die einen konvertierten Wert enthält, wird eine WHERE-Klausel ausgeführt. Liefert die WHERE-Klausel Datensätze zurück, handelt es sich um Konvertierungsfehler. Alle gefundenen Fehler werden in einer Fehlertabelle protokolliert.
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?
Fachliche Datenqualität prüfen
Die Prüfung der fachlichen Datenqualität ist grundsätzlich eine komplexe Aufgabe. Aber wie so oft lässt sich die Qualität bereits mit einfachen Maßnahmen erheblich verbessern. Eine erste Prüfung kann auf den extrahierten Daten erfolgen; weitere Prüfungen sind nach der Transformation der Daten durchzuführen.
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?
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 die Wurzel 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.
Mit der technischen Prüfung — sie hat das beste Aufwand-Nutzen-Verhältnis. 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.
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 die Konvertierung fehlgeschlagen ist (konvertierter Wert ist NULL, Rohwert aber nicht leer) oder eine fachliche Bedingung verletzt ist. Jeder Treffer ist ein Fehler 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, Fehlerprotokollierung funktionieren in jeder relationalen Datenbank. Der konkrete Code dieser Serie ist T-SQL (TRY_CONVERT, SSIS). In Postgres übernimmt etwa eine Konvertierung mit Exception-Handling oder ein CASE-Ausdruck die Rolle von TRY_CONVERT; das übergeordnete Muster bleibt identisch.
Dieser Artikel beschreibt das Was und Warum der Datenqualität. Wo im Prozess welche Prüfung greift — an welcher Schema-Grenze (E0–L2) — beschreibt der Artikel Architektur eines ETL-Prozesses. Die Protokollierung zeigt, wie die gefundenen Fehler auswertbar gespeichert werden.
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