Best Practices zum Erstellen von "ordentlichen Daten"

Hadley Wickham schrieb im vergangenen Jahr in JSS einen herausragenden Artikel mit dem Titel "Tidy Data" ( Link ) über Datenmanipulation und das Versetzen der Daten in einen "optimalen" Zustand, um eine Analyse durchzuführen. Ich habe mich jedoch gefragt, welche Best Practices für die Darstellung von Tabellendaten in einer Arbeitsumgebung gelten. Angenommen, Ihr Mitarbeiter bittet Sie, ihm einige Daten zur Verfügung zu stellen. Welche allgemeinen Regeln verwenden Sie bei der Strukturierung dieser Daten? Sind die Richtlinien in "Ordentliche Daten" genauso anwendbar, wenn Sie Daten mit Nicht-Datenprofis teilen? Dies ist natürlich sehr kontextspezifisch, aber ich frage nach Best Practices auf hoher Ebene.

Wie von Hadley zu erwarten ist, enthält sein Artikel eine gute Definition für ordentliche Daten, und ich stimme fast allem in seinem Artikel zu und glaube, dass dies nicht nur für "Datenprofis" gilt. Einige der von ihm angesprochenen Punkte sind jedoch relativ einfach zu beheben (z. B. bei von ihm verfassten Paketen), wenn einige grundlegendere Probleme vermieden werden. Die meisten dieser Probleme sind auf die weit verbreitete Verwendung von Excel zurückzuführen. Excel ist ein wertvolles Werkzeug und hat seine Vorzüge, aber einige seiner Funktionen führen zu Problemen für Datenanalysten.

Einige Punkte (aus meinen Erfahrungen):

1. Einige Leute mögen bunte Tabellenkalkulationen und nutzen häufig Formatierungsoptionen. Dies ist alles in Ordnung, wenn es ihnen hilft, ihre Daten zu organisieren und Tabellen für die Präsentation vorzubereiten. Es ist jedoch gefährlich, wenn eine Zellenfarbe tatsächlich Daten codiert. Es ist leicht, diese Daten zu verlieren und sehr schwierig, solche Daten in statistische Software zu importieren (siehe z. B. diese Frage zum Stapelüberlauf).
2. Manchmal erhalte ich einige gut formatierte Daten (nachdem ich den Leuten gesagt habe, wie sie vorbereitet werden sollen), aber obwohl sie gebeten werden, eine dedizierte Spalte oder eine separate Datei für Kommentare zu verwenden, entscheiden sie sich, einen Kommentar in eine Wertespalte einzufügen. Ich muss mich beim Importieren der Daten nicht nur auf besondere Weise mit dieser Spalte befassen, sondern das Hauptproblem besteht auch darin, dass ich durch die gesamte Tabelle scrollen muss, um solche Kommentare zu sehen (was ich normalerweise nicht tun würde). Dies wird noch schlimmer, wenn sie die Kommentarfunktionen von Excel verwenden.
3. Tabellenkalkulationen mit mehreren Tabellen, mehreren Kopfzeilen oder verbundenen Zellen führen zu manueller Arbeit, um sie für den Import in statistische Software vorzubereiten. Gute Datenanalysten genießen diese Art der manuellen Arbeit normalerweise nicht.
4. Verstecken Sie niemals Spalten in Excel. Wenn sie nicht benötigt werden, löschen Sie sie. Wenn sie gebraucht werden, zeigen Sie sie.
5. xls und seine Nachkommen sind keine geeigneten Dateiformate, um Daten mit anderen auszutauschen oder zu archivieren. Formeln werden aktualisiert, wenn die Datei geöffnet wird und verschiedene Excel-Versionen die Dateien möglicherweise unterschiedlich behandeln. Ich empfehle stattdessen eine einfache CSV-Datei, da fast jede datenbezogene Software diese importieren kann (sogar Excel) und zu erwarten ist, dass sich dies nicht bald ändern wird. Beachten Sie jedoch, dass Excel beim Speichern in einer CSV auf sichtbare Ziffern rundet (wodurch die Genauigkeit verworfen wird).
6. Wenn Sie anderen das Leben leichter machen möchten, halten Sie sich an die Grundsätze in Hadleys Artikel. Haben Sie eine Wertespalte für jede Variablen- und Faktorspalte, die Schichten definiert.

Es gibt wahrscheinlich einige zusätzliche Punkte, die mir nicht in den Sinn gekommen sind.

Erstens bin ich normalerweise derjenige, der die Daten erhält. Das kann also als meine Wunschliste gelesen werden.

• Mein wichtigster Punkt ist daher: Sprechen Sie mit demjenigen, der die Daten analysieren wird.

• Ich hatte einen kurzen Blick auf das Papier: Vieles, was Hadley schreibt, könnte durch "Normalisieren Ihrer relationalen Datenbank" zusammengefasst werden.

• Er erwähnt aber auch, dass es je nachdem, was tatsächlich vor sich geht, sinnvoll sein kann, dieselbe Variable entweder in langer oder in breiter Form zu haben.

  Hier ein Beispiel: Ich beschäftige mich mit Spektren. Aus physikalisch / spektroskopischer Sicht ist das Spektrum zB eine Intensität$I$ als Funktion der Wellenlänge $λ$: I = f (λ). Aus physikalischen Gründen ist diese Funktion kontinuierlich (und kontinuierlich differenzierbar). Eine Diskretisierung zu bestimmten$λ_i$s tritt nur aus praktischen Gründen auf (z. B. digitale Computer, Messinstrumente). Dies würde eindeutig auf eine lange Form hinweisen. Mein Instrument misst jedoch den Unterschied$λ_i$in verschiedenen Kanälen (einer CCD / Detektorleitung oder eines Arrays). Die Datenanalyse behandelt auch jeden$λ_i$als Variate. Das wäre zugunsten der breiten Form.

• Die nicht normalisierte Anzeige / Verteilung der Daten bietet jedoch einige praktische Vorteile:

  • Es kann viel einfacher sein, die Vollständigkeit der Daten zu überprüfen .

  • Verbundene Tabellen wie in einer normalisierten relationalen Datenbank sind in Ordnung, wenn sich die Daten tatsächlich in einer Datenbank befinden (im Sinne der Software). Dort können Sie Einschränkungen festlegen, die die Vollständigkeit gewährleisten. Wenn die Daten in Form mehrerer Tabellen ausgetauscht werden, sind die Links in der Praxis ein Chaos.

  • Durch die Datenbanknormalisierung werden Redundanzen beseitigt. Im realen Laborleben werden Redundanzen verwendet, um die Integrität zu überprüfen.
    Redundante Informationen sollten daher nicht zu früh entfernt werden.

  • Die Speicher- / Festplattengröße scheint heutzutage weniger problematisch zu sein. Aber auch die Datenmenge, die unsere Instrumente produzieren, nimmt zu.

    Ich arbeite mit einem Instrument, mit dem innerhalb weniger Stunden problemlos 250 GB qualitativ hochwertige Daten erzeugt werden können. Diese 250 GB sind in einem Array-Format. Wenn Sie diese Form auf eine lange Form erweitern, wird sie um einen Faktor von mindestens 4 vergrößert: Jede der Array-Dimensionen (laterales x und y und Wellenlänge λ) wird zu einer Spalte plus einer Spalte für die Intensität. Außerdem besteht mein erster Schritt während der Datenanalyse normalerweise darin, die normalisierten Langformdaten wieder in spektrenweite Form umzuwandeln.

  • Normalerweise benötigt die Datenanalyse ein bestimmtes Formular. Aus diesem Grund empfehle ich, mit demjenigen zu sprechen, der die Daten analysiert.

• Die Aufräumarbeiten, die in diesen Normalisierungspunkten behandelt werden, sind mühsam und keine gute Arbeit. In der Praxis verbringe ich jedoch normalerweise viel mehr Zeit mit anderen Aspekten des Aufräumens

  • Die Gewährleistung der Integrität und Vollständigkeit der Daten in der Praxis ist ein großer Teil meiner Arbeit beim Aufräumen von Daten.

  • Daten liegen nicht in einem leicht lesbaren Format vor / wechseln zwischen leicht unterschiedlichen Formaten:

    Ich erhalte viele Daten in Form vieler Dateien, und normalerweise werden einige Informationen im Dateinamen und / oder Pfad gespeichert: Die Instrumentensoftware und / oder die erstellten Dateiformate erlauben es nicht, Informationen auf konsistente Weise hinzuzufügen Entweder haben Sie eine zusätzliche Tabelle (wie in einer relationalen Datenbank), die die Metainformationen mit einem Dateinamen verknüpft, oder der Dateiname codiert wichtige Informationen.

    Tippfehler oder geringfügige Änderungen im Muster der Dateinamen verursachen hier viele Probleme.

  • Aufräumen aus Sicht der Messung: Beseitigung falscher Messungen (normalerweise verursacht durch bekannte physikalische Prozesse wie jemanden, der versehentlich das Licht einschaltet, kosmische Strahlen, die auf den Detektor treffen, Bildverschiebungen der Kamera, ...).