Modelado de datos de Power BI: diseño de esquemas en estrella para inteligencia empresarial

El modelo de datos es la base de cada informe de Power BI. Un modelo bien diseñado hace que las medidas DAX sean simples, el rendimiento de las consultas sea rápido y el desarrollo de informes sea intuitivo. Un modelo mal diseñado hace que todo sea difícil: las medidas requieren soluciones complicadas, las consultas se ejecutan lentamente y los desarrolladores dedican más tiempo a luchar contra el modelo que a generar conocimientos.

El esquema en estrella es el estándar de oro para los modelos de datos analíticos y lo ha sido durante décadas. Las bases de datos relacionales que impulsan sus sistemas ERP y CRM están diseñadas para brindar eficiencia transaccional utilizando esquemas normalizados con docenas de tablas interconectadas. Este diseño es óptimo para registrar transacciones individuales pero terrible para la agregación, comparación y análisis de tendencias. El esquema en estrella reestructura esos mismos datos para el rendimiento analítico separándolos en tablas de hechos (lo que sucedió) y tablas de dimensiones (el contexto en torno a lo que sucedió).

Esta guía cubre los principios de diseño de esquemas en estrella específicamente para Power BI, incluido cómo crear tablas de hechos y dimensiones, configurar relaciones, escribir medidas DAX eficientes, aprovechar grupos de cálculo, implementar inteligencia de tiempo y usar modelos compuestos para conectarse a múltiples orígenes de datos.

Conclusiones clave

• El esquema en estrella separa los datos en tablas de hechos (medidas numéricas, claves externas) y tablas de dimensiones (atributos descriptivos). --- esta estructura está optimizada para el motor VertiPaq de Power BI.
• Cada relación en un modelo de Power BI debe fluir de dimensión a hecho (uno a muchos), con filtrado cruzado en una sola dirección.
• Las medidas DAX funcionan dramáticamente mejor en esquemas en estrella porque VertiPaq puede comprimir columnas de dimensiones de manera eficiente y filtrar hechos a través de relaciones.
• Los grupos de cálculo reemplazan docenas de medidas redundantes (YTD, QTD, MTD, año anterior) con un patrón único aplicado a todas las medidas base.
• La inteligencia de tiempo requiere una tabla de dimensiones de fecha dedicada. Nunca use fecha/hora automática ni dependa de columnas de fecha en tablas de hechos.
• Los modelos compuestos le permiten combinar datos importados con conexiones DirectQuery, lo que le brinda el rendimiento de las consultas en memoria con la frescura de las consultas en vivo.
• Las dimensiones de juego de roles (una tabla utilizada en múltiples roles de relación) requieren la función USERELATIONSHIP de DAX

---

Fundamentos del esquema en estrella

Por qué el esquema en estrella para Power BI

El motor en memoria de Power BI, VertiPaq, utiliza compresión de columnas para almacenar datos. Comprime cada columna de forma independiente, y las columnas con baja cardinalidad (pocos valores únicos) se comprimen dramáticamente: una columna "País" con 40 valores únicos en 10 millones de filas se comprime hasta casi nada. Las columnas con alta cardinalidad (muchos valores únicos), como los ID de transacciones o las marcas de tiempo, se comprimen mal.

El esquema en estrella aprovecha esto aislando datos transaccionales de alta cardinalidad (fechas, montos, cantidades) en tablas de hechos estrechas y colocando datos descriptivos de baja cardinalidad (nombres, categorías, regiones) en tablas de dimensiones separadas. El resultado es un modelo de datos con menor memoria y más rápido de consultar.

Considere la diferencia. Una tabla plana desnormalizada para un negocio minorista puede tener 50 columnas: Fecha del pedido, Nombre del cliente, Correo electrónico del cliente, Ciudad del cliente, País del cliente, Segmento del cliente, Nombre del producto, Categoría del producto, Subcategoría del producto, Marca, Proveedor, País del proveedor, Cantidad, Precio unitario, Descuento, Importe total, etc. Cada fila repite "Estados Unidos" miles de veces, "Electrónica" cientos de veces y el nombre completo del cliente para cada pedido que haya realizado.

El equivalente del esquema en estrella lo separa en:

FactSales (estrecho, una fila por línea de pedido): OrderDateKey, CustomerKey, ProductKey, Cantidad, UnitPrice, Discount, TotalAmount.

DimCustomer: Clave de cliente, Nombre de cliente, Correo electrónico, Ciudad, País, Segmento.

DimProduct: clave de producto, nombre de producto, categoría, subcategoría, marca.

DimDate: Clave de fecha, Fecha, Año, Trimestre, Mes, Nombre del mes, Día de la semana.

La tabla de hechos tiene sólo 7 columnas en lugar de 50. Cada tabla de dimensiones almacena cada valor único exactamente una vez. VertiPaq comprime esta estructura entre 3 y 5 veces mejor que la tabla plana y las consultas se ejecutan entre 2 y 10 veces más rápido porque el motor filtra tablas de dimensiones pequeñas y luego resuelve solo las filas coincidentes en la tabla de hechos.

Tablas de hechos: principios de diseño

Las tablas de hechos registran eventos comerciales: ventas, pedidos, envíos, tickets de soporte, visitas web, procesos de fabricación. Cada fila representa un evento o una línea de un evento.

Definición de grano. El grano es el nivel de detalle en la tabla de hechos. Defínala con precisión y aplíquela consistentemente. Una tabla de datos de ventas puede tener un tamaño de "una fila por línea de pedido" o "una fila por resumen diario de ventas de productos". Mezclar granos en una sola tabla de hechos (algunas filas son transacciones individuales, otras son agregados diarios) crea errores de cálculo que son extremadamente difíciles de depurar.

Solo claves externas. La tabla de hechos contiene claves externas para tablas de dimensiones, no atributos descriptivos. Una tabla de hechos no debe contener "Nombre de cliente" o "Categoría de producto", ya que pertenecen a las tablas de dimensiones. La tabla de hechos tiene CustomerKey y ProductKey, que enlazan con las dimensiones donde se encuentran los detalles descriptivos.

Medidas aditivas. Las columnas numéricas de una tabla de hechos deben ser aditivas: valores que se pueden sumar de manera significativa en cualquier dimensión. Los ingresos, la cantidad, el costo y el descuento son aditivos. Los porcentajes, las proporciones y los precios unitarios no son aditivos (no se pueden sumar los precios unitarios de todos los productos). Almacene los componentes (numerador y denominador) en la tabla de hechos y calcule la proporción en una medida DAX.

Evite columnas calculadas en hechos. Agregar columnas calculadas a una tabla de hechos aumenta el uso de memoria de la tabla y agrega tiempo de procesamiento durante la actualización. En su lugar, calcule los valores derivados en medidas DAX, que se calculan en el momento de la consulta y no consumen almacenamiento.

Tablas de dimensiones: principios de diseño

Las tablas de dimensiones describen "quién, qué, dónde, cuándo y por qué" de los eventos empresariales. Contienen los atributos que los usuarios filtran, agrupan y dividen.

Claves sustitutas. Utilice claves sustitutas enteras (ClaveCliente, ClaveProducto) como clave principal en las tablas de dimensiones, no claves naturales (correo electrónico del cliente, SKU del producto). Las claves sustitutas son más pequeñas, se comprimen mejor y aíslan el modelo de los cambios en las claves del sistema fuente.

Desnormalizar dimensiones. En un esquema en estrella, las tablas de dimensiones se desnormalizan deliberadamente. Una tabla DimProduct incluye Categoría, Subcategoría y Marca como columnas en la misma tabla, no como tablas normalizadas separadas con sus propias claves. Esto es lo opuesto al diseño de bases de datos transaccionales y es intencional. Las dimensiones desnormalizadas producen consultas más rápidas y DAX más simples porque el motor VertiPaq escanea una sola tabla en lugar de unir varias tablas.

Incluir jerarquías descriptivas. Si los usuarios profundizarán desde Categoría a Subcategoría y Producto, los tres niveles deben ser columnas en DimProduct. Cree un objeto de jerarquía en el modelo de Power BI que defina esta ruta de exploración.

Dimensiones que cambian lentamente. Cuando los atributos de las dimensiones cambian con el tiempo (un cliente se muda de ciudad, un producto cambia de categoría), necesita una estrategia. El tipo 1 (sobrescribir) es el más simple: actualice la fila de dimensión con el nuevo valor. El tipo 2 (agregar nueva fila) conserva el historial: agregue una nueva fila con un rango de fechas efectivo, de modo que las transacciones históricas se asocien con los valores de atributos que estaban vigentes en ese momento. El tipo 2 es más complejo pero necesario cuando la precisión histórica importa (auditorías financieras, informes regulatorios).

---

Configurar relaciones

Reglas de relación para Power BI

Las relaciones de Power BI definen cómo se conectan las tablas y cómo se propagan los filtros. Lograr que las relaciones sean correctas es fundamental: las relaciones incorrectas producen números incorrectos en silencio, lo cual es peor que producir errores.

Solo uno a muchos. Cada relación en un esquema en estrella conecta una tabla de dimensiones (un lado) con una tabla de hechos (varios lados). La tabla de dimensiones tiene valores únicos en la columna clave. La tabla de hechos tiene valores repetidos. Power BI valida esto y marca las infracciones. Si Power BI detecta una relación de muchos a muchos, tiene un problema de modelado que solucionar.

Filtrado cruzado de dirección única. Establezca la dirección del filtro cruzado en "Único" en todas las relaciones. Esto significa que los filtros fluyen de la dimensión al hecho (cuando selecciona un cliente en una segmentación de datos, solo las filas de ese cliente aparecen en los objetos visuales de la tabla de hechos) pero no del hecho a la dimensión. El filtrado bidireccional crea rutas de filtrado ambiguas en modelos con múltiples tablas de hechos y debe evitarse excepto en escenarios muy específicos.

Relaciones activas versus inactivas. Power BI solo permite una relación activa entre dos tablas. Si una tabla de hechos tiene varias columnas de fecha (OrderDate, ShipDate, DeliveryDate), cree una relación activa (normalmente OrderDate a DimDate) y relaciones inactivas para las demás. Utilice la función USERELATIONSHIP en medidas DAX para activar la relación inactiva cuando sea necesario:

Shipped Revenue =
CALCULATE(
    [Total Revenue],
    USERELATIONSHIP(FactSales[ShipDateKey], DimDate[DateKey])
)

Dimensiones del juego de roles

Una dimensión de juego de roles es una tabla de una sola dimensión que cumple múltiples roles en el modelo. La dimensión de fecha es el ejemplo más común: se conecta con OrderDate, ShipDate y DeliveryDate en la tabla de hechos, desempeñando un "papel" diferente en cada relación.

En Power BI, puede controlar las dimensiones de juego de roles de dos maneras:

Relaciones inactivas + USERELATIONSHIP (recomendado). Mantenga una única tabla DimDate con una relación activa (con OrderDate) y relaciones inactivas con las otras columnas de fecha. Cree medidas que utilicen USERELATIONSHIP para las perspectivas de fechas alternativas. Esto mantiene el modelo compacto y evita la duplicación de datos.

Tablas de dimensiones duplicadas. Cree copias separadas de DimDate (DimOrderDate, DimShipDate, DimDeliveryDate), cada una con una relación activa con su respectiva columna de hechos. Este enfoque es más simple desde una perspectiva DAX (no se necesita USERELATIONSHIP) pero aumenta el tamaño del modelo y la carga de mantenimiento.

Para la mayoría de las implementaciones, se prefiere el enfoque de relación inactiva. Produce un modelo más limpio y una menor huella de memoria a costa de un DAX ligeramente más detallado.

Relaciones de muchos a muchos

Algunos escenarios comerciales realmente requieren relaciones de muchos a muchos. Un cliente puede pertenecer a múltiples segmentos, un producto puede estar en múltiples campañas promocionales, un vendedor puede cubrir múltiples territorios. El esquema en estrella los maneja a través de tablas puente.

Una tabla puente se encuentra entre las dos tablas en una relación de muchos a muchos y contiene una fila para cada combinación:

BridgeCustomerSegment: Clave de cliente, Clave de segmento

DimCustomer se conecta a BridgeCustomerSegment (uno a muchos en CustomerKey). DimSegment se conecta a BridgeCustomerSegment (uno a muchos en SegmentKey). La tabla puente permite filtrar FactSales por segmento mientras maneja correctamente a los clientes en múltiples segmentos.

Tenga cuidado con las tablas puente: pueden producir una doble contabilización si no se combinan con medidas DAX apropiadas que manejen la asignación de muchos a muchos. Pruebe minuciosamente con datos conocidos para validar que los totales sean correctos.

---

Medidas DAX: patrones y rendimiento

Medidas base

Todo modelo analítico necesita un conjunto de medidas base que realicen agregaciones simples en columnas de tablas de hechos. Defina estos primero: sirven como componentes básicos para cálculos más complejos.

Total Revenue = SUM(FactSales[TotalAmount])
Total Quantity = SUM(FactSales[Quantity])
Total Cost = SUM(FactSales[CostAmount])
Order Count = COUNTROWS(FactSales)
Average Order Value = DIVIDE([Total Revenue], [Order Count])
Gross Margin = DIVIDE([Total Revenue] - [Total Cost], [Total Revenue])

Observe que el valor promedio del pedido y el margen bruto hacen referencia a otras medidas en lugar de repetir la lógica de agregación. Esto es deliberado: si la definición de ingresos totales cambia (por ejemplo, para excluir retornos), las medidas posteriores reflejan automáticamente el cambio.

CALCULAR: El núcleo de DAX

CALCULATE es la función DAX más importante. Evalúa una expresión en un contexto de filtro modificado. Comprender CALCULATE es comprender DAX.

Revenue Last Year =
CALCULATE(
    [Total Revenue],
    SAMEPERIODLASTYEAR(DimDate[Date])
)

Esta medida toma la medida de Ingresos totales y la evalúa en un contexto de filtro donde el rango de fechas se retrasa un año. Si el contexto del filtro actual es "enero de 2026", CALCULATE lo modifica a "enero de 2025" y evalúa los ingresos totales en ese contexto modificado.

CALCULATE acepta múltiples argumentos de filtro e interactúan de manera diferente según su tipo:

Los filtros de tabla (como SAMEPERIODLASTYEAR) reemplazan el filtro existente en las columnas de esa tabla. Si el objeto visual ya tiene un filtro de mes, SAMEPERIODLASTYEAR lo anula con el mes correspondiente del año anterior.

Los filtros booleanos (como DimProduct[Category] = "Electronics") se agregan al contexto existente. Si la imagen se filtra hasta 2026, el resultado de CALCULAR muestra los ingresos por electrónica de 2026.

REMOVEFILTERS borra los filtros existentes. CALCULATE([Total Revenue], REMOVEFILTERS(DimProduct[Category])) devuelve los ingresos totales en todas las categorías, independientemente de qué filtros de categoría estén activos.

Variables de legibilidad y rendimiento

Las variables (VAR) calculan un valor una vez y hacen referencia a él varias veces. Hacen legibles medidas complejas y eliminan cálculos redundantes:

Revenue YoY Growth =
VAR CurrentRevenue = [Total Revenue]
VAR PriorRevenue = [Revenue Last Year]
VAR Growth = CurrentRevenue - PriorRevenue
VAR GrowthPct = DIVIDE(Growth, PriorRevenue)
RETURN
    GrowthPct

Sin variables, esta medida calcularía [Ingresos totales] e [Ingresos del año pasado] varias veces (una para la resta y otra para la división), duplicando el costo de cálculo. Las variables garantizan que cada una se calcule exactamente una vez.

Funciones de iterador: cuándo usarlas

Las funciones iteradoras (SUMX, AVERAGEX, MAXX, MINX, COUNTX, RANKX) evalúan una expresión fila por fila en una tabla. Son potentes pero costosos: escanean cada fila de la tabla especificada.

Utilice iteradores cuando necesite cálculos a nivel de fila antes de la agregación:

Weighted Average Price =
DIVIDE(
    SUMX(FactSales, FactSales[Quantity] * FactSales[UnitPrice]),
    SUM(FactSales[Quantity])
)

Esto no se puede lograr con una suma simple porque es necesario multiplicar la cantidad por el precio unitario en cada fila antes de sumar. El iterador SUMX maneja esta multiplicación fila por fila.

Evite iteradores cuando un agregado simple sea suficiente. SUMX(FactSales, FactSales[TotalAmount]) es funcionalmente equivalente a SUM(FactSales[TotalAmount]) pero más lento porque el iterador escanea fila por fila mientras SUM aprovecha la compresión de columnas.

---

Grupos de cálculo

Qué resuelven los grupos de cálculo

Antes de los grupos de cálculo, un modelo de datos con 10 medidas base (ingresos, cantidad, costo, margen, etc.) y 5 variaciones de inteligencia temporal (YTD, QTD, MTD, año anterior, año anterior YTD) requería 50 medidas separadas. Agregar una nueva medida base significó crear cinco variantes de inteligencia temporal más. Agregar un nuevo patrón de inteligencia temporal significó crear 10 medidas más. Esta explosión combinatoria hizo que los modelos fueran difíciles de mantener.

Los grupos de cálculo resuelven esto definiendo patrones de inteligencia temporal una vez y aplicándolos a cualquier medida de forma dinámica.

Creación de un grupo de cálculo de inteligencia del tiempo

En Power BI Desktop, cree un grupo de cálculo a través de la vista Modelo o utilizando herramientas externas como Tabular Editor (que proporciona más control).

Defina elementos de cálculo para cada patrón de inteligencia temporal:

Actual: Sin modificación --- devuelve la medida tal como está.

SELECTEDMEASURE()

YTD (año hasta la fecha):

CALCULATE(
    SELECTEDMEASURE(),
    DATESYTD(DimDate[Date])
)

Año anterior:

CALCULATE(
    SELECTEDMEASURE(),
    SAMEPERIODLASTYEAR(DimDate[Date])
)

Año anterior hasta la fecha:

CALCULATE(
    SELECTEDMEASURE(),
    DATESYTD(SAMEPERIODLASTYEAR(DimDate[Date]))
)

Cambio interanual:

VAR CurrentValue = SELECTEDMEASURE()
VAR PriorValue = CALCULATE(SELECTEDMEASURE(), SAMEPERIODLASTYEAR(DimDate[Date]))
RETURN CurrentValue - PriorValue

Cambio % interanual:

VAR CurrentValue = SELECTEDMEASURE()
VAR PriorValue = CALCULATE(SELECTEDMEASURE(), SAMEPERIODLASTYEAR(DimDate[Date]))
RETURN DIVIDE(CurrentValue - PriorValue, PriorValue)

Una vez definido, los usuarios colocan el grupo de cálculo en el eje de columna o fila de un objeto visual, y Power BI aplica cada elemento de cálculo a cualquier medida que esté en los valores. Un grupo de cálculo con 6 elementos reemplaza 60 medidas individuales (para 10 medidas base).

Formato de expresiones de cadena

Cada elemento de cálculo puede tener una expresión de cadena de formato que cambia dinámicamente el formato del número según el cálculo:

Para medidas absolutas (actual, hasta la fecha, año anterior): utilice el formato de la medida base. Para medidas porcentuales (% de cambio interanual): formato como porcentaje.

// Format string for YoY % Change
"0.0%;-0.0%;0.0%"

Esto garantiza que cuando un usuario cambia entre "Actual" (que muestra $1,234,567) y "% de cambio interanual" (que muestra 12,5%), el formato es correcto sin intervención manual.

---

Inteligencia del tiempo

La tabla de dimensiones de fecha

La inteligencia temporal en Power BI requiere una tabla de dimensiones de fecha dedicada. No confíe en la función de fecha/hora automática (desactívela en Archivo → Opciones → Carga de datos): crea tablas de fechas ocultas para cada columna de fecha, inflando su modelo y limitando su control.

Cree una tabla de dimensiones de fecha que cubra el rango completo de sus datos más al menos un año en cada lado. Si su primera transacción es enero de 2020, comience la tabla de fechas en enero de 2019. Si su análisis incluirá pronósticos para 2027, finalice en diciembre de 2027.

Columnas esenciales para una tabla de dimensiones de fecha:

Cree la tabla de fechas en Power Query o como una tabla calculada DAX:

DimDate =
VAR StartDate = DATE(2019, 1, 1)
VAR EndDate = DATE(2027, 12, 31)
RETURN
ADDCOLUMNS(
    CALENDAR(StartDate, EndDate),
    "DateKey", YEAR([Date]) * 10000 + MONTH([Date]) * 100 + DAY([Date]),
    "Year", YEAR([Date]),
    "Quarter", "Q" & QUARTER([Date]),
    "MonthNumber", MONTH([Date]),
    "Month", FORMAT([Date], "MMMM"),
    "DayOfWeek", FORMAT([Date], "dddd"),
    "IsWeekend", WEEKDAY([Date], 2) >= 6
)

Marque la tabla como tabla de fechas en Power BI (Herramientas de tabla → Marcar como tabla de fechas → seleccione la columna Fecha). Esto habilita las funciones de inteligencia de tiempo incorporadas.

Patrones comunes de inteligencia temporal

Con una dimensión de fecha adecuada, las funciones de inteligencia temporal de Power BI manejan los cálculos temporales más comunes:

Año hasta la fecha: DATESYTD(DimDate[Date]) Trimestre hasta la fecha: DATESQTD(DimDate[Date]) Mes hasta la fecha: DATESMTD(DimDate[Date]) Mismo período del año pasado: SAMEPERIODLASTYEAR(DimDate[Date]) 12 meses consecutivos: DATESINPERIOD(DimDate[Date], MAX(DimDate[Date]), -12, MONTH) Período paralelo: PARALLELPERIOD(DimDate[Date], -1, QUARTER) (ventana del mismo tamaño desplazada hacia atrás)

Estas funciones modifican el contexto del filtro de fecha cuando se usan dentro de CALCULATE. Solo funcionan correctamente cuando la columna de fecha proviene de una tabla marcada como Tabla de fechas con un rango de fechas completo y contiguo.

Soporte de calendario fiscal

Si el año fiscal de su organización no se alinea con el año calendario, modifique los cálculos de inteligencia de tiempo para usar el calendario fiscal:

Fiscal YTD Revenue =
CALCULATE(
    [Total Revenue],
    DATESYTD(DimDate[Date], "6/30")  -- Fiscal year ends June 30
)

El segundo argumento de DATESYTD especifica la fecha de fin del año fiscal. Todos los cálculos hasta la fecha utilizan el límite del año fiscal en lugar del 31 de diciembre.

---

Modelos compuestos

Cuándo utilizar modelos compuestos

Los modelos compuestos combinan datos importados (almacenados en VertiPaq) con datos de DirectQuery (consultados en vivo desde la fuente) en un solo modelo. Este enfoque híbrido es valioso cuando necesita el rendimiento de los datos importados para el análisis histórico y la actualidad de los datos en vivo para las métricas operativas.

Escenarios comunes:

Histórico + en tiempo real. Importe 3 años de datos históricos de ventas para análisis de tendencias (consultas rápidas, sin impacto en la base de datos de origen). Conéctese a los datos del mes actual a través de DirectQuery para obtener vistas operativas actualizadas al minuto.

Modelo central + enriquecimiento local. Conéctese a un conjunto de datos administrado centralmente a través de DirectQuery (asegurándose de utilizar las definiciones gobernadas por la organización). Agregue tablas importadas locales para datos específicos de departamentos (objetivos presupuestarios, clasificaciones personalizadas) que no existen en el modelo central.

Múltiples sistemas de origen. Importe datos desde un almacén de datos en la nube (Snowflake, Azure Synapse) y conéctese a través de DirectQuery a una base de datos operativa (PostgreSQL, SQL Server) en un solo informe, sin crear una canalización ETL separada para consolidarlos.

Arquitectura de modelo compuesto

En un modelo compuesto, cada tabla tiene un modo de almacenamiento:

Importar: Los datos se cargan en la memoria de VertiPaq. Rendimiento de consultas más rápido, pero requiere una actualización programada para actualizarse.

DirectQuery: Los datos se consultan en vivo desde la fuente. Siempre actualizado, pero depende del rendimiento de la base de datos de origen.

Dual: La tabla se importa y está disponible para DirectQuery. Se utiliza para tablas de dimensiones que deben relacionarse con tablas de hechos de Importación y DirectQuery.

Establezca tablas de dimensiones que unen los datos de Importación y DirectQuery al modo "Dual". Esto permite que el motor VertiPaq utilice la copia en memoria al filtrar datos de importación y generar consultas SQL al filtrar datos de DirectQuery.

Consideraciones de rendimiento

Los modelos compuestos introducen complejidad. Las consultas que abarcan tablas Import y DirectQuery requieren que Power BI combine resultados de dos motores diferentes, lo que puede ser lento si el origen de DirectQuery no está optimizado.

Minimice las uniones entre fuentes estructurando su modelo para que la mayoría de las consultas analíticas lleguen a Importar tablas. Utilice DirectQuery solo para tablas específicas que requieren actualización en tiempo real. Indexe las tablas de origen de DirectQuery en las columnas utilizadas en relaciones y filtros.

Para las organizaciones que crean modelos de datos complejos de Power BI, los servicios de modelado de datos de ECOSIRE brindan orientación experta sobre el diseño de esquemas en estrella, la optimización de DAX y la arquitectura de modelos compuestos adaptada a su panorama de datos específico y sus requisitos de rendimiento.

---

Optimización del modelo

Reducir el tamaño del modelo

Los modelos grandes consumen más memoria, se actualizan más lentamente y realizan consultas con menor capacidad de respuesta. Optimice el tamaño del modelo mediante estas técnicas:

Elimine las columnas no utilizadas. Si una columna no se utiliza en ningún objeto visual, medida, relación o regla RLS, elimínela. Cada columna consume memoria incluso si no hay ninguna referencia visual a ella. Los infractores comunes incluyen columnas generadas automáticamente, columnas de auditoría (CreatedBy, ModifiedDate) e identificadores técnicos que no tienen ningún propósito analítico.

Reducir la cardinalidad. Las columnas con millones de valores únicos (marcas de tiempo, GUID, campos de texto libre) se comprimen mal. Redondear las marcas de tiempo a la granularidad adecuada (diariamente, cada hora). Reemplace los GUID con claves sustitutas de números enteros. Mueva los campos de texto libre a una tabla de detalles separada que solo se consulta al profundizar.

Utilice tipos de datos adecuados. Power BI almacena "Número entero" de manera más eficiente que "Número decimal". Si una columna contiene solo números enteros (cantidades, recuentos), establezca su tipo en Número entero. Las columnas de texto consumen más memoria que las columnas numéricas de la misma cardinalidad. Cuando sea posible, codifique las categorías de texto como números enteros con una dimensión de búsqueda.

Desactivar fecha/hora automática. La función de fecha/hora automática crea una tabla de fechas oculta para cada columna de fecha en el modelo. Para un modelo con 10 columnas de fecha, son 10 tablas de fechas ocultas que consumen memoria. Deshabilite esta función y utilice en su lugar una única dimensión de fecha explícita.

Diagnóstico de rendimiento de consultas

Utilice DAX Studio para analizar el rendimiento de las consultas más allá de lo que muestra el Analizador de rendimiento integrado de Power BI. DAX Studio revela:

Consultas del motor de almacenamiento. Cuántas consultas se envían al motor VertiPaq y cuántos datos escanean. Menos consultas que analizan menos datos significan un mejor rendimiento.

Actividad del motor de fórmulas. Cuánto trabajo realiza el motor de fórmulas (cálculos fila por fila, expresiones complejas). Un tiempo alto del motor de fórmula indica medidas que deben reescribirse para enviar más trabajo al motor de almacenamiento.

Plan de consulta. El plan de ejecución lógica y física para una consulta DAX, que muestra cómo Power BI descompone una medida en consultas del motor de almacenamiento y operaciones del motor de fórmulas.

Apunte a tiempos de consulta inferiores a 500 ms para imágenes interactivas. Las consultas de más de 2 segundos resultan lentas y desalientan el uso del panel. Si un objeto visual específico excede constantemente los 2 segundos, simplifique su DAX, reduzca el volumen de datos que procesa o muévalo a una página de obtención de detalles donde los usuarios acepten una breve espera.

---

Preguntas frecuentes

¿Debo usar un esquema de estrella o un esquema de copo de nieve en Power BI?

El esquema en estrella casi siempre es la mejor opción para Power BI. El esquema Snowflake normaliza las tablas de dimensiones en subtablas (Categoría → Subcategoría → Producto), lo que funciona bien en bases de datos relacionales pero crea uniones innecesarias en el motor VertiPaq de Power BI. VertiPaq comprime columnas de dimensiones desnormalizadas de manera extremadamente eficiente, por lo que el ahorro de espacio gracias a la formación de copos de nieve es insignificante, mientras que el costo de rendimiento de las relaciones adicionales es real. Aplane sus dimensiones en un esquema de estrella a menos que tenga una razón técnica específica para no hacerlo (como una tabla de dimensiones muy grande con una columna de alta cardinalidad rara vez utilizada que desee aislar).

¿Cuál es el tamaño máximo del conjunto de datos en Power BI?

Power BI Pro admite conjuntos de datos de hasta 1 GB comprimidos. Premium por usuario admite hasta 100 GB. La capacidad premium (P1 y superior) admite hasta 400 GB con almacenamiento de grandes conjuntos de datos habilitado. Estos límites se refieren al tamaño comprimido en memoria, no al tamaño de los datos de origen. VertiPaq normalmente comprime datos en una proporción de 10:1, por lo que un conjunto de datos comprimidos de 1 GB podría representar 10 GB de datos de origen. Para conjuntos de datos que se acercan a estos límites, considere agregaciones, actualizaciones incrementales o modelos compuestos con DirectQuery para obtener datos a nivel de detalle.

¿Cómo manejo las relaciones de muchos a muchos en un esquema en estrella?

Utilice una tabla puente (también llamada tabla de hechos sin hechos o tabla de unión). La tabla puente tiene una fila para cada combinación en la relación de muchos a muchos (por ejemplo, una fila para cada asignación de segmento de cliente). Cree relaciones de uno a muchos desde cada dimensión a la tabla puente. Tenga en cuenta que las tablas puente pueden provocar una doble contabilización; emparéjelos con medidas DISTINCTCOUNT o use CROSSFILTER en DAX para controlar la propagación del filtro. Pruebe minuciosamente con datos conocidos para garantizar que los totales sean correctos.

¿Debo crear columnas calculadas o medidas DAX?

Prefiera medidas a columnas calculadas en casi todos los casos. Las medidas se calculan en el momento de la consulta y no consumen almacenamiento. Las columnas calculadas se calculan durante la actualización y se almacenan en la memoria, lo que aumenta el tamaño del modelo. Utilice columnas calculadas solo cuando necesite el valor disponible para filtrar, ordenar o establecer relaciones (no puede filtrar por una medida en una segmentación de datos, pero puede filtrar por una columna calculada). Una excepción común es una columna concatenada para etiquetas a nivel de fila (Nombre completo = Nombre + " " + Apellido) que los usuarios necesitan en segmentaciones de datos o objetos visuales de tabla.

¿Cómo interactúan los grupos de cálculo con las medidas existentes?

Los grupos de cálculo interceptan la evaluación de la medida envolviendo la medida en la expresión del elemento de cálculo. Cuando un objeto visual contiene una medida y un grupo de cálculo, Power BI aplica el elemento de cálculo a la medida mediante la función SELECTEDMEASURE(). Esto significa que no es necesario modificar sus medidas base. Sin embargo, a las medidas que ya contienen inteligencia de tiempo (como una medida YTD codificada) se les aplicará el grupo de cálculo en la parte superior, lo que potencialmente producirá una doble aplicación. Para evitar esto, defina solo medidas base (agregaciones simples) y use grupos de cálculo exclusivamente para inteligencia de todos los tiempos y lógica de comparación.