Esquema estrella en Power BI: hechos, dimensiones y claves

El esquema estrella es la forma de organizar las tablas que Microsoft recomienda para cualquier modelo de Power BI, y es también la decisión que más determina si un informe responde en un segundo o en veinte. En concreto, esta guía explica qué son las tablas de hechos y las de dimensiones, cómo se relacionan, qué cardinalidad elegir y por qué la tabla plana que sale del sistema de origen casi nunca sirve tal cual.

Además, está escrita en dos niveles. Si usted arma informes para su área y no se considera técnico, los primeros apartados y las tablas del caso le bastan para entender qué pedir. En cambio, si administra la plataforma, encontrará la cardinalidad, las relaciones inactivas, las claves sustitutas y los patrones de dimensión que aparecen en cuanto el modelo crece.

Una serie de seis guías sobre el mismo conjunto de datos

Esta guía es la primera de seis. En efecto, las seis usan el mismo caso —la mesa de servicio de una empresa con cuatro sedes— y cada una obtiene de él un resultado distinto, así que se pueden leer en orden o por separado:

1. Esquema estrella: hechos, dimensiones y claves (esta guía).
2. CALCULATE: contexto de filtro y modificadores.
3. Tabla de fechas y cálculos de tiempo.
4. Visualizaciones: qué gráfico usar en cada caso.
5. Áreas de trabajo, aplicaciones y actualización.
6. Licencias: Free, Pro, PPU y capacidad.

Antes de esta serie conviene tener a mano dos piezas previas del blog: la introducción a Power BI y su flujo completo, y la de Power Query, que es donde se limpian los datos antes de que lleguen al modelo. Es decir, aquí empezamos justo donde aquella termina.

Qué es un esquema estrella

En primer lugar, un esquema estrella clasifica cada tabla del modelo en una de dos familias. Las tablas de hechos guardan sucesos que se cuentan o se suman: un ticket abierto, una venta, una licencia consumida. Las tablas de dimensiones describen las cosas por las que uno quiere filtrar y agrupar: la sede, la categoría, el técnico, la fecha.

Dibujado, en efecto, el resultado se parece a una estrella: la tabla de hechos en el centro y las dimensiones alrededor, cada una unida por una sola relación. De ahí el nombre. Además, es un método con cuarenta años de uso en almacenes de datos y no lo inventó Power BI; lo que sí hace Power BI es recomendarlo expresamente porque su motor está diseñado para ese reparto.

La razón es mecánica. En efecto, cada objeto visual de un informe genera una consulta que filtra, agrupa y resume. Por lo tanto, un modelo bien hecho es simplemente el que ofrece tablas para filtrar y agrupar por un lado, y tablas para sumar por el otro. Por consiguiente, el esquema estrella es exactamente ese reparto.

Conviene aclarar algo que confunde a mucha gente: en Power BI no existe una casilla para marcar una tabla como «hecho» o como «dimensión». En realidad, el tipo lo determina la relación. El lado «uno» de una relación siempre es una dimensión y el lado «varios» siempre es un hecho.

El caso sobre el que se monta el esquema estrella

Para verlo, trabajaremos con la mesa de servicio de una empresa colombiana con cuatro sedes, durante el tercer trimestre de 2026. Ciertamente, son cifras pequeñas a propósito, para que se puedan comprobar a mano, pero la estructura es idéntica a la de un caso de cien mil filas.

Por lo demás, los 1.240 tickets se reparten así, y estas cifras reaparecen en las seis guías:

Por otra parte, la misma cifra se agrupa también por categoría:

Es decir, las dos agrupaciones dan 1.240. Ese cuadre es la primera comprobación que hay que hacer siempre después de cargar datos, y en la guía de Power Query se explica cómo detectar cuándo deja de cumplirse.

La tabla de hechos: lo que se suma

Por lo general, una tabla de hechos tiene dos clases de columnas. Por un lado, las claves que apuntan a cada dimensión; por otro, las medidas numéricas que se van a resumir. Así queda Tickets en el caso:

Ahora bien, dos conceptos se esconden ahí. Por un lado, la dimensionalidad es cuántas claves de dimensión tiene la tabla: aquí, cinco. Por otro, la granularidad es qué representa una fila: aquí, un ticket individual. Sin embargo, no son lo mismo, y confundirlas produce dobles conteos.

Además, la granularidad tiene que ser uniforme. Si en la misma tabla mezclara filas de tickets individuales con filas de resumen mensual, cualquier suma saldría inflada. Por eso el segundo hecho del caso, Consumo, va en su propia tabla: su grano es mes, sede y plan, no ticket.

Las dimensiones del esquema estrella: filtrar y agrupar

En cambio, una dimensión tiene una columna clave única y todas las columnas descriptivas que hagan falta. Suele tener pocas filas y crecer despacio, mientras que la tabla de hechos crece sin parar. De hecho, la dimensión Sedes del caso cabe entera aquí:

Fíjese, por ejemplo, en la columna Región. No aporta ninguna cifra, pero permite agrupar cuatro sedes en tres regiones sin tocar la tabla de hechos. Es decir, esa es justamente la utilidad de una dimensión: cada columna nueva es una forma nueva de mirar los mismos hechos.

Tabla plana o esquema estrella

Al principio, casi todo el mundo empieza con una exportación única: 1.240 filas con el nombre de la sede, el de la categoría y el del técnico repetidos en cada fila. Funciona, y por eso engaña. Sin embargo, tiene cuatro problemas que aparecen más tarde, cuando ya cuesta rehacer el trabajo.

De los cuatro, el último es el decisivo. En cuanto aparece un segundo hecho —el consumo de licencias, el inventario, el presupuesto—, la tabla plana se queda sin salida. Con dimensiones compartidas, en cambio, los dos hechos se filtran a la vez con la misma segmentación de sede.

Con todo, hay una excepción honesta: para una exploración de media hora sobre un archivo que nadie volverá a abrir, la tabla plana es la decisión correcta. En cambio, el esquema estrella se justifica cuando el informe va a vivir.

Relaciones: cardinalidad y dirección del filtro

En un esquema estrella, una relación une una columna de una tabla con otra y define por dónde viaja el filtro. Tiene dos propiedades que hay que mirar siempre, porque Power BI las deduce solo y a veces se equivoca.

Una relación varios a varios no siempre es un error, pero sí es siempre un aviso. En el caso, si Sedes trajera la sede duplicada por un error de carga, Power BI propondría varios a varios y los totales dejarían de cuadrar en silencio. Por eso conviene comprobar que la columna clave de cada dimensión no tiene repetidos antes de crear la relación.

Además, la segunda propiedad es la dirección del filtro cruzado. Por omisión es sencilla: la dimensión filtra al hecho, y no al revés. Ponerla en ambos sentidos parece cómodo, pero introduce caminos de filtrado difíciles de predecir cuando hay varias dimensiones. La regla práctica es dejarla sencilla y resolver los casos puntuales con CROSSFILTER dentro de una medida, como se ve en la guía siguiente.

Cuando la dimensión no tiene clave única

Por desgracia, a veces el origen entrega una lista sin identificador: nombres de técnico, por ejemplo. Entonces hay que fabricar una clave sustituta, que es un identificador que no existía en los datos y que solo sirve para sostener la relación.

En la práctica, en Power Query se hace añadiendo una columna de índice a la tabla de dimensión y combinándola después con la de hechos, para que el número viaje a las dos. Con todo, es un paso de dos minutos que evita meses de relaciones ambiguas. Además, una clave numérica ocupa mucho menos que un nombre repetido.

Una dimensión con dos papeles: las fechas

Por ejemplo, en el caso hay dos fechas por ticket: cuándo se abrió y cuándo se cerró. Las dos querrían conectarse a Calendario, pero Power BI solo admite una relación activa entre dos tablas. Por eso la segunda queda inactiva, dibujada con línea punteada.

Eso se llama dimensión de rol, y tiene dos soluciones. La primera es dejar la relación inactiva y activarla dentro de una medida concreta con USERELATIONSHIP. La segunda es duplicar la dimensión: una tabla Fecha de apertura y otra Fecha de cierre, cada una con su relación activa.

Además, con dimensiones duplicadas conviene renombrar las columnas: Año de cierre en vez de Año. De lo contrario, los títulos de los gráficos salen ambiguos y nadie sabe qué está mirando. Por lo demás, la tercera guía de la serie entra en detalle en esa tabla de calendario.

La dimensión de copo de nieve: cuándo desnormalizar

Si, en cambio, Categorias se dividiera en categoría y subcategoría en dos tablas encadenadas, tendríamos un copo de nieve en lugar de una estrella. Es legítimo, pero cuesta: más tablas que cargar, cadenas de filtrado más largas, un panel de datos más confuso y, sobre todo, la imposibilidad de crear una jerarquía que abarque columnas de dos tablas distintas.

Por lo general compensa combinar las dos tablas en una sola dimensión desnormalizada. De hecho, es la única excepción recomendada a la regla de normalizar, y conviene tomarla casi siempre que la dimensión sea pequeña.

Cuatro patrones del modelado dimensional

Cuando el modelo lleva unos meses en uso, siempre surgen los mismos cuatro casos. Conviene reconocerlos por su nombre, porque así es como están documentados.

Sin embargo, el último merece un aviso. Por ejemplo, si un técnico pasa de Cali a Bogotá en agosto, hay que decidir si los tickets de julio siguen contando para Cali. Guardar dos versiones del técnico, cada una con su rango de validez, es lo que permite responder bien; pero eso Power Query no lo genera solo, así que el origen tiene que traerlo.

Cómo queda el modelo en estrella del caso

Con todo lo anterior, el modelo final tiene siete tablas y siete relaciones. Así se leen:

Observe además que Sedes alimenta las dos tablas de hechos. En definitiva, esa es la pieza que hace posible la pregunta que interesa a la dirección: si Cali cumple el SLA cuatro puntos por debajo de Bogotá, ¿tiene menos licencias por puesto? Con una tabla plana, en cambio, esa pregunta no se puede formular.

Errores frecuentes al montar un esquema estrella

En conjunto, estos seis explican la mayoría de los modelos que hay que rehacer:

De todos ellos, el cuarto es el más silencioso y el más caro. Si no se desactiva, Power BI crea una tabla de calendario oculta por cada columna de fecha del modelo; con dos fechas en Tickets son dos tablas invisibles que ocupan espacio y no sirven para nada, porque no pueden filtrar dos tablas a la vez.

Qué comprobar antes de seguir

Por último, una lista corta para revisar cualquier modelo antes de escribir la primera medida:

Si las seis salen bien, entonces el modelo está listo. A partir de ahí, las medidas se escriben solas, o casi: es el asunto de la segunda guía de esta serie, dedicada a CALCULATE y al contexto de filtro.

En resumen: el esquema estrella en seis comprobaciones

En definitiva, un esquema estrella no es una sofisticación opcional, sino el reparto que espera el motor: dimensiones que filtran, hechos que se suman y una relación uno a varios entre cada par. Así pues, con siete tablas bien puestas el modelo del caso responde cualquier pregunta sobre 1.240 tickets y 36 filas de consumo, incluidas las que cruzan ambos.

Por último, si lo que necesita es que alguien administre las licencias, los usuarios y los accesos de Microsoft 365 sobre los que se apoya todo esto, esa es la conversación de nuestro servicio de gestión de plataformas. Modelar bien es cuestión de método; mantener la plataforma al día, todos los días, es otra cosa.