Esquema Estrella

El patrón gold standard para modelado en Power BI. Aprende a implementarlo y por qué es la base de todo modelo de datos profesional

Intermedio

¿Qué es el Esquema Estrella?

El patrón fundamental del modelado analítico

El esquema estrella (star schema) es un patrón de diseño de base de datos optimizado para análisis y reporting. Se llama así porque visualmente se parece a una estrella: una tabla de hechos central rodeada de tablas de dimensiones que irradian hacia afuera.

Es el patrón recomendado por Microsoft para Power BI y el que mejor aprovecha el motor VertiPaq (el motor de almacenamiento columnar de Analysis Services / Power BI).

Por qué es el estándar:

  • Consultas DAX más simples y predecibles
  • Mejor rendimiento (menos JOINs, mejor compresión)
  • Más fácil de entender y mantener
  • Las funciones de inteligencia de tiempo funcionan perfectamente
  • RLS (seguridad) es más fácil de implementar
🗺️

Diagrama y Estructura

Estructura visual del esquema estrella

        DimFecha
            │
            │ 1:N
            ▼
DimCliente ─1:N─▶ FactVentas ◀─1:N─ DimProducto
                        │
                      1:N │
                        ▼
                    DimTienda

FactVentas contiene:
  ├─ IDFecha (FK)
  ├─ IDCliente (FK)
  ├─ IDProducto (FK)
  ├─ IDTienda (FK)
  ├─ Cantidad
  ├─ PrecioUnitario
  └─ Descuento

Reglas del esquema estrella:

  • Una tabla de hechos central (o varias, si el modelo tiene varias áreas)
  • Dimensiones conectadas directamente a los hechos (sin dimensiones anidadas)
  • Relaciones siempre 1:N (dimensión → hechos)
  • Dimensiones desnormalizadas (un solo nivel, sin JOINs entre dimensiones)
❄️

Esquema Estrella vs Copo de Nieve

¿Cuándo importa la diferencia?

El esquema copo de nieve (snowflake schema) es una extensión del esquema estrella donde las dimensiones están normalizadas: en lugar de una tabla plana DimProducto, tienes DimProducto → DimCategoria → DimSubcategoria.

⭐ Estrella (recomendado)

  • Dimensiones planas y desnormalizadas
  • Un solo JOIN por dimensión
  • Consultas DAX simples
  • Mejor rendimiento VertiPaq
  • Más fácil de mantener

❄️ Copo de Nieve (evitar en PBI)

  • Dimensiones normalizadas en cascada
  • Múltiples JOINs en cadena
  • DAX más complejo con RELATED
  • Más tablas = más relaciones = más lento
  • Dificulta la inteligencia de tiempo
⚠️ Ojo con esto: Si tu base de datos fuente está normalizada (esquema copo de nieve), aplana las dimensiones en Power Query antes de cargar al modelo. Combina las tablas Producto + Categoria + Subcategoria en una sola DimProducto plana.
🛠️

Cómo Implementar un Esquema Estrella

Proceso paso a paso

  1. Identifica el proceso de negocio: ¿Qué quieres analizar? (Ventas, Inventario, RR.HH., etc.)
  2. Define la granularidad: ¿Qué representa cada fila de la tabla de hechos? (línea de pedido, pedido, día)
  3. Identifica las dimensiones: ¿Desde qué perspectivas analizarás? (fecha, cliente, producto, geografía)
  4. Define las métricas: ¿Qué números quieres medir? (importe, cantidad, coste, margen)
  5. Aplana las dimensiones en Power Query: JOINs de tablas normalizadas en dimensiones planas
  6. Crea las relaciones en Power BI: 1:N desde cada dimensión a la tabla de hechos
  7. Crea una tabla de fechas dedicada: nunca uses la fecha directamente de la tabla de hechos
💼

Ejemplo Completo: Modelo de Ventas Retail

Caso práctico: cadena de tiendas retail

Vamos a diseñar el modelo estrella para una cadena de tiendas que quiere analizar sus ventas por fecha, producto, cliente y tienda.

-- TABLA DE HECHOS
FactVentas (
  IDFecha       INT,    -- FK → DimFecha
  IDCliente     INT,    -- FK → DimCliente
  IDProducto    INT,    -- FK → DimProducto
  IDTienda      INT,    -- FK → DimTienda
  IDPromocion   INT,    -- FK → DimPromocion (puede ser NULL)
  Cantidad      INT,
  PrecioUnitario DECIMAL,
  Coste         DECIMAL,
  Descuento     DECIMAL
)

-- DIMENSIÓN FECHA (tabla calendario)
DimFecha (
  IDFecha       INT PRIMARY KEY,  -- formato YYYYMMDD
  Fecha         DATE,
  Año           INT,
  Trimestre     INT,
  Mes           INT,
  NombreMes     VARCHAR,
  Semana        INT,
  DiaSemana     VARCHAR,
  EsFestivo     BIT
)

-- DIMENSIÓN CLIENTE (aplanada)
DimCliente (
  IDCliente     INT PRIMARY KEY,
  Nombre        VARCHAR,
  Email         VARCHAR,
  Segmento      VARCHAR,  -- Incluido desde tabla segmentos (aplanado)
  Pais          VARCHAR,
  Region        VARCHAR,
  Ciudad        VARCHAR   -- Incluido desde tabla geografia (aplanado)
)

-- DIMENSIÓN PRODUCTO (aplanada)
DimProducto (
  IDProducto    INT PRIMARY KEY,
  Nombre        VARCHAR,
  SKU           VARCHAR,
  Categoria     VARCHAR,  -- Aplanado desde tabla categorias
  Subcategoria  VARCHAR,  -- Aplanado desde tabla subcategorias
  Marca         VARCHAR,
  PrecioLista   DECIMAL
)

-- DIMENSIÓN TIENDA (aplanada)
DimTienda (
  IDTienda      INT PRIMARY KEY,
  Nombre        VARCHAR,
  Ciudad        VARCHAR,
  Comunidad     VARCHAR,
  Pais          VARCHAR,
  Formato       VARCHAR,  -- 'Flagship', 'Outlet', 'Express'
  M2            INT
)
📌 Buena práctica: Nombra siempre tus tablas de hechos con el prefijo Fact y tus dimensiones con el prefijo Dim. Hace el modelo inmediatamente legible y facilita el trabajo en equipo. Muchas organizaciones usan esta convención de nomenclatura como estándar.
🚀 ¡Modelo diseñado! Con el esquema estrella en mente, el siguiente paso es crear una Tabla de Fechas correcta — uno de los errores más comunes en Power BI es no tenerla. También te recomiendo revisar Columnas Calculadas vs Medidas para decidir dónde poner tus cálculos.