Mejores prácticas para crear "datos ordenados

Question

Hadley Wickham escribió un artículo estelar llamado "Tidy Data" ( enlace ) en JSS el año pasado sobre la manipulación de los datos y su puesta en condiciones "óptimas" para realizar el análisis. Sin embargo, me preguntaba cuáles eran las mejores prácticas en cuanto a la presentación de datos tabulares en un entorno de trabajo. Digamos que tu compañero de trabajo te pide que le proporciones algunos datos. ¿Cuáles son algunas de las reglas generales que utilizas al estructurar esos datos? ¿Son las directrices de "Tidy Data" igual de aplicables en los casos en los que compartes datos con personas que no son profesionales de los datos? Obviamente, esto es muy específico del contexto, pero estoy preguntando por las "mejores prácticas" de alto nivel.

Answer 1

Como cabe esperar de Hadley, su artículo contiene una buena definición de datos ordenados y estoy de acuerdo con casi todo lo que dice y creo que no sólo es válido para los "profesionales de los datos". Sin embargo, algunos de los puntos que expone son relativamente fáciles de solucionar (por ejemplo, con paquetes de su autoría) si se evitan algunos problemas más fundamentales. La mayoría de estos problemas son el resultado del uso generalizado de Excel. Excel es una herramienta valiosa y tiene sus méritos, pero algunas de sus facilidades dan lugar a problemas para los analistas de datos.

Algunos puntos (de mis experiencias):

1. A algunas personas les gustan las hojas de cálculo coloridas y hacen un uso abundante de las opciones de formato. Todo esto está muy bien, si les ayuda a organizar sus datos y a preparar las tablas para su presentación. Sin embargo, es peligroso si el color de una celda realmente codifica los datos. Es fácil perder estos datos y muy difícil conseguir que se importen a un software estadístico (por ejemplo, véase esta pregunta en Stack Overflow).
2. A veces recibo datos muy bien formateados (después de haberles dicho cómo prepararlos), pero a pesar de pedirles que utilicen una columna dedicada o un archivo separado para los comentarios, deciden poner un comentario en una columna de valores. No sólo tengo que tratar esta columna de forma especial al importar los datos, sino que el principal problema es que tendría que desplazarme por toda la tabla para ver dichos comentarios (algo que normalmente no haría). Esto se agrava aún más si se utilizan las funciones de comentario de Excel.
3. Las hojas de cálculo con varias tablas, múltiples líneas de encabezamiento o celdas conectadas suponen un trabajo manual para prepararlas para la importación en el software estadístico. Los buenos analistas de datos no suelen disfrutar de este tipo de trabajo manual.
4. Nunca, nunca ocultes las columnas en Excel. Si no son necesarias, elimínalas. Si son necesarias, muéstralas.
5. xls y sus descendientes no son formatos de archivo adecuados para intercambiar datos con otros o archivarlos. Las fórmulas se actualizan cuando se abre el archivo y las distintas versiones de Excel pueden tratar los archivos de forma diferente. En su lugar, recomiendo un simple archivo CSV, ya que casi todo el software relacionado con los datos puede importarlo (incluso Excel) y es de esperar que eso no cambie pronto. Sin embargo, ten en cuenta que Excel redondea a los dígitos visibles cuando se guarda en un CSV (descartando así la precisión).
6. Si quieres facilitarle la vida a los demás, sigue los principios indicados en el artículo de Hadley. Tenga una columna de valores para cada variable y columnas de factores que definan los estratos.

Probablemente hay varios puntos adicionales que no se me ocurrieron.

Answer 2

En primer lugar, suelo ser yo quien obtiene los datos. Así que esto puede leerse como mi lista de deseos.

• Por lo tanto, mi punto más importante es: hablar con el que va a analizar los datos.

• He echado un vistazo rápido al documento: mucho de lo que escribe Hadley podría resumirse en "normalice su base de datos relacional".

• Pero también menciona que, dependiendo de lo que ocurra en realidad, puede ser sensato tener la misma variable en forma larga o en forma ancha.

  He aquí un ejemplo: Yo me ocupo de los espectros. Desde un punto de vista físico/espectroscópico, el espectro es, por ejemplo, una intensidad $I$ en función de la longitud de onda $λ$ : I = f (λ). Por razones físicas, esta función es continua (y continuamente diferenciable). Una discretización a la particular $λ_i$ s se produce sólo por razones prácticas (por ejemplo, ordenadores digitales, instrumentos de medición). Esto apuntaría claramente a una forma larga. Sin embargo, mi instrumento mide los diferentes $λ_i$ en diferentes canales (de una línea o conjunto de detectores CCD). El análisis de datos también trata cada $λ_i$ como variante. Eso sería a favor de la forma amplia.

• Sin embargo, la presentación/distribución no normalizada de los datos tiene algunas ventajas prácticas:

  • Puede ser mucho más fácil comprobar que los datos son completa .

  • Las tablas conectadas, como en una base de datos relacional normalizada, están bien si los datos están realmente en una base de datos (en el sentido del software). Allí se pueden poner restricciones que garanticen la integridad. Si los datos se intercambian en forma de varias tablas, en la práctica los enlaces serán un lío.

  • La normalización de la base de datos elimina las redundancias. En la vida real del laboratorio, las redundancias se utilizan para comprobar la integridad.
    Por lo tanto, la información redundante no debe eliminarse demasiado pronto.

  • El tamaño de la memoria y del disco parece ser un problema menor hoy en día. Pero también aumenta la cantidad de datos que producen nuestros instrumentos.

    Estoy trabajando con un instrumento que puede producir fácilmente 250 GB de datos de alta calidad en pocas horas. Esos 250 GB están en un formato de matriz. La ampliación de estos datos a formato largo los multiplicaría por un factor de al menos 4: cada una de las dimensiones de la matriz (laterales x e y, y longitud de onda λ) se convertiría en una columna, más una columna para la intensidad). Además, mi primer paso durante el análisis de datos suele ser convertir los datos normalizados en forma larga en forma de espectro.

  • Por lo general, el análisis de datos necesitará un formulario particular. Por eso aconsejo hablar con quien vaya a analizar los datos.

• El trabajo de ordenación que abordan estos puntos de normalización es tedioso y no es un trabajo agradable. Sin embargo, en la práctica suelo dedicar mucho más tiempo a otros aspectos de la ordenación

  • Garantizar la integridad y la exhaustividad de los datos en la práctica es una parte importante de mi trabajo de ordenación de datos.

  • Los datos no están en un formato fácilmente legible / cambian entre formatos ligeramente diferentes:

    Recibo muchos datos en forma de muchos archivos, y normalmente alguna información se almacena en el nombre del archivo y/o en la ruta: el software del instrumento y/o los formatos de archivo producidos no permiten añadir información de forma consistente, así que o bien tenemos una tabla adicional (como en una base de datos relacional) que vincula la meta información a un nombre de archivo o el nombre del archivo codifica información importante.

    Los errores tipográficos o los pequeños cambios en el patrón de los nombres de los archivos causan muchos problemas aquí.

  • Ordenar desde el punto de vista de las mediciones: deshacerse de las mediciones falsas (normalmente causadas por procesos físicos conocidos como que alguien encienda accidentalmente la luz, que los rayos cósmicos golpeen el detector, que se produzcan desplazamientos de la cámara, ...).