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 bis in den Bericht durchläuft, kostet eine falsche Rechnung, eine Fehlentscheidung — und das Vertrauen in jede weitere Zahl. Dieser Artikel macht den Rahmen dahinter greifbar, ohne Theorie-Durststrecke: Er sortiert die gängigen Datenfehler in Klassen, ordnet sie den etablierten Dimensionen der Datenqualität zu — und zeigt mit einer ehrlichen Coverage-Karte, welche davon drei generische SQL-Routinen wirklich abdecken. Und er benennt die zwei, die sie nicht erreichen.

Das Wichtigste vorab:

• Datenfehler lassen sich in wenige Klassen sortieren — technisch vs. fachlich, und feldweise vs. satzweise vs. beziehungsweise. Das genügt, um jeden konkreten Fehler einzuordnen.
• Die Dimensionen der Datenqualität sind Fachkanon, nicht Geschmack — im deutschsprachigen Standardwerk von Apel et al. als definierte Kriterien, international bei Wang & Strong, der DAMA und ISO/IEC 25012.
• Vier Kriterien prüft generisches SQL direkt in der Datenbank: Vollständigkeit, Gültigkeit, Eindeutigkeit und referenzielle Integrität/Konsistenz. Zwei bleiben außen vor — die inhaltliche Korrektheit und die Aktualität; beide brauchen Information von außerhalb der Datenbank.
• Früh prüfen ist billig, spät reparieren teuer: Prävention an der Quelle senkt die Gesamtkosten um rund zwei Drittel (Redman, zitiert bei Apel et al.) — und 100 % Datenqualität ist ohnehin nicht das wirtschaftliche Ziel.

Voraussetzung: keine. Dieser Artikel ordnet ein, bevor es an die SQL-Praxis geht; SQL-Vorwissen braucht der Theorie-Teil nicht. Wer direkt zum Wie will, findet es im Framework-Artikel Datenqualität mit SQL prüfen.

Inhalt

• Wie Datenfehler aussehen: eine Klassifikation
• Die Dimensionen der Datenqualität
• Was davon lässt sich mit SQL prüfen?
• Die zwei blinden Flecken
• Was schlechte Daten kosten
• Von der Theorie zur Praxis
• FAQ
• Verwandte Artikel

Wie Datenfehler aussehen: eine Klassifikation

Bevor man Datenqualität in Dimensionen zerlegt, hilft ein Blick auf die Fehler selbst. Sie lassen sich entlang zweier Achsen sortieren, und die beiden Achsen zusammen decken praktisch jeden Fall ab.

Die erste Achse ist technisch gegen fachlich. Ein technischer (syntaktischer) Fehler verletzt die Form: Buchstaben in einer Zahlenspalte, ein Datum, das kein Datum ist, ein Fremdschlüssel ins Leere. Solche Fehler erkennt man ohne Kenntnis der Fachdomäne — sie brechen die Regeln des Datentyps oder des Modells. Ein fachlicher (semantischer) Fehler dagegen ist formal tadellos und trotzdem falsch: ein Alter von 200, ein Lieferdatum vor dem Bestelldatum, ein als „Premium“ geführter Kunde ohne einen einzigen Auftrag. Erst das Wissen um die Fachlichkeit macht den Fehler sichtbar.

Die zweite Achse ist die Reichweite des Fehlers:

• feldweise — der Fehler steckt in einem einzelnen Wert (age = 200, "abc" in einer Zahlenspalte).
• satzweise — der Fehler entsteht erst im Zusammenspiel mehrerer Felder einer Zeile (lieferdatum < bestelldatum) oder zwischen Zeilen einer Tabelle (zwei Sätze mit demselben Schlüssel).
• beziehungsweise — der Fehler liegt in der Beziehung zwischen Tabellen (ein Verweis, dessen Ziel nicht existiert).

Aus den beiden Achsen ergibt sich eine kompakte Taxonomie, in der jeder konkrete Fehler einen Platz und eine zuständige Prüfroutine bekommt:

Reichweite	technisch / syntaktisch	fachlich / semantisch
feldweise	"abc" in einer Zahlenspalte, ungültiges Datum → Gültigkeit	alter = 200, negativer Preis → Gültigkeit (Fachregel)
satzweise	zwei Sätze mit gleichem Primärschlüssel → Eindeutigkeit	lieferdatum < bestelldatum → Konsistenz (feldübergreifend)
beziehungsweise	Fremdschlüssel zeigt auf fehlenden Master → Konsistenz (Integrität)	„Premium“-Kunde ohne Auftrag → Geschäftsregel

Ein Sonderfall fällt aus dem Raster: der Wert, der fehlt. Ein leeres Pflichtfeld ist weder technisch noch fachlich falsch geformt — es ist schlicht nicht da. Dafür ist ein eigenes Kriterium zuständig, die Vollständigkeit — sie lässt sich keiner einzelnen Zelle zuordnen, sondern schneidet quer durch die ganze Matrix. Zwei weitere Fehlerarten fehlen in der Matrix ganz — der Wert, der gut geformt und trotzdem sachlich falsch ist, und der Wert, der veraltet ist. Auf beide kommen wir zurück; sie sind die blinden Flecken.

Die Dimensionen der Datenqualität

Die Klassifikation sagt, wie ein Fehler aussieht. Die Dimensionen der Datenqualität sagen, welche Eigenschaft guter Daten er verletzt. Hier gibt es keinen Mangel an Theorie, sondern eher einen Überfluss — und das ist der Grund, warum der Begriff so oft schwammig bleibt.

Das deutschsprachige Praxis-Standardwerk zur Datenqualität in Business-Intelligence-Projekten ist Datenqualität erfolgreich steuern von Apel, Behme, Eberlein und Merighi (3. Auflage, Edition TDWI). Es definiert Datenqualität mit Würthele als „mehrdimensionales Maß für die Eignung von Daten, den an ihre Erfassung/Generierung gebundenen Zweck zu erfüllen“ — eine Eignung, die sich über die Zeit ändern kann, wenn sich die Bedürfnisse ändern. Zwei Dinge stecken schon in dieser Definition: Qualität ist mehrdimensional, und sie ist zweckgebunden. Es gibt kein absolutes „gut“, nur ein „gut genug für diesen Zweck“.

Wie viele Dimensionen es sind, ist Definitionssache. Das Buch führt zunächst einen alphabetischen Katalog von sechzig möglichen Qualitätskriterien auf und grenzt daraus die praktisch tragfähigen ein; für den Business-Intelligence-Kontext hebt es sechs hervor — Korrektheit, Konsistenz, Zuverlässigkeit, Vollständigkeit, Zeitnähe und Relevanz. Für diesen Artikel zählen die Kriterien, an denen sich Datenfehler technisch festmachen lassen:

Kriterium	Was es verlangt (nach Apel et al.)
Vollständigkeit	Die Attribute sind mit Werten belegt, die „semantisch vom Wert NULL (unbekannt) abweichen“; bei Transformationen gehen keine Daten verloren.
Gültigkeit (im Buch: formale Korrektheit + Einheitlichkeit)	Die Werte liegen im vordefinierten Format vor und werden einheitlich abgebildet — praktisch gehört der erlaubte Wertebereich dazu.
Eindeutigkeit (im Buch: Redundanzfreiheit + Schlüsseleindeutigkeit)	Kein Datensatz beschreibt dieselbe Entität der realen Welt doppelt; der fachliche Schlüssel kommt nur so oft vor, wie er darf.
Referenzielle Integrität / Konsistenz	Jeder Fremdschlüssel referenziert eindeutig einen existierenden Primärschlüssel; Werte widersprechen sich nicht — im Satz, zwischen Datensätzen, über Anwendungen.
Korrektheit (inhaltlich)	Die Werte stimmen mit den Entitäten der realen Welt überein — die Daten entsprechen der Realität.
Zeitnähe / Aktualität	Die Datensätze entsprechen dem aktuellen Zustand der modellierten Welt und sind nicht veraltet.

Zwei Namen in dieser Tabelle bündeln je zwei Buch-Kriterien — das Buch schneidet feiner, als der internationale Sprachgebrauch es tut. Gültigkeit taucht im Katalog zwar auf, eigens definiert ist die Sache aber über die formale Komponente der Korrektheit (die Anlieferung im vordefinierten Datenformat) und die Einheitlichkeit. Und was international — bei DAMA wie ISO — Eindeutigkeit (Uniqueness) heißt, führt das Buch als Redundanzfreiheit und Schlüsseleindeutigkeit; sein eigenes Kriterium „Eindeutigkeit“ meint dort etwas anderes, nämlich die eindeutige Interpretierbarkeit eines Datensatzes über seine Metadaten. Die Schlüsseleindeutigkeit formuliert das Buch über Primärschlüssel — prüfen lässt sie sich sinnvoll nur am fachlichen Schlüssel, denn ein per Constraint erzwungener Primärschlüssel kann gar nicht doppelt vorkommen. Interessant ist die Prüfung genau dort, wo der Constraint (noch) fehlt: in Staging-Tabellen und an Schnittstellen. Dieser Artikel bleibt bei den gängigen Namen und meint damit die genannten Buch-Kriterien.

Dass mehrere solcher Listen existieren, ist kein Widerspruch, sondern Methode: Fasst man die Kriterien in Gruppen zusammen, entsteht ein Qualitätsmodell. Das Buch stellt zwei nebeneinander — eine theoretische Taxonomie nach Hinrichs und die aus einer Anwenderbefragung gewonnene Kategorisierung der Deutschen Gesellschaft für Informations- und Datenqualität (DGIQ), die ihrerseits auf die vielzitierte Studie von Wang und Strong (1996) mit ihren fünfzehn Dimensionen zurückgeht. International gebräuchlich sind daneben die sechs Dimensionen der DAMA UK (2013) und die Norm ISO/IEC 25012. Es sind verschiedene Schnitte durch denselben Gegenstand — welcher taugt, hängt vom Zweck ab. Für den Rest dieses Artikels bleiben wir bei den Kriterien des Buches, weil sie am direktesten auf eine SQL-Prüfung zeigen.

Was davon lässt sich mit SQL prüfen?

Jetzt die entscheidende Frage: Wie viele dieser Kriterien erreicht eine Handvoll generischer SQL-Prüfungen tatsächlich? Das praktische Framework der SQL-Prüf-Serie baut auf drei Routinen — eine wertebasierte WHERE-Prüfung, eine Duplikat-Prüfung und eine Fremdschlüssel-Prüfung. Trägt man sie gegen die Kriterien auf, ergibt sich diese Coverage-Karte:

Kriterium	mit SQL prüfbar?	Routine
Vollständigkeit	✅ ja	Wertprüfung (IS NULL auf Pflichtfeldern)
Gültigkeit	✅ ja	Wertprüfung (Wertebereich, Format, sichere Typ-Konvertierung)
Eindeutigkeit	✅ ja	Duplikat-Prüfung (GROUP BY … HAVING count(*) > 1)
Referenzielle Integrität / Konsistenz	✅ teilweise	Fremdschlüssel-Prüfung; feldübergreifende Regeln im WHERE
Korrektheit	❌ nein	—
Zeitnähe / Aktualität	❌ nein	—

Vier Kriterien sind also mit generischem, konfigurierbarem SQL erreichbar — und zwar mit erstaunlich wenig Code. „Prüfbar“ heißt dabei: SQL führt die Regel aus; formulieren muss sie die Fachlichkeit — ein preis > 0 steht in keiner Engine von selbst. Die Vollständigkeit ist eine IS NULL-Prüfung auf den Pflichtspalten — im Wortlaut des Buches: „die einzelnen Attribute beinhalten keine NULL-Werte“. Die Gültigkeit ist eine Wertebereichs- oder Format-Prüfung; ihr klassischer Fall ist die sichere Typ-Konvertierung, die etwa mit TRY_CONVERT in SQL Server einen ungültigen Wert zu NULL macht, statt den Load abzubrechen (mehr dazu in den Grundlagen der Typ-Konvertierung). Die Eindeutigkeit ist eine Gruppierung über den fachlichen Schlüssel mit HAVING count(*) > 1. Die referenzielle Integrität — im Buch-Wortlaut: es „muss jeder Fremdschlüssel eindeutig auf einen existierenden Primärschlüssel referenzieren“ — ist eine Fremdschlüssel-Prüfung.

Beim „teilweise“ der Konsistenz lohnt Ehrlichkeit — und eine Abgrenzung: Die referenzielle Integrität ist nur die relationale Spezialform der Konsistenz; das Buch nennt seine Schlüssel-Kriterien ausdrücklich eine „spezielle Ausrichtung auf das relationale Datenbankmodell“. Konsistenz selbst reicht weiter: Das Buch fasst darunter ausdrücklich auch den Abgleich von Daten aus verschiedenen Anwendungen — dass sich ein Wert über Systeme hinweg nicht widerspricht. Diesen systemübergreifenden Abgleich leistet eine einzelne SQL-Prüfung in einer Datenbank nicht; die innerhalb der Datenbank prüfbaren Ausprägungen (referenzielle Integrität, feldübergreifende Regeln in einer Zeile) deckt sie dagegen sauber ab. Die Grenze hängt dabei am Prozess, nicht an der Technik: Werden die für den Abgleich benötigten Daten — der Master aus dem anderen System, die Referenztabelle der anderen Anwendung — in den ETL-Prozess mit eingebunden, liegen sie nebeneinander in einer Datenbank, und der übergreifende Abgleich wird zur gewöhnlichen SQL-Prüfung. Dann läuft auch die Fremdschlüssel-Prüfung gegen einen Master, der ursprünglich aus einem ganz anderen System stammt.

Diese Grenze zieht das Buch übrigens selbst — nur an anderer Stelle: In seinen Kennzahlen-Beispielen je Kriterium (Kapitel 7, Tabelle 7–3) ist die Vollständigkeit eine automatisierte „Anzahl der NULL-Werte“-Abfrage, während bei der inhaltlichen Korrektheit und der Aktualität „User-Feedback“ als Messverfahren steht. Wo keine Abfrage mehr hinkommt, muss ein Mensch antworten.

Die zwei blinden Flecken

Bleiben die zwei Kriterien, bei denen SQL allein passen muss — nicht aus einer Schwäche der Sprache, sondern weil die nötige Information gar nicht in der Datenbank steht. Beide stehen im Kriterienkatalog des Buches direkt neben den prüfbaren.

Der erste blinde Fleck ist die Zeitnähe / Aktualität. Ob eine Adresse „aktuell“ ist, lässt sich aus der Adresse selbst nicht ablesen — sie sieht gestern wie heute identisch aus. Aktualität verlangt, dass die Daten „den aktuellen Zustand der modellierten Welt“ abbilden, wie das Buch es formuliert — und dazu braucht es eine zeitliche Referenz: einen Zeitstempel, wann der Wert zuletzt bestätigt wurde, und eine Erwartung, wie lange er gültig bleibt. Existiert so ein last_verified-Feld, kann SQL die Regel prüfen (last_verified < now() - interval '1 year') — aber dann prüft es die Vollständigkeit und Gültigkeit dieses Zeitstempels, nicht die Aktualität des eigentlichen Werts. Ohne den Zeitstempel ist das Kriterium für eine reine Datenbank-Prüfung unsichtbar.

Der zweite blinde Fleck ist die Korrektheit — und sie ist der subtilste Punkt des ganzen Artikels, weil das Buch sie als „inhaltliche und formale Komponente“ definiert. Die formale Seite — der richtige Datentyp, das vordefinierte Format — ist genau die Gültigkeit und damit prüfbar. Die inhaltliche Seite ist es nicht: Ein Geburtsdatum 1990-05-14 ist perfekt gültig — richtiger Typ, plausibler Bereich, sauberes Format. Ob es das tatsächliche Geburtsdatum der Person ist, weiß die Datenbank nicht und kann es nicht wissen. Dafür bräuchte man eine externe Wahrheitsquelle: das Ausweisdokument, ein Melderegister, einen zweiten unabhängigen Datensatz. SQL vergleicht Daten gegen Regeln, nicht gegen die Welt.

Die Grenze lässt sich damit präziser fassen: Nicht prüfbar ist die Korrektheit, solange die Wahrheitsquelle außerhalb der Datenbank liegt. Sobald sie als Daten verfügbar wird — etwa ein führendes System, das im ETL-Prozess mit-extrahiert wird, dasselbe Muster wie beim systemübergreifenden Konsistenz-Abgleich —, wird die Prüfung zum gewöhnlichen SQL-Abgleich: Quelle gegen führendes System, Abweichung gleich Finding. Der typische Fall ist die Datenmigration, bei der das Zielsystem viele Datensätze bereits kennt; wie solche Abgleiche systematisch aufgebaut werden, zeigt der Artikel zur Verifikation einer Migration. Geprüft ist dann allerdings die Übereinstimmung mit der designierten Wahrheitsquelle — ob die selbst mit der Welt übereinstimmt, bleibt eine Governance-Entscheidung, keine SQL-Frage.

Diese Grenze ist keine Ausrede, sondern der ehrliche Kern der Sache: Eine SQL-Prüfung garantiert, dass Daten wohlgeformt und in sich stimmig sind — nicht, dass sie wahr sind. Wer „automatisch geprüft“ sagt, muss die zwei ausgesparten Kriterien mitnennen, sonst verkauft er ein grünes Häkchen als Wahrheitsbeweis.

Was schlechte Daten kosten

Man findet online reihenweise Schaubilder à la „37 % aller Datenfehler sind Vollständigkeitsfehler“. Ein solches Diagramm steht hier bewusst nicht — für eine belastbare Häufigkeitsverteilung pro Dimension gibt es keine zitierfähige Primärquelle, und eine erfundene Zahl wäre genau der Sorte Datenfehler, um die es hier geht.

Zitierfähig ist dagegen die Ökonomie dahinter — und sie hat zwei Seiten. Die erste betrifft, wann man prüft. Die 1-10-100-Regel stammt ursprünglich aus dem Qualitätsmanagement (Labovitz und Chang, Making Quality Work, 1992) und wird seither auf Datenqualität übertragen: Was an der Quelle zu verhindern 1 kostet, kostet 10 in der nachträglichen Korrektur und 100, wenn man den Fehler wirken lässt — als falsche Rechnung, verlorenen Kunden, Fehlentscheidung. Die konkreten Faktoren sind eine Faustregel, kein Naturgesetz; die Richtung ist aber unstrittig und deckt sich mit jeder Erfahrung: Ein Fehler wird teurer, je später er auffällt. Genau deshalb lohnt sich die Prüfung in der Quelle (Staging), bevor die Daten weiterfließen — dort ist ein Fehler noch meldbar, am Ziel ist er fatal.

Die zweite Seite betrifft nicht, wann man prüft, sondern wie weit man die Datenqualität treiben soll. Apel, Behme, Eberlein und Merighi stellen in ihrem Praxisbuch Datenqualität erfolgreich steuern (3. Auflage, Edition TDWI, Abbildung 3–2, S. 43) zwei gegenläufige Kostenkurven gegenüber: Die Kosten durch schlechte Datenqualität sinken, je höher die Qualität steigt — Fehlentscheidungen, Nacharbeit und verlorene Kunden werden seltener. Die Kosten, gute Qualität herzustellen und zu sichern, steigen dagegen, und zwar überproportional, je näher man den 100 % kommt. Die Summe beider — die Total Quality Cost — hat ihr Minimum nicht bei 100 %, sondern in einem Optimum dazwischen. Das ist die Kernbotschaft: 100 % Datenqualität ist selten das wirtschaftliche Ziel; gesucht ist die kostengünstigste Kombination für den jeweiligen Zweck.

Eigene Darstellung nach Apel et al., „Datenqualität erfolgreich steuern“ (3. Auflage, Edition TDWI, Abbildung 3–2, S. 43) — die klassische Total-Cost-of-Quality-Darstellung.

Das Schaubild ist bewusst vereinfacht — ein Prinzip, kein Messwert; das Optimum verschiebt sich je nach Daten und Zweck. Zwei praktische Konsequenzen folgen daraus:

• Mit wenig Aufwand viel erreichen. Die Herstellungskurve bleibt lange flach und explodiert erst am oberen Ende. Die billige Anfangsstrecke sind die offensichtlichen NULL-Werte, kaputten Formate und Dubletten, die generisches SQL mit wenig Aufwand herausholt — genau die vier prüfbaren Kriterien. Die letzten Prozent, und erst recht die zwei nicht prüfbaren Kriterien (Korrektheit und Aktualität), kosten ungleich mehr und lohnen sich nur dort, wo die Fachlichkeit es verlangt.
• Früh verhindern statt spät bereinigen. Prävention an der Quelle ist der stärkste Hebel: Fehler dort zu vermeiden, statt sie später zu entdecken und zu bereinigen, senkt die Gesamtkosten den im selben Kapitel zitierten Untersuchungen zufolge (Redman 2008) im Schnitt um rund zwei Drittel.

Von der Theorie zur Praxis

Der Rahmen steht: Fehler sortieren sich in wenige Klassen, gute Daten beschreiben sich in einer Handvoll Kriterien, und vier davon sind mit generischem SQL prüfbar. Der Weg von hier in die Praxis führt über vier Artikel:

• Das Framework — Datenqualität mit SQL prüfen — baut die gemeinsame Fehlertabelle, das Schweregrad-Gate und den konfigurierbaren Runner, der die drei Routinen zur Laufzeit erzeugt.
• Die Gültigkeit + Vollständigkeit vertieft Daten mit SQL validieren — Wertebereiche, Pflichtfelder und die Unterscheidung „kein Wert“ gegen „unbekannter Wert“.
• Die Eindeutigkeit vertieft Duplikate finden mit SQL — von count(*) > 1 bis zu zusammengesetzten Schlüsseln.
• Die Konsistenz / Integrität vertieft Verwaiste Datensätze finden — referenzielle Integrität prüfen, auch ohne Fremdschlüssel-Constraint.

Wer die Dimensionen im Kopf hat, liest diese vier Artikel nicht mehr als lose Tricks, sondern als das, was sie sind: je eine Antwort auf je eine messbare Eigenschaft guter Daten.

FAQ

Verwandte Artikel

• Datenqualität mit SQL prüfen — das konfigurierbare SQL-Framework, das die vier prüfbaren Kriterien dieses Artikels in drei generische Routinen gießt: gemeinsame Fehlertabelle, Schweregrad-Gate, dynamischer Runner.
• Daten mit SQL validieren — die Routine zu Gültigkeit und Vollständigkeit, inklusive der NULL-Falle.
• Duplikate finden mit SQL — die Routine zur Eindeutigkeit: maximale Kardinalität und zusammengesetzte Schlüssel.
• Verwaiste Datensätze finden — die Routine zur Konsistenz / referenziellen Integrität.
• Datenqualität in einem ETL-Prozess — der übergeordnete Kontext: wo im ETL-Prozess die Dimensionen geprüft werden und wie schlechte Daten isoliert werden.