Daten & Data Science
Datenqualität hängt nicht nur von einzelnen Werten ab. Struktur, Datentypen, Schlüssel, Beziehungen, zulässige Wertebereiche und Evolutionsregeln bestimmen, ob ein Datenbestand technisch konsistent interpretiert und verarbeitet werden kann. Die Untersuchung verbindet deshalb Schema, tatsächlichen Datenbestand und Verarbeitungscode.
Kurzantwort
Geprüft werden erwartetes Datenmodell, implementiertes Schema und beobachtete Daten gemeinsam. Constraints und Validierungsregeln werden darauf untersucht, ob sie tatsächlich wirksam sind. Abweichungen werden danach klassifiziert, ob sie syntaktische, relationale, semantische oder zeitliche Integrität betreffen.
Vom Prüfgegenstand zur dokumentierten technischen Schlussfolgerung
1. Logisches Datenmodell und physisches Schema unterscheiden
Ein fachliches Datenmodell beschreibt Entitäten, Attribute und Beziehungen, während das physische Schema deren konkrete Umsetzung in relationalen Tabellen, Dokumenten, Events oder Dateien enthält. Beide Ebenen können auseinanderfallen.
Die Begutachtung dokumentiert daher, welche Struktur erwartet wurde und welche tatsächlich gespeichert wird. Ein fehlender Fremdschlüssel kann beispielsweise durch Anwendungscode kompensiert werden, bleibt aber hinsichtlich Integrität und Nachweisbarkeit anders zu bewerten als eine datenbankseitig erzwungene Regel.
2. Datentypen, Pflichtfelder und Wertebereiche prüfen
Datentypen bestimmen, welche Werte technisch repräsentierbar sind. Zusätzlich können Nullability, Längen, Enumerationen, reguläre Ausdrücke oder JSON-Schemas zulässige Werte einschränken.
Relevant ist nicht nur die Definition, sondern ihre Durchsetzung. Ein dokumentierter Wertebereich ohne technische Validierung kann von importierten oder historischen Daten verletzt werden. Solche Unterschiede zwischen Spezifikation und realem Bestand werden messbar gemacht.
3. Schlüssel und Beziehungen auf referentielle Integrität untersuchen
Primär- und Fremdschlüssel, eindeutige Identifikatoren und Join-Logik beeinflussen, ob Datensätze zuverlässig verknüpft werden können. Verwaiste Referenzen, doppelte Schlüssel oder instabile Business Keys können Analysen und Geschäftslogik verfälschen.
Bei NoSQL- oder Event-Systemen existieren Beziehungen häufig implizit. Dann wird geprüft, welche Identifikatoren Anwendungen verwenden und ob Konsistenz über Services oder Datenströme hinweg nachvollziehbar bleibt.
4. Schema- und Formatvalidierung reproduzierbar durchführen
Für strukturierte Austauschformate können formale Schemas eine reproduzierbare Validierung ermöglichen. JSON Schema definiert beispielsweise Struktur- und Validierungsmechanismen; SHACL ermöglicht die Validierung von RDF-Graphen gegen Shapes.
Solche Werkzeuge beantworten nur die in den Regeln kodierten Fragen. Ein formal gültiges Objekt kann fachlich falsch sein. Deshalb werden syntaktische und semantische Integrität getrennt ausgewiesen.
5. Migrationen und Schema-Drift berücksichtigen
Datenmodelle verändern sich. Spalten werden umbenannt, Werte neu codiert, Events erweitert oder Felder aus Kompatibilitätsgründen parallel geführt. Eine heutige Schemaansicht darf daher nicht automatisch auf historische Datenstände übertragen werden.
Migrationen, Versionsfelder, DDL-Historien und Transformationscode helfen, die zeitliche Gültigkeit von Regeln zu bestimmen. Bei fehlender Historie wird die Unsicherheit ausdrücklich dokumentiert.
6. Integritätsbefunde mit Verarbeitungsauswirkungen verbinden
Nicht jede Schemaabweichung beeinflusst das untersuchte Ergebnis. Für eine sachverständige Bewertung wird geprüft, ob verletzte Regeln zu verworfenen Datensätzen, falschen Aggregationen, Join-Verlusten oder fehlerhaften Modellinputs führen können.
Dadurch wird zwischen rein formaler Abweichung und technisch relevanter Auswirkung unterschieden. Gegenproben mit bereinigten oder alternativen Datensätzen können zeigen, ob der Befund das Ergebnis tatsächlich beeinflusst.
Bei verteilten Systemen ist außerdem zu berücksichtigen, dass Konsistenz zeitabhängig sein kann. Eventual Consistency, asynchrone Replikation oder verzögerte Events können kurzfristig scheinbar widersprüchliche Zustände erzeugen. Die Prüfung muss daher festlegen, ob ein beobachteter Zustand eine zulässige Übergangsphase oder eine dauerhafte Integritätsverletzung darstellt.
Für analytische Systeme kann zusätzlich geprüft werden, ob semantisch gleich benannte Felder über Quellen hinweg tatsächlich dieselbe Bedeutung besitzen. Unterschiedliche Zeitzonen, Einheiten, Codierungen oder Aggregationsstände können technisch gültige Daten zu fehlerhaften Joins oder Vergleichen machen, obwohl kein Schemafehler im engeren Sinn vorliegt.
Bei Datenbanken mit Triggern, Stored Procedures oder materialisierten Views wird geprüft, ob Integritätsregeln außerhalb des sichtbaren Tabellenschemas umgesetzt werden. Andernfalls kann eine reine DDL-Analyse Regeln übersehen, die erst zur Laufzeit greifen. Umgekehrt können deaktivierte Constraints oder migrationsbedingt ausgesetzte Prüfungen ein formal definiertes Regelwerk praktisch unwirksam machen.
Ist ein schema-valider Datensatz automatisch korrekt?
Nein. Schema-Validität bestätigt nur die definierten Struktur- und Wertebedingungen.
Ein Datum kann formal korrekt formatiert und trotzdem sachlich falsch sein; eine ID kann syntaktisch gültig sein und dennoch auf die falsche Entität verweisen.
Deshalb werden strukturelle Integrität, fachliche Plausibilität und Provenienz getrennt geprüft.
Ist die Untersuchung für diesen Themenbereich nachvollziehbar abgegrenzt?
- Sind erwartetes Datenmodell und tatsächlich implementiertes Schema getrennt dokumentiert?
- Sind Datentypen, Pflichtfelder und Wertebereiche auf reale Daten angewendet geprüft?
- Sind Schlüssel, Eindeutigkeit und Beziehungen technisch nachvollziehbar?
- Ist erkennbar, welche Regeln durch Datenbank, Schema oder Anwendungscode erzwungen werden?
- Sind Schema-Versionen und Migrationen für den untersuchten Zeitraum berücksichtigt?
- Wurden Integritätsverletzungen auf ihre tatsächliche Verarbeitungsauswirkung gegengeprüft?
- Bleiben technische Konsistenz und fachliche beziehungsweise rechtliche Wahrheit getrennt?
Konstruiertes Beispiel
Ein Export enthält gültige JSON-Objekte, doch mehrere Datensätze referenzieren Kundennummern, die im Stammdatensatz nicht existieren. Die Untersuchung trennt Formatvalidität von referentieller Integrität und prüft anschließend, ob die fehlenden Beziehungen zu verworfenen oder falsch aggregierten Datensätzen führen.
Das Beispiel ist konstruiert und beschreibt kein reales Mandat.
Quellen und fachliche Grundlage
- Technische Spezifikation JSON Schema Draft 2020-12 für Struktur und Validierung von JSON-Dokumenten. Quelle öffnen.
- W3C Recommendation SHACL Recommendation 2017 für die Validierung von RDF-Graphen gegen Shapes. Quelle öffnen.
- Eigene Methodik Quellen und Methodik der Wissensplattform. Quelle öffnen.
Weiterführende Beiträge
- Datenqualität technisch prüfen
- Datenherkunft und Transformationen rekonstruieren
- Alle Beiträge in diesem Themenbereich
Eigene Fachliteratur und Veröffentlichungen
Die folgenden eigenen Arbeiten dienen der fachlichen Vertiefung und methodischen Einordnung. Sie ersetzen keine erforderlichen Primär-, Norm-, Hersteller- oder sonstigen unabhängigen Fachquellen. Unveröffentlichte Manuskripte, Entwürfe und Lehrunterlagen werden hier bewusst nicht als öffentliche Quellen ausgewiesen.
Technische Untersuchung zum Themenbereich Daten & Data Science
Die konkrete Aussagekraft hängt vom Untersuchungsgegenstand, der verfügbaren Evidenz und der dokumentierten Prüfmethode ab.
Data-Science-Gutachten