Cada vez que alguien me pide «un modelo de datos para Power BI» y me enseña una única tabla gigante con cien columnas, sé que voy a tener una conversación sobre el esquema en estrella. No es una moda ni una preferencia estética: es la forma en la que el motor de Power BI espera que le entreguemos los datos para que todo lo demás —rendimiento, DAX, usabilidad— funcione bien.
Qué es un esquema en estrella
Un star schema divide el modelo en dos tipos de tabla claramente diferenciados. Por un lado, las tablas de dimensión: describen «cosas» del negocio (productos, clientes, fechas, tiendas), tienen pocas filas y una clave única, y sirven para filtrar y agrupar. Por otro, la tabla de hechos: guarda eventos u observaciones (una venta, un movimiento de stock), crece constantemente y contiene las claves foráneas que la conectan con cada dimensión, además de las columnas numéricas que queremos sumar.
Imagina un informe de ventas genérico de una tienda online: una tabla Ventas con una fila por línea de pedido, y a su alrededor las dimensiones Producto, Cliente, Fecha y Tienda. Cada visual del informe, en el fondo, hace lo mismo: filtra por alguna dimensión y suma algo de la tabla de hechos.
Pocas filas, describen entidades del negocio. Se usan para filtrar y agrupar en los visuales.
Muchas filas, una por línea de venta. Contiene las claves hacia cada dimensión y las medidas numéricas (importe, cantidad).
Por qué Power BI lo recomienda frente a un modelo plano o en copo de nieve
Con una única tabla plana (todo desnormalizado en una sola fila por venta, repitiendo el nombre del producto, la categoría, el país del cliente…) el modelo pesa más de lo necesario, comprime peor y es más difícil de mantener: si cambias el nombre de una categoría tienes que tocar miles de filas repetidas.
En el otro extremo está el copo de nieve (snowflake): en vez de una dimensión Producto plana, la partes en Categoría → Subcategoría → Producto. Microsoft es explícito al respecto: recomienda desnormalizar estas cadenas en una única tabla de dimensión siempre que sea posible, porque cada tabla adicional añade una relación más que el motor debe recorrer para propagar un filtro, complica el panel de campos y te impide crear jerarquías de forma natural entre tablas separadas.
Relaciones uno a muchos y dirección del filtro
La relación típica entre una dimensión y la tabla de hechos es uno a muchos: una fila de Producto puede aparecer en muchas filas de Ventas, pero no al revés. En Power BI no existe una propiedad «esta tabla es dimensión / esta es hecho»: lo determina la cardinalidad de la relación. El lado «uno» es la dimensión; el lado «muchos», el hecho.
La dirección del filtro es igual de importante. Lo habitual y recomendado es dirección única: el filtro viaja de la dimensión hacia los hechos (filtras por año y eso reduce las ventas, nunca al revés). La dirección ambas (bidireccional) propaga el filtro en los dos sentidos, y aunque a veces resuelve casos concretos, puede generar filtros circulares o resultados inesperados si no se controla con cuidado.
Idea clave: en el modelo relacional de Power BI, quién es dimensión y quién es tabla de hechos no lo decide el nombre que le pongas, sino la cardinalidad «uno a muchos» de la relación que los une. Diseñar bien esa relación es la base de todo lo demás.
Rendimiento y usabilidad, las dos caras de la misma moneda
Cada visual de un informe genera, por debajo, una consulta que filtra, agrupa y resume. Un modelo en estrella le da al motor justo esa estructura: dimensiones pequeñas para filtrar, una tabla de hechos grande para sumarizar. El resultado es un modelo que comprime mejor, consultas más rápidas y, además, un panel de campos que cualquier persona del equipo entiende de un vistazo sin que tengas que explicarle nada.
- Normaliza en dimensiones y hechos, pero evita cadenas de copo de nieve: colapsa categoría/subcategoría/producto en una sola tabla de dimensión.
- Usa claves subrogadas si tu origen no tiene una clave única y estable para relacionar dimensión y hechos.
- Deja la dirección del filtro en único sentido salvo que tengas un motivo muy concreto para lo contrario, y valida siempre el resultado.
- Si necesitas filtrar por dos fechas distintas (pedido y envío), crea una tabla de fechas por cada rol en vez de forzar una relación inactiva.
- Antes de escribir una sola medida, revisa que cada tabla de hechos tenga claro quiénes son sus dimensiones: ahorra muchos dolores de cabeza en DAX más adelante.
¿Ya tienes el modelo en estrella bien montado? El siguiente paso natural es escribir las métricas encima, y ahí es donde entra en juego DAX.
Leer el artículo sobre medidas vs columnas calculadas en DAX