DP-600: optimizar cardinalidad y rendimiento de relaciones en modelos semánticos

João Barros 04 de October de 2026 6 min de lectura

Te enseñaré cómo optimizar la cardinalidad y el rendimiento de las relaciones en un modelo semántico (Power BI / Fabric) — una competencia útil para el DP-600 y esencial para modelos escalables y ágiles. Saber esto ayuda a reducir la latencia de las consultas, disminuir el uso de memoria y garantizar resultados correctos en análisis complejos, especialmente en escenarios con millones de filas o cuando se combina Import y DirectQuery.

Qué necesitas saber

En un modelo semántico, las tablas están enlazadas por relaciones (relationships) definidas entre columnas. La cardinalidad (one-to-one, one-to-many, many-to-one, many-to-many) y la dirección del filtro (single, both/directions) afectan tanto a la lógica de los cálculos como al rendimiento de las consultas. Las relaciones son evaluadas por el motor VertiPaq en modo Import y pasan por mecanismos de delegación en modo DirectQuery. Un diseño eficiente evita cálculos innecesarios, reduce uniones y permite que el engine use compresión columnar e índices de forma eficaz.

Ejemplo simple y numérico: supongamos una FactSales con 10 millones de filas y una DimProduct con 10 000 filas. La relación correcta es DimProduct (1) -> FactSales (many). Si DimProduct tiene duplicados o claves mal definidas, la misma consulta que tarda 200 ms con una relación correcta puede pasar a tardar varios segundos o devolver resultados erróneos. En modo Import, columnas enteras y de baja cardinalidad se comprimen mucho mejor que cadenas largas o GUIDs.

Cómo funciona en la práctica

Pasos prácticos para optimizar relaciones:

Verificar unicidad en las tablas de dimensión: las columnas usadas como clave (por ejemplo ProductID) deben ser únicas en la dimensión. Usa DISTINCTCOUNT(DimProduct[ProductID]) para validar en Power BI o una consulta SQL en la ETL. Si existen duplicados, crea una surrogate key (ID entero secuencial) o resuelve la duplicidad en la fase de preparación de datos. En una dimensión típica de 10k filas, la unicidad es fácil de garantizar; ya en dimensiones de clientes con 2M de registros, es crítico.
Elegir la cardinalidad correcta: define one-to-many siempre que una dimensión describa varias filas de fact. Evita many-to-many excepto cuando sea estrictamente necesario — many-to-many frecuentemente requiere una tabla bridge y aumenta el coste de cálculo. Por ejemplo, una relación many-to-many entre 100k clientes y 50k productos puede multiplicar la carga de cálculo y aumentar el tiempo de consulta 5x–10x si no se trata correctamente.
Definir la dirección de filtro mínima: usa single direction filter por defecto. Solo utiliza both direction cuando sea necesario para cross-filtering en visuales específicos. En modelos grandes, both direction puede provocar una propagación de filtros costosa y ambigüedad en las rutas de filtro, elevando el coste de computación y de RAM.
Normalizar claves y tipos: asegura que las columnas de enlace tienen el mismo tipo (entero vs texto) y formato. Conversiones implícitas en tiempo de ejecución degradan el rendimiento. Por ejemplo, enlazar una columna GUID (texto de 36 caracteres) a un entero impide una compresión eficiente y aumenta el tamaño del modelo — la conversión a un ID entero puede reducir el espacio ocupado en 25–50% y disminuir tiempos de consulta en 30–70% en algunos escenarios.
Reducir cardinalidad de las fact keys: si la fact tiene claves muy anchas (p. ej. GUIDs string o claves compuestas), considera mapear a enteros secuenciales para mejorar compresión e indexabilidad. Columnas con alta cardinalidad (millones de valores distintos) reducen la eficacia de la compresión columnar de VertiPaq.
Evitar relaciones cruzadas y ambiguas: mantén un esquema claro (star schema). Relaciones en cadena o cruzadas crean caminos alternativos de filtro que aumentan el coste de cálculo y pueden causar resultados inesperados. Mantén un star schema con dimensiones centralizadas para las fact tables siempre que sea posible.

-- Pseudocódigo DAX para probar unicidad
EVALUATE
SUMMARIZE(
  DimProduct,
  DimProduct[ProductID],
  "CountRows", COUNTROWS(FILTER(DimProduct, DimProduct[ProductID]=EARLIER(DimProduct[ProductID])))
)
-- Busca ProductID con CountRows > 1

En entornos con DirectQuery, minimizar uniones y delegar agregaciones al sistema fuente (por ejemplo SQL del data warehouse) es crucial para mantener latencias bajas. Para modo Import, optimizar cardinalidad y tipos ayuda al engine a usar compresión columnar y reducir memoria, además de acelerar cálculos DAX.

Errores comunes

Usar both-direction por defecto: conduce a un rendimiento degradado y dificulta explicar el comportamiento de los filtros. En un informe con 15 visuales, both-direction puede duplicar el tiempo total de procesamiento porque los filtros se propagan por múltiples caminos.
Ignorar unicidad: establecer una relación one-to-many cuando la dimensión no es única causa resultados incorrectos y confusión en los cálculos. Detecta esto con pruebas de unicidad y validación automática en la ETL.
Mezclar tipos en las columnas de relación: claves de texto vs entero fuerzan conversiones e impiden optimizaciones del motor. Esto puede no solo aumentar la latencia, sino provocar fallos en ciertas funciones DAX que esperan tipos específicos.
Modelos snowflake cuando no es necesario: normalizar en exceso puede obligar a múltiples uniones y penalizar el rendimiento. Prefiere star schema para reporting.

Cómo practicar

Practica con datasets reales y sintéticos: crea una Fact grande (por ejemplo 5–20 millones de filas) y varias Dimensions (5k–50k filas); prueba diferentes configuraciones de cardinalidad y dirección de filtro; mide tiempo de refresh y tiempo de queries en Power BI Desktop o en el entorno Fabric. Usa el Performance Analyzer en Power BI para capturar la duración de queries DAX por visual. Herramientas adicionales como DAX Studio y VertiPaq Analyzer ayudan a analizar planes y compresión.

Ejercicio sugerido: importa una FactSales de 10M filas con ProductID como GUID y mide el tamaño del archivo y el tiempo de consulta; luego transforma el GUID en entero secuencial, reinstala la relación one-to-many y registra la reducción de tamaño del modelo y la mejora de latencia. Anota números (MB, ms) para comparar.

Para preparación formal, utiliza el Practice Assessment OFICIAL gratuito de Microsoft y la study guide oficial (también gratuita). Estos recursos te ayudan a validar conocimientos en las áreas medidas por el DP-600 sin recurrir a material prohibido.

En resumen

Define correctamente la cardinalidad (one-to-many cuando la dimensión es única) para garantizar resultados correctos y mejor rendimiento.
Usa la dirección de filtro mínima (single) y evita both-direction excepto cuando sea necesario.
Asegura unicidad y compatibilidad de tipos en las columnas de enlace para evitar conversiones y errores.
Prueba el rendimiento con datos reales y con el Performance Analyzer; usa DAX Studio/VertiPaq Analyzer para diagnóstico; y consulta los recursos oficiales de Microsoft (Practice Assessment y study guide gratuitos) para estructurar tu estudio.