DP-700: cómo diseñar e implementar esquemas dimensionales para analytics

En esta guía voy a enseñar la competencia de diseñar e implementar esquemas dimensionales (star y snowflake) para soluciones de analytics en el contexto del DP-700. Esta competencia importa porque los modelos dimensionales mejoran el rendimiento de las consultas, facilitan los informes en Power BI y son frecuentemente exigidos en arquitecturas de Data Warehouse y Lakehouse.

Qué necesitas saber

Un esquema dimensional organiza los datos en fact tables (hechos) y dimension tables (dimensiones). La fact table contiene medidas numéricas (p. ej.: sales_amount, quantity) y claves hacia dimensiones; las dimension tables contienen atributos descriptivos (p. ej.: product_name, customer_segment). El formato más común es el star schema (fact table central enlazada a varias dimensiones), y la variante snowflake normaliza dimensiones en múltiples tablas.

Ejemplo simple:

FactSales
- SalesID (PK)
- DateKey (FK -> DimDate.DateKey)
- ProductKey (FK -> DimProduct.ProductKey)
- CustomerKey (FK -> DimCustomer.CustomerKey)
- SalesAmount

DimDate
- DateKey (PK)
- Date
- Year
- Month

DimProduct
- ProductKey (PK)
- ProductName
- Category

DimCustomer
- CustomerKey (PK)
- CustomerName
- Region

En este modelo, consultas analíticas típicas (p. ej.: total de ventas por mes y por categoría) unen la fact table con las dimensiones por claves numéricas, lo que es eficiente.

Cómo funciona

Pasos prácticos para diseñar e implementar un esquema dimensional en una solución Fabric (OneLake, Delta tables, Power BI):

1. Identifica los procesos de negocio y las métricas — comienza por listar los principales indicadores (KPIs) que los informes van a necesitar: revenue, units_sold, margin, etc.
2. Define las granularidades — la fact table debe reflejar la menor granularidad necesaria (p. ej.: por transacción, por línea de pedido, por día). Una granularidad incorrecta obliga a agregaciones complejas en el consumo.
3. Modela las dimensiones — crea dimensiones para entidades que describen los hechos: cliente, producto, tiempo, ubicación. Evita duplicación de atributos que pertenezcan claramente a una dimensión.
4. Elige claves surrogate — prefiere surrogate keys enteras (ProductKey, CustomerKey) en lugar de natural keys (SKU, NIF) para mantener integridad y rendimiento.
5. Implementa en Fabric — crea tablas Delta en OneLake (o tablas del Lakehouse):

   -- Exemplo simplificado T-SQL / SQL para crear tablas Delta no Notebook SQL
   CREATE TABLE lakehouse.dbo.DimDate (
     DateKey INT PRIMARY KEY,
     Date DATE,
     Year INT,
     Month INT
   ) WITH ( LOCATION = '.../DimDate' );
   
   CREATE TABLE lakehouse.dbo.FactSales (
     SalesID BIGINT,
     DateKey INT,
     ProductKey INT,
     CustomerKey INT,
     SalesAmount DECIMAL(18,2)
   ) USING DELTA;
   

6. Ingestión y mantenimiento — usa pipelines (Dataflows, Synapse Pipelines o Fabric pipelines) para cargar facts y dimensiones. Para dimensiones lentas (slowly changing dimensions, SCD) implementa la estrategia adecuada (Type 1 o Type 2). Por ejemplo, para SCD Type 2 añade columnas de effective_date y end_date y genera una nueva row cuando el atributo cambia.
7. Optimización física — la indexación en sistemas MPP no es directa; en Fabric optimiza con ordenación (sort order) y particiones adecuadas (p. ej.: partición por DateKey). Para consultas por categoría, considera clustering por Category o ProductKey.

En la práctica — un caso de uso paso a paso

Objetivo: crear un star schema sencillo para informes de ventas por mes y categoría.

1. Identifica campos: SalesDate, ProductSKU, CustomerID, Quantity, Amount, Category.
2. Crea DimDate con DateKey = YYYYMMDD; pobla la dimensión con un pipeline diario.
3. Crea DimProduct con ProductKey (surrogate), ProductSKU, ProductName, Category. Resuelve duplicados en el proceso ETL y genera ProductKey con secuencia.
4. Crea FactSales con SalesID, DateKey, ProductKey, CustomerKey, Quantity, Amount. En el pipeline de ingestión convierte ProductSKU -> ProductKey usando lookup en la DimProduct.
5. Particiona FactSales por YearMonth (p. ej.: 202601) para consultas por período, y ordénala por ProductKey para análisis por producto.
6. Prueba consultas típicas (GROUP BY Month, Category) con datos de muestra y mide tiempos; ajusta partición/ordenación según sea necesario.

Errores comunes

• Granularidad incorrecta: definir la fact table con granularidad demasiado agregada o demasiado fina que no corresponde a los requisitos analíticos; ambos causan problemas de rendimiento o complicaciones en las agregaciones.
• Usar claves naturales como PKs: claves textuales o compuestas (p. ej.: SKU) degradan el rendimiento y complican cambios; prefiere surrogate integer keys.
• Dimensiones sin historial cuando es necesario: tratar cambios históricos como Type 1 cuando necesitas historial (Type 2) conduce a informes erróneos y pérdida de trazabilidad.

Cómo practicar

Practica implementando un star schema en un entorno Fabric o en un sandbox: crea DimDate, DimProduct, FactSales; implementa pipelines simples para poblar tablas y crea informes en Power BI sobre ese modelo. Para la preparación del examen, usa el Practice Assessment OFICIAL y gratuito de Microsoft y la Study Guide oficial (ambos gratuitos) — estos recursos ayudan a validar el conocimiento en ese dominio sin recurrir a dumps. Busca en la página del examen DP-700 los enlaces al practice assessment y a la study guide.

En resumen

• Modela facts y dimensiones basándote en los KPIs y en la granularidad necesaria.
• Usa surrogate keys, particiones y ordenación para optimizar consultas analíticas.
• Implementa SCDs adecuadas para preservar historial cuando sea necesario.
• Prueba consultas reales y ajusta parámetros físicos (particiones/clustering) en Fabric antes de publicar para consumo.