Was ist Datenqualität?

Datenqualität misst, wie gut Daten ihren vorgesehenen Zweck erfüllen. Hochwertige Daten sind genau, vollständig, konsistent und aktuell genug, um die Entscheidungen, Analysen und KI-Modelle zu tragen, die auf ihnen aufsetzen. Daten von geringer Qualität erzeugen falsche Antworten, kaputte Dashboards und unzuverlässige KI-Ergebnisse, ganz gleich wie ausgefeilt die Werkzeuge sind, die sie verarbeiten.

Datenqualität ist kein Ja-oder-Nein-Zustand. Ein Datensatz kann für eine Trendanalyse völlig ausreichen und für die regulatorische Meldung untauglich sein. Qualität wird immer relativ zu einem konkreten Anwendungsfall gemessen, und deshalb ist das Management der Datenqualität von der übergreifenden Data Governance nicht zu trennen: Sie brauchen klare Verantwortung, definierte Standards und abgestimmte Fachdefinitionen, bevor sich sinnvoll messen lässt, ob Daten sie erfüllen.

Die sechs Dimensionen der Datenqualität

Datenqualität wird üblicherweise in sechs Kerndimensionen bewertet. Die folgenden sechs hat DAMA UK definiert, und das UK Government Data Quality Framework übernimmt sie und beschreibt Datenqualität ebenfalls als Eignung für den Zweck. Jede erfasst einen anderen Aspekt dessen, was Daten brauchbar macht, und verschiedene fachliche Zusammenhänge gewichten sie unterschiedlich.

Genauigkeit

Genauigkeit misst, ob die Datenwerte die realen Objekte oder Ereignisse richtig abbilden, die sie beschreiben. Eine Kundenadresse, die noch eine vor drei Jahren umbenannte Straße nennt, ist ungenau. Ein Produktpreis, der um eine Dezimalstelle danebenliegt, ist ungenau. Genauigkeit ist die eingängigste Dimension und zugleich eine der am schwersten messbaren im großen Maßstab, weil sie einen Abgleich mit einer vertrauenswürdigen Referenz verlangt.

Vollständigkeit

Vollständigkeit misst, ob alle erforderlichen Werte vorhanden sind. Ein Kundendatensatz ohne E-Mail-Adresse ist unvollständig. Eine Finanztransaktion ohne Zeitstempel ist unvollständig. Die Schwellwerte hängen vom Zusammenhang ab: Eine Füllrate von 95 % kann bei optionalen Feldern in Ordnung sein, während 99,9 % bei regulatorischen Pflichtfeldern womöglich nicht reichen.

Konsistenz

Konsistenz misst, ob dieselben Werte über verschiedene Systeme, Datenbanken und Berichte hinweg übereinstimmen. Wenn das CRM von 12 aktiven Lizenzen eines Kunden spricht und die Abrechnung von 14, ist eines von beiden inkonsistent. Konsistenzprobleme gehören zu den häufigsten Mängeln der Datenqualität in Unternehmen mit mehreren Quellsystemen, und sie zerstören Vertrauen schneller als fast jeder andere Mangel.

Aktualität

Aktualität misst, ob Daten für ihren Zweck rechtzeitig und frisch genug verfügbar sind. Ein 15 Minuten alter Aktienkurs ist für eine Trendanalyse aktuell genug und für den Handel veraltet. Ein Modell zur Abwanderungsprognose, das auf Monatsdaten läuft, übersieht womöglich Kunden, die gerade jetzt gehen. Die Anforderungen an Aktualität unterscheiden sich je nach Anwendungsfall drastisch.

Eindeutigkeit

Eindeutigkeit misst, ob jedes Objekt in einem Datensatz nur einmal vorkommt. Doppelte Kundendatensätze, doppelte Transaktionen und doppelte Produkteinträge führen zu aufgeblähten Kennzahlen, mehrfacher Ansprache und falschen Aggregationen. Die Entitätsauflösung, also das Erkennen und Zusammenführen doppelter Datensätze, gehört technisch zu den anspruchsvollsten Aufgaben im Management der Datenqualität.

Gültigkeit

Gültigkeit misst, ob Daten den definierten Formaten, Typen und fachlichen Regeln entsprechen. Ein Datumsfeld mit „32.13.2025“ ist ungültig. Ein Altersfeld mit einer negativen Zahl ist ungültig. Ein Ländercode, den es in ISO 3166 nicht gibt, ist ungültig. Gültigkeitsprüfungen sind die am besten automatisierbare Dimension der Datenqualität, weil sie sich als eindeutige Regeln formulieren lassen.

Warum Datenqualität wichtig ist

Jedes nachgelagerte System erbt die Qualität seiner Eingangsdaten. Schlechte Datenqualität erzeugt nicht nur falsche Zahlen, sondern falsche Entscheidungen, verlorenes Vertrauen und vergeudete Mittel.

KI und maschinelles Lernen

KI-Modelle sind nur so gut wie die Daten, aus denen sie lernen. Eine Empfehlungsmaschine, die auf Produktdaten mit uneinheitlichen Kategorien trainiert wurde, liefert unsinnige Vorschläge. Ein Modell zur Betrugserkennung, das auf Daten mit doppelten Transaktionen trainiert wurde, lernt falsche Muster. Kein Modell ist zuverlässiger als die Daten, aus denen es lernt. Deshalb sollte die Arbeit an der Datenqualität vor einer KI-Einführung beginnen und nicht erst nach der ersten falschen Antwort.

Analysen und Berichte

Wenn Führungskräfte den Zahlen in ihren Dashboards nicht trauen, entscheiden sie entweder aus dem Bauch heraus, womit der Sinn von Analytics entfällt, oder sie prüfen die Daten stundenlang von Hand nach, womit der Sinn der Automatisierung entfällt. Vertrauen in Analysen ruht auf Datenqualität, und einmal verloren, kostet es erheblichen Aufwand, es wieder aufzubauen.

Regulatorische Compliance

Die DSGVO verlangt, dass personenbezogene Daten sachlich richtig und erforderlichenfalls auf dem neuesten Stand sind (Art. 5 Abs. 1 lit. d DSGVO), und die BCBS-239-Grundsätze des Basler Ausschusses stellen ausdrückliche Erwartungen an Genauigkeit, Vollständigkeit und Aktualität der Risikodaten von Banken. Falsche regulatorische Meldungen bringen Geldbußen und Reputationsschaden. Das Management der Datenqualität liefert die Belegkette, die Compliance verlangt.

Effizienz im Betrieb

Qualitätsmängel pflanzen sich durch Systeme und Abläufe fort. Ein einziger falscher Produktcode kann sich durch Bestandsführung, Auftragsabwicklung, Finanzabstimmung und Kundenkommunikation ziehen. Die Kosten, Datenqualität an der Quelle zu beheben, sind ein Bruchteil der Kosten ihrer nachgelagerten Folgen.

Datenqualität unter dem Dach der Data Governance

Datenqualität steht nicht für sich. Sie ist eine der tragenden Säulen der Data Governance, also des organisatorischen Rahmens aus Richtlinien, Rollen und Standards, der Daten vertrauenswürdig macht. Ohne Governance bleiben Bemühungen um Qualität taktisch: Teams beheben Probleme, wenn sie ihnen begegnen, ohne die systemischen Ursachen anzugehen.

Governance liefert den Kontext, der Datenqualität handhabbar macht:

• Verantwortung: Governance legt fest, wer für die Qualität jeder Datendomäne einsteht. Ohne klare Verantwortung wird ein Qualitätsmangel zum Problem aller und zur Aufgabe von niemandem.
• Fachdefinitionen: Ein Business Glossary hält fest, was jeder Begriff bedeutet, und daraus ergibt sich, was „genau“ und „konsistent“ überhaupt heißen. Sie können die Konsistenz zweier Systeme nicht messen, solange nicht feststeht, was ein „Kunde“ oder ein „Umsatz“ ist.
• Data Lineage: Wenn ein Qualitätsmangel auftaucht, sagt die Lineage, wo er entstanden ist, welche Systeme betroffen sind und wo zu beheben ist. Ohne Lineage ist die Korrektur Ratearbeit.
• Richtlinien und Standards: Governance legt die zulässigen Qualitätsschwellen für verschiedene Datenklassen fest. Finanzdaten verlangen vielleicht 99,99 % Genauigkeit, Marketing-Analysen kommen mit 95 % aus.

Deshalb tun sich Organisationen, die Datenqualität als eigenständige technische Initiative behandeln und Qualitätswerkzeuge ohne Governance ausrollen, oft schwer mit Akzeptanz und Durchhaltevermögen. Werkzeuge können Probleme erkennen, aber um sie zu verhindern, braucht es Governance.

DQ wandert in die Plattform

Ein deutlicher Trend verändert die Landschaft: Führende Datenplattformen bauen Datenqualität direkt in ihre Kernfunktionen ein. Statt sie als externe Angelegenheit separater Werkzeuge zu behandeln, bieten Databricks und Snowflake plattformeigene DQ-Fähigkeiten als Teil ihrer Verarbeitungs- und Speicher-Engines an, und Microsoft bietet Datenqualität für Fabric-Daten über Microsoft Purview.

Databricks

Databricks bietet Expectations in Lakeflow-Pipelines (früher Delta Live Tables), mit denen Teams DQ-Regeln direkt in ihren Datenpipelines definieren, und Data Quality Monitoring für Tabellen in Unity Catalog, dessen Data Profiling früher Lakehouse Monitoring hieß. Expectations laufen als Teil der Verarbeitung statt als nachgelagerter Schritt. Verletzt ein Datensatz eine Expectation, kann die Pipeline ihn behalten und den Verstoß festhalten, ihn verwerfen oder die Aktualisierung scheitern lassen, und mit zusätzlicher Logik lassen sich ungültige Datensätze stattdessen in Quarantäne legen. Damit wird Datenqualität in der Lakehouse-Architektur zum erstklassigen Anliegen.

Microsoft Fabric

Für Microsoft Fabric kommt die Datenqualität über Data Quality in Microsoft Purview Unified Catalog, das Fabric-Lakehouses als Quelle unterstützt. Purview profiliert die Daten und führt No-Code- oder Low-Code-Regeln aus, darunter mitgelieferte und KI-generierte, auf Spaltenebene. Die Ergebnisse fließen in Qualitätswerte für Datenbestände, Datenprodukte und Governance-Domänen, und Benachrichtigungen informieren Data Owner und Data Stewards, wenn ein Schwellwert verfehlt wird.

Snowflake

Snowflake bietet Data Metric Functions (DMFs): System-DMFs für gängige Kennzahlen und eigene DMFs für alles Weitere, geplant auf einer Tabelle oder View (standardmäßig stündlich), mit Ergebnissen in einer Event-Tabelle. Data Quality Monitoring setzt die Enterprise Edition voraus. Die Überwachung arbeitet auf den Live-Daten, ohne sie in externe Werkzeuge zu bewegen, was Latenz senkt und die Architektur vereinfacht.

Was diese Verschiebung bedeutet

Plattformeigene DQ-Fähigkeiten verändern Wirtschaftlichkeit und Architektur des Qualitätsmanagements. Statt Datenproben zu ziehen, an ein separates Werkzeug zu schicken und dann auf die Ergebnisse zu reagieren, können Teams Prüfungen jetzt dort einbetten, wo die Daten gespeichert und verarbeitet werden. Das senkt den Integrationsaufwand und die Latenz und macht Datenqualität zum laufenden Teil des Datenlebenszyklus statt zur turnusmäßigen Prüfung.

Für Organisationen, die ihre Strategie für Datenqualität heute aufsetzen, ist die Folgerung eindeutig: Die Plattform, auf der Ihre Daten liegen, ist zunehmend auch die Stelle, an der Ihre Qualitätsprüfungen laufen sollten.

Wie Datenkataloge Datenqualität angehen

Da Datenqualität zur eingebauten Fähigkeit der Plattformen wird, haben Datenkataloge ihren Ansatz weiterentwickelt. Am Markt haben sich zwei Strategien herausgebildet, jede mit einer anderen Haltung dazu, wo die Verantwortung für Datenqualität liegen sollte.

Offene DQ-Metadaten: einbinden statt ersetzen

Dawiso verfolgt den Ansatz offener DQ-Metadaten. Statt eine eigene Engine für Datenqualität zu bauen, überlässt Dawiso das Messen den Qualitätsfähigkeiten, die es bereits gibt, ob das plattformeigene Funktionen in Databricks, Snowflake oder Microsoft Purview sind oder spezialisierte Werkzeuge wie Great Expectations, Soda oder dbt-Tests.

In Dawiso halten Datenprodukte Qualitätsdimensionen, Prüfungen und SLAs fest, und jede Prüfung nennt die Engine, die sie ausführt. Der Katalog zeigt diese Qualitätszusagen neben den übrigen Metadaten: Fachdefinitionen, Verantwortung und Lineage. Das gibt den Abnehmern eine Stelle, an der sie die Qualitätszusagen hinter einem Datenprodukt sehen, ohne die Ausführungslogik zu verdoppeln. Öffnet ein Data Steward ein Datenprodukt im Katalog, sieht er nicht nur, was die Daten sind und woher sie kommen, sondern auch, an welchen Prüfungen und SLAs sie gemessen werden und welches Werkzeug die jeweilige Prüfung ausführt.

Dieser Weg passt zum Trend der plattformeigenen DQ. Während Databricks, Snowflake und Microsoft stark in eigene Qualitätsfähigkeiten investieren, ist es für Kataloge sinnvoller, sich mit diesen Investitionen zu verbinden, als gegen sie anzutreten.

Eingebaute DQ-Engine: den Qualitäts-Stack selbst besitzen

Andere Kataloge gehen den umgekehrten Weg: Sie bringen eigenes Profiling der Datenqualität, eigene Regeldefinition, Überwachung und Korrektur als Teil der Plattform mit. Organisationen definieren und führen Qualitätsregeln im Katalog selbst aus, was Governance und Qualität aus einer Hand eng verzahnt.

Das bringt Einfachheit, nämlich eine Plattform für Governance und Qualität, kann sich aber mit den plattformeigenen DQ-Fähigkeiten überschneiden. Wer Databricks mit Pipeline-Expectations und daneben die eingebaute DQ-Engine eines Katalogs betreibt, endet womöglich mit zwei getrennten Systemen, die dieselben Daten prüfen, jedes mit eigenen Regeln, eigenen Werten und eigenen Meldewegen.

Wohin die Branche geht

Der Trend begünstigt Einbinden gegenüber Ersetzen. Je reifer die plattformeigenen DQ-Funktionen werden, desto weniger trägt eine eigenständige Engine im Katalog. Was seinen Wert behält, ist die Fähigkeit des Katalogs, Qualitätssignale aus mehreren Quellen zusammenzuführen und einzuordnen, also den Abnehmern das ganze Bild vom Zustand eines Objekts neben seiner fachlichen Bedeutung und seiner Lineage zu zeigen.

Das Muster, das sich abzeichnet, ist eine Architektur aus drei Schichten: Die Datenplattformen führen DQ aus (Regeln, Prüfungen, Überwachung), spezialisierte Werkzeuge decken die anspruchsvollen Fälle ab (Entitätsauflösung, Anomalieerkennung per ML), und Datenkataloge sind die Schicht, die Qualitätssignale einbindet, darstellt und mit dem Governance-Kontext verknüpft.

Typische Hürden bei der Datenqualität

Auch Organisationen mit reifen Governance-Programmen stoßen immer wieder auf dieselben Hürden bei der Datenqualität. Wer diese Muster kennt, kann seine Investitionen besser priorisieren.

Qualität verfällt mit der Zeit

Datenqualität ist nichts, was man einmal erreicht. Quellsysteme ändern sich, fachliche Regeln entwickeln sich, neue Datenquellen kommen hinzu, und Eingabefehler summieren sich. Ohne laufende Überwachung kann ein zum Start sauberer Datensatz innerhalb von Monaten deutlich verfallen. Datenqualität muss als laufender Prozess behandelt werden, nicht als Projekt mit Enddatum.

Die Ursache liegt meist stromaufwärts

Qualitätsprobleme sind in der Regel Symptome vorgelagerter Mängel: fehlende Prüfungen in den Quellanwendungen, schlecht definierte Integrationszuordnungen oder unklare Verantwortung für gemeinsam genutzte Datendomänen. Die Datenqualität am Ort des Verbrauchs zu reparieren, also Daten in Berichten oder Dashboards zu bereinigen, ist teuer und nicht durchzuhalten. Wirksames Qualitätsmanagement setzt an der Quelle an.

Qualität zu messen verlangt fachlichen Kontext

Sie können keine Qualitätsregel schreiben, ohne zu wissen, wie „richtig“ aussieht, und „richtig“ ist eine fachliche Entscheidung, keine technische. Ist eine Kundenadresse gültig, wenn die Postleitzahl stimmt, der Straßenname aber falsch geschrieben ist? Die Antwort hängt davon ab, ob die Adresse für den Versand, für Marketing oder für Compliance verwendet wird. Genau deshalb sind Datenqualität und Data Governance nicht zu trennen: Governance liefert den fachlichen Kontext, den die Messung braucht.

Werkzeugwildwuchs

Organisationen sammeln oft mehrere überlappende Qualitätswerkzeuge an: eines in der ETL-Plattform, eines im Data Warehouse, ein drittes in der BI-Schicht und ein viertes als eigenständiges DQ-Produkt. Jedes erzeugt eigene Werte, verwendet eigene Regelsyntax und meldet in sein eigenes Dashboard. Das Ergebnis ist zersplitterte Sicht auf die Qualität und doppelte Arbeit. Ein Datenkatalog mit offenen DQ-Metadaten kann diese Prüfungen, ihre Verantwortlichen und die ausführenden Werkzeuge an einer Stelle festhalten.

Fazit

Datenqualität ist das Fundament, auf dem Analysen, KI und geschäftliche Entscheidungen ruhen. Ohne sie liefern auch die ausgefeiltesten Werkzeuge unzuverlässige Ergebnisse. Als tragende Säule der Data Governance wirkt das Management der Datenqualität dann am besten, wenn es klare Verantwortung, abgestimmte Fachdefinitionen und systematische Überwachung hat.

Die Landschaft der Datenqualität verschiebt sich. Führende Datenplattformen betten Qualitätsfähigkeiten direkt in ihre Verarbeitungs-Engines ein und machen DQ damit zur nativen Funktion statt zum Nachgedanken. Datenkataloge passen sich an, indem sie die in diesen Plattformen und Werkzeugen definierten Qualitätsprüfungen mit dem Governance-Kontext verbinden. Das Ergebnis ist eine sparsamere Architektur, in der Prüfungen dort laufen, wo die Daten liegen, und Kataloge den gemeinsamen Kontext liefern, den Abnehmer brauchen, um dem zu trauen, was sie sehen.

Quellen

• Gartner, Data Quality: Why It Matters and How to Achieve It (mindestens 12,9 Millionen US-Dollar pro Jahr im Durchschnitt, Studie von 2020).
• Central Digital and Data Office (GOV.UK), The Government Data Quality Framework (die sechs Kerndimensionen nach der Definition von DAMA UK).
• DSGVO Article 5, Principles relating to processing of personal data (Art. 5 Abs. 1 lit. d DSGVO, Richtigkeit).
• Basler Ausschuss für Bankenaufsicht, Principles for effective risk data aggregation and risk reporting (BCBS 239, Januar 2013).
• Databricks, Manage data quality with pipeline expectations.
• Databricks, Data quality monitoring.
• Microsoft Learn, Data Quality in Microsoft Purview Unified Catalog.
• Snowflake, Introduction to data quality checks.
• Dawiso Help, Data quality and SLAs.