Cuando se trata de proveer datos, se comienza la minuciosa tarea de diseñar la manera de hacerlo. El proveer datos no es solo tener una base de datos presentable y dejar al usuario que haga queries de unos datos que se supone ya están bien organizados; proveer datos incluye el entender la necesidad que los usuarios tienen de acceder a los datos y la manera en que lo van a hacer, mientras más fácil sea acceder, más difícil puede llegar a ser el proveerlos.
Uno de los pasos siguientes al procesamiento de los datos, es crear el modelo de datos. Es muy importante alinearse con el negocio y entender los diferentes casos de uso que se tendrán que resolver con datos, esto nos dará un panorama general de cómo debe ser construido el modelo y de las necesidades que debe cubrir.
Pero ¿qué es un modelo de datos? Para poderlo definir, explicaré primero algunos conceptos básicos dentro del ambiente de los datos que definitivamente ayudarán a entender la situación.
Conceptos base
Una arquitectura de datos, normalmente está dividida en dos componentes:
- OLTP (Online Transactional Processing): Soporta aplicaciones orientadas a transacciones. Está orientado al procesamiento de consultas y al mantenimiento de la integridad de los datos en ambientes de múltiple acceso…. En otras palabras, contiene la lógica del negocio representada en estructuras de datos y algoritmos eficientes.
- OLAP (Online Analytical Processing): Soporta el análisis de datos para la toma de decisiones de negocio. Permite a los usuarios analizar información proveniente de múltiples fuentes.
También es muy importante tener en cuenta lo siguiente:
- Data-lake: Es un repositorio centralizado que permite el almacenamiento de datos estructurados y no estructurados a escala (que pueden incrementar o decrementar).
- Data-Warehouse: Es una colección de datos que está separada de los sistemas operacionales y que soporta la toma de decisiones. Provee insights del negocio y contesta preguntas concretas del mismo.
Ahora que tenemos los conceptos base, hablemos del modelo de datos: el modelo dimensional.
El modelo dimensional es una técnica de estructura de datos optimizada para el almacenamiento de datos en un Data warehouse (almacén de datos). El propósito del modelo dimensional es optimizar las bases de datos para un rápido regreso de datos (consultas rápidas), este modelo fue desarrollado por Ralp Kimball y está compuesto por fact tables y dimensional tables.
Nota importante: el modelo dimensional está diseñado para leer, resumir y analizar información en un data warehouse, y los modelos relacionales normales son optimizados para las operaciones de inserción, borrado, actualización de datos (OLTP)
¿Que es un fact table?
Es la tabla primaria del modelo dimensional. Los facts son medidas/métricas del negocio. Por ejemplo en un negocio de ventas, un fact sería “numero de ventas”.
¿Que es una dimension table?
La dimensión provee el quién, qué, dónde de un fact. La dimensión está compuesta por atributos que describen una fact. Por ejemplo en un negocio de ventas:
Fact: número de ventas
Dimension:
- Quién: nombre del comprador/cliente.
- Dónde: ubicación de la tienda
- Qué: nombre del producto
- Atributos: Para la dimensión de ubicación de la tienda
- Ciudad
- Estado
- Pais
- CP
- Una dimension table se une a una fact table mediante una llave foránea
- Dimension tables son de-normalizadas
- Los atributos son las columnas de una dimension table
- No hay número límite de atributos por dimensión.
Pasos del modelo dimensional
- Identificar el negocio
- Identificar la granularidad (nivel de detalle)
- Identificar las dimensiones
- Identificar las facts
- Construir el esquema
1. Identificar el negocio
Debemos identificar el negocio y generar casos de uso. De acuerdo a las necesidades de análisis (de los analistas), podemos categorizar los procesos del negocio para resolver casos de uso particulares, por ejemplo casos de uso de marketing, de ventas, de recursos humanos, etc. Este paso es el más importante, pues de este depende todo el diseño del modelo.
2. Identificar la granularidad
La granularidad describe el nivel de detalle para el problema/solución del negocio. Es el proceso de identificar el nivel más bajo de información de todas las tablas en el data warehouse. Por ejemplo, si la tabla de ventas contiene la información de las ventas diarias, entonces la granularidad es “diario”.
Ejemplo de caso de uso: Se quiere un reporte de las ventas diarias de productos específicos en diferentes ubicaciones.
La granularidad entonces es: información de la venta del producto por ubicación por dia.
3. Identificar las dimensiones
La dimensión es donde todos los datos deben ser almacenados. Por ejemplo, la dimensión de tiempo puede contener atributos como día, mes, año.
Ejemplo de caso de uso: Se quiere un reporte de las ventas diarias de productos específicos en diferentes ubicaciones.
Dimensiones: Productos, ubicaciones, tiempo
Atributos: Para productos: producto_id (llave foránea), nombre, tipo, especificaciones
Para Ubicaciones: Pais, estado, ciudad, dirección
4. Identificar la fact
Este paso es co-asociado con identificar el negocio porque la fact table es el negocio que queremos describir. La mayoría de las fact tables son rows numéricos que describen diferentes métricas/medidas. Ejemplo: precio, precio unitario.
Ejemplo de caso de uso: Se quiere un reporte de las ventas diarias de productos específicos en diferentes ubicaciones.
La fact aquí es la suma de las ventas por producto por ubicación por día.
5. Construir el esquema
Aquí es donde se implementa el modelo dimensional (finalmente). El esquema es la estructura de la base de datos o arreglo de las tablas, y existen dos esquemas muy populares:
El esquema de estrella: Se caracteriza porque su diagrama parece una estrella, el centro es la fact table y los diferentes puntos de la estrella son las dimensiones.
El esquema snowflake (nada tiene que ver con el servicio en la nube snowflake): Este esquema es una extensión del esquema de estrella, la diferencia es que en este esquema las dimensiones están conectadas a otras dimensiones.
Entendiendo y siguiendo estos 5 pasos, podemos crear nuestro modelo dimensional, el cual además tiene los siguientes beneficios:
- Estandarización de dimensiones que permite hacer reportes fácilmente sobre diferentes áreas del negocio.
- Puedes introducir nuevas dimensiones sin descomponer la fact table.
- La información se organiza de una manera que es fácil acceder a los datos a través de consultas.
- Es un modelo fácil de entender.
- El modelo dimensional está optimizado para consultas rápidas.
- Las dimensiones pueden tener muchas columnas y podemos agregar más cada vez que se necesite.
Conclusion
El modelo dimensional suena complicado, sin embargo en esta entrada se proveen los conceptos básicos necesarios para entenderlo.
Identificar el negocio, identificar la granularidad, identificar las dimensiones, identificar las facts y crear el esquema, son los pasos a seguir para la implementación de un modelo dimensional exitoso.
Recordemos que tener una réplica de datos operacionales en un data warehouse nos servirá para enfocarnos en el análisis y resolver preguntas específicas del negocio.
De-todología 
Hola Teresita,
Veo que es interesante el tema de la ciencia de datos, yo vengo del modelo relacional y formas normales en bases de datos, creo que el modelo dimensional que describes tiene cierta similitud con las formas normales, de tu experiencia, ¿realmente hay similitud? ¿crees que hay ventajas o contras entre estos paradigmas?
Saludos
Me gustaMe gusta
Hola Silverio … perdona la demora en contestar.
Bueno, una de las principales diferencias es que el modelo relacional esta mas pensado para ser eficiente en tareas propias de la manipulación de datos: inserts, deletes y updates. Por otro lado el modelo dimensional esta mas pensado para ser eficiente a la hora de hacer queries, el performace al regresar la información es bastante bueno.
En general si, son muy parecidos ambos modelos pero cada uno esta hecho para ser mejor en diferentes cosas 😀
Saludos!!
Me gustaMe gusta