El esquema en estrella es el concepto clave detrás de una pregunta habitual de DP-900: ¿qué forma deben tener los datos analíticos cuando se almacenan? Las tablas de hechos y de dimensiones, la diferencia entre los diseños en estrella y en copo de nieve, y el modelo de datos analítico (modelo semántico) que se construye encima abarcan dos elementos del Dominio 4 del temario oficial: "Describir opciones para almacenes de datos analíticos" y "Describir características de los modelos de datos en Power BI". Si lo aprendes una vez, puedes responder preguntas de ambas áreas.
Este artículo es una entrega complementaria de nuestra serie de estudio de DP-900. Partiendo de los conceptos de OLTP frente a OLAP y de lago de datos frente a almacenamiento de datos que vimos antes, recorre cómo se organizan realmente los datos analíticos en tablas y cómo se convierten en un modelo en Power BI.
---
¿Por qué los datos analíticos necesitan otra forma?
Piensa en el sistema de pedidos de una tienda en línea. Cada pedido se registra repartido en varias tablas: pedidos, líneas de pedido, clientes, direcciones, productos y pagos. La normalización elimina la duplicación y mantiene rápidas las escrituras, pero responder a "ingresos por región y categoría del último trimestre" obliga a combinar cinco o seis tablas con JOIN.
Es la diferencia entre una caja llena de tiques y un libro de cuentas doméstico bien llevado. Los tiques se guardan rápido de uno en uno, pero para saber cuánto gastaste en comida el mes pasado tienes que revisarlos todos. El libro de cuentas ya ordena fecha, categoría e importe en columnas fijas, así que el total está a la vista.
Por eso los almacenes analíticos no copian sin más los datos transaccionales. Los reorganizan en una forma que sea fácil de agregar.
| Aspecto | Esquema transaccional (OLTP) | Esquema analítico (OLAP) | |------|------|------| | Propósito | Registrar pedidos y pagos de forma rápida y precisa | Agregar y comparar grandes volúmenes de datos | | Principio de diseño | Normalizar para minimizar la duplicación | Separar hechos y dimensiones para agregar con facilidad | | Consulta típica | Leer o actualizar un único pedido | Totales mensuales o regionales, tendencias | | Estructura de tablas | Muchas tablas pequeñas | Una tabla de hechos central más tablas de dimensiones | | Ejemplo típico | Base de datos de pedidos de una tienda en línea | Almacenamiento de datos, modelo de Power BI |
Consejo para el examen: "Transformar datos transaccionales en un esquema optimizado para consultas analíticas" → almacenamiento de datos (data warehouse). El diseño de tablas más común para ello es el esquema en estrella.
---
Tablas de hechos y tablas de dimensiones
Un esquema en estrella se construye con dos tipos de tablas: las tablas de hechos, que guardan los números, y las tablas de dimensiones, que guardan los atributos con los que agrupas y filtras esos números.
Tablas de hechos: lo que pasó, en números
Cada fila de una tabla de hechos es un evento registrado. Una venta, un envío o una lectura de sensor se convierten cada uno en una fila. La fila contiene los valores numéricos que quieres analizar (cantidad, ingresos, coste) y las claves que apuntan a las dimensiones a las que pertenece el evento (clave de fecha, clave de producto, clave de cliente).
Tablas de dimensiones: el "por qué cosa" del análisis
Una tabla de dimensiones representa una entidad por la que agregas. Una dimensión de producto contiene el nombre del producto, la categoría y la marca; una dimensión de cliente contiene el nombre, la ciudad y el nivel. Cada fila tiene un valor de clave único, y la tabla de hechos hace referencia a las filas de la dimensión mediante esa clave.
Casi todos los modelos analíticos incluyen una dimensión de fecha (tiempo). Con una dimensión de fecha que ya tiene columnas de día, mes, trimestre y año, preguntas como "ingresos por mes" o "comparado con el mismo trimestre del año pasado" se responden con facilidad.
| Aspecto | Tabla de hechos | Tabla de dimensiones | |------|------|------| | Qué contiene | Medidas (números) más claves de dimensión | Atributos descriptivos (nombres, categorías, ubicaciones) | | Qué significa una fila | Un evento (una venta) | Una entidad (un producto) | | Número de filas | Muy grande y en crecimiento constante | Relativamente pequeño | | Columnas de ejemplo | Cantidad, ingresos, clave de fecha, clave de producto | Nombre del producto, categoría, marca | | Papel en una consulta | Los valores que sumas o promedias | Aquello por lo que agrupas y filtras |
En un modelo analítico, estas dos ideas se llaman medidas y dimensiones. "Ingresos totales por cliente" y "unidades vendidas al mes por producto" son medidas agregadas según una o más dimensiones.
Consejo para el examen: "Valores numéricos que se van a agregar, como cantidad o ingresos" → tabla de hechos. "Atributos para agrupar o filtrar, como nombre del producto, categoría o ciudad" → tabla de dimensiones.
---
Esquema en estrella vs esquema en copo de nieve
Una sola tabla de hechos en el centro con tablas de dimensiones alrededor parece una estrella; de ahí el nombre de esquema en estrella. Las tablas de dimensiones se relacionan con la tabla de hechos mediante una relación de uno a varios (1:N): un producto aparece en muchos registros de venta, pero cada venta apunta exactamente a un producto.
Un esquema en copo de nieve toma las tablas de dimensiones de un esquema en estrella y las divide todavía más. Por ejemplo, en lugar de repetir el nombre de la categoría dentro de la dimensión de producto, creas una tabla de categorías aparte y la vinculas a la tabla de productos. Las ramas que se extienden hacia fuera recuerdan a un copo de nieve, y de ahí viene el nombre.
!Esquema en estrella vs esquema en copo de nieve
| Aspecto | Esquema en estrella | Esquema en copo de nieve | |------|------|------| | Estructura de la dimensión | Una tabla por dimensión | La dimensión se normaliza en varias tablas | | Cómo se guardan las jerarquías | Columnas en la misma tabla (producto → categoría) | Tablas separadas (tabla de productos → tabla de categorías) | | Número de JOIN | Pocos | Más | | Consultas y modelo | Simples y rápidos | Más complejos | | Duplicación | Se permite algo de duplicación en las dimensiones | Menos duplicación |
La guía oficial de Power BI recomienda diseñar los modelos como esquemas en estrella. Las relaciones simples hacen que los filtros fluyan como esperas y que las fórmulas DAX sean más fáciles de escribir. Cuando el origen tiene forma de copo de nieve, es habitual fusionar las tablas de dimensiones en una sola para que el modelo quede en estrella.
Consejo para el examen: "Una tabla de dimensiones se vincula con otra tabla más (por ejemplo, producto → categoría) para representar una jerarquía" → esquema en copo de nieve. "Las tablas de dimensiones se conectan directamente a una tabla de hechos" → esquema en estrella.
---
De los cubos a los modelos semánticos
Los analistas pueden consultar directamente las tablas del almacenamiento de datos, pero para crear informes y paneles con más facilidad suele añadirse encima un modelo de datos analítico. Es un plano que define de antemano qué tablas se conectan con cuáles, qué cuenta como medida y por qué jerarquías puedes profundizar.
La forma antigua: cubos OLAP
En el pasado, los cubos se creaban con tecnologías como SQL Server Analysis Services (SSAS) Multidimensional. Los números se agregaban previamente y se guardaban para cada combinación de dimensiones, como los ingresos por producto y región. Las consultas eran rápidas, pero cualquier agregación nueva obligaba a volver a procesar el cubo.
La forma actual: modelos semánticos
Power BI y Microsoft Fabric usan un modelo semántico, también llamado modelo tabular. Define tablas, relaciones, jerarquías y medidas escritas en DAX, y las agregaciones se calculan en el momento de la consulta en lugar de guardarse por adelantado. En el modo Import, los datos se cargan en el almacén columnar en memoria del motor VertiPaq para calcular con rapidez. En Fabric, el modo Direct Lake carga las tablas Delta de OneLake directamente en la memoria del modelo sin una copia aparte.
| Aspecto | Cubo OLAP (multidimensional) | Modelo semántico (tabular) | |------|------|------| | Tecnología típica | SSAS Multidimensional | Power BI, Microsoft Fabric | | Cuándo se agrega | Se calcula y se guarda de antemano | Se calcula al consultar | | Cómo se definen los cálculos | MDX y similares | Medidas DAX | | Situación actual | Enfoque heredado | Enfoque recomendado hoy |
Jerarquías de atributos: subir y bajar de nivel
Las jerarquías te permiten moverte entre niveles dentro de una dimensión. Ver los ingresos por año y hacer clic en un año para verlo por meses es profundizar (drill down); volver a la vista anual es subir de nivel (drill up).
Dimensión de fecha: día → mes → año Dimensión de producto: producto → categoría Dimensión de cliente: cliente → ciudad
En la vista Modelo de Power BI Desktop creas las relaciones entre las tablas de hechos y de dimensiones, defines jerarquías y estableces tipos de datos y formatos de presentación. Para la diferencia entre medidas y columnas calculadas, y para los modos de conexión de datos, continúa con Power BI: Conceptos Clave.
Consejo para el examen: "Una estructura multidimensional que guarda los números agregados previamente por dimensión" → cubo. "Empezar con valores anuales y bajar a valores mensuales" → profundizar a través de una jerarquía. "Cargar tablas Delta de Fabric en un modelo sin copiarlas" → Direct Lake.
---
Almacenamiento de datos, lago de datos y lakehouse
Si el esquema en estrella trata de cómo dar forma a las tablas, los almacenes de datos analíticos tratan de dónde viven los datos y en qué forma. DP-900 espera que distingas tres opciones.
| Aspecto | Almacenamiento de datos | Lago de datos | Lakehouse de datos | |------|-----