Datenintegrität erklärt: Mehr als nur korrekte Werte

Es wird geschätzt, dass eine schlechte Datenqualität Unternehmen durchschnittlich 12,9 Millionen US-Dollar pro Jahr kostet, und breitere Zusammenfassungen beziffern die Spanne auf 12,9 bis 15 Millionen US-Dollar jährlich. Bei der Datenintegrität geht es darum, korrekte und zuverlässige Beziehungen zwischen Datenelementen und Datensätzen aufrechtzuerhalten, und nicht nur darum, ob einzelne Werte richtig sind.

Diese Unterscheidung ist wichtig, weil ein Feld sauber aussehen und dennoch Teil einer fehlerhaften Beziehung sein kann. Eine Bestellung kann einen gültigen Betrag, ein korrektes Datum und eine echt aussehende Kunden-ID aufweisen und dennoch fehlerhaft sein, wenn dieser Kunde in den Stammdaten nicht mehr existiert oder wenn die Zeile gegen eine Geschäftsregel verstößt, die die Vertrauenswürdigkeit des Datensatzes gewährleistet.

Inhaltsverzeichnis

• Was Datenintegrität wirklich bedeutet

  • Warum „korrekte Werte“ ein unvollständiger Test ist

• Wo Integrität in die Datenqualität passt

  • Warum Integrität einen eigenen Pfad benötigt

• Was Datenintegrität in der Praxis abdeckt

• Wie sich Integrität von Genauigkeit, Validität und Konsistenz unterscheidet

  • Direkte Gegenüberstellung

• Wie man Datenintegrität misst

  • Ein einfacher Integritäts-Score

  • Praktische Metriken, die Teams verfolgen

• Was ist referenzielle Integrität?

  • Warum verwaiste Datensätze ein echtes Problem sind

• Wie kann Datenintegrität kontinuierlich überwacht werden?

  • Wie kontinuierliches Monitoring aussieht

• Ein Bestellungs- und Kundenbeispiel für das Integritäts-Monitoring

  • Drei Prüfungen erfassen unterschiedliche Signale

  • Wie der Vorfall behandelt werden sollte

• Wie kann digna die Datenintegrität unterstützen?

  • Was die einzelnen Module für die Integrität tun

Was Datenintegrität wirklich bedeutet

Datenintegrität ist die Wahrung gültiger Beziehungen, struktureller Bedingungen und geschäftlicher Einschränkungen über Datenelemente und Datensätze hinweg. Sie greift weiter als die Prüfung, ob eine einzelne Zelle den richtigen Wert enthält, da ein Wert wohlgeformt sein und dennoch in einer fehlerhaften Beziehung stehen kann.

Warum „korrekte Werte“ ein unvollständiger Test ist

Eine Kunden-ID kann gültig aussehen, eine Rechnungssumme numerisch sein und ein Statusfeld die richtige Kennzeichnung verwenden. Nichts davon garantiert, dass der Datensatz noch zu den Regeln des Systems passt. Wenn eine Rechnung auf ein fehlendes Konto verweist oder eine Bestellung sich auf einen Kunden bezieht, der im Quellsystem gelöscht wurde, haben die Daten ihre Integrität verloren, obwohl jedes einzelne Feld für sich genommen akzeptabel aussehen mag.

Deshalb sind Integritätsfehler in Analyse- und KI-Pipelines so gefährlich. Die Datensätze kommen an, der Job wird abgeschlossen und das Dashboard wird gerendert. Das System sieht fehlerfrei aus, aber die Beziehungen, die den Daten Bedeutung verleihen, sind verloren gegangen. In der Praxis ist dies der Unterschied zwischen einer existierenden Zahl und einer Zahl, der man vertrauen kann.

Praktische Regel: Betrachten Sie Integrität als eine Eigenschaft von Verbindungen und Strukturen, nicht als Eigenschaft einer einzelnen Zelle.

Für Teams, die auch Herkunft und Datenfluss (Lineage) verfolgen, ist die Beziehung eng verwandt, aber nicht identisch. Bei der Integrität geht es darum, ob der Datensatz noch wie beabsichtigt zusammenhält, während Lineage und Herkunft beschreiben, wie die Daten dorthin gelangt sind. Ein nützlicher Bezugspunkt ist dieser Vergleich von Herkunft und Lineage, der hilft, die Rückverfolgung des Ursprungs von der strukturellen Vertrauenswürdigkeit abzugrenzen.

Der Grund auf Vorstandsebene, sich darum zu kümmern, ist naheliegend. IBM und die Harvard Business Review beziffern die jährlichen Kosten schlechter Daten für die US-Wirtschaft seit langem auf geschätzte 3,1 Billionen US-Dollar, und die MIT Sloan Management Review berichtete ebenfalls über frühere Untersuchungen, wonach schlechte Daten bei vielen Unternehmen 15 % bis 25 % des Umsatzes verschlingen können. Dies erklärt, warum das Thema Datenintegrität zunehmend den Bereich des Datenbankteams verlässt und in governance- und Führungsdiskussionen rückt. Das finanzielle Risiko entsteht nicht nur durch falsche Werte, sondern durch fehlerhafte Beziehungen, die nachgelagerte Entscheidungen verzerren.

Wo Integrität in die Datenqualität passt

Integrität ist eine der anerkannten Datenqualitätsdimensionen in der DAMA-DMBOK® 2.0 Revised Edition, neben Genauigkeit, Vollständigkeit, Timeliness, Konsistenz, Eindeutigkeit, Validität und verwandten Qualitätsdimensionen. Diese Einordnung ist wichtig, da sie bestätigt, dass Integrität keine Nischen-Datenbankidee ist, sondern ein Kernbestandteil des Denkens rund um DAMA-Datenqualität und DMBOK-Datenqualität.

Warum Integrität einen eigenen Pfad benötigt

Ein Team kann über starke Genauigkeitsprüfungen verfügen und dennoch Integritätsfehler übersehen. Das liegt daran, dass Genauigkeit prüft, ob ein Wert der Realität entspricht, während Integrität untersucht, ob die Struktur und die Beziehungen um den Wert herum noch Bestand haben. Eine Kundenadresse kann korrekt sein, aber wenn der Kundendatensatz nicht mehr mit dem richtigen Konto verknüpft ist, ist die Integrität bereits verletzt.

Das gleiche Problem zeigt sich im Betrieb. Viele Gruppen verlassen sich auf manuelle Prüfungen oder SQL-basierte Validierung, während weniger Teams dedizierte Observability-Tools einsetzen und die Verantwortung für die governance oft auf verschiedene Teams verteilt ist. Aktuelle Umfragedaten zeigen, dass 44 % der Befragten angeben, dass die Verantwortung für die Datenqualität auf mehrere Teams verteilt ist, 61 % sich immer noch auf manuelle Prüfungen oder SQL-basierte Validierung verlassen, 27 % eine dedizierte Observability-Plattform nutzen, 39 % SLAs für wichtige Pipelines verfolgen und 14 % diese unternehmensweit durchsetzen. Diese Zahlen weisen auf eine häufige operative Lücke hin: Teams überwachen Qualitätswerte, aber sie kontrollieren nicht immer die Beziehungsgesundheit über die gesamte Kette hinweg. Interne Konsistenz über Datenqualitätsdimensionen hinweg sorgt dafür, dass Integrität nicht mit einer anderen Dimension verwechselt wird.

Was Datenintegrität in der Praxis abdeckt

Datenintegrität umfasst mehrere verwandte Prüfungen, von denen jede eine andere Art von Fehler erfasst. Die vier primären Subtypen und wie sie sich in der Praxis darstellen:

Diese Tabelle ist wichtig, weil jeder Subtyp das Vertrauen auf eine andere Weise erschüttert. Ein Datensatz kann für sich genommen vollkommen gültig aussehen und dennoch die übergeordnete Integritätsprüfung nicht bestehen, wenn seine Verknüpfungen, seine Form oder sein Regelkontext nicht mehr stimmen.

Ein Abrechnungssystem für Schadensfälle ist ein gutes Beispiel. Eine Schadenszeile kann einen gültigen Code, einen gültigen Betrag und ein gültiges Datum enthalten. Wenn diese Zeile jedoch dem falschen Kundenkonto zugeordnet ist oder das Ereignis, von dem sie abhängt, in der falschen Reihenfolge abgeschlossen wurde, sind die Daten dennoch fehlerhaft. Der Wert ist in Ordnung. Die Beziehung ist es nicht.

Diese Unterscheidung ist der Grund, warum Teams Integritätsprobleme oft übersehen, wenn sie nur einzelne Felder prüfen. Strukturelle Prüfungen erkennen fehlende Spalten oder Typänderungen. Referenzielle Prüfungen erkennen fehlerhafte Verknüpfungen. Geschäftsregel-Prüfungen erkennen Kombinationen, die niemals zusammen auftreten sollten. Zusammen zeigen sie, ob sich der Datensatz noch wie ein zusammenhängendes System verhält und nicht wie eine Ansammlung von korrekt aussehenden Werten.

Eine Plattform kann diese Prüfungen auf unterschiedliche Weise unterstützen. Integritätstests von Datenbanken sind ein praktischer Ansatz, da sie Teams dazu zwingen, jede Regel als Referenzproblem, Strukturproblem oder Geschäftsregelproblem zu klassifizieren. Wenn der Fehler in einer fehlenden übergeordneten Zeile liegt, unterscheidet sich die Behebung von einer Schemaänderung oder einer Regelverletzung.

Wie sich Integrität von Genauigkeit, Validität und Konsistenz unterscheidet

Integrität ist nicht dasselbe wie Genauigkeit, Validität oder Konsistenz. Der einfachste Weg, sie voneinander abzugrenzen, besteht darin, sich zu fragen, welche Art von Fehler die jeweilige Prüfung aufdeckt.

Direkte Gegenüberstellung

Ein Datensatz kann gültig, genau und sogar konsistent sein und dennoch die Integrität verletzen. Die E-Mail-Adresse eines Kunden ist möglicherweise im richtigen Format, stimmt mit dem CRM überein und entspricht der tatsächlichen Person. Wenn diese Kunden-ID jedoch im Bestellsystem nicht mehr existiert, ist die Beziehung unterbrochen und der Datensatz nicht mehr vertrauenswürdig.

Faustregel: Verwenden Sie Genauigkeitsprüfungen für die Korrektheit von Werten, Validitätsprüfungen für Format- und Wertebereichsregeln, Konsistenzprüfungen für die systemübergreifende Übereinstimmung und Integritätsprüfungen für die Beziehungen, die die Daten miteinander verbinden.

Genauigkeit in der Datenqualität ist ein hilfreicher Vergleichspunkt, da er zeigt, warum die Korrektheit von Werten allein das Modell, den Bericht oder das Buchhaltungssystem nicht schützt. Datenteams benötigen jede Prüfung an der richtigen Stelle und nicht einen einzigen Pauschaltest, der vorgibt, alles zu erledigen.

Wie man Datenintegrität misst

Datenintegrität wird messbar, wenn Sie die Beziehungen und Geschäftsregeln definieren, die für einen bestimmten Datensatz gelten müssen. Die Formel ist einfach, aber das dahinterstehende Regelwerk muss explizit sein.

Ein einfacher Integritäts-Score

Integritätsrate = Datensätze, die die erforderlichen Integritätsbedingungen erfüllen / bewertete Datensätze × 100

Diese Formel funktioniert nur, wenn sich das Team einig ist, welche Bedingungen zählen. Für eine Pipeline kann die Bedingung ein gültiger Fremdschlüssel sein. Für eine andere kann es eine Schemaregel plus ein übergeordneter Datensatz plus eine geschäftliche Einschränkung sein. Die Messung hängt von der jeweils bewerteten Beziehung ab.

Praktische Metriken, die Teams verfolgen

• Verletzungsrate der referenziellen Integrität: wie oft Verknüpfungen auf fehlende übergeordnete Datensätze verweisen.

• Anzahl verwaister Datensätze: die Anzahl der untergeordneten Zeilen ohne gültiges Parent-Element.

• Fehlgeschlagene Beziehungsprüfungen: die Gesamtzahl fehlerhafter Joins oder Abhängigkeitsregeln.

• Prozentsatz der Datensätze mit gültigen Referenzen: eine einfache Ansicht der Erfolgsquote.

• Anzahl fehlerhafter Beziehungen: nützlich für die Trendverfolgung über verschiedene Releases hinweg.

• Verletzungsrate von Geschäftsregeln: der Anteil der Zeilen, die eine definierte Regel nicht bestehen.

Datenqualitätsmetriken werden weitaus nützlicher, wenn sie Struktur von der Wertqualität trennen. Ein sauberes Dashboard sollte die Beziehungsgesundheit zeigen, nicht nur Nullwert-Raten und Vollständigkeit. Wenn Schema-Drift, Fremdschlüsselprüfungen und Regelprüfungen im selben Zeitfenster fehlschlagen, sinkt der Integritäts-Score, selbst wenn die Werte an der Oberfläche normal aussehen.

Was ist referenzielle Integrität?

Referenzielle Integrität bedeutet, dass Beziehungen zwischen verbundenen Entitäten gültig bleiben. Jede Bestellung sollte auf einen existierenden Kunden verweisen, jede Rechnung auf ein existierendes Konto und jede Produkt-ID im Produktstamm vorhanden sein.

Warum verwaiste Datensätze ein echtes Problem sind

Eine fehlerhafte Referenz führt zu einem verwaisten Datensatz. Die Zeile existiert zwar noch, aber ihre Bedeutung ist beschädigt, da sie nicht mehr auf ein gültiges Parent-Element verweist. Die Dokumentation des SQL Servers von Microsoft beschreibt dies ganz einfach: Ein Fremdschlüssel hängt von dem Primärschlüssel ab, auf den er verweist, und Verweise auf nicht existierende Werte sind unzulässig.

Deshalb wird referenzielle Integrität oft durch Primärschlüssel- und Fremdschlüssel-Constraints erzwungen, wobei auch CHECK-Constraints helfen, gültige Beziehungen über Tabellen hinweg zu bewahren. Wenn sich ein Schlüssel ändert, müssen sich alle abhängigen Referenzen ebenfalls konsistent ändern, andernfalls verliert der Datensatz seine Bedeutung.

Wenn eine untergeordnete Zeile ihr übergeordnetes Element nicht finden kann, werden die Daten möglicherweise dennoch geladen, aber die Beziehung ist nicht mehr vertrauenswürdig.

Das Gesamtbild ist besorgniserregend. Das Identity Theft Resource Center meldete für das Jahr 2025 in den USA 3.322 Datenkompromittierungen – ein Anstieg von 79 % innerhalb von fünf Jahren – und 471,2 Millionen Benachrichtigungen an Opfer allein in der ersten Hälfte des Jahres 2026. Diese Zahlen zeigen, warum Teams Beziehungsfehler nicht als kleine Bereinigungsaufgaben abtun können, da Integritätsprobleme Teil eines breiteren Betriebs- und Risikoumfelds sind. Die Anleitung zur referenziellen Integrität liefert eine klare operative Definition: Gültige Beziehungen zwischen verknüpften Datensätzen sind der entscheidende Mechanismus.

Wie kann Datenintegrität kontinuierlich überwacht werden?

Das Monitoring der Datenintegrität funktioniert am besten als laufende Kontrolle, nicht als vierteljährliches Audit. Geplante Prüfungen erfassen Probleme erst im Nachhinein, während eine kontinuierliche Überwachung fehlerhafte Beziehungen, Schemaänderungen und Regelverletzungen direkt bei deren Entstehen aufdeckt.

Wie kontinuierliches Monitoring aussieht

Beginnen Sie mit Grenzwerten. Definieren Sie, was als normal für Beziehungsprüfungen, die Anzahl verwaister Datensätze, Schemaänderungen und Verletzungen von Geschäftsregeln gilt. Richten Sie dann Warnmeldungen ein, wenn die Daten den erwarteten Bereich verlassen, und leiten Sie den Vorfall mit ausreichend Kontext an den zuständigen Mitarbeiter weiter, damit die Ursache behoben werden kann.

Ein nützlicher Arbeitsrhythmus ist einfach:

1. KPIs definieren, wie z. B. Beziehungs-Erfolgsquoten und die Anzahl fehlgeschlagener Constraints.

2. Baselines festlegen, damit das Team weiß, wie der Normalzustand aussieht.

3. Bei Abweichungen alarmieren, anstatt zu warten, bis ein Bericht fehlerhaft ist.

4. Monatlich überprüfen, damit wiederkehrende Probleme sichtbar und behebbbar werden.

Schema-Drift verdient besondere Aufmerksamkeit, da strukturelle Änderungen die nachgelagerte Bedeutung verfälschen können, selbst wenn die Zeilenwerte immer noch in Ordnung aussehen. Typänderungen, umbenannte Spalten, entfernte Felder und unkoordinierte Ergänzungen können die Kompatibilität beeinträchtigen oder Transformationen ungültig machen, bevor es jemand bemerkt.

Ein Bestellungs- und Kundenbeispiel für das Integritäts-Monitoring

Eine Bestellzeile mit customer_id = 4821 kann perfekt aussehen und dennoch fehlerhaft sein, wenn der Kunde 4821 im letzten Quartal aus dem Kundenstamm gelöscht wurde. Der Bestellbetrag kann korrekt sein, die Bestell-ID eindeutig und das E-Mail-Format die Validierung bestehen, während die Integrität bereits verletzt ist.

Drei Prüfungen erfassen unterschiedliche Signale

digna Data Validation markiert die ungültige Referenz, wenn die Bestellung auf einen Kunden verweist, der nicht mehr existiert.
Data Reconciliation vergleicht die zugehörigen Quell- und Zieldatensätze und deckt die Diskrepanz zwischen den Erwartungen der Bestellgabelle und dem Inhalt des Kundenstamms auf.
digna Schema Tracker bemerkt die strukturelle Änderung, die möglicherweise zu dem Problem beigetragen hat, wie z. B. ein gelöschtes oder umbenanntes Feld im Quellsystem.

Die Pipeline selbst wird möglicherweise immer noch erfolgreich abgeschlossen. Das ist die Falle. Ein grüner Job-Status bedeutet nicht, dass die Datenintegrität den Durchlauf unbeschadet überstanden hat.

Wie der Vorfall behandelt werden sollte

Das Team sollte die drei Signale zu einem einzigen Vorfall zusammenfassen und nicht drei separate Tickets erstellen. Dadurch bleibt der Fokus auf der eigentlichen Ursache, die in einer fehlenden Löschregel, einer fehlerhaften Synchronisierung oder einer nicht mit nachgelagerten Systemen abgestimmten Schemaänderung liegen kann. Die richtige Behebung erfolgt in der Regel im Quellsystem, da das bloße Patchen der verwaisten Zeile die fehlerhafte Beziehung nicht wiederherstellt.

Wie kann digna die Datenintegrität unterstützen?

digna Data Validation unterstützt explizite Beziehungs- und Geschäftsregelprüfungen, was die Grundvoraussetzung für das Aufspüren fehlerhafter Referenzen, verwaister Zeilen und Regelverletzungen ist. digna Data Reconciliation hilft beim Vergleich verknüpfter Quell- und Zieldatensätze, bei denen die Integrität von der Übereinstimmung der beiden Systeme abhängt. Der digna Schema Tracker identifiziert strukturelle oder Schemaänderungen, die sich im Laufe der Zeit auf die Integrität auswirken können.

Was die einzelnen Module für die Integrität tun

Data Validation eignet sich direkt für Prüfungen auf Datensatzebene. Reconciliation ist die richtige Wahl, wenn die Integrität von der Konsistenz zwischen Systemen abhängt. Der Schema Tracker fungiert als Frühwarnsystem für strukturelle Änderungen, die nachgelagerte Annahmen gefährden können.

Das Schema-Monitoring kann strukturelle Änderungen erkennen, die sich auf die Integrität auswirken können. Es beweist für sich genommen jedoch nicht, dass die Daten strukturell oder referenziell korrekt sind.

Diese Unterscheidung ist wichtig, da Teams manchmal Erkennung mit Beweis verwechseln. Eine Schema-Warnung teilt Ihnen mit, dass sich die Form geändert hat. Sie bestätigt nicht, dass jede Beziehung immer noch funktioniert oder dass jede Regel weiterhin eingehalten wird.

Wenn Ihr Team versucht, sauber aussehende Daten von tatsächlich vertrauenswürdigen Daten zu unterscheiden, sollten Sie sich mit den Beziehungsregeln, Schemaänderungen und Validierungssignalen befassen, die unter dem Dashboard liegen. Besuchen Sie digna, um zu sehen, wie die Funktionen zur Validierung, Abstimmung und Schemaverfolgung das Monitoring der Datenintegrität in Ihren bestehenden Systemen unterstützen können.