🎯 Situación

Un cliente me envió un archivo de Power BI el mes pasado. Una sola tabla. 47 columnas. Datos de ventas, datos de clientes, datos de productos, datos de regiones — todo en la misma hoja plana, exportada desde su ERP cada lunes por la mañana.

Funcionaba. Los visuales cargaban. Los números eran correctos. Pero cada vez que agregaban un nuevo slicer o visual, el reporte se ponía un poco más lento. Después de dos años añadiendo columnas, se había vuelto imposible de mantener.

👉 El modelo era una tabla plana — el punto de partida más natural, y uno de los errores de modelado más comunes en Power BI.

La solución era un star schema. No porque sea una casilla de buenas prácticas — sino porque el motor de Power BI está diseñado específicamente para funcionar sobre él.

⚠️ El reto

Cuando la gente conecta datos a Power BI por primera vez, generalmente trabaja con lo que tiene: una tabla grande de un export de Excel o una vista SQL. Se siente limpio y simple. Pero a medida que el modelo crece, aparecen las limitaciones.

📈 Tabla plana

  • Fácil de entender a primera vista
  • Un export, una carga, listo
  • Sin relaciones que gestionar
  • Familiar — se parece a Excel

❌ Lo que termina fallando

  • Datos duplicados por todas partes — mismo nombre de cliente repetido en cada fila de venta
  • Archivo muy pesado — VertiPaq comprime mal sin estructura
  • DAX lento — las medidas iteran sobre millones de filas redundantes
  • Difícil de mantener — agregar un atributo implica tocar toda la tabla
  • Los filtros sobre valores repetidos son costosos e impredecibles

La tabla plana no es mala porque se vea desordenada. Es mala porque el motor de almacenamiento de Power BI — VertiPaq — está orientado a columnas y optimizado para compresión. Rinde mejor cuando cada columna tiene baja cardinalidad y valores limpios, no repetidos.

🔍 Qué es realmente un star schema

Un star schema tiene dos tipos de tablas:

  • Una tabla de hechos — las transacciones. Cada fila es un evento: una venta, un pedido, una entrada de log. Contiene valores numéricos (montos, cantidades) y claves foráneas (IDs que apuntan a las dimensiones).
  • Varias tablas de dimensiones — el contexto. Clientes, productos, fechas, regiones, vendedores. Cada fila es única. Sin duplicados.

La tabla de hechos se conecta a cada tabla de dimensión mediante una relación única. Esa es la estrella — un centro, varias ramas.

Antes: una tabla plana de 47 columnas y 2 millones de filas — NombreCliente repetido 2 millones de veces, CategoríaProducto repetida 2 millones de veces.

Después: una tabla de hechos de 8 columnas (IDs + montos) y tablas de dimensiones con valores únicos. Mismos datos, una fracción del tamaño, filtros que corren en milisegundos.

VertiPaq comprime extremadamente bien los valores repetidos — pero solo si están en una columna dedicada con baja cardinalidad. "México" repetido en una dimensión de Región de 5 filas se comprime a casi nada. "México" repetido 2 millones de veces en una tabla de hechos, no.

✓️ Cómo abordar la migración

No hace falta reconstruir todo desde cero. La mayoría de las tablas planas se pueden convertir en un star schema en pocos pasos:

  • Identificar el grano — ¿qué representa una fila? ¿Una venta? ¿Una línea de pedido? Eso se convierte en tu tabla de hechos.
  • Extraer las columnas descriptivas — nombre de cliente, categoría de producto, región, vendedor → cada uno se convierte en una dimensión con un ID único
  • Conservar solo IDs y métricas en la tabla de hechos — ClienteID, ProductoID, RegiónID, Monto, Cantidad, Fecha
  • Crear las relaciones en Power BI — hechos hacia cada dimensión, uno a muchos, dirección única
  • Siempre agregar una tabla de fechas dedicada — nunca usar directamente una columna de fecha de la tabla de hechos para time intelligence

En el caso del cliente mencionado: la tabla plana de 47 columnas se convirtió en una tabla de hechos de 7 columnas + 5 tablas de dimensiones. El tiempo de carga del reporte pasó de 9 segundos a menos de 2.

💡 Síntesis

El star schema no es un concepto avanzado reservado para ingenieros de datos. Es la estructura básica que hace que Power BI funcione como está pensado.

Tres cosas para recordar:

  • Las tablas planas son un punto de partida, no un destino — funcionan bien a pequeña escala, luego se convierten en un problema cuando los datos crecen
  • Las ganancias de rendimiento son estructurales — ninguna optimización de DAX compensa completamente un dataset mal modelado
  • El star schema también facilita escribir DAX — los filtros se propagan naturalmente de las dimensiones a los hechos, que es exactamente cómo están diseñados CALCULATE y las relaciones

Si tu reporte de Power BI es lento y tu DAX parece correcto, el modelo es casi siempre el verdadero problema. Empieza por ahí antes de optimizar cualquier otra cosa.

👉 Un buen modelo hace el DAX fácil. Un mal modelo hace el DAX imposible.

Corrige los cimientos primero.