Crear relaciones en el modelo semántico

Define la lógica inicial de tu modelo vinculando datos entre tablas para poder agrupar, filtrar y segmentar los valores.

En esta serie, compartimos consejos para crear de forma eficaz un modelo semántico. En el artículo anterior, describimos cómo conectarte a los datos y transformarlos para usarlos en un modelo semántico. En este punto, ya tienes tablas y columnas en tu modelo, y estás listo para agregar la lógica de negocio.

En este artículo, describimos uno de los primeros pasos para incorporar esa lógica: crear relaciones entre tablas. Las relaciones son uno de los objetos más importantes de tu modelo. Sin embargo, también son engañosamente simples: es fácil crear relaciones, pero existen muchos tipos y propiedades. Es fácil crear problemas en tu modelo cuando las relaciones y las columnas entre ellas no están configuradas correctamente.

¿Qué es una relación y por qué es tan importante?

Una relación te permite filtrar o agrupar datos de una tabla por columnas de una segunda tabla. Para hacerlo, emparejas columnas equivalentes (conocidas como columnas clave, o claves) de cada tabla. Las relaciones son fundamentales para pasar de un conjunto de puntos de datos desconectados a un modelo funcional de un proceso de negocio.

Figura 1: Agrupas los datos de la tabla ‘Invoices’ para las dimensiones ‘Customer’, ‘Region’ o ‘Date’ mediante relaciones. Usas relaciones en lugar de unir estas cuatro tablas, lo que da como resultado un modelo más organizado y con mejor rendimiento. Por ejemplo, puedes crear una matriz (o Pivot Grid en Tabular Editor) que resuma las líneas de factura (de ‘Invoices’) por las columnas ‘Regions’[System], ‘Customers’[Key Account Name] y ‘Date’[Calendar Year] (p. ej., 2021).

Hay distintos tipos de relaciones que puedes crear en un modelo, pero las relaciones físicas son las más comunes. Estas son las relaciones representadas por flechas entre tablas en la vista de modelo. Creas una relación entre dos columnas, especificando la dirección de la relación y si está activa o no. En un modelo semántico, las relaciones físicas usan estructuras de datos en memoria para permitir una navegación eficiente entre tablas relacionadas. Estas estructuras de datos en memoria son conceptualmente parecidas a un índice SQL, pero se diferencian en que son el resultado de cómo VertiPaq comprime y almacena los datos en memoria.

En otros blogs, vídeos y artículos, oirás hablar de distintos tipos de relaciones físicas. En el siguiente diagrama se muestra una visión general de las relaciones según su cardinalidad (con ejemplos).

Figura 2: Las relaciones difieren en su cardinalidad, como uno a varios (o varios a uno), uno a uno, y varios a varios. También difieren en su direccionalidad, con relaciones unidireccionales y bidireccionales. Las relaciones uno a uno deben ser bidireccionales, pero otros tipos de relación pueden ser unidireccionales o bidireccionales. Ten en cuenta que este ejemplo muestra una relación varios a varios unidireccional limitada, en lugar de una relación varios a varios bidireccional.

Cómo crear relaciones

Puedes crear y administrar relaciones tanto con Power BI Desktop como con Tabular Editor. Como comentamos al principio de este artículo, crear relaciones es muy fácil; lo difícil es asegurarte de que tienes las columnas clave adecuadas y las propiedades configuradas correctamente.

Crear una relación con Power BI Desktop

Puedes crear una relación en Power BI Desktop con la interfaz de usuario en la ventana de la vista de modelo, como se muestra en el siguiente diagrama. Ten en cuenta que, de forma predeterminada, Power BI Desktop detecta automáticamente las relaciones cuando cargas o actualizas por primera vez un modelo semántico local.

Figura 5: En Power BI Desktop, puedes crear relaciones desde la vista Modelo.

Puedes crear una relación en Power BI Desktop de tres formas.

1. Arrastrar y soltar en la vista Modelo: Selecciona la vista Modelo, busca las tablas y arrastra la columna clave de “origen” a la columna clave de “destino”. Puedes hacer doble clic en cualquier relación para editar sus propiedades.
2. Editor de relaciones: Selecciona “Administrar relaciones” en la parte superior de la vista Modelo y selecciona “Nuevo…” para crear una relación nueva. También puedes administrar relaciones existentes.
3. Detectar relaciones automáticamente: Power BI Desktop, de forma predeterminada, detecta automáticamente relaciones entre columnas con nombres y tipos similares, Puedes ajustar este comportamiento desde las opciones de Power BI Desktop. Por lo general, se recomienda desactivar la detección automática de relaciones cuando estás desarrollando tu modelo semántico con Power BI Desktop, porque puede dar lugar a relaciones inesperadas cuando agregas nuevas columnas o modificas el nombre y los tipos de datos de columnas existentes.

Puedes crear relaciones usando la interfaz de usuario o el cuadro de diálogo de C# Script en Tabular Editor, como se muestra en el siguiente diagrama.

Figura 7: En Tabular Editor, puedes crear relaciones desde la vista de diagrama del modelo, el Explorador TOM o un C# Script.

En Tabular Editor, puedes crear relaciones de cuatro formas diferentes.

1. Diagrama del modelo: Crea un nuevo diagrama del modelo, agrega las tablas y luego arrastra la columna clave de “destino” a la columna clave de “origen”. Ten en cuenta que esta es la dirección opuesta a Power BI Desktop. Puedes hacer clic con el botón derecho en cualquier relación para editar sus propiedades.
2. Explorador TOM (grupo de relaciones): Haz clic con el botón derecho en el grupo “Relationships” y selecciona Crear > Relación. También puedes seleccionar cualquier relación existente para modificar sus propiedades desde la ventana Propiedades.
3. Explorador TOM (columna clave): Haz clic con el botón derecho en una columna clave y selecciona Crear > Relación desde o Relación a. Cuando selecciones una tabla en el siguiente cuadro de diálogo de relación, Tabular Editor sugerirá automáticamente una columna clave para una relación plausible y válida.
4. C# Script: Puedes crear y modificar relaciones mediante programación usando scripts en C#. Por ejemplo, puedes usar un C# Script para crear automáticamente relaciones entre columnas con nombres o tipos similares, o en función de otros metadatos que especifiques. Puedes adaptarlo para usar metadatos adicionales o incluso resultados de consultas DAX, y guardar el script como una macro que puedes ejecutar cada vez que crees un modelo nuevo.

Las relaciones son engañosamente simples; no se reduce a arrastrar y soltar. En función de las columnas clave implicadas y de las propiedades de la relación que configures, puedes obtener distintos resultados de consulta, rendimiento y funcionalidad.

Cuando creas una relación, deberías comprobar lo siguiente:

• ¿La cardinalidad es la que esperas? La mayoría de las relaciones deberían ser de uno a varios, desde la dimensión a la tabla de hechos. Si tienes intención de usar una cardinalidad distinta, como muchos a muchos o uno a uno, asegúrate de conocer las consecuencias para el rendimiento de tu modelo y los resultados de las consultas.
• ¿La direccionalidad es la que esperas? La mayoría de las relaciones deberían ser unidireccionales, desde la dimensión a la tabla de hechos. Si tienes intención de usar relaciones bidireccionales —que, por lo general, deberías evitar— asegúrate de evitar la ambigüedad y de conocer las consecuencias para el rendimiento del modelo y los resultados de las consultas.
• ¿La relación está activa? La mayoría de las relaciones físicas deberían estar activas, salvo que estés usando dimensiones con roles y actives la relación mediante la función DAX USERELATIONSHIP dentro de CALCULATE.
• ¿Te faltan claves? Las relaciones deben garantizar la integridad referencial para ser válidas; es decir, que todos los valores de la tabla de hechos (en el lado “a” o “varios” de una relación de uno a varios) tengan un valor correspondiente en la tabla de dimensiones (en el lado “de” o “uno” de una relación de uno a varios). Si te faltan claves, acabarás con valores que se asignan a filas (Blank) o vacías.

Hay muchos conceptos avanzados sobre las relaciones que pueden resultarte útiles, según el modelo que quieras construir y los requisitos que tengas que cubrir.

• Relaciones entre columnas del tipo de datos Date: Una relación entre columnas Date se trata como tipo de datos DateTime, incluso cuando está formateada como Date, Time o Date/Time/Timezone. Hay consideraciones especiales cuando tengas que elegir entre usar columnas de los tipos de datos Date e Integer.
  • Te encuentras con esto cuando creas una tabla de dimensión de fechas y decides cómo se relacionará con tus tablas de hechos.
• Relaciones entre columnas Integer y rendimiento: A menudo se asume que una relación entre columnas de tipo Integer tiene mejor rendimiento que las relaciones entre columnas de otros tipos de datos. A diferencia de una base de datos relacional, no siempre es así.
  • Normalmente te encuentras con esto al diseñar tu modelo y transformar los datos.
• Relaciones virtuales: Un tipo de relación que defines en medidas DAX o en una columna calculada. Para ello, usas funciones como TREATAS, que pueden transferir el contexto de filtro de una tabla a otra. A diferencia de las relaciones físicas, una relación virtual no aprovecha los índices de relación y, por tanto, rinde peor.
  • Usas relaciones virtuales para muchas funcionalidades y características avanzadas Por ejemplo, si quieres reemplazo selectivo de medidas, o si quieres sincronizar segmentadores del Report.
• Relaciones no válidas y la fila (Blank): Un concepto por el que tu modelo agrega una fila (Blank) si hay una violación de integridad referencial en la relación. Las violaciones de integridad referencial se producen cuando hay filas huérfanas en la tabla del lado N, porque la clave tiene valores para los que no existe un valor correspondiente en el otro lado de la relación. Puedes identificar violaciones de RI cuando validas las relaciones (se trata en el siguiente artículo de esta serie). Por ejemplo, puedes usar el Analizador VertiPaq en Tabular Editor 3 para identificar violaciones de RI y ver ejemplos de valores faltantes.
  • A menudo te enfrentas a esto cuando tienes claves en una tabla de hechos que faltan en tu tabla de dimensiones. por ejemplo, nuevos clientes que están en la tabla 'Budget', pero de los que aún no tienes un registro maestro de clientes. Este es un reto habitual.
• Relaciones inactivas: Un tipo de relación que no se usa salvo que se active con la función USERELATIONSHIP en DAX. Usas relaciones inactivas con dimensiones con roles. Las relaciones inactivas cuentan a la hora de determinar violaciones de integridad referencial y si el motor VertiPaq debe agregar una fila (Blank) a la tabla.
  • Puede que necesites esto cuando una dimensión, como Date, debería tener una relación con varias columnas de una tabla de hechos, como [Order Date], [Billing Date] y [Goods Issue Date]. Por ejemplo, quizá quieras permitir que los usuarios elijan qué fecha usar para resumir los datos.
• Relaciones bidireccionales y ambigüedad en DAX: Un escenario en el que varias relaciones bidireccionales pueden crear rutas alternativas para propagar filtros. Esto puede producir resultados inesperados cuando resumes datos.
  • Puede que te encuentres con esto cuando decidas usar relaciones bidireccionales en un modelo. Esto suele ocurrir si usas relaciones bidireccionales para sincronizar segmentadores (no lo hagas; hay mejores enfoques).
• Relaciones bidireccionales y seguridad a nivel de filas (RLS): Un escenario en el que usas relaciones bidireccionales y haces que el filtro de seguridad también se propague en ambas direcciones.
  • Puede que te encuentres con esto cuando hayas configurado RLS en tu modelo semántico para una tabla que forma parte de una cadena de relaciones en la que una o más relaciones usan filtrado cruzado bidireccional.
• Tablas expandidas en DAX: Un concepto en DAX en el que la tabla ‘base’ en una relación de muchos a uno o de uno a uno incluye todas las columnas de las tablas relacionadas. Usas tablas expandidas para acceder a columnas relacionadas de una tabla referenciada en algunas expresiones DAX.
  • Te encuentras con esto cuando quieres realizar cálculos DAX más avanzados, por ejemplo, si quieres conversión dinámica de divisa.
• Relaciones limitadas: Un concepto en el que no se puede garantizar la integridad referencial; no hay un lado “uno” garantizado en una relación de uno a varios. Las relaciones limitadas no usan tablas expandidas.
  • Te encuentras con esto cuando usas relaciones de muchos a muchos, o relaciones en algunos modelos compuestos (conocidas como relaciones de grupo entre orígenes).
• Asumir la integridad referencial: Una propiedad de la relación que puedes habilitar en Power BI Desktop o Tabular Editor (llamada Confiar en la integridad referencial) cuando tienes un modelo semántico en modo de almacenamiento DirectQuery. Asumir la integridad referencial hace que las tablas usen un INNER JOIN en lugar de un OUTER JOIN, lo cual puede mejorar el rendimiento. Esta mejora de rendimiento depende del planificador de consultas y de los índices en la base de datos de origen usados en el modelo DirectQuery.
  • Te encuentras con esto cuando creas y optimizas modelos DirectQuery o modelos Direct Lake con la conmutación por error a DirectQuery habilitada.

En conclusión

Las relaciones son uno de los objetos más importantes de tu modelo y los primeros objetos que creas una vez que ya has configurado tablas y columnas. Crear relaciones es sencillo, pero hay muchas propiedades adicionales y escenarios que debes considerar para que tus relaciones se comporten como esperas. En el siguiente artículo de esta serie, te mostraremos cómo puedes validar tus relaciones en un modelo semántico usando Power BI Desktop, Microsoft Fabric y Tabular Editor.