Hay metodologías que envejecen mal y otras que resisten el paso del tiempo. El modelado dimensional de Ralph Kimball pertenece claramente al segundo grupo. Décadas después de proponerse, sigue siendo la base de prácticamente todos los data warehouses y modelos semánticos que funcionan bien, desde SQL Server hasta Microsoft Fabric. La razón es sencilla: alinea el modelo de datos con la forma en que piensa el negocio.
Quien trabaja con datos conoce el síntoma del modelo mal diseñado: informes lentos, métricas que no cuadran entre departamentos y cada pregunta nueva exigiendo horas de trabajo. Un buen modelo dimensional resuelve esto en el origen. Veamos cómo, en la práctica.
Hechos y dimensiones: la idea central
Todo el modelado dimensional se basa en una distinción sencilla. Los hechos representan eventos medibles del negocio, como una venta, un pedido o un pago. Las dimensiones representan el contexto de esos eventos, el quién, qué, cuándo y dónde. La tabla de hechos guarda los números (cantidad, importe); las dimensiones guardan los atributos por los que se filtra y agrupa (cliente, producto, fecha, tienda).
Esta separación no es burocracia técnica: es lo que permite que un usuario de negocio responda a "ventas por región y por mes" sin escribir una sola línea de código, arrastrando dimensiones y medidas de forma intuitiva.
La decisión más importante: la granularidad
Si una decisión define el éxito de un modelo, es esta: definir la granularidad de la tabla de hechos antes que cualquier otra cosa. La granularidad es el nivel de detalle de cada fila. ¿Una fila por venta? ¿Por línea de venta? ¿Por día y producto?
La regla de oro es elegir siempre el nivel más atómico disponible. Guardar al nivel de la línea de venta da flexibilidad para agregar de todas las formas posibles en el futuro. Elegir un nivel ya agregado ahorra espacio a corto plazo, pero tarde o temprano alguien pedirá un detalle que ya no existe, y la reconstrucción es cara y arriesgada.
Los ingredientes de un modelo sólido
Más allá de la granularidad, algunos patrones separan un modelo robusto de uno frágil:
- Claves surrogate: claves numéricas propias del warehouse, independientes de las claves de negocio, que hacen las uniones rápidas y resistentes a cambios en el origen.
- Dimensiones desnormalizadas: a diferencia del modelo transaccional, aquí compensa aplanar las dimensiones (el producto con su categoría y marca en la misma tabla), priorizando la simplicidad y el rendimiento de lectura.
- Una tabla de fechas completa: quizá la dimensión más subestimada. Tener una dimensión de calendario con año, trimestre, mes, día de la semana y festivos desbloquea todo el análisis temporal.
- Esquema en estrella: hechos en el centro, dimensiones alrededor. Simple de entender, rápido de consultar.
En la práctica: de lo transaccional a lo analítico
Imagine una base de datos de e-commerce, normalizada al detalle para soportar la aplicación: pedidos, líneas de pedido, productos, categorías, clientes, direcciones, todo en tablas separadas y unidas por claves. Es excelente para grabar datos y pésima para analizarlos.
Al transformarla en un modelo dimensional, esa maraña se colapsa en algo simple: una tabla de hechos "ventas" al nivel de la línea de pedido, y un puñado de dimensiones (cliente, producto, fecha, canal). De repente, una pregunta que exigía varias uniones y un analista se convierte en un informe que cualquier gestor construye en segundos.
Kimball en la era del lakehouse
Podría pensarse que, con Fabric, Databricks y los lakehouses, el modelado dimensional dejó de importar. Es lo contrario. Las herramientas cambiaron, con Delta Lake, Direct Lake y el procesamiento distribuido, pero la necesidad de un modelo que el negocio entienda permanece intacta. La capa Gold de una arquitectura Medallion es, típicamente, un modelo dimensional Kimball.
La lección que perdura es esta: la tecnología acelera, pero no sustituye un buen diseño. Invertir tiempo en el modelado sigue siendo lo que separa un warehouse que la gente usa y en el que confía de uno que nadie abre. Y en su proyecto: ¿la granularidad de la tabla de hechos fue una decisión pensada o sucedió por casualidad?
