Ein Change Log trennt Beobachtung und Entscheidung
Datenbereinigung ist kein unsichtbarer Vorbereitungsschritt. Korrekturen, Ausschlüsse, Umkodierungen, Dublettenbehandlung und der Umgang mit fehlenden Werten können Ergebnisse beeinflussen. Ein Change Log macht sichtbar, welcher Befund vorlag, welche Regel angewendet wurde und welche Wirkung entstand. Dadurch kann eine zweite Person die Verarbeitung prüfen, wiederholen oder fachlich kritisieren, ohne die Entscheidung aus einer fertigen Tabelle erraten zu müssen.
Das Log sollte während der Arbeit entstehen. Eine nachträgliche Zusammenfassung verliert leicht verworfene Regeln und überraschende Nebenwirkungen. Dabei muss nicht jede automatisch entfernte Leerzeile einen Roman erhalten. Gruppiere gleichartige, vorab definierte Operationen, aber dokumentiere Einzelentscheidungen dort, wo sie fachlich begründet oder potenziell ergebnisrelevant sind. Das angemessene Detail hängt von Datenart, Risiko und Methode ab.
Sieben Felder machen einen Schritt prüfbar
Beginne mit einer eindeutigen Kennung und Datum. Nenne dann Eingabedatei und Version, betroffene Variable oder Objektklasse sowie den erkannten Befund. Formuliere die Regel so, dass sie testbar ist: „Werte außerhalb 0–100 prüfen“ ist klarer als „Ausreißer korrigieren“. Die Entscheidung kann Beibehaltung, Kennzeichnung, Korrektur, Ausschluss oder Rückfrage lauten. Anschließend folgen Ausführung, Ergebnis und Kontrolle.
- Identität: Log-ID, Datum, Bearbeitende und Prüfer.
- Eingabe: Dateiname, Version und optional Prüfsumme.
- Befund: reproduzierbare Abfrage oder genaue Fundstelle.
- Regel: vorab definierter Test und fachliche Begründung.
- Aktion: Skript, Befehl oder kontrollierte manuelle Änderung.
- Wirkung: Zahl betroffener Fälle, Fallzahl davor/danach, neue Ausgabe.
- Kontrolle: automatischer Test, Sichtprüfung oder Vier-Augen-Freigabe.
Beispiel: Kategorien bereinigen, ohne Bedeutung zu erfinden
Angenommen, eine Exportdatei enthält in der Variable abschluss die Schreibweisen „Master“, „master “ und „MA“. Ein technischer Test findet 27 Werte außerhalb des vorab festgelegten Codebuchs. Die sichere Reaktion ist nicht, alle ähnlichen Zeichenketten automatisch gleichzusetzen. Zuerst prüfst du Erhebungsinstrument, Codebuch und bekannte Exportartefakte. Nur belegbare Entsprechungen werden einer Zielkategorie zugeordnet; unklare Werte bleiben markiert oder werden fachlich geklärt.
Der Logeintrag könnte lauten: „CL-014, Eingabe survey_interim_v03, Regel: Entferne äußere Leerzeichen und mappe ausschließlich die im Codebuch bestätigten Aliasse; Grund: technische Eingabevarianten ohne Bedeutungsunterschied. Aktion: Skript clean_categories.R, Tabelle alias_map_v02. Wirkung: 18 Leerzeichen korrigiert, 6 bestätigte Aliasse vereinheitlicht, 3 Werte als ungeklärt belassen; Fallzahl unverändert; Häufigkeitstabelle vor/nachher geprüft.“ So sind Befund, Grenze und Kontrolle sichtbar.
Manuelle Korrekturen brauchen eine engere Spur
Manche Fehler lassen sich nicht regelbasiert behandeln, etwa eine eindeutig falsch übertragene Zahl, die anhand eines autorisierten Erhebungsbogens korrigiert wird. Dokumentiere dann Fallkennung, Variable, alten Wert, neuen Wert, Beleg, Entscheidung und prüfende Person. Der Beleg bleibt in geschützter Ablage. Im Log stehen keine Klarnamen oder unnötigen vertraulichen Inhalte.
Direkte Zelländerungen sind riskant, weil sie schwer zu wiederholen sind. Nutze möglichst eine separate Korrekturtabelle, die ein Skript kontrolliert einliest. Diese Tabelle kann Fall-ID, Feld, Altwert, Neuwert, Grund und Freigabe enthalten. Das Verfahren erzeugt bei jedem Lauf dieselbe Änderung und kann testen, ob der erwartete Altwert noch vorliegt. Trifft er nicht zu, sollte der Prozess stoppen statt unbemerkt einen anderen Stand zu verändern.
Fehlende Werte, Dubletten und Ausreißer getrennt behandeln
Ein fehlender Wert kann Nichtbeantwortung, technische Störung, nicht anwendbare Frage oder echten Nullwert bedeuten. Bewahre diese Bedeutungen, wenn Methode und Erhebung sie unterscheiden. Bei Dubletten ist vorab zu definieren, ob gleiche Personen, Messungen oder Datensätze gemeint sind und welche Instanz Vorrang hat. Ein identischer Name ist kein ausreichender Dublettennachweis.
Ausreißer sind zunächst Befunde, keine Fehler. Dokumentiere Erkennungsverfahren und fachliche Prüfung. Ein plausibler Extremwert darf nicht automatisch entfernt werden. Wenn eine Analyse mit und ohne fragliche Fälle sinnvoll ist, halte beide Versionen und Ergebnisse getrennt. So wird eine Unsicherheit nicht durch stilles Löschen verdeckt.
Vom Log zur freigegebenen Datenversion
Nach der Bereinigung vergleichst du Fallzahlen, Variablentypen, Wertebereiche, Missing-Codes und Schlüsselverteilungen mit dem Eingang. Lass automatisierte Tests fehlschlagen, wenn unerwartete Abweichungen auftreten. Prüfe außerdem, ob jeder Logeintrag eine existierende Ausgabe und jeder Verarbeitungsschritt einen Logeintrag besitzt. Vergib erst danach eine Clean-Version und sichere sie gegen Überschreiben.
Wenn später ein Fehler entdeckt wird, bleibt die alte Version erhalten. Ein neuer Logeintrag beschreibt Korrektur, betroffene Analysen und erforderliche Neuberechnungen. Aktualisiere Tabellen oder Abbildungen nicht still. Der Zweck des Protokolls ist eine ehrliche, rekonstruierbare Entwicklung, nicht der Eindruck eines von Anfang an perfekten Datenbestands.
Qualitätscheck für das Protokoll
- Kann eine andere Person jede Regel als Abfrage oder Handlung ausführen?
- Ist erkennbar, welche Entscheidungen vor und welche nach Ergebnissicht entstanden?
- Sind Fallzahlen und Auswirkungen statt nur Tätigkeitswörter dokumentiert?
- Bleiben sensible Werte und Identitäten angemessen geschützt?
- Verweist die finale Analyse eindeutig auf Clean-Version, Log und Code?