El modelo estrella en la práctica

Has aprendido qué son tablas de hechos y dimensiones, y cómo crear relaciones. Ahora es momento de unir todo en un modelo estrella (star schema), la estructura que usan el 95% de los dashboards profesionales en Power BI. Es simple, rápido y fácil de mantener.

¿Qué es el modelo estrella?

Un modelo estrella es una estructura donde:

• Una tabla de hechos está en el centro
• Múltiples tablas de dimensiones rodean la tabla de hechos
• Cada dimensión se conecta directamente a la tabla de hechos
• Las dimensiones NO se conectan entre sí

Visualización

                    [Fechas]
                       │
                       │
[Categorías] ← [Productos] ← [VENTAS] → [Clientes] → [Ciudades]
                       │
                       │
                  [Territorios]

Forma: Parece una estrella con la tabla de hechos en el centro y las dimensiones como puntas.

Por qué el modelo estrella es el estándar

Ventaja	Beneficio
Simplicidad	Fácil de entender para cualquiera
Rendimiento	Consultas ultra rápidas
Escalabilidad	Agregar nuevas dimensiones es fácil
Consistencia	Métricas consistentes en todos los reportes
Mantenimiento	Cambiar una dimensión no rompe todo

Comparación: Modelo estrella vs tabla única

Modelo de tabla única (Excel-style):

[Ventas_Todo_En_Una_Tabla]
- VentaID, Fecha, Año, Mes, Trimestre,
- ProductoID, ProductoNombre, Categoría, Precio,
- ClienteID, ClienteNombre, Segmento, Ciudad, País,
- TerritorioNombre, Región
- Cantidad, Monto, Costo

Problemas:

• ✗ Datos duplicados (categoría se repite 10,000 veces)
• ✗ Archivo gigante (1.5 GB vs 300 MB)
• ✗ Actualizar un producto requiere cambiar miles de filas
• ✗ Lento al filtrar
• ✗ Difícil de mantener

Modelo estrella:

[Ventas] (centro)
- VentaID, FechaID, ProductoID, ClienteID, TerritorioID
- Cantidad, Monto, Costo

[Fechas] [Productos] [Clientes] [Territorios]
(cada uno con sus atributos)

Beneficios:

• ✓ Datos no duplicados
• ✓ Archivo 5x más pequeño
• ✓ Actualizar un producto = cambiar 1 fila
• ✓ Consultas 10x más rápidas
• ✓ Fácil de entender y mantener

Anatomía de un modelo estrella perfecto

Tabla de hechos (centro)

Contiene:

• Claves foráneas (IDs que apuntan a dimensiones)
• Métricas numéricas (cantidad, monto, costo)

NO contiene:

• Descripciones textuales
• Atributos que no cambian por transacción

Ejemplo: Tabla Ventas

┌─────────┬────────┬────────────┬───────────┬─────────────┬──────────┬────────┐
│ VentaID │ FechaID│ ProductoID │ ClienteID │ TerritorioID│ Cantidad │ Monto  │
├─────────┼────────┼────────────┼───────────┼─────────────┼──────────┼────────┤
│ 1       │ 20240115│ 301       │ C001      │ T01         │ 5        │ 2,500  │
│ 2       │ 20240115│ 428       │ C002      │ T02         │ 2        │ 1,800  │
│ 3       │ 20240116│ 301       │ C001      │ T01         │ 1        │ 500    │
└─────────┴────────┴────────────┴───────────┴─────────────┴──────────┴────────┘

Tablas de dimensiones (puntas de la estrella)

Contienen:

• Clave primaria única (ID)
• Atributos descriptivos
• Jerarquías (ej: Producto → Categoría → Departamento)

Ejemplo: Tabla Productos

┌────────────┬──────────────────┬─────────────┬────────────┬─────────┐
│ ProductoID │ Nombre           │ CategoríaID │ Categoría  │ Precio  │
├────────────┼──────────────────┼─────────────┼────────────┼─────────┤
│ 301        │ Laptop Dell XPS  │ COMP        │ Computadoras│ 1,299  │
│ 428        │ iPhone 15 Pro    │ CEL         │ Celulares  │ 999    │
└────────────┴──────────────────┴─────────────┴────────────┴─────────┘

Ejemplo completo: Dashboard de ventas

Escenario

Una empresa de retail quiere analizar:

• Ventas por producto, categoría, marca
• Ventas por cliente, segmento, ciudad
• Ventas por fecha, mes, trimestre, año
• Ventas por vendedor, territorio, región

Modelo estrella resultante

Tabla de hechos:

• Ventas (centro)

Tablas de dimensiones:

1. Fechas (calendario completo)
2. Productos (con categoría y marca)
3. Clientes (con segmento)
4. Ciudades (jerarquía geográfica)
5. Vendedores (con territorio y región)

Visualización del modelo

              [Fechas]
         (Fecha, Año, Mes,
          Trimestre, Día)
                │
                │
[Productos] ──── [VENTAS] ──── [Clientes]
(Nombre,         │             (Nombre,
Categoría)       │              Segmento)
                 │
            ┌────┴────┐
            │         │
       [Vendedores] [Ciudades]
       (Nombre,     (Ciudad,
        Territorio)  Estado, País)

Relaciones

Desde (N)	Hacia (1)	Columna
Ventas	Fechas	FechaID
Ventas	Productos	ProductoID
Ventas	Clientes	ClienteID
Ventas	Ciudades	CiudadID
Ventas	Vendedores	VendedorID

Todas son:

• Cardinalidad: N:1
• Dirección: Única (de dimensión → hecho)

Variante: Modelo copo de nieve (Snowflake)

A veces verás un modelo copo de nieve, donde las dimensiones se normalizan aún más.

Ejemplo: Normalizar Productos

Modelo estrella:

[Ventas] → [Productos]
           (ProductoID, Nombre, Categoría, Marca)

Modelo copo de nieve:

[Ventas] → [Productos] → [Categorías]
           (ProductoID,  (CategoríaID,
            Nombre)       Nombre)
              │
              ↓
           [Marcas]
           (MarcaID,
            Nombre)

Cuándo usar cada uno

Modelo	Cuándo usar	Ventaja	Desventaja
Estrella	El 95% del tiempo	Simple, rápido	Algo de duplicación
Copo de nieve	Dimensiones muy grandes	Menos duplicación	Más complejo, más lento

Recomendación: Usa modelo estrella a menos que tengas una razón muy específica para no hacerlo.

Las 7 reglas de oro del modelo estrella

1. Una sola tabla de hechos por estrella

Si tienes múltiples procesos de negocio (ventas, inventario, finanzas), crea múltiples modelos estrella.

Incorrecto:

[Ventas] ←→ [Inventario] ←→ [Productos]
(dos hechos conectados)

Correcto:

Estrella 1:  [Productos] → [Ventas]
Estrella 2:  [Productos] → [Inventario]
(dimensión compartida)

2. Las dimensiones NO se conectan entre sí

Incorrecto:

[Ventas] → [Productos] → [Categorías]

Correcto:

[Ventas] → [Productos]
           (incluye columna Categoría)

Por qué: Simplifica las relaciones y mejora el rendimiento.

3. Usa IDs numéricos en relaciones

Incorrecto: Relacionar por nombres (texto) Correcto: Relacionar por IDs (enteros)

Tipo	Rendimiento	Espacio
Texto ("PROD-001")	Lento	10 bytes/fila
Entero (301)	Rápido	4 bytes/fila

4. La tabla de fechas es obligatoria

Siempre crea una tabla de fechas continua y márcala como tabla de fechas.

Cómo marcarla:

1. Selecciona la tabla Fechas
2. Modelado → Marcar como tabla de fechas
3. Selecciona la columna de fecha

Beneficios:

• Funciones de inteligencia de tiempo (TOTALYTD, SAMEPERIODLASTYEAR)
• Filtros de fecha funcionan correctamente
• Visualizaciones ordenan fechas correctamente

5. Mantén la tabla de hechos delgada

Mal diseño:

Ventas: VentaID, Fecha, Año, Mes, Trimestre,
        ProductoNombre, Categoría, ClienteNombre,
        Segmento, Ciudad, País, Cantidad, Monto
(13 columnas)

Buen diseño:

Ventas: VentaID, FechaID, ProductoID, ClienteID,
        Cantidad, Monto
(6 columnas)

Por qué: La tabla de hechos tiene millones de filas. Cada columna extra multiplica el tamaño del archivo.

6. Agrega columnas calculadas a dimensiones, no a hechos

Ejemplo: Margen de ganancia

Incorrecto (columna calculada en Ventas):

Margen % = (Ventas[Monto] - Ventas[Costo]) / Ventas[Monto]

Problema: Calcula 1 millón de veces (1 por cada venta)

Correcto (medida DAX):

Margen % =
DIVIDE(
    SUM(Ventas[Monto]) - SUM(Ventas[Costo]),
    SUM(Ventas[Monto])
)

Problema: Calcula solo cuando se visualiza

7. Usa nombres consistentes

Convención de nombres:

• Tablas: Singular (Cliente, no Clientes)
• Columnas de ID: [NombreTablaID] (ProductoID, no ID o ProdID)
• Columnas de descripción: [NombreTabla] (ProductoNombre, o simplemente Nombre)

Checklist del modelo estrella perfecto

Antes de crear visualizaciones, verifica:

Estructura:

• Una tabla de hechos en el centro
• Múltiples tablas de dimensiones rodeándola
• Las dimensiones NO se conectan entre sí
• Hay una tabla de fechas marcada correctamente

Relaciones:

• Todas las relaciones son 1:N (dimensión → hecho)
• Dirección de filtro es "Única" en el 95% de casos
• Se usan IDs numéricos, no texto

Tabla de hechos:

• Solo tiene IDs + métricas numéricas
• No tiene descripciones textuales
• Es la tabla más grande (más filas)

Tablas de dimensiones:

• Tienen una clave primaria única
• Contienen atributos descriptivos
• No tienen filas duplicadas en la clave primaria

Rendimiento:

• Archivo .pbix es razonablemente pequeño
• Las visualizaciones cargan rápido (<3 segundos)

Errores comunes a evitar

Error 1: Múltiples tablas de hechos conectadas

[Ventas] ←→ [Pedidos] ←→ [Productos]

Problema: Dificulta calcular métricas combinadas.

Solución: Usa dimensiones conformadas (compartidas entre hechos).

Error 2: Dimensiones conectadas en cadena

[Ventas] → [Productos] → [Categorías] → [Departamentos]

Problema: Los filtros no fluyen correctamente.

Solución: Desnormaliza (trae Categoría y Departamento a la tabla Productos).

Error 3: Usar fechas de la tabla de hechos

Problema: No puedes usar funciones de inteligencia de tiempo.

Solución: Siempre crea una tabla de fechas independiente.

Error 4: Relaciones bidireccionales sin razón

Problema: Causa ambigüedad y lentitud.

Solución: Usa dirección "Única" a menos que tengas una razón muy específica.

Caso real: Antes y después

Antes (modelo caótico)

Estructura:

• 12 tablas de Excel importadas sin cambios
• Relaciones automáticas incorrectas
• Algunas relaciones N:N
• Sin tabla de fechas

Resultado:

• Dashboard tarda 90 segundos en cargar
• Archivo .pbix: 2.1 GB
• Filtros muestran datos incorrectos
• Difícil de mantener

Después (modelo estrella)

Estructura:

• 1 tabla de hechos (Ventas)
• 6 tablas de dimensiones (Fechas, Productos, Clientes, Ciudades, Vendedores, Categorías)
• Todas las relaciones 1:N con dirección única
• Tabla de fechas marcada correctamente

Resultado:

• Dashboard carga en 4 segundos (95% más rápido)
• Archivo .pbix: 380 MB (82% más pequeño)
• Filtros funcionan correctamente
• Fácil de mantener y extender

Ejercicio práctico

Diseña un modelo estrella para este escenario:

Empresa: Plataforma de educación online

Necesitan analizar:

• Inscripciones por curso, categoría, instructor
• Ingresos por estudiante, país, canal de adquisición
• Completado de cursos por fecha
• Calificaciones de cursos

Tu tarea:

1. Identifica la tabla de hechos
2. Lista las tablas de dimensiones necesarias
3. Define las relaciones

Respuesta sugerida:

Tabla de hechos:

• Inscripciones (InscripciónID, FechaID, CursoID, EstudianteID, InstructorID, Precio, Completado, Calificación)

Tablas de dimensiones:

1. Fechas (Fecha, Año, Mes, Trimestre, DíaSemana)
2. Cursos (CursoID, Título, CategoríaID, Categoría, Duración)
3. Estudiantes (EstudianteID, Nombre, PaísID, País, CanalID, Canal)
4. Instructores (InstructorID, Nombre, Especialidad)

Relaciones:

• Inscripciones → Fechas (FechaID)
• Inscripciones → Cursos (CursoID)
• Inscripciones → Estudiantes (EstudianteID)
• Inscripciones → Instructores (InstructorID)

Puntos clave de esta lección

• El modelo estrella es el estándar en BI: simple, rápido y fácil de mantener
• Tiene una tabla de hechos (centro) rodeada por tablas de dimensiones (puntas)
• Las dimensiones NO se conectan entre sí, solo a la tabla de hechos
• Todas las relaciones son 1:N con dirección única
• Siempre crea una tabla de fechas independiente y márcala correctamente
• Mantén la tabla de hechos delgada (solo IDs + métricas)
• El modelo copo de nieve existe, pero el estrella es mejor el 95% del tiempo

Próxima lección

Ya sabes diseñar un modelo estrella perfecto. En la siguiente lección, aprenderás sobre errores comunes de modelado y cómo detectarlos y solucionarlos antes de que causen problemas en tus dashboards.

---

Quiz de comprensión

1. ¿Qué forma tiene un modelo estrella y por qué se llama así?
2. ¿Por qué las tablas de dimensiones NO deben conectarse entre sí?
3. Menciona 3 ventajas del modelo estrella sobre una tabla única gigante
4. ¿Cuál es la diferencia entre un modelo estrella y un modelo copo de nieve? ¿Cuál es mejor?