Tipología práctica de los datos: lo que debes entender antes de modelar

¿Qué es el modelado de datos?

El modelado de datos es el proceso de creación de una representación gráfica que representa visualmente cómo se organizan y estructuran los datos. Cuando estás en Power BI, por ejemplo, es cuando acudes a diseñar las relaciones entre tus hechos y dimensiones antes de comenzar el análisis y su representación visual.

Es lo mismo que un plano o un mapa. Tienes, por un lado, la representación esquemática de los datos, que son los recuadros donde ves el nombre de la tabla y sus atributos (campos o columnas). Y luego las líneas que representan las relaciones, determinadas por los extremos que unen los datos y la forma en que se unen (uno a uno, uno a muchos, muchos a muchos).

En un momento dado, puede haber electricistas, carpinteros y fontaneros utilizando ese plano. El administrador de base de datos estará usando esa misma estructura, dibujada en SQL Server Management Studio y el desarrollador la tendrá disponible en las especificaciones del proyecto para tenerla en cuenta.

Cada uno de estos perfiles profesionales, al relacionarse con los datos, tiene una relación diferente y una necesidad específica, pero todos lo necesitan para comprender la estructura general de la casa, de los datos, para poder desarrollar su labor. El desarrollador para poner a disposición de los usuarios una aplicación que les permita interactuar con los datos, preservando su integridad y su estructura. El administrador del servidor SQL para elaborar informes a demanda. Y el analista para crear sus cuadros de mando.

Los distintos perfiles tienen necesidades de datos diferentes, pero el modelo de datos les permite comprender la estructura en su conjunto.

Niveles del modelado de datos

Existen varios niveles en el modelado de datos que pueden variar, según el autor, en un mayor o menor número de capas, pero que suelen reducirse a los siguientes:

Modelo conceptual de datos:
Es una visión de alto nivel de la estructura de datos, por ejemplo, cómo representan y registran los datos (hechos y dimensiones) los procesos en una organización. Este nivel no contiene detalles técnicos y está fundamentado en las necesidades.
Modelo lógico de datos:
Se centra en detalles técnicos como las relaciones entre cada conjunto (a los que empezamos a llamar índices), los atributos (a los que empezamos a llamar campos o columnas) y las entidades (tablas). En este nivel también podemos hablar de los procesos CRUD (create, read, update, delete), de los condicionantes para que estos se den y de cualquier otra cosa que pueda suceder alrededor de los datos.
Modelo físico de datos:
Describe cómo funciona una base de datos. Aquí ya empezamos a determinar qué herramienta de gestión se usará para operar con los datos y ejecutar esos procesos definidos en el modelo lógico. Se determina el naming en la base de datos: tablas, relaciones y campos son etiquetados de una manera específica y estandarizada en el proyecto en cuestión. También se definen detalles como la tipología de los datos, los límites de los valores, la gestión de los valores inexistentes, el tratamiento de los errores, si se ubicarán en la nube o en un servidor propio, los backups y un largo etcétera.

Técnicas de diseño de modelos de datos

Los dos métodos comunes son el Diagrama de Relación de Entidades (ERD) y el diagrama de Lenguaje Unificado de Modelado (UML).

Los ERD son una forma visual de entender la relación entre entidades en el Modelo de datos. Estos diagramas pueden ser tan simples como los ya mencionados, diseñados en Power BI o en tu Management Studio, hasta diseños más complejos que son necesarios interpretar a través de la lectura de lo que significa cada elemento del diagrama.
Los diagramas UML son diagramas muy detallados que describen la estructura de un sistema mostrando las entidades del sistema, los atributos, las operaciones y sus relaciones. Igualmente pueden ir desde un simple listado de instrucciones CREATE de Transact-SQL hasta un documento de estandarización detallado previo a la ejecución de un proyecto concreto.

Como analista de datos, en cualquier caso, debes entender que antes de que los datos existan, alguien ha diseñado su estructura y sus relaciones (los ha modelado). Y que, en consecuencia, ese mismo modelado limita la información disponible y su interpretación.

El modelado físico va a determinar tus procesos de extracción.
El modelado lógico va a determinar tus procesos de transformación.
Y el modelado conceptual va a determinar tus procesos analíticos.

Son como fronteras invisibles que existen antes de que tú comiences tu proyecto de análisis y representación de los datos, que en muchas ocasiones no percibes, pero que son infranqueables.

Por ejemplo, una base de datos que trunque totales facturados a 2 decimales (nivel físico) estará arrastrando un error de cálculo en los acumulados que se trasladará en una diferencia notable a lo largo del tiempo.

Sin embargo, debes asumir esa desviación acumulada en tu análisis porque es (casi) imposible volver atrás, a no ser que puedas recuperar el paso previo (nivel lógico) al cálculo de esos totales (recuperando unidades y precios originales), en cuyo caso, de existir, podrás rehacer los cálculos y mantener un mayor número de decimales.

En cualquier caso, será algo preocupante si se decide, en el contexto en el que se desarrolla el proyecto de análisis, si esa desviación en los cálculos será relevante o no (modelado conceptual).

Análisis del modelado de datos

El modelado de datos puede ayudarte a explorar los detalles de alto nivel de los datos de tu proyecto y cómo se relacionan a través de los sistemas de información de la organización, al mismo tiempo que te ayuda a entender la relación de las partes interesadas (los stakeholders) con los mismos.

El modelado de datos requiere un análisis de cómo existen los datos antes de ser exprimidos, para comprender su composición los datos.

Este mapa que vas a tener que reconstruir desarrollando el proceso inverso (analizar el modelo físico, entender el modelo lógico y comprender los porqués del modelo conceptual) te ayudará a poner límites reales a lo que puedes hacer y no puedes hacer.

Las métricas que vas a poder abordar y las que no.

Además es un excelente punto de partida para que todas las personas de la organización comprendan lo que estás haciendo, por qué lo estás haciendo de una manera u otra y por qué los resultados están limitados de esta o aquella forma

Para saber más:
https://dataedo.com/blog/basic-data-modeling-techniques

Formato ancho vs. formato largo

Los datos en formato ancho y formato largo son dos formas de comprimir y estructurar datos a la hora de analizarlos y vienen marcadas por ese modelo previo que ya existe.

Si bien no son las únicas maneras de estructurarlos si son las más comunes en las que se organizan los datos.

Entender el formato de los datos que llegan a tus manos es vital para poder determinar las herramientas que vas a utilizar para su análisis y el alcance del mismo.

La diferencia principal radica en cómo se distribuyen las variables (atributos, campos) y observaciones (registros) en las filas y columnas.

Es muy habitual que como analista de datos no tengas acceso a la base de datos fuente sino que lleguen a ti en forma de consulta hecha en específico para cubrir tus necesidades.

En ocasiones tú puedes definir esa query para que los datos sean extraídos y aquí es donde tomas la decisión en si quieres datos en formato ancho o en formato largo.

La elección entre formato ancho o largo depende del propósito del análisis.

Si se busca rapidez y una posible interpretación directa, necesitas el formato ancho.
Si se busca la mayor flexibilidad posible para cálculos o visualizaciones, necesitas el formato largo.

Muchas herramientas permiten transformar entre ambos formatos. Por ejemplo, en Excel puedes crear tablas dinámicas o matrices a partir de tablas de datos previas. Pero esto será posible siempre que conserves los datos fuente o de origen.

1. Formato Ancho

Estructura:
- Cada fila representa una entidad o una unidad de análisis, un hecho único.
- Cada columna representa diferentes variables, mediciones o atributos.
- Diferentes columnas pueden representar diferentes categorías de un mismo atributo.
Características:
- Facilita la comparación entre categorías o momentos.
- Suelen ser tablas pequeñas y resumidas, como las tablas dinámicas en Excel o Google SpreadSheet.
Ventajas:
- Visualmente compacta, adecuado para informes (de hecho, hay dos objetos visual en Power BI, por ejemplo, para representarlas en un dashboard).
- Utilizables para cálculos simples, rápidos y comparaciones directas, especialmente cuando queremos manejar frecuencias relativas (%).
Desventajas:
- Imposibilita, casi siempre, el análisis avanzado o el recálculo o reestructuración de los datos. Ganas rapidez, pierdes flexibilidad.

Cuando trabajas con datos de formato ancho sueles trabajar con tablas pequeñas (casi siempre tablas totalizadoras o tablas resumen). Pesan poco y no lastran las herramientas. Y el trabajo viene prácticamente dado.

Debes confiar en que el origen de esos datos de formato ancho hayan garantizado la generación de la tabla en cuanto a su integridad, veracidad y confiabilidad.

Aquí es donde, por ejemplo, sueles encontrar lastres como la pérdida de decimales, la pérdida de categorías originales, la pérdida de puntos en una serie temporal, entre otras circunstancias limitantes.

2. Formato Largo

Estructura:
- Cada fila representa una única observación o medición o hecho en un momento específico por lo que pueden encontrarse 1 o más filas relacionadas entre sí, por ejemplo, las compras de un cliente estarán vinculadas por el dato representativo de ese cliente.
- Las columnas indican las variables esenciales, como la identidad de la entidad, la categoría o el tiempo y el valor medido. Nunca se separan las categorías (valores posibles de un atributo) en diferentes columnas.
Características:
- Facilita la manipulación de datos en análisis así como expandir todas las posibilidades de los datos, sobre todo cuando es un dato fuente (el que puedes encontrar en origen y no ha sido pre-procesado antes de llegar a tus manos).
- Generalmente requieren de herramientas de tratamiento más potentes que una hoja de cálculo.
Ventajas:
- Compatible con herramientas de análisis de datos como la librería pandas en Python, tidyverse en R, Tableu o Power BI.
- Necesario para transformaciones que requieran agrupaciones, agregación, transformaciones o cálculos estadísticos.
Desventajas:
- Lo habitual es que están almacenados en formatos extensos, de gran peso y difícil tratamiento a nivel físico. Suelen requerir ordenadores de mayor potencia que tu pequeño y escueto portácil o tablet.
- Resulta casi imposible hacer una interpretación directa de los datos.

Diferencias clave desde la perspectiva del Análisis de Datos

Aspecto	Formato Ancho	Formato Largo
Flexibilidad	Uso limitado a los datos disponibles pre-procesados.	Uso flexible y versátil que se expande al nivel de los datos de origen.
Compatibilidad	Adecuado para informes básicos y herramientas sencillas como hojas de cálculo.	Adecuado para análisis estadístico y gráficos con herramientas como SPSS o Power BI.
Estructura de datos	Más columnas. Menos filas. Categorías convertidas en columnas.	Más filas. Menos columnas. Categorías agrupadas por columna.
Uso típico	Directo. Informes ejecutivos. Cuadros simples.	Requiere analítica. Informes en profundidad. Cuadros complejos.
Transformación	Puede requerir realizar procesos inversos o bien solicitar nuevas tablas de datos.	Pueden generarse nuevas tablas de formato ancho a partir de las de formato largo.

(De mis apuntes del curso de Google: Data Analytics.)