DP-600: optimizar modelos semánticos con star schema

Esta lección se centra en una competencia clave del DP-600: implementar y gestionar modelos semánticos utilizando el patrón star schema (esquema en estrella). Saber cuándo y cómo estructurar fact y dimension tables mejora el rendimiento, facilita los cálculos DAX y se evalúa con frecuencia en el examen y se usa en escenarios reales. Un modelo bien diseñado reduce los tiempos de respuesta, disminuye el consumo de memoria y simplifica la gobernanza del informe y de los datos.

Qué necesitas saber

Un star schema organiza datos en tablas de fact (fact tables) que contienen medidas numéricas (como ventas, cantidades) y tablas de dimensión (dimension tables) que contienen atributos descriptivos (como producto, cliente, fecha). La idea central es mantener la fact table desnormalizada y las dimensiones relativamente estables, enlazadas mediante claves simples. Ventajas: consultas más rápidas, modelado DAX más sencillo y mejor compresión en el motor VertiPaq.

Ejemplo simple: una fact table Sales con columnas SaleID, ProductKey, CustomerKey, DateKey, Quantity, SalesAmount; y dimensiones Product (ProductKey, ProductName, Category), Customer (CustomerKey, Name, Region) y Date (DateKey, Date, Year, Month). En escenarios reales, la fact table puede alcanzar millones de filas (por ejemplo 5–50M rows), mientras que las dimensiones típicamente tienen decenas a cientos de miles de registros (por ejemplo Product = 10k, Customer = 120k). Mantener las dimensiones limpias y con claves enteras ayuda a la compresión: cambiar claves textuales por surrogate keys puede reducir el espacio ocupado por esas columnas en un 60–80% en muchos casos.

Cómo funciona en la práctica

Elementos y pasos principales para implementar un star schema eficaz en Power BI/Fabric:

1. Identificar facts y dimensions: parte de las fuentes; tablas transaccionales (ventas, transacciones) se convierten en fact tables. Tablas con atributos descriptivos (productos, clientes, calendario) se convierten en dimensiones. Por ejemplo, una tabla de orders con 12 columnas y 10M de filas debe transformarse en una fact table con claves y medidas y las restantes columnas movidas a dimensiones para reducir la duplicación.

2. Elegir y mantener claves de enlace: utiliza surrogate keys enteras cuando sea posible (ej.: ProductKey) en lugar de combinaciones de cadenas. Las claves enteras optimizan las relaciones y la compresión. En la práctica, genera un ProductKey como entero secuencial en el ETL (IDENTITY/auto-increment) y almacena la clave natural (SKU) solo en la dimensión para referencia. Esto acelera los joins y reduce el tamaño del índice; por ejemplo, una columna int ocupa 4 bytes, mientras que una SKU de 20 caracteres puede superar los 20 bytes por registro.

3. Desnormalizar fact, normalizar dimensiones: evita joins profundos en consultas analíticas; la fact table debe contener solo las claves y las medidas. Las dimensiones pueden agrupar atributos relacionados (ej.: ProductCategory en la dimensión Product). Desnormalizar la fact significa, por ejemplo, evitar columnas que repiten texto largo en cada fila de venta; en su lugar, guarda la referencia a la dimensión.

4. Modelar relaciones con cardinalidad correcta: define relaciones 1:* (dimension → fact). En Power BI Desktop/Fabric, marca las relaciones activate/bi-directional según sea necesario, pero prefiere el filtrado unidireccional en la mayoría de los casos. Las relaciones unidireccionales mantienen el modelo predecible y evitan contextos ambiguos; utiliza bi-directional solo cuando necesites filtrar across sin bridge tables, y realiza pruebas de integridad antes de publicar.

5. Gestionar jerarquías y columnas calculadas: crea jerarquías (Year > Month > Day) en las dimensiones de fecha. Usa columnas calculadas con moderación: prefiere medidas DAX para cálculos dinámicos y mejor rendimiento. Por ejemplo, calcular margen medio por producto debe hacerse como medida (agregada en runtime) y no como columna calculada que aumenta el tamaño del modelo; solo crea columnas calculadas cuando necesites que la columna exista para segmentación o relaciones.

En la práctica — ejemplo DAX y modelado

Supón que tienes las tablas Sales (fact) y Date (dim). Para crear una medida de Total Sales en lugar de columna calculada, escribe:

Total Sales = SUM(Sales[SalesAmount])

YTD Sales = TOTALYTD([Total Sales], Date[Date])

Explicación: SUM agrega la fact table; TOTALYTD usa la dimensión Date para evaluar el año hasta la fecha. Si la relación entre Sales[DateKey] y Date[DateKey] es correcta (1:*), estas medidas son eficientes y reutilizables en visuales. En una base con 10M de filas de fact, medidas bien escritas reducen de forma drástica el tiempo de cálculo: consultas típicas de sumatorio que tardaban 5–10s en modelos mal diseñados pueden caer a 0.2–2s con compresión y claves correctas.

Errores comunes

• Usar relaciones muchos-a-muchos sin necesidad: recurrir a cardinalidad *:* y filtrado bi-directional por defecto puede causar resultados incorrectos y lentos. Evalúa alternativas (bridge tables o modelado diferente). Por ejemplo, múltiples relaciones directas entre fact y varias dimensiones pueden llevar a duplicación de resultados si no se aíslan correctamente.
• Exceso de columnas calculadas en la fact table: crear muchas columnas derivadas en facts aumenta el tamaño del modelo. Prefiere medidas DAX, excepto cuando necesites columnas para segmentación/categorización persistente. Como regla práctica, cada columna adicional en una fact de 20M de filas añade costes de memoria lineales.
• Claves textuales largas como PK/FK: usar strings como claves de enlace (ej.: códigos alfa) incrementa el espacio y reduce el rendimiento. Sustitúyelas por surrogate keys enteras siempre que puedas.

Cómo practicar

Para practicar, monta un pequeño proyecto en Power BI Desktop/Fabric: importa una tabla de ventas y tablas dimensionales, crea el modelo star, define relaciones e implementa medidas como Total Sales, YTD y Average Price. Experimenta comparando rendimiento entre columnas calculadas y medidas usando el Performance Analyzer y observando el tamaño del archivo (.pbix/.parquet) antes y después. Un ejercicio útil es duplicar el modelo con claves textuales y con claves enteras y comparar: muchos equipos observan reducciones del 30–70% en el tamaño del modelo tras optimizar claves y eliminar columnas innecesarias.

Consulta los recursos oficiales gratuitos de Microsoft: el Practice Assessment OFICIAL para DP-600 (práctica de evaluación gratis) y la study guide de Microsoft para DP-600. Ambos son gratuitos y ayudan a validar tus conocimientos en las skills measured sin recurrir a material no autorizado.

En resumen

• Star schema separa fact tables (medidas) de dimension tables (atributos) para mejor rendimiento y claridad.
• Utiliza surrogate keys enteras, relaciones 1:*, y preferiblemente filtrado unidireccional.
• Prefiere medidas DAX a columnas calculadas en la fact table para reducir uso de memoria y mejorar rendimiento.
• Evita cardinalidades muchos-a-muchos y claves textuales largas; prueba y compara rendimiento en tu entorno usando herramientas como Performance Analyzer antes de publicar.