Dimensional Modeling (Modelado Dimensional)

Definición

El dimensional modeling es la disciplina de diseñar esquemas de bases de datos para uso analítico. A diferencia del modelado transaccional — que organiza los datos en tercera forma normal (3NF) para optimizar la escritura, la actualización y la integridad referencial en sistemas operacionales — el modelado dimensional organiza los datos para optimizar la lectura analítica: consultas que agregan métricas sobre grandes volúmenes de eventos y las segmentan por atributos descriptivos.

Los dos componentes fundamentales del modelado dimensional son las tablas de hechos y las tablas de dimensión. Las tablas de hechos registran eventos de negocio — cada fila es una ocurrencia: una transacción de venta, un pago procesado, una sesión de usuario, una llamada de soporte. Cada fila de la tabla de hechos contiene claves foráneas hacia las dimensiones y las métricas medibles del evento: el monto de la venta, la duración de la llamada, la cantidad de unidades vendidas. Las tablas de dimensión proveen el contexto descriptivo: quién realizó la compra, qué producto se vendió, dónde ocurrió, cuándo fue.

El principio fundamental de Ralph Kimball — el académico y consultor que formalizó la metodología en los años noventa — es que el modelo dimensional debe reflejar la forma en que los usuarios de negocio piensan sobre los datos, no la forma en que los datos están almacenados en los sistemas operacionales. Un analista financiero no piensa en tablas normalizadas en 3NF; piensa en "ventas por producto por mes por región". El modelado dimensional estructura los datos exactamente de esa forma, convirtiendo esa pregunta en un JOIN simple entre la tabla de hechos de ventas y las dimensiones de producto, fecha y geografía.

Cómo se implementa

La implementación de un modelo dimensional sigue cuatro decisiones de diseño que Kimball denominó el Bus Matrix o la matriz de dimensiones. El primer paso es identificar el proceso de negocio que se va a modelar: ventas, facturación, soporte, marketing o logística. Cada proceso de negocio produce una tabla de hechos. El segundo paso es definir el grano de esa tabla de hechos — el nivel de detalle de cada fila. El grano debe ser el más atómico posible: una fila por línea de orden, no una fila por orden agregada. La regla de Kimball es explícita: declarar el grano primero, nunca después.

El tercer paso es identificar las dimensiones — los objetos de negocio que proveen contexto al evento registrado en la tabla de hechos. El cuarto paso es definir los hechos — las métricas medibles en cada evento. Los hechos se clasifican en tres tipos: aditivos (pueden sumarse a través de todas las dimensiones, como el monto de venta), semiaditivos (pueden sumarse por algunas dimensiones pero no por otras, como el saldo de una cuenta que no tiene sentido sumar a través del tiempo) y no aditivos (ratios o porcentajes que nunca deben sumarse directamente).

En un stack moderno con dbt, la implementación típica sigue tres capas: la capa de staging (modelos que mapean las fuentes operacionales a un formato limpio y consistente, sin transformaciones de negocio), la capa intermedia o de transformación (modelos que aplican lógica de negocio, resuelven duplicados, calculan métricas derivadas) y la capa de marts (los modelos dimensionales finales — tablas de hechos y dimensiones — que se exponen a las herramientas de BI y a los usuarios finales). Las claves sustitutas (surrogate keys) reemplazan a las claves naturales de los sistemas fuente para aislar el modelo analítico de los cambios operacionales.

Ejemplo práctico

Considere una empresa de distribución mayorista con sede en Bogotá que vende materiales de construcción a ferreterías en Colombia y Venezuela. Su sistema ERP registra órdenes de venta, líneas de orden, facturas y pagos en tablas normalizadas en 3NF. El equipo de datos necesita responder preguntas como: ¿cuáles son los 10 productos con mayor margen bruto en el trimestre?, ¿qué representantes de ventas tienen el menor ratio de descuento promedio?, ¿qué ciudades tienen la mayor concentración de clientes con más de tres órdenes en los últimos 90 días?

Para responder esas preguntas con el esquema transaccional en 3NF, cada consulta requiere JOINs complejos a través de 8 a 12 tablas, con lógica condicional para manejar órdenes parcialmente facturadas, descuentos a nivel de línea versus a nivel de cabecera, y monedas mixtas (COP y USD). El tiempo de desarrollo de cada consulta ad hoc es de horas y el riesgo de errores lógicos es alto.

Con un modelo dimensional construido sobre esos mismos datos, la tabla fact_lineas_venta tiene una fila por cada línea de orden con las métricas ya calculadas: monto neto en COP, costo en COP, margen bruto, descuento aplicado. Las dimensiones de cliente, producto, representante de ventas, fecha y territorio están desnormalizadas. La primera pregunta — los 10 productos con mayor margen bruto — se convierte en un SELECT con GROUP BY producto_id, ORDER BY SUM(margen_bruto) DESC, LIMIT 10. Una consulta de tres líneas en lugar de un CTE anidado de veinte líneas.

Análisis en profundidad

El dimensional modeling sobrevivió la transición del data warehouse on-premise al cloud warehouse y luego al data lakehouse por una razón fundamental: el patrón de consulta analítica no ha cambiado. Los usuarios de negocio siempre han querido responder preguntas del tipo "¿cuánto X por Y durante Z?", donde X es una métrica, Y es un atributo descriptivo y Z es un período de tiempo. El star schema dimensional resuelve esa pregunta de forma natural con un JOIN entre la tabla de hechos y las dimensiones relevantes. La 3NF no.

Las dimensiones conformadas son el concepto más importante y más frecuentemente ignorado del modelado dimensional Kimball. Una dimensión conformada es una tabla de dimensión compartida por múltiples tablas de hechos. La dimensión de Fecha es el ejemplo más simple: todas las tablas de hechos del data warehouse se conectan a la misma tabla dim_fecha con los mismos atributos. Esto permite hacer consultas que cruzan procesos de negocio: ventas y costos en el mismo período, utilizando la misma definición de "Q3 2025" de la dimensión de fecha compartida. Sin dimensiones conformadas, cada data mart tiene su propia definición de fecha, cliente y producto, y los análisis cruzados requieren reconciliación manual costosa.

El manejo de Slowly Changing Dimensions (SCD) es uno de los problemas de diseño más frecuentes y mal resueltos en proyectos de modelado dimensional. Una SCD es una dimensión cuyos atributos cambian con el tiempo: un cliente puede cambiar de segmento, un representante puede moverse a otra región, un producto puede cambiar de categoría. La pregunta de diseño es: ¿se preserva el historial de esos cambios? SCD Tipo 1 sobreescribe el valor anterior — las consultas históricas reflejarán siempre el valor actual, perdiendo el estado en el momento del evento. SCD Tipo 2 inserta una nueva fila para cada cambio con fechas de vigencia — las consultas históricas pueden recuperar el estado del atributo en cualquier punto del tiempo. La elección entre SCD Tipo 1 y Tipo 2 tiene consecuencias directas en la exactitud del análisis histórico y debe documentarse explícitamente en el diseño de cada dimensión.

La Bus Matrix de Kimball — también conocida como Enterprise Data Warehouse Bus Architecture — es el artefacto de diseño que garantiza la coherencia de un modelo dimensional a escala de empresa. La Bus Matrix es una tabla donde las filas son los procesos de negocio (ventas, soporte, facturación, logística) y las columnas son las dimensiones del modelo. Cada celda indica si esa dimensión es aplicable a ese proceso de negocio. Las dimensiones que aparecen en múltiples filas son candidatas a ser dimensiones conformadas. La Bus Matrix permite al equipo de datos visualizar el alcance del modelo, identificar oportunidades de conformación y planificar el orden de implementación de los data marts de forma que las dimensiones compartidas se construyan primero.

En el contexto de equipos de datos en LATAM que trabajan con stacks modernos — Fivetran o Airbyte para extracción, Snowflake o BigQuery como warehouse, dbt para transformación, Looker o Metabase para visualización — el dimensional modeling de Kimball sigue siendo la metodología de referencia, pero con adaptaciones pragmáticas. La mayoría de los equipos modernos no siguen el proceso Kimball al pie de la letra; toman los principios fundamentales (hechos y dimensiones, conformación, grano explícito, claves sustitutas, SCD Tipo 2 para atributos históricos) y los aplican con las herramientas de su stack. El archivo schema.yml de dbt actúa como el documento de diseño del modelo dimensional, los modelos de staging como la capa de limpieza de datos operacionales, y los modelos de marts como las tablas de hechos y dimensiones finales.

Errores frecuentes

• ✗

  Mezclar granos en la misma tabla de hechos. El error de diseño más frecuente y más costoso en modelado dimensional es almacenar en la misma tabla de hechos eventos de granularidad diferente — por ejemplo, mezclar líneas de orden individuales con totales de orden por cabecera. Cuando se agrega una métrica de esa tabla, el resultado es una mezcla de niveles de agregación que produce números incorrectos de forma silenciosa. Kimball es explícito: una tabla de hechos debe tener un único grano declarado. Si se necesitan dos granos, se crean dos tablas de hechos separadas.

• ✗

  Exponer el modelo de datos transaccional directamente a las herramientas de BI. Un patrón común en equipos sin práctica de modelado dimensional es conectar Metabase, Tableau o Power BI directamente al esquema operacional en 3NF del ERP o CRM, sin una capa de transformación dimensional intermedia. El resultado es que cada analista construye su propia lógica de JOIN ad hoc, las métricas se calculan de forma diferente en cada dashboard, y los números entre reportes nunca coinciden. La capa dimensional existe precisamente para centralizar esa lógica y garantizar una única definición de cada métrica.

• ✗

  No declarar ni documentar el manejo de SCD para cada dimensión. Los equipos que no piensan explícitamente en Slowly Changing Dimensions terminan con modelos donde los atributos de dimensión se sobreescriben silenciosamente (SCD Tipo 1 por omisión) sin que el equipo sea consciente de esa decisión. Cuando seis meses después alguien intenta analizar el rendimiento de ventas por segmento de cliente para el primer trimestre del año, todos los clientes ya muestran su segmento actual, no el que tenían en Q1. El análisis histórico queda irrecuperable. La decisión de SCD debe documentarse en el diseño de cada dimensión desde el inicio del proyecto.

Cómo lo rastrea Fairview

Fairview construye internamente un modelo dimensional sobre los datos operativos del negocio — CRM, ERP, plataformas de facturación, herramientas de ventas y soporte — sin requerir que el equipo diseñe o mantenga el modelo de datos por su cuenta. La plataforma abstrae la complejidad del modelado dimensional: define automáticamente el grano de cada tabla de hechos (una fila por transacción, por contacto, por ticket de soporte), construye las dimensiones conformadas de fecha, cliente, producto y canal, y aplica SCD Tipo 2 para los atributos donde el historial importa para el análisis de negocio.

Para los equipos que ya tienen un modelo dimensional propio en BigQuery, Snowflake o Redshift, Fairview puede conectarse a esa capa de marts y construir sobre ella las métricas de operating intelligence sin necesidad de duplicar el trabajo de modelado. El Operating Dashboard de Fairview consume directamente tablas de hechos y dimensiones estándar, y el equipo de implementación asiste en el mapeo de las tablas existentes del cliente al modelo de Fairview cuando los nombres de columnas o la estructura de granos difieren de los estándares de la plataforma.

Preguntas frecuentes