Meilleures pratiques pour créer des «données bien rangées»

Hadley Wickham a écrit un article stellaire intitulé "Tidy Data" ( lien ) dans JSS l'année dernière sur la manipulation des données et la mise en état "optimal" des données afin d'effectuer une analyse. Cependant, je me demandais quelles étaient les meilleures pratiques en termes de présentation de données tabulaires dans un environnement de travail? Supposons que votre collègue vous demande de lui fournir des données. Quelles règles générales utilisez-vous lors de la structuration de ces données? Les directives de "Tidy Data" sont-elles tout aussi applicables dans les cas où vous partagez des données avec des non-professionnels de la données? Évidemment, c'est très spécifique au contexte mais je pose des questions sur les «meilleures pratiques» de haut niveau.

Comme on peut s'y attendre de Hadley, son article contient une bonne définition des données bien rangées et je suis d'accord avec presque tout dans son article et je crois que ce n'est pas seulement valable pour les "professionnels des données". Cependant, certains des points qu'il soulève sont relativement faciles à corriger (par exemple, avec les packages qu'il a créés) si certains problèmes plus fondamentaux sont évités. La plupart de ces problèmes sont le résultat de l'utilisation généralisée d'Excel. Excel est un outil précieux et a ses mérites, mais certaines de ses installations entraînent des problèmes pour les analystes de données.

Quelques points (de mes expériences):

1. Certaines personnes aiment les feuilles de calcul colorées et utilisent abondamment les options de formatage. C'est très bien, si cela les aide à organiser leurs données et à préparer des tableaux pour la présentation. Cependant, il est dangereux si une couleur de cellule code réellement les données. Il est facile de perdre ces données et très difficile d'obtenir ces données importées dans un logiciel statistique (par exemple, voir cette question sur Stack Overflow).
2. Parfois, j'obtiens des données bien formatées (après avoir dit aux gens comment les préparer), mais malgré leur avoir demandé d'utiliser une colonne dédiée ou un fichier séparé pour les commentaires, ils décident de mettre un commentaire dans une colonne de valeur. Non seulement dois-je traiter cette colonne d'une manière spéciale lors de l'importation des données, mais le problème principal est que je devrais faire défiler tout le tableau pour voir de tels commentaires (ce que je ne ferais généralement pas). Cela devient encore pire s'ils utilisent les fonctionnalités de commentaires d'Excel.
3. Les feuilles de calcul contenant plusieurs tableaux, plusieurs lignes d'en-tête ou cellules connectées entraînent un travail manuel pour les préparer à l'importation dans un logiciel statistique. Les bons analystes de données n'apprécient généralement pas ce type de travail manuel.
4. Ne masquez jamais les colonnes dans Excel. S'ils ne sont pas nécessaires, supprimez-les. S'ils sont nécessaires, montrez-les.
5. xls et ses descendants ne sont pas des formats de fichier appropriés pour échanger des données avec d'autres ou les archiver. Les formules sont mises à jour lorsque le fichier est ouvert et différentes versions d'Excel peuvent gérer les fichiers différemment. Je recommande plutôt un fichier CSV simple, car presque tous les logiciels liés aux données peuvent importer cela (même Excel) et on peut s'attendre à ce que cela ne change pas bientôt. Cependant, sachez qu'Excel arrondit aux chiffres visibles lors de l'enregistrement dans un fichier CSV (ce qui annule la précision).
6. Si vous voulez faciliter la vie des autres, respectez les principes énoncés dans l'article de Hadley. Avoir une colonne de valeurs pour chaque variable et colonnes factorielles définissant les strates.

Il y a probablement plusieurs points supplémentaires qui ne me sont pas venus à l'esprit.

Premièrement, je suis généralement celui qui obtient les données. Donc, cela peut se lire comme ma liste de souhaits.

• Mon point le plus important est donc: parler à celui qui va analyser les données.

• J'ai eu un bref aperçu du document: beaucoup de ce que Hadley écrit pourrait être résumé par «normaliser votre base de données relationnelles».

• Mais il mentionne également qu'en fonction de ce qui se passe réellement, il peut être judicieux d'avoir la même variable sous forme longue ou large.

  Voici un exemple: je traite des spectres. D'un point de vue physique / spectroscopique, le spectre est par exemple une intensité en fonction de la longueur d'onde : I = f (λ). Pour des raisons physiques, cette fonction est continue (et différenciable en continu). Une discrétisation à des particuliers se produit uniquement pour des raisons pratiques (par exemple, ordinateurs numériques, instruments de mesure). Cela indiquerait clairement une forme longue. Cependant, mon instrument mesure les différents dans différents canaux (d'une ligne ou d'un réseau CCD / détecteur). L'analyse des données traite également chaque comme une variable. Ce serait en faveur de la forme large.$I$$λ$$λ_i$$λ_i$$λ_i$

• Cependant, l'affichage / la distribution non normalisée des données présente certains avantages pratiques:

  • Il peut être beaucoup plus facile de vérifier que les données sont complètes .

  • Les tables connectées comme dans une base de données relationnelle normalisée sont OK si les données sont réellement dans une base de données (au sens logiciel). Là, vous pouvez mettre des contraintes qui garantissent l'exhaustivité. Si les données sont échangées sous forme de plusieurs tableaux, en pratique les liens seront un gâchis.

  • La normalisation de la base de données supprime les redondances. Dans la vraie vie de laboratoire, les redondances sont utilisées pour revérifier l'intégrité.
    Les informations redondantes ne doivent donc pas être supprimées trop tôt.

  • La taille de la mémoire / du disque semble être moins problématique de nos jours. Mais la quantité de données que nos instruments produisent augmente également.

    Je travaille avec un instrument qui peut facilement produire 250 Go de données de haute qualité en quelques heures. Ces 250 Go sont au format tableau. Le développer en forme longue le ferait exploser d'un facteur d'au moins 4: chacune des dimensions du réseau (x et y latéraux et longueur d'onde λ) deviendrait une colonne, plus une colonne pour l'intensité). De plus, ma première étape au cours de l'analyse des données serait généralement de reconstituer les données de forme longue normalisées sous forme spectrale.

  • Habituellement, l'analyse des données aura besoin d'un formulaire particulier. C'est pourquoi je conseille de parler à celui qui analysera les données.

• Le travail de rangement qui est adressé par ces points de normalisation est fastidieux et pas un bon travail. Cependant, dans la pratique, je passe généralement beaucoup plus de temps sur d'autres aspects du rangement

  • Assurer l'intégrité et l'exhaustivité des données dans la pratique est une grande partie de mon travail de rangement des données.

  • Les données ne sont pas dans un format facilement lisible / basculer entre des formats légèrement différents:

    Je reçois beaucoup de données sous la forme de nombreux fichiers, et généralement certaines informations sont stockées dans le nom et / ou le chemin du fichier: le logiciel de l'instrument et / ou les formats de fichiers produits ne permettent pas d'ajouter des informations de manière cohérente, nous soit avoir une table supplémentaire (comme dans une base de données relationnelle) qui relie les métadonnées à un nom de fichier ou le nom de fichier code des informations importantes.

    Les fautes de frappe ou de légères modifications dans le modèle des noms de fichiers causent beaucoup de problèmes ici.

  • Rangement du point de vue de la mesure: se débarrasser des fausses mesures (généralement causées par des processus physiques connus comme une personne qui allume accidentellement la lumière, des rayons cosmiques frappant le détecteur, des décalages de trame de la caméra, ...).