"El modelo de datos en Power BI: anatomía de una implantación correcta con esquema en estrella"

La mayoría de los proyectos de Power BI no fracasan por la complejidad de las fórmulas DAX, sino porque el modelo de datos subyacente está mal construido. El esquema en estrella —el enfoque de modelado dimensional popularizado por Ralph Kimball— es la estructura que mejor funciona con el motor matemático de Power BI. En este artículo abordamos, con mirada corporativa, el esquema en estrella, las tablas de hechos y dimensiones, las decisiones sobre la dirección de las relaciones y los errores más frecuentes.

01. ¿Por qué esquema en estrella? La perspectiva del motor VertiPaq

El corazón de Power BI es un motor de compresión columnar llamado VertiPaq. Ese motor comprime y almacena los datos columna por columna y procesa las consultas en paralelo.

VertiPaq comprime los valores repetidos con enorme eficacia: en una tabla de 10 millones de filas, si la columna «categoría de producto» solo contiene ocho valores distintos, la tasa de compresión llega al 99%. Pero si esa misma columna se guarda en una tabla plana junto al nombre del producto y los datos del proveedor, el patrón de repetición se rompe y la compresión cae en picado.

El esquema en estrella maximiza precisamente esa compresión: separa los atributos repetitivos en tablas de dimensiones y mantiene los eventos medibles en la tabla de hechos. Resultado: un modelo entre 5 y 10 veces más pequeño y consultas entre 3 y 5 veces más rápidas.

02. Tablas de hechos y de dimensiones: una mirada anatómica

La tabla de hechos guarda los eventos de negocio medibles: ventas, pedidos, cobros, producción. Cada fila representa un «evento» y contiene:

• Medidas numéricas (cantidad, importe, coste, unidades)
• Claves foráneas que apuntan a las tablas de dimensiones

La tabla de dimensiones guarda el «quién, qué, dónde y cuándo» del evento:

• Cliente (nombre, sector, ciudad)
• Producto (código, categoría, marca)
• Fecha (año, trimestre, mes, día, indicador de festivo)
• Tienda o almacén (ubicación, región, tipo)

En un esquema en estrella ideal, la tabla de hechos es estrecha y larga (millones de filas pero solo 8-15 columnas) y las de dimensiones son anchas y cortas (miles de filas y 20-40 columnas).

03. La dimensión de fecha: un estándar irrenunciable

Todo modelo serio de Power BI debe tener una tabla de dimensión de fecha independiente. No es un detalle menor: es una pieza obligatoria para que funcionen las funciones DAX de inteligencia de tiempo (YTD, SAMEPERIODLASTYEAR, DATESYTD, PARALLELPERIOD).

Una buena tabla de fechas:

• Contiene un rango continuo que cubre todo el periodo de análisis (una fila por día)
• Está marcada como «tabla de fechas» dentro del modelo
• Incluye columnas de año, trimestre, nombre y número de mes, semana, día e indicador de día laborable
• Se relaciona con los campos de fecha de las tablas de hechos en una relación de uno a varios

Sin tabla de fechas no se puede escribir DAX de inteligencia de tiempo; y si se escribe, produce resultados inesperados.

04. Dirección de las relaciones y decisiones de cardinalidad

Al crear una relación entre dos tablas hay que tomar tres decisiones:

• Cardinalidad (uno a varios, uno a uno, varios a varios)
• Dirección del filtro cruzado (sencilla o bidireccional)
• Relación activa o inactiva

En un esquema en estrella estándar, todas las relaciones deben ser de uno a varios (de la dimensión al hecho) y funcionar en una sola dirección. La relación bidireccional resulta tentadora, pero complica el modelo, ralentiza las consultas y provoca comportamientos inesperados en los totales.

Hay que evitar especialmente las relaciones de varios a varios; si de verdad hacen falta, deben convertirse en relaciones unidireccionales mediante una tabla puente. Entre cada par de tablas solo puede haber una relación activa; para la segunda se necesita la función USERELATIONSHIP.

05. Esquema en copo de nieve: ¿cuándo es aceptable?

El copo de nieve es la estructura en la que las tablas de dimensiones se dividen a su vez en subdimensiones (Producto → Categoría → Categoría principal). En la teoría clásica se prefería por estar «normalizado».

En Power BI, el copo de nieve reduce la ventaja de compresión de VertiPaq y complica la escritura de DAX. Regla general: desnormalice las dimensiones todo lo posible, prefiriendo una única tabla ancha.

El caso en que sí es aceptable: cuando una misma subdimensión la comparten varias dimensiones principales (por ejemplo, si «Región» vale tanto para «Cliente» como para «Tienda»). Entonces una tabla de Región aparte queda más limpia que desnormalizar.

06. Cinco errores de modelado frecuentes

Los errores que más vemos sobre el terreno:

• Unir hechos y dimensiones en una única tabla (modelo plano): el rendimiento se hunde y la compresión cae
• Usar la columna de fecha de la tabla de hechos como dimensión de fecha: se rompe la inteligencia de tiempo
• Colocar campos numéricos en la dimensión: los importes y precios deben estar siempre en el hecho
• Poner las relaciones en bidireccional: complejidad y lentitud
• Usar claves compuestas: en lugar de crear una clave a partir de dos campos, hay que generar una clave subrogada única en el origen

Corregidos esos cinco errores, tanto el tamaño como la velocidad del modelo mejoran entre dos y tres veces.

07. Validar el modelo: Vertipaq Analyzer y buenas prácticas

No dé por bueno el modelo nada más construirlo: mida su comportamiento. Vertipaq Analyzer (herramienta gratuita dentro de DAX Studio) muestra cuánto ocupa cada columna de su tabla. Las que más espacio ocupan suelen ser:

• Texto de alta cardinalidad (nombre de cliente, descripción de producto)
• Columnas de fecha y hora (cuando bastaba con la fecha y también se guardó la hora)
• Columnas de identificador (si son únicas, no se pueden comprimir)

El Best Practices Analyzer, dentro de Tabular Editor, revisa automáticamente las buenas prácticas del esquema en estrella y enumera los incumplimientos. Conviene ejecutarlo antes de cada salida a producción.