Daten als Untersuchungsgegenstand: Herkunft, Datenstand und Reproduzierbarkeit

Daten & Data Science

Technische Aussagen über Daten sind nur dann nachvollziehbar, wenn feststeht, welcher konkrete Datenbestand untersucht wurde, woher er stammt, wie er übernommen wurde und welche Veränderungen zwischen Quelle und Analyse stattgefunden haben. Ein Dateiname wie kunden_final.csv oder die Bezeichnung „Produktionsdaten“ identifiziert für sich genommen keinen reproduzierbaren Untersuchungsgegenstand.

1. Zuerst muss der konkrete Datenbestand bestimmt werden

Der Begriff „die Daten“ ist für eine technische Untersuchung regelmäßig zu unbestimmt. Ein Informationssystem kann parallel mehrere Datenstände, Datenbanken, Tabellen, Exporte, Backups oder abgeleitete Datensätze enthalten.

Deshalb sollte zunächst festgelegt werden, welcher konkrete Datenbestand Untersuchungsgegenstand ist. Je nach Fall kann dies beispielsweise sein:

• ein Datenbank-Snapshot,
• ein bestimmter Datenbank-Export,
• ein Satz von CSV- oder JSON-Dateien,
• ein API-Abruf mit dokumentierten Parametern,
• ein Rohdatensatz vor der Aufbereitung,
• ein transformierter Analysedatensatz,
• ein Trainings-, Validierungs- oder Testdatensatz.

2. Herkunft und Dateninhalt sind getrennt zu dokumentieren

Zwei Dateien können denselben Aufbau oder sogar denselben Dateinamen besitzen, ohne aus derselben Quelle zu stammen. Umgekehrt kann dieselbe fachliche Datenquelle zu unterschiedlichen Zeitpunkten unterschiedliche Inhalte liefern.

Für die Untersuchung sind deshalb mindestens zwei Fragen zu trennen:

• Was liegt technisch vor? Welche Dateien, Tabellen, Datensätze oder sonstigen Datenobjekte werden untersucht?
• Woher stammt dieser Bestand? Aus welchem System, welcher Datenbank, welchem Export, welcher Schnittstelle oder welcher sonstigen Quelle wurde er übernommen?

3. Provenienz beschreibt die Entstehungs- und Ableitungskette

Das W3C-Provenienzmodell PROV-DM beschreibt Provenienz als Information über Entitäten, Aktivitäten und beteiligte Akteure beziehungsweise Agenten. Es berücksichtigt außerdem, wie Entitäten aus anderen Entitäten abgeleitet werden können.

Für eine gutachterliche Datenuntersuchung lässt sich dieses Prinzip methodisch übertragen: Ein Rohdatensatz kann durch eine Import- oder Transformationsaktivität in einen bereinigten Datensatz überführt werden, aus dem anschließend ein Analyse- oder Trainingsdatensatz entsteht.

Entscheidend ist dabei nicht, ein bestimmtes Provenienzformat zwingend einzusetzen. Entscheidend ist, dass relevante Ableitungen technisch nachvollziehbar beschrieben werden.

4. Der Übernahmevorgang gehört zur Untersuchungsgrundlage

Ein Datenbestand kann beispielsweise durch Dateiübergabe, Datenbankexport, SQL-Abfrage, API-Aufruf, Backup-Wiederherstellung oder einen automatisierten ETL-Prozess übernommen worden sein.

Je nach Fragestellung sollten dabei unter anderem dokumentiert werden:

• Quellsystem,
• Zeitpunkt der Übernahme,
• verwendete Abfrage oder Exportfunktion,
• Filter- und Auswahlkriterien,
• relevante Parameter,
• verwendetes Datenformat,
• Zeichenkodierung und gegebenenfalls Trennzeichen,
• Umfang des übernommenen Bestands.

5. Ein Datenstand benötigt einen Zeit- und Versionsbezug

Veränderliche Datenquellen können bei zwei Abrufen unterschiedliche Ergebnisse liefern. Deshalb sollte dokumentiert werden, für welchen Zeitpunkt oder Zeitraum ein Datenbestand steht.

Der relevante Bezug kann beispielsweise über Snapshot-Zeitpunkt, Exportzeitpunkt, fachlichen Berichtszeitraum, Versionskennung, Release einer Datenlieferung oder einen anderen nachvollziehbaren Identifikator hergestellt werden.

Dabei ist zu unterscheiden zwischen dem Zeitpunkt, den die Daten fachlich abbilden, und dem Zeitpunkt, zu dem sie technisch exportiert, übertragen oder untersucht wurden.

6. Ein Dateiname identifiziert keinen unveränderlichen Datensatz

Bezeichnungen wie export.csv, final.json oder dataset_v2.xlsx können organisatorisch nützlich sein. Sie beweisen aber nicht, dass zwei gleich bezeichnete Dateien byteidentisch sind.

Ebenso genügt eine identische Dateigröße oder dieselbe Anzahl von Datensätzen nicht, um Inhaltsidentität festzustellen.

Für übernommene Dateien können deshalb zusätzlich kryptografische Hashwerte zusammen mit dem verwendeten Hashverfahren als technische Identifikatoren des konkret übernommenen Bytebestands dokumentiert werden.

7. Hashwerte belegen nicht Herkunft oder fachliche Bedeutung

Ein Hashwert kann helfen, einen konkret übernommenen Dateibestand später wiederzuerkennen und Veränderungen des Byteinhalts technisch zu prüfen.

Daraus folgt jedoch nicht automatisch, aus welchem Ursprungssystem die Datei stammt, ob der Export vollständig ist, welche Abfrage ihm zugrunde lag oder ob die enthaltenen Daten fachlich richtig sind.

RFC 8493 beschreibt mit BagIt beispielsweise ein Format, bei dem Payload-Manifeste Dateinamen und zugehörige Checksummen enthalten, um die Integrität eines übertragenen Dateibestands prüfen zu können. Für ein Gutachten ist dies ein technisches Beispiel für die Trennung von Datenidentifikation und fachlicher Bewertung.

8. Rohdaten und abgeleitete Datenstände sollten getrennt bleiben

In Data-Science- und Analyseprozessen werden ursprüngliche Daten häufig bereinigt, gefiltert, zusammengeführt, aggregiert, umkodiert oder anderweitig transformiert.

Dadurch entsteht ein neuer Datenstand. Dieser sollte nicht stillschweigend mit den Rohdaten gleichgesetzt werden.

Eine nachvollziehbare Dokumentation unterscheidet deshalb beispielsweise:

• unveränderte Ausgangsdaten,
• technisch bereinigte Daten,
• zusammengeführte Daten,
• aggregierte Daten,
• erzeugte Merkmale oder Features,
• finalen Analyse- oder Modelldatensatz.

9. Transformationen müssen reproduzierbar beschrieben werden

Soll ein abgeleiteter Datensatz nachvollzogen werden, reicht dessen Endzustand allein häufig nicht aus.

Je nach Verfahren können zusätzlich relevant sein:

• Transformationsskripte oder Abfragen,
• verwendete Parameter,
• Reihenfolge der Verarbeitungsschritte,
• Zuordnungs- und Mappingtabellen,
• verwendete Software- und Bibliotheksversionen,
• Regeln zum Umgang mit Fehlwerten,
• Regeln für Filterung, Aggregation und Duplikate,
• gegebenenfalls Zufallsparameter oder weitere nichtdeterministische Einflüsse.

10. Reproduzierbarkeit ist mehr als das Vorhandensein eines Skripts

Ein vorhandenes Notebook, SQL-Skript oder Python-Programm zeigt zwar, welche Verarbeitung beabsichtigt war. Für eine technische Reproduktion muss jedoch zusätzlich die dazugehörige Eingabebasis bestimmbar sein.

Werden dasselbe Skript und ein anderer Datenstand kombiniert, kann ein anderes Ergebnis entstehen. Ebenso können Konfiguration, Bibliotheksversionen, externe Datenquellen oder nicht dokumentierte manuelle Schritte die Reproduktion beeinflussen.

11. Provenienz und Datenqualität sind unterschiedliche Fragen

Ein Datensatz kann technisch eindeutig identifiziert und seine Herkunft vollständig dokumentiert sein, obwohl seine fachliche Datenqualität eingeschränkt ist.

Umgekehrt kann ein plausibel wirkender Datenbestand vorliegen, dessen Herkunft oder Ableitung nicht ausreichend nachvollziehbar ist.

ISO/IEC 25012 beschreibt ein allgemeines Datenqualitätsmodell für strukturierte Daten. Die technische Bestimmung von Herkunft, Datenstand und Ableitung ist davon zu unterscheiden. Konkrete Datenqualitätsmerkmale können anschließend in einer gesonderten Untersuchung bewertet werden.

12. Versionsinformationen erhöhen die Nachvollziehbarkeit

Die W3C Data on the Web Best Practices behandeln neben Provenienzinformationen auch Versionsindikatoren und Versionshistorien für Datensätze.

Für interne oder gutachterliche Datenbestände kann dieses Grundprinzip ebenfalls hilfreich sein. Ein veränderter Datensatz sollte möglichst nicht nur denselben unspezifischen Namen weiterverwenden, wenn dadurch frühere Datenstände nicht mehr unterscheidbar sind.

Welche Versionierungsmethode geeignet ist, hängt vom jeweiligen System ab. Möglich sind beispielsweise Snapshot-Kennungen, datierte Exporte, Datenlieferungsnummern oder technisch verwaltete Dataset-Versionen.

13. Ein Analysedatensatz muss zur Untersuchung passen

Für eine technische Bewertung ist nicht nur relevant, ob ein Datensatz reproduzierbar erzeugt wurde. Es muss außerdem klar sein, welche Aussage gerade auf diesem Datenstand beruhen soll.

Wird beispielsweise eine Modellkennzahl auf einem bestimmten Testdatensatz berichtet, sollte genau dieser Testdatensatz bestimmbar sein. Wird dagegen eine historische Auswertung untersucht, kann ein später aktualisierter Datenbestand für diese konkrete Frage ungeeignet sein.

Datenstand, Fragestellung und Analyseergebnis müssen deshalb zusammenpassen.

14. Fehlende Provenienz begrenzt die Aussage

Nicht immer lässt sich eine Datenkette vollständig rekonstruieren. Es können beispielsweise ursprüngliche Exporte fehlen, Transformationen nicht dokumentiert sein oder Zwischendatensätze überschrieben worden sein.

In diesem Fall sollte die fehlende Nachvollziehbarkeit nicht durch Annahmen verdeckt werden. Stattdessen ist zu dokumentieren, welche Teile der Datenherkunft gesichert, rekonstruiert, nur plausibel oder nicht mehr bestimmbar sind.

Diese Unsicherheit ist selbst Teil des technischen Untersuchungsergebnisses.

15. Technischer Datenbefund und rechtliche Würdigung sind zu trennen

Ein technischer Befund kann beispielsweise lauten, dass der untersuchte Analysedatensatz aus einem dokumentierten Rohdatenexport durch drei nachvollziehbare Transformationsschritte erzeugt wurde oder dass die Herkunft eines Teils der Daten nicht mehr belegt werden kann.

16. Praktische Dokumentationsstruktur für einen Datenbestand

Für einen konkreten Untersuchungsgegenstand können beispielsweise folgende Angaben festgehalten werden:

• Bezeichnung des Datenbestands,
• Ursprungssystem und Datenquelle,
• Art und Zeitpunkt der Übernahme,
• Export- oder Abfragebedingungen,
• relevanter fachlicher Zeitraum,
• Format und Schema,
• Anzahl und Struktur der übernommenen Datenobjekte,
• gegebenenfalls Datei-Hashwerte einschließlich Hashverfahren,
• Transformationsschritte und erzeugte Zwischenstände,
• final verwendeter Analyse- oder Modelldatensatz,
• dokumentierte Unsicherheiten und Aussagegrenzen.

Weiterführende Beiträge

Wie allgemein festgelegt wird, welcher konkrete Daten- oder Versionsstand Gegenstand einer technischen Untersuchung ist, erläutert Welche technische Fragestellung kann ein IT-Sachverständiger tatsächlich beantworten? .

Wie unterschiedliche Quellen und Zeitbezüge bei einer technischen Rekonstruktion miteinander verbunden werden, zeigt IT-Projektverlauf rekonstruieren: Tickets, Git-Historie, E-Mails und Protokolle .

Wie konkrete Qualitätsdimensionen eines eindeutig bestimmten Datenbestands mit dokumentierten Prüfregeln und Metriken untersucht werden können, erläutert Datenqualität technisch prüfen: Vollständigkeit, Konsistenz, Genauigkeit und Aktualität .

Der allgemeine Quellen- und Dokumentationsstandard ist unter Quellen und Methodik beschrieben.

Daten und Data-Science-Systeme untersuchen

Wenn Datenherkunft, Datenstand, Datenaufbereitung, Reproduzierbarkeit oder die technische Grundlage einer datenbasierten Analyse untersucht werden sollen, können Untersuchungsgegenstand, Datenkette und vorhandene Nachweise zunächst fachlich eingegrenzt werden.

Data-Science-Gutachten ansehen