Fundamentos del esquema en estrella: hechos, dimensiones y declaración de la granularidad

Qué es

El modelado dimensional divide los datos en mediciones de eventos de negocio y el contexto descriptivo de esos eventos: quién, qué, dónde, cuándo, por qué y cómo. En una base de datos relacional esto se materializa en un esquema en estrella: las tablas de hechos ocupan el centro y cada una se enlaza mediante claves foráneas con las tablas de dimensiones que las rodean. La guía de Power BI (citada) lo formula en términos operativos: una tabla de hechos contiene columnas de claves de dimensión que se relacionan con las tablas de dimensiones, y columnas numéricas de medidas; las columnas de clave determinan la dimensionalidad de la tabla de hechos y los valores de clave, su granularidad; las tablas de dimensiones son comparativamente pequeñas, mientras que las tablas de hechos son grandes y siguen creciendo. La página sobre la granularidad del Kimball Group (citada) deja explícito el primer paso del diseño: declarar la granularidad establece exactamente qué representa una sola fila de la tabla de hechos, se convierte en un contrato vinculante y debe preceder a la elección de dimensiones y hechos. Se recomienda la granularidad atómica, el nivel más bajo que captura el proceso, porque resiste consultas impredecibles. La página sobre hechos (citada) clasifica las medidas: las aditivas pueden sumarse en cualquier dimensión; las semiaditivas, como los saldos, en todas las dimensiones excepto el tiempo; las no aditivas, como las razones o ratios, en ninguna, por lo que conviene almacenar sus componentes aditivos y calcular la razón después de agregar.

Por qué importa

Los analistas y las herramientas de BI pueden agregar sobre un esquema en estrella sin conocer los sistemas de origen: filtran por atributos de dimensión, suman medidas y agrupan por cualquier dimensión. Un esquema operacional normalizado obliga a hacer joins de varias tablas cuya semántica cambia según la consulta, y una tabla que mezcla granularidades (líneas de pedido y cabeceras de pedido) cuenta por duplicado en cuanto alguien la suma.

Cómo aplicarlo

• Escribe la granularidad como una frase («una fila por línea de pedido y día») y rechaza cualquier medida o dimensión que no encaje; si la granularidad es distinta, ponla en otra tabla de hechos.
• Asigna a cada dimensión una clave sustituta (surrogate key) entera, conserva la clave natural del origen como atributo e incluye una dimensión de fecha con atributos de calendario en lugar de derivarlos en cada consulta.
• Guarda las dimensiones degeneradas (el número de pedido) directamente en la tabla de hechos; reserva las tablas de dimensiones para entidades con atributos descriptivos.
• Define las dimensiones conformadas una sola vez y reutilízalas en varias tablas de hechos, de modo que los resultados de distintos procesos se alineen sobre las mismas filas.

Trampas

Descomponer las dimensiones en subtablas normalizadas (snowflaking) ahorra poco almacenamiento y cuesta joins adicionales. Las claves foráneas NULL rompen los filtros; usa un miembro de dimensión explícito «desconocido». Los promedios y porcentajes almacenados como hechos no se pueden reagregar correctamente.

Claves sustitutas en pipelines que se pueden reejecutar

Una clave obtenida de una secuencia se asigna en el orden de carga, así que reejecutar o rellenar (backfill) una dimensión fuera de orden cambia las claves y deja huérfanos los hechos cargados entretanto. En pipelines diseñados para reejecuciones idempotentes, deriva la clave sustituta de forma determinista a partir de la clave natural (y de valid_from en las filas de tipo 2), normalmente mediante un hash; dbt_utils.generate_surrogate_key es la implementación habitual. Así, las cargas de dimensiones y de hechos siguen siendo reejecutables de forma independiente y los hechos pueden recibir su clave en el momento de la carga, sin búsqueda previa. Conserva las claves enteras de secuencia cuando las cargas se serialicen y importe el rendimiento de los joins con un entero estrecho, y no mezcles nunca los dos métodos en una misma dimensión.