Datos y Estructuras

En cualquier proyecto de datos, comprender los diferentes tipos de estructuras de datos es crucial para una gestión y análisis efectivos. Esta sección explora las tres categorías principales de estructuras de datos: estructurados, semiestructurados y no estructurados, y proporciona orientación sobre cómo manejarlos en un proyecto. Además, cubre las herramientas y tecnologías comúnmente utilizadas para trabajar con estos tipos de datos, como bases de datos relacionales, bases de datos NoSQL, archivos JSON y XML.

1. Tipos de Estructuras de Datos:

• Datos Estructurados: Datos organizados en un formato predefinido, generalmente almacenados en tablas con filas y columnas. Ejemplos incluyen bases de datos relacionales como MySQL o PostgreSQL.

• Datos Semiestructurados: Datos que no se ajustan a un esquema estricto pero tienen algunas propiedades organizativas, como etiquetas o marcadores. Ejemplos incluyen archivos JSON y XML.

• Datos No Estructurados: Datos que carecen de una estructura predefinida, lo que los hace más desafiantes de analizar. Ejemplos incluyen documentos de texto, imágenes, videos y publicaciones en redes sociales.

2. Herramientas y Tecnologías:

• Bases de Datos Relacionales: Ideales para datos estructurados, estas bases de datos utilizan SQL (Structured Query Language) para gestionar y consultar datos. Ejemplos incluyen MySQL, PostgreSQL y Oracle.

• Bases de Datos NoSQL: Diseñadas para datos semiestructurados y no estructurados, las bases de datos NoSQL (por ejemplo, MongoDB, Cassandra) ofrecen flexibilidad y escalabilidad para manejar diversos tipos de datos.

• JSON y XML: Formatos comunes para datos semiestructurados, frecuentemente utilizados en APIs web y archivos de configuración. JSON es ligero y fácil de analizar, mientras que XML es más detallado pero altamente estructurado.

3. Elección de la Estructura de Datos Adecuada:

La elección de la estructura de datos depende de la naturaleza del proyecto y del tipo de datos que se manejan. Por ejemplo:

• Usar bases de datos relacionales para datos estructurados con relaciones claras (por ejemplo, registros financieros).

• Usar bases de datos NoSQL para proyectos que requieren escalabilidad y flexibilidad (por ejemplo, análisis en tiempo real o aplicaciones de big data).

• Usar JSON o XML para el intercambio de datos entre sistemas o cuando se trabaja con APIs.

4. Desafíos y Mejores Prácticas:

Integración de Datos: Combinar datos de diferentes estructuras puede ser complejo. Herramientas como los pipelines ETL (Extract, Transform, Load) pueden ayudar.

Escalabilidad: Asegúrate de que la estructura de datos elegida pueda manejar el volumen y crecimiento de los datos.

Rendimiento: Optimiza el almacenamiento y la recuperación de datos para cumplir con los requisitos del proyecto.

5. Enfoque analítico

Comprender las estructuras de datos es esencial para diseñar pipelines de datos eficientes, garantizar la calidad de los datos y seleccionar las herramientas adecuadas para el análisis. Al elegir la estructura de datos apropiada, los equipos pueden mejorar el rendimiento, reducir costos y ofrecer insights más precisos.

Ordenamiento y documentación de datos

Cuando encaramos un proyecto con datos es muy útil tener una guía al menos mental de los pasos a seguir para tener los datos listos para ser procesados en pos de un objetivo. Es decir, que los datos deben ser preprocesados adecuadamente para que al procesarlos tengamos buenos resultados. Por esto existen metodologías para la gestión de proyectos de datos por ejemplo como la CRISP-DM-Standard.

Hacer un buen preprocesamiento implica un intenso trabajo de análisis de datos, estructura, metadatos, necesidades y por supuesto redundancia, errores y ruido o basura.

Si seguimos cualquier metodología para el análisis de datos, vemos que entre las etapas de comprensión de los datos, preprocesamiento y modelado es importante definir y/o disponer de tablas o archivos con datos bien estructurados. Esto implica una prolija organización de los metadatos. 

Tener una buena estructura en cada tabla o archivo con metadatos correctamente ordenados y normalizados es el punto de partida para la limpieza y depuración de los datos existente (si los hay) y para el procesamiento de los mimos. Y lo mismo es importante si en lugar de existir datos preexistentes, estamos definiiendo un modelo de datos desde cero.

Ejelmplo

Supongamos que tenemos que trabajar en la depuración de un sistema de gestión comercial. Tomemos, dentro de este caso, la base, tabla o archivo de clientes y pensemos:

• Cuáles son los atributos más importantes?

• Cuáles son los indispensables para la lógica del negocio?

• Cuáles son los atributos que pueden ser redudantes y generar ruido?

• Cuál debe ser el tipo y formato de cada uno de los datos?

• Que norma es conveniente que cada dato deba respetar?

• Que tan  bien esta documentada la estructura de datos y/o que tan bién la vamos a documentar?

Situacion actual de la estructura de datos

Observemos los primeros registros y hagámonos estas preguntas.

Pasemos ahora a ver la estructura utilizando para esto la ayuda del lenguale M en power query. La salida arroja lo que se observa en la figura 2. Observemos la salida y volvamos a hacernos el mismo tipo de peguntas que las mencionadas. Podemos ver por ejemplo que:

1. Por el nombre de los campos o columnas se puede deducir de que setrata cada campo. Pero en rigor esto no está documentado. Debería documentarse porque cuando los archivos son grandes en dimensiones y contenidos, la falta de documentación da lugar a malos entendidos muy frecuentemente.

2. Se utiliza definiciones de unicamente de dos tipos: texto y número. Pero no existe una definición del tipo de datos y su alcance y validación. Aquí es facil preguntarse por ejemplo que normalización tienen columnas como las de e-mail o la de zip_code. Pueden tener cualquier largo y formato?

3. Todos los campos pueden ser nulos. Cuesta creer que no existan datos faltantes con esta observación.

4. No se observan y por lo tanto no están claros los criterios de normalización y validación de los datos. El negativo que esto genera es enorme en términos de necesidades de limpieza y validez de los datos.

Situación deseada de la estructura de datos

La observación de la situación actual de los datos nos lleva a tener una visión de la situación deseada en el ordenamiento y la definición de los metadatos. Veamos entonces la figura 3, en dónde se propone una primera versión de la situación deseada. En correspondencia con los tres puntos mencionados anteriormente en la situación actual, ahora podemos observar que:

1. Ademas de los nombres de las columnas se ha agregado un campo de descripción en dónde cada campo de la tabla de clientes queda ahora debidamente documentado. Esto ademas de sumar claridad y evitar confusiones, contribuye a la reducción de dimensiones de archivos y bases de datos que con el tiempo suelen hacerse redundantes e innecesariamente grandes.

2. Se utilizan definiciones de dos tipos unicamente: texto y número. Sin embargo,  se agregan restricciones y condiciones de normalización. Por ejemplo el cambo str_num corresondiente al número de una dirección postal no puede ser mayor a 6 dígitos. El campo correspondiente al piso o puede ser superior a 3 dígitos.

3. En la situación actual, los 17 campos pueden ser nulos. En la situación deseada solo 5 de los 17 campos pueden ser nulos.

4. Se agregaron definiciones en dos columnas: una para la normalización y otra para la validación. 

El ordenamiento y las definiciones contenidas en la situación deseada, permite ahora sí hacer un trabajo prolijo de data cleansing.