Data Quality: Definition, sechs Dimensionen, Abgrenzung

Data Quality (Datenqualität) beschreibt, wie gut ein Datenbestand für den vorgesehenen Zweck taugt: ob die Daten vollständig, korrekt, aktuell, widerspruchsfrei und eindeutig genug sind, um darauf Reports, Entscheidungen und KI-Modelle aufzubauen. Sie ist der Sollzustand, gegen den Datenprodukte laufend geprüft werden.

Was ist Data Quality?

Datenqualität ist eine Aussage über die Eignung von Daten für einen bestimmten Zweck (in der Fachwelt „Fitness for Use"): Derselbe Datensatz kann für eine Meldung an die Aufsichtsbehörde ungeeignet und für eine grobe Bestandsschätzung ausreichend sein. Die methodische Grundlage kommt aus drei Ecken. Das [DAMA-DMBOK](https://www.dama.org/cpages/body-of-knowledge) (Data Management Body of Knowledge, der Standard-Referenzband der Data-Management-Association) und die ISO-Norm 25012 (Data Quality Model) liefern das Fach-Vokabular. Aus dem Bankenumfeld kommt [BCBS 239](https://www.bis.org/publ/bcbs239.htm), ein Regelwerk des Basler Ausschusses für Bankenaufsicht zu Risikodaten-Qualität. Regulatorisch verankert die Datenschutz-Grundverordnung (DSGVO) die Datenrichtigkeit als Grundsatz, und die europäische KI-Verordnung (EU AI Act) verlangt in Artikel 10 Datenqualitäts-Nachweise für risikoreiche KI-Systeme.

Die Fachwelt beschreibt Datenqualität über sechs klassische Dimensionen. Completeness misst den Anteil der Datensätze oder Felder ohne Null- oder Leerwerte gegenüber dem Soll. Accuracy prüft die Übereinstimmung eines Wertes mit der realen Entität, etwa ob eine Adresse tatsächlich existiert oder ein Preis dem Vertrag entspricht. Consistency erfasst die Widerspruchsfreiheit über Systeme und Zeitpunkte hinweg, zum Beispiel eine identische Kundennummer in SAP und Salesforce. Timeliness beschreibt die Aktualität gemessen am Nutzungszeitpunkt (der Bestand vor dem Batch-Lauf, der Preis zum Kaufzeitpunkt). Uniqueness stellt sicher, dass eine Entität durch genau einen Datensatz repräsentiert wird (kein doppelter Kunde durch Tippfehler). Validity schließlich prüft, ob Werte innerhalb der erlaubten Domäne liegen (Postleitzahl fünfstellig, IBAN prüfziffernkonform, Land aus einer ISO-Liste).

Die Durchsetzung der Regeln ist gestaffelt. Technische Constraints (NOT NULL, CHECK, Foreign Key) sitzen auf der Storage-Ebene und werden vom Katalog oder Warehouse selbst erzwungen. Assertion-basierte Tests wie dbt tests, [Great Expectations](https://greatexpectations.io/), Deequ oder Soda laufen in der Pipeline und prüfen bei jedem Batch eine explizit formulierte Regel. Batch-Validierungen im Reporting-Layer decken domänenspezifische Regeln ab (Umsatz nicht negativ, Rechnungssumme gleich Positionen-Summe). Baseline-basierte Anomalie-Erkennung schließt die vierte Ebene und fängt Abweichungen ab, die sich nicht in feste Schwellwerte gießen lassen.

Der Marktrend verlagert Data Quality vom eigenständigen Werkzeug-Zoo (Informatica Data Quality, Talend DQ, Ataccama) hin zur katalog- und pipeline-nativen Umsetzung. Unity Catalog Constraints und Lakehouse Monitoring, dbt tests in der Transformations-Schicht, Great Expectations in CI-Pipelines und Data Contracts als expliziter Vertrag zwischen Produzent und Konsument sind die aktuellen Bausteine. Datenqualität wird damit zu einem Attribut der Datenplattform selbst, statt eine separate Suite darüber zu legen.

Abgrenzung zu Data Observability, Data Testing und Master Data Management

Data Quality wird häufig mit angrenzenden Disziplinen synonym verwendet, obwohl die Begriffe unterschiedliche Rollen im Datenplattform-Stack einnehmen.

Begriff	Achse	Kernunterschied
Data Observability	Zeitachse	Data Quality definiert den Sollzustand (welche Regeln gelten müssen) über Dimensionen und explizite Tests. Data Observability ist das Betriebs-Instrument, das den Ist-Zustand kontinuierlich misst und dabei auch Abweichungen meldet, für die keine Regel formuliert wurde. Data Quality beschreibt, was gilt; Data Observability zeigt, ob es gilt.
Data Testing (dbt tests, Great Expectations, Deequ)	Ebene	Assertion-basierte Tests sind das technische Werkzeug, mit dem einzelne DQ-Regeln in der Pipeline durchgesetzt werden. Data Quality ist die Disziplin, die diese Regeln definiert; das Test-Framework setzt sie um. Nicht jede DQ-Regel ist ein Pipeline-Test (Uniqueness über mehrere Systeme braucht andere Verfahren), und nicht jeder Pipeline-Test ist eine DQ-Regel (Schema-Match-Assertions sind technische Kompatibilitätsprüfungen).
Master Data Management (MDM)	Umfang	MDM konsolidiert Stammdaten (Kunde, Produkt, Lieferant) zu Golden Records. DQ-Regeln sind die Voraussetzung dafür: Deduplizierung braucht Uniqueness, Konsolidierung braucht Accuracy und Consistency. Data Quality deckt darüber hinaus auch Bewegungsdaten und Analytik-Marts ab, die MDM nicht adressiert.
Data Governance	Rolle	Data Governance ist der organisatorische Rahmen (Rollen, Prozesse, Ownership, Regelwerk). Data Quality ist eine der Disziplinen, die Governance operationalisiert. Ohne Governance-Klammer bleibt Data Quality eine Sammlung technischer Regeln ohne verbindlichen Owner.
Data Cleansing	Verhältnis	Data Cleansing ist die aktive Bereinigung fehlerhafter Datensätze (Adress-Standardisierung, Duplikat-Merge, Null-Ersetzung). Data Quality ist der übergeordnete Zielzustand, Cleansing eine der Reparatur-Aktivitäten. Cleansing behandelt Symptome, Data-Quality-Regeln plus Governance behandeln die Ursache.

Die zentrale Trennlinie verläuft zwischen Sollzustand und Messung. Data Quality, Data Contracts und dbt tests formulieren, was Daten leisten müssen. Data Observability liefert die laufende Messung darauf. Data Lineage bildet das Substrat für die Root-Cause-Analyse, wenn ein DQ-Vorfall gemeldet wird. Master Data Management operiert auf einem Ausschnitt (Stammdaten) mit eigenen Verfahren, konsumiert die DQ-Regeln aber für seine Konsolidierungs-Logik.

Beispiel: Data Quality auf einem Databricks-Lakehouse im Retail-Umfeld

Ein Retail-Handel betreibt auf Databricks eine Bronze-Silber-Gold-Architektur für Filialverkäufe, Kunden- und Produktdaten. Datenqualitäts-Regeln greifen auf drei Ebenen entlang der Pipeline. Auf der Silber-Ebene erzwingen Unity-Catalog-Constraints technische Regeln (NOT NULL auf customer_id und store_id, Foreign Key auf product_id, CHECK auf order_total >= 0). Verletzungen einer harten Constraint werden vom Katalog selbst zurückgewiesen; die Pipeline schlägt fehl und markiert den Batch als ungültig.

Auf der Gold-Ebene laufen dbt tests bei jedem Transformations-Lauf: Completeness (kein Fehltag im Verkaufskalender), Uniqueness (jeder order_id exakt einmal), Validity (Umsatz nicht negativ, Land aus ISO-Liste), Consistency (Summe der Positionen gleich Rechnungsbetrag). Verletzungen weicher Regeln laufen ohne Pipeline-Abbruch durch und öffnen stattdessen ein Ticket beim Owner des Datenprodukts. Parallel läuft Databricks Lakehouse Monitoring agent-los auf denselben Tabellen und meldet Distribution-Ausreißer: Wenn der Null-Anteil in customer_id außerhalb der gelernten 30-Tage-Baseline liegt, entsteht automatisch ein Data-Quality-Ticket, ohne dass eine feste Schwelle definiert werden musste.

Der monatliche DQ-Report je Domain-Team fasst Verletzungs-Historie und Fix-Zeit zusammen und dient als Grundlage für interne DQ-SLAs, für die Kommunikation mit BI- und ML-Konsumenten und für regulatorische Nachweise (BCBS 239 gegenüber Finance, AI-Act-Dokumentation für Modell-Trainingsdaten). Damit wird Datenqualität zu einem prüfbaren Betriebsmodus mit klaren Ownern, dokumentierten Regeln und messbarer Verletzungs-Historie.