Tabla de dimensiones: qué es y cómo se diseña

Una tabla de dimensiones guarda el contexto descriptivo por el que se filtra, agrupa y etiqueta lo que mide una tabla de hechos. Si la tabla de hechos responde cuánto, la dimensión responde quién, qué, dónde y cuándo.

En un modelo de ventas, la tabla de hechos guarda el importe y las unidades. Las dimensiones guardan el nombre del producto, su categoría y su marca; la ciudad y la provincia de la tienda; el segmento del cliente. Son las columnas que acaban siendo las filas y los filtros de cualquier informe.

Qué contiene

• Una clave primaria que la tabla de hechos referencia.
• Atributos descriptivos, normalmente texto: nombres, categorías, códigos, clasificaciones.
• Jerarquías naturales: producto → subfamilia → familia → categoría; día → mes → trimestre → año.

Las dimensiones suelen tener muchas columnas y pocas filas, justo al revés que las tablas de hechos. Una dimensión de producto con cincuenta atributos y veinte mil filas es perfectamente normal, y es buena señal: cada atributo es una forma más de cortar los datos. En modelado dimensional los atributos descriptivos no se consideran un exceso, se consideran el producto.

Por qué se desnormaliza a propósito

Aquí es donde el modelado dimensional se separa del diseño transaccional. En una base de datos operacional se normaliza para evitar redundancia. En una dimensión se hace lo contrario: se aplanan las jerarquías en una sola tabla ancha, aunque «categoría» se repita en miles de filas.

El motivo es doble. Primero, el rendimiento: resolver un informe con una sola unión entre hechos y dimensión es mucho más barato que encadenar cinco tablas normalizadas. Y segundo, la comprensión: quien construye un informe ve una tabla «Producto» con todo dentro, en vez de tener que reconstruir la jerarquía. Esa desnormalización es precisamente lo que distingue el esquema en estrella del copo de nieve, que sí normaliza las jerarquías en tablas separadas.

La redundancia que se acepta es de espacio, que es barato. Lo que no se acepta es la ambigüedad.

La clave subrogada

La clave primaria de una dimensión no suele ser el identificador del sistema origen, sino una clave subrogada: un entero sin significado de negocio, generado por el propio almacén.

Parece un rodeo innecesario y no lo es. El código del origen puede reutilizarse, cambiar de formato en una migración, o venir de dos sistemas distintos que usan el mismo código para cosas diferentes. Sobre todo, la clave subrogada es lo que permite guardar varias versiones de la misma entidad: si un cliente cambia de provincia y se quiere conservar el histórico, se inserta una fila nueva con otra clave subrogada y el mismo código de origen. Es el mecanismo sobre el que se apoyan las dimensiones de cambio lento.

Dimensiones conformadas

Cuando varias tablas de hechos comparten la misma dimensión —ventas y devoluciones usando la misma dimensión de producto— se habla de dimensión conformada. Es la pieza que permite comparar procesos distintos en un mismo informe y sostiene la coherencia de todo el modelo.

Sin dimensiones conformadas, cada área acaba con su propia versión de «cliente» o «producto», los totales no cuadran entre informes y las reuniones se dedican a discutir de dónde sale cada cifra en lugar de qué hacer con ella.

Casos que conviene conocer

• Dimensión de fecha: se construye una vez, con una fila por día y columnas para mes, trimestre, año, día de la semana y festivos. Evita repetir esa lógica en cada consulta.
• Dimensión degenerada: un identificador que se queda en la tabla de hechos sin dimensión propia, como el número de ticket, porque no tiene atributos que describir.
• Dimensión basura: agrupa en una sola tabla varios indicadores sueltos de poca cardinalidad —marcas de sí/no, estados— que no merecen una dimensión cada uno.

En el directorio de plataformas de datos de Dataprix hay fichas y análisis de los motores sobre los que se implementan estos modelos, y el encaje del modelado en el diseño global está en la guía de arquitectura de datos.