Tabla de Dimensión (Dimension Table)

Definición

Una tabla de dimensión provee el contexto descriptivo de los eventos registrados en la tabla de hechos. Si la tabla de hechos responde a la pregunta "cuánto ocurrió", la tabla de dimensión responde "quién lo hizo, qué fue, dónde ocurrió, cuándo sucedió y bajo qué circunstancias". Dimensiones típicas incluyen Cliente, Producto, Tiempo, Geografía, Canal, Empleado y Campaña. Cada dimensión contiene tantos atributos descriptivos como sean útiles para el análisis: la dimensión de cliente puede incluir nombre, segmento de mercado, industria, tamaño de empresa, canal de adquisición, región, país y decena de otros atributos relevantes.

La forma de una tabla de dimensión contrasta deliberadamente con la de una tabla de hechos. Una tabla de hechos es alta y estrecha: millones de filas con pocas columnas. Una tabla de dimensión es corta y ancha: pocos registros (la dimensión de cliente de una empresa mediana puede tener 50,000 registros), pero con muchas columnas de atributos descriptivos. Esta asimetría de forma tiene una razón funcional: la tabla de hechos almacena cada ocurrencia de un evento con su medida, mientras que la tabla de dimensión almacena el catálogo estable de entidades de negocio contra las cuales se filtran y agrupan esos eventos.

En el star schema, las dimensiones se mantienen intencionalmente desnormalizadas: en lugar de dividir los atributos de un cliente en sub-tablas (cliente base, segmento, región, industria), todos los atributos se consolidan en una sola tabla de dimensión de cliente. Esta desnormalización simplifica las queries analíticas —cada JOIN es directo entre la tabla de hechos y la dimensión, sin cadenas de JOINs intermedios— y hace que los motores de business intelligence puedan generar SQL eficiente automáticamente para cualquier combinación de atributos que seleccione el usuario.

Cómo se implementa

La implementación de una tabla de dimensión comienza con la elección de la llave primaria. El modelado dimensional de Kimball especifica el uso de llaves sustitutas (surrogate keys) —enteros autogenerados secuencialmente— en lugar de los identificadores naturales de los sistemas fuente. Esto desacopla la tabla de dimensión de las convenciones de nomenclatura y cambios de los sistemas transaccionales: si el CRM cambia el ID de cliente de un esquema alfanumérico a uno numérico, la tabla de dimensión y la tabla de hechos permanecen inmutables.

El SCD Tipo 2 es el patrón más común en implementaciones modernas de data warehouse porque es el único que permite responder preguntas históricas correctamente: ¿Cuánto compró este cliente cuando pertenecía al segmento PYMEs, antes de que lo reclasificáramos como cliente Enterprise? Con SCD Tipo 1, esa pregunta es imposible de responder porque el valor anterior se perdió en la actualización.

Ejemplo práctico

Una empresa de software B2B con sede en Ciudad de México sirve a clientes en México, Colombia y Chile. Su equipo de datos mantiene una dimensión de cliente con los siguientes atributos: nombre de empresa, sector industrial, número de empleados (rango), país, ciudad, plan de suscripción, canal de adquisición, nombre del ejecutivo de cuenta asignado, y segmento de mercado (Startup, PYME, Mediana Empresa, Enterprise).

En marzo, un cliente llamado "Distribuidora Andina S.A." que operaba en el segmento PYME con un plan Growth a $349 USD/mes expande su operación y se reclasifica al segmento Enterprise con un plan Scale a $699 USD/mes. Con SCD Tipo 2, el proceso de actualización crea un nuevo registro en la dimensión de cliente para "Distribuidora Andina S.A." con los nuevos atributos y fecha_inicio = 2026-03-01, y cierra el registro anterior con fecha_fin = 2026-02-28. La tabla de hechos no se modifica: los eventos de enero y febrero siguen apuntando al registro anterior de dimensión (segmento PYME, plan Growth), mientras que los eventos de marzo en adelante apuntan al nuevo registro (segmento Enterprise, plan Scale).

Este diseño permite al COO de la empresa responder con precisión: ¿Cuánto MRR generaban los clientes que hoy son Enterprise cuando aún estaban en segmento PYME? ¿Qué canal de adquisición produce más upgrades desde PYME hacia Enterprise en los primeros 12 meses? Sin SCD Tipo 2, ambas preguntas serían imposibles de responder con los datos históricos del warehouse.

La dimensión de tiempo —también llamada dimensión de calendario— es un ejemplo de dimensión sin SCD porque los atributos de una fecha no cambian: el 15 de septiembre de 2026 siempre será martes, siempre será el 258vo día del año, siempre estará en el tercer trimestre. La tabla de tiempo se pregenera con una fila por cada día del período histórico y proyectado (típicamente 10-15 años), incluyendo atributos como día de la semana, número de semana ISO, mes, trimestre, año, indicador de día hábil, nombre del mes en español, y banderas de festivos nacionales para México y Colombia. Esta tabla se usa como dimensión en todas las tablas de hechos de tiempo del modelo.

Análisis en profundidad

Las dimensiones conformadas son el mecanismo que hace posible la integración analítica entre múltiples procesos de negocio. Una dimensión conformada es aquella que se define una sola vez y se reutiliza sin modificación en múltiples tablas de hechos y data marts. La dimensión de tiempo es el ejemplo más universal: la misma tabla de fechas se une a la tabla de hechos de ventas, de inventario, de soporte, de marketing y de nómina. Cuando todas las tablas de hechos usan la misma dimensión de tiempo con las mismas llaves y los mismos atributos, un analista puede cruzar ventas con costos de soporte con gasto de marketing sobre la misma línea de tiempo sin ninguna transformación adicional. Sin dimensiones conformadas, cada data mart tiene su propia definición de "cliente" o "producto" y los reportes ejecutivos consolidados requieren reconciliación manual constante.

La mini-dimensión es un patrón avanzado para dimensiones de alta cardinalidad cuyos atributos cambian con frecuencia. Suponga que una empresa de telecomunicaciones tiene una dimensión de cliente con 5 millones de registros. Si aplica SCD Tipo 2 a un atributo como el decil de gasto mensual — que cambia cada mes para millones de clientes — la tabla de dimensión crece a decenas de millones de registros rápidamente. La solución es extraer esos atributos de cambio frecuente a una tabla separada llamada mini-dimensión, que contiene solo las combinaciones posibles de esos atributos (no una fila por cliente, sino una fila por combinación de valores). La tabla de hechos entonces lleva dos llaves foráneas: una a la dimensión de cliente principal (SCD Tipo 2 solo para atributos de cambio lento) y otra a la mini-dimensión (para los atributos de cambio rápido). Este patrón controla el crecimiento explosivo de la dimensión principal sin perder la capacidad de análisis histórico.

La dimensión degenerada (degenerate dimension) es un caso especial donde el atributo dimensional vive directamente en la tabla de hechos sin una tabla de dimensión separada. El número de orden de compra es el ejemplo clásico: tiene un solo atributo (el número), actúa como identificador de un evento de negocio, y sería un desperdicio crear una tabla de dimensión de un solo atributo solo para normalizarlo. Los números de pedido, números de factura, números de ticket de soporte y códigos de transacción son candidatos naturales para dimensiones degeneradas. Identificarlos correctamente evita la creación innecesaria de tablas de dimensión vacías que complican el modelo sin añadir valor analítico.

La jerarquía de atributos dentro de una dimensión es una de las fuentes más comunes de errores en dashboards de BI. Una dimensión geográfica puede tener los atributos: ciudad, estado/departamento, región comercial, país y zona horaria. Si el diseñador no documenta las relaciones jerárquicas entre estos atributos — ciudad pertenece a estado, estado pertenece a país — los usuarios de la herramienta de BI pueden crear reportes que mezclan niveles jerárquicos incompatibles, como sumar métricas de "ciudad" con métricas de "región" en la misma columna. Las herramientas de BI modernas como Looker, Tableau o Power BI pueden explotar las jerarquías explícitas para navegar drill-down de forma intuitiva, pero solo si están correctamente declaradas en el modelo semántico o en la propia dimensión.

El atributo de auditoría en las dimensiones es una práctica de gobierno de datos que añade columnas técnicas a cada registro de dimensión para rastrear su procedencia y estado: sistema_fuente, fecha_carga, fecha_ultima_modificacion, es_registro_activo. Estos atributos no son visibles para los analistas de negocio — se excluyen de las vistas de BI — pero son indispensables para el equipo de datos cuando necesita diagnosticar por qué un registro específico tiene un valor inesperado, rastrear si un atributo fue cargado correctamente en un pipeline fallido, o identificar registros obsoletos que deberían haberse marcado como inactivos tras una migración de sistema fuente.

Errores frecuentes

• ✗

  Normalizar las dimensiones en sub-tablas (snowflake schema) sin una razón de peso. La tentación de normalizar la dimensión de producto en tablas separadas de producto, categoría y subcategoría replica los hábitos del diseño de bases de datos transaccionales, que optimizan para escrituras, no para lecturas. En un warehouse columnar moderno, el almacenamiento duplicado en dimensiones desnormalizadas es insignificante gracias a la compresión, y el costo de los JOINs adicionales en cada query analítica es concreto y acumulativo. La desnormalización intencional de las dimensiones es un principio central del modelado Kimball, no un descuido.

• ✗

  Aplicar SCD Tipo 1 por defecto sin evaluar el valor histórico del atributo. Actualizar todos los atributos de dimensión por sobreescritura es el camino de menor resistencia técnica, pero destruye irrecuperablemente el historial analítico. Una vez que el sistema sobrescribió el segmento de un cliente de "PYME" a "Enterprise", es imposible responder qué comportamiento tenía cuando era PYME. La evaluación del tipo de SCD adecuado para cada atributo debe ser una decisión explícita de diseño documentada, no el resultado de usar la implementación más simple disponible.

• ✗

  Crear múltiples versiones inconsistentes de la misma dimensión en data marts diferentes. Cuando el equipo de ventas define "cliente activo" de forma diferente al equipo de finanzas, y cada uno construye su propia dimensión de cliente con esa definición, los reportes ejecutivos que cruzan métricas de ventas con métricas financieras producen números inconsistentes. La solución no es técnica sino de gobierno: definir dimensiones conformadas con definiciones de negocio acordadas entre todas las áreas y mantenerlas en una capa central única que todos los data marts consumen.

Cómo lo rastrea Fairview

Fairview mantiene dimensiones conformadas centrales — cliente, producto, canal, tiempo — que se alimentan automáticamente desde las integraciones con CRM, ERP, plataformas de ecommerce y sistemas de facturación. Cuando los datos de un cliente cambian en Salesforce — un cambio de segmento, un reasignación de ejecutivo de cuenta, una actualización de la industria clasificada — Fairview aplica SCD Tipo 2 al registro correspondiente en la dimensión de cliente, preservando el historial completo de atributos sin requerir intervención manual del equipo de datos.

Las métricas del Operating Dashboard de Fairview están construidas sobre estas dimensiones conformadas: cuando el COO filtra el reporte de margen por segmento de cliente o por canal de adquisición, los filtros operan sobre los mismos atributos de dimensión que usa el equipo de finanzas en sus proyecciones. Esto elimina la discrepancia más común en los reportes ejecutivos de operadores que manejan múltiples fuentes de datos: el mismo cliente aparece como "PYME" en el reporte de ventas y como "Mediana Empresa" en el reporte financiero porque cada sistema lo clasificó con su propia nomenclatura.

Para los equipos con necesidades de análisis histórico avanzado — seguimiento de cohortes de clientes a lo largo de múltiples reclasificaciones de segmento, atribución de ingresos a campañas de marketing activas en fechas históricas específicas — Fairview expone acceso directo al modelo dimensional subyacente a través de su API de datos, con documentación del tipo de SCD aplicado a cada atributo de cada dimensión.

Preguntas frecuentes