In diesem Post zählen wir uns die drei Prinzipien von Hadley Wickham an, um saubere Daten (tidy data) zu haben.
Jede Variable hat ihre eigene Spalte
Datenmanagement klingt erstmal langweilig. Wenn Studierende an Statistik denken, denken sie an Tests, Formeln, Outputs. Was sie selten erwarten: dass sie den Großteil ihrer Zeit damit verbringen werden, Daten überhaupt erst in eine Form zu bringen, in der man damit rechnen kann.
Hadley Wickham, einer der einflussreichsten Statistiker und Softwareentwickler unserer Zeit, hat in einem vielzitierten Paper festgehalten, was Praktikerinnen und Praktiker längst wissen: Rund 80% der Zeit in einer Datenanalyse entfällt auf das Bereinigen und Vorbereiten der Daten. Nicht auf die Analyse selbst. Nicht auf die Interpretation. Auf das Aufräumen.
Das Paper hat einen klaren Vorschlag, wie saubere Daten aussehen sollen – „Tidy Data“ – und es folgt drei Prinzipien. Das erste: Jede Variable hat ihre eigene Spalte.
Das klingt selbstverständlich. Ist es aber nicht.
Schau dir einen typischen Datensatz an, der Einkommensdaten nach Religionszugehörigkeit erfasst. Die Zeilen sind Religionen, die Spalten sind Einkommensgruppen: unter 10.000 Euro, 10.000–20.000, und so weiter. Optisch wirkt das ordentlich. Statistisch ist es ein Problem. Die Einkommensgruppen sind keine Spaltennamen – sie sind Werte. Sie gehören nicht in die Kopfzeile, sondern in eine eigene Spalte namens „Einkommen“. Solange das nicht so ist, kann keine Statistiksoftware der Welt damit vernünftig arbeiten.
Das ist Muster Nummer eins in Wickhams Katalog typischer Datenchaos-Probleme: Spaltennamen sind Werte, keine Variablen. Und es ist das häufigste Problem überhaupt – weil es fast immer aus demselben Grund entsteht. Die Tabelle wurde für Präsentation gebaut, nicht für Analyse. Sie sieht gut aus, wenn man sie anschaut. Aber sie versagt, sobald man sie in Software einliest.
Das zweite Muster ist noch subtiler: Mehrere Variablen stecken in einer einzigen Spalte. Der WHO-Tuberkulose-Datensatz ist ein gutes Beispiel. Dort gibt es Spalten wie „m1524“ – das steht für männlich, 15 bis 24 Jahre alt. Zwei Variablen, ein Spaltenname. Für Menschen lesbar, für Software unbrauchbar. Bevor man damit rechnen kann, muss man trennen: eine Spalte für Geschlecht, eine für Altersgruppe.
Was beide Muster verbindet: Sie verletzen dasselbe Prinzip. Eine Variable, eine Spalte. Sobald das nicht stimmt – egal ob weil Werte als Spaltennamen verkleidet sind, oder weil mehrere Variablen zusammengequetscht wurden – bricht die Analyse zusammen. Man bekommt entweder Fehlermeldungen, oder, was noch schlimmer ist, Ergebnisse, die falsch sind, ohne dass man es sofort merkt.
Oder wie ich immer sage: Die Ausführung von Tests ist selten ein Problem. Die kritischen Herausforderungen liegen fast immer im Datenmanagement. Und sie beginnen fast immer mit den Spalten.
Jede Beobachtung hat ihre eigene Zeile
Wenn das erste Prinzip von Tidy Data die Spalten betrifft, betrifft das zweite die Zeilen. Und es ist genauso oft verletzt – aus genauso nachvollziehbaren Gründen.
Das Prinzip lautet: Jede Beobachtung hat ihre eigene Zeile.
Eine Beobachtung ist dabei alles, was an einer Einheit zu einem bestimmten Zeitpunkt gemessen wurde. Wenn du eine Person an zehn verschiedenen Tagen befragst, hast du zehn Beobachtungen – nicht eine Person mit zehn Spalten. Wenn ein Song zehn Wochen lang in den Charts war, hat er zehn Chartpositionen – nicht eine Zeile mit zehn Spalten.
Genau das ist aber das klassische Problem im Billboard-Datensatz, den Wickham als Beispiel analysiert. Jeder Song hat dort eine Zeile. Die Chartpositionen in Woche 1, Woche 2, Woche 3 – bis Woche 75 – stehen in separaten Spalten: wk1, wk2, wk3, und so weiter. Das ist praktisch für die Dateneingabe. Es spart Platz. Jeder Song kommt nur einmal vor. Aber statistisch ist es ein Problem, weil jede Woche eine eigene Beobachtung ist und damit eine eigene Zeile braucht.
Warum ist das so wichtig? Weil Statistiksoftware mit Zeilen rechnet, nicht mit Spalten. Wenn du wissen willst, wie sich die durchschnittliche Chartposition über die Wochen verändert, brauchst du eine Spalte „Woche“ und eine Spalte „Position“ – und eine Zeile pro Song pro Woche. Mit dem Originalformat kommst du da nicht weit.
Das zugehörige Chaos-Muster ist das kompliziertest von allen: Variablen stecken sowohl in Zeilen als auch in Spalten. Wickham illustriert das mit einem Wetterdatensatz. Maximal- und Minimaltemperatur – eigentlich zwei Variablen, also zwei Spalten – stehen dort nicht nebeneinander, sondern untereinander. „tmax“ und „tmin“ sind Werte in einer Spalte namens „element“, die eigentlichen Temperaturzahlen stehen in einer anderen Spalte. Was eine Zeile pro Tag sein sollte, sind zwei Zeilen – eine für tmax, eine für tmin.
Um das zu bereinigen, braucht man zwei Schritte in entgegengesetzte Richtungen: zuerst melten, dann wieder zusammenführen. Am Ende steht eine Zeile pro Tag, mit je einer Spalte für Maximal- und Minimaltemperatur. Ordentlich – und analysierbar.
Was beide Fälle zeigen: Das Problem entsteht nicht aus Nachlässigkeit, sondern aus einem Zielkonflikt. Daten werden fast immer für einen bestimmten Zweck erhoben und gespeichert – für Dateneingabe, für Präsentation, für kompakte Speicherung. Dieser Zweck ist selten „statistische Analyse“. Das Ergebnis sind Strukturen, die gut aussehen, aber bei der Analyse versagen.
Das Bewusstsein dafür ist der erste Schritt. Die Frage „Ist das hier eine Beobachtung oder mehrere?“ ist einfach – aber sie wird erstaunlich selten gestellt.
Jeder Beobachtungstyp hat seine eigene Tabelle
Das dritte Prinzip von Tidy Data ist das abstrakteste – und das am häufigsten missverstandene. Es geht nicht um Spalten, nicht um Zeilen, sondern um die Frage: Was gehört überhaupt zusammen?
Das Prinzip lautet: Jeder Typ von Beobachtungseinheit hat seine eigene Tabelle.
Was ist eine Beobachtungseinheit? Ein Song. Eine Person. Ein Messtag. Eine Schule. Eine Beobachtungseinheit ist das „Ding“, über das man Informationen sammelt. Und das Problem entsteht, wenn man Informationen über verschiedene Dinge in dieselbe Tabelle packt.
Wieder das Billboard-Beispiel. Der Datensatz enthält zwei Arten von Information: Fakten über Songs – Titel, Interpret, Länge – und Fakten über ihre wöchentlichen Chartpositionen. Das sind zwei verschiedene Beobachtungseinheiten. Der Song als solcher, und der Song in einer bestimmten Woche. Mischt man das in einer Tabelle, wiederholt sich der Titel, der Interpret und die Länge für jede Woche, in der der Song in den Charts war. Das ist ineffizient. Schlimmer noch: Es kann zu Inkonsistenzen führen. Wenn der Interpret an einer Stelle korrigiert wird, aber nicht an einer anderen, hat man plötzlich widersprüchliche Daten.
Die Lösung ist Normalisierung: zwei verknüpfte Tabellen. Eine für Songs, eine für Chartpositionen. Verbunden über eine gemeinsame ID. Jede Information existiert nur einmal, an genau einer Stelle.
Das Gegenteil davon ist das fünfte und letzte Chaos-Muster in Wickhams Katalog: Eine Beobachtungseinheit ist über mehrere Tabellen verteilt. Jahresdaten, die für jedes Jahr in einer separaten Datei gespeichert sind. Jede Datei ist für sich ordentlich, aber zusammen sind sie kaum zu analysieren – vor allem dann, wenn die Dateien leicht unterschiedliche Strukturen haben, unterschiedliche Variablennamen oder unterschiedliche Konventionen für fehlende Werte.
Zu viel in einer Tabelle, oder zu wenig – beides verletzt dasselbe Prinzip. Die Frage ist immer dieselbe: Was ist hier eigentlich die Einheit, über die ich etwas aussagen will? Wenn die Antwort zwei verschiedene Dinge umfasst, braucht man zwei Tabellen. Wenn die Antwort über mehrere Dateien verteilt ist, muss man sie zusammenführen.
Das klingt nach Datenbankdesign – und das ist es auch. Wickham verweist ausdrücklich auf Codds relationale Algebra als Grundlage. Der Unterschied ist nur die Sprache: Was Datenbankentwickler als „dritte Normalform“ kennen, übersetzt Wickham in statistische Begriffe, die für Forscherinnen und Forscher zugänglicher sind.
Und das ist der eigentliche Wert der Tidy-Data-Prinzipien insgesamt. Nicht dass sie neu wären – die Ideen dahinter sind Jahrzehnte alt. Sondern dass sie einen Standard schaffen, der für alle gilt: für R-Nutzerinnen genauso wie für SPSS-Nutzer, für erfahrene Datenanalysten genauso wie für Studierende in ihrer ersten Abschlussarbeit. Wer die drei Prinzipien kennt, kann auf den ersten Blick erkennen, wenn etwas nicht stimmt – und weiß, wie er es beheben kann.
Die drei Prinzipien zusammengefasst
Saubere Daten folgen drei Prinzipien: Jede Variable hat ihre eigene Spalte, jede Beobachtung hat ihre eigene Zeile, und jeder Beobachtungstyp hat seine eigene Tabelle. Diese Regeln klingen simpel – werden aber in der Praxis ständig verletzt, weil Daten fast immer für Präsentation oder Dateneingabe gebaut werden, nicht für Analyse. Wer die drei Prinzipien verinnerlicht hat, spart sich nicht nur Fehlermeldungen und falsche Ergebnisse, sondern auch jenen frustrierenden Moment, in dem man merkt: Das Problem lag nicht in der Statistik, sondern im Datensatz.