Relaciones de modelo en Power BI Desktop

Este artículo está dirigido a modeladores de datos de importación que trabajan con Power BI Desktop. Es un tema de diseño de modelos importante que es esencial para ofrecer modelos intuitivos, precisos y óptimos.

Para obtener una explicación más detallada sobre el diseño óptimo del modelo, incluidos los roles de tabla y las relaciones, consulte Descripción del esquema de estrella y la importancia de Power BI.

Propósito de la relación

Una relación de modelo propaga los filtros aplicados en la columna de una tabla de modelo a una tabla de modelo diferente. Los filtros se propagarán siempre que haya una ruta de relación que seguir, lo que puede implicar la propagación a varias tablas.

Las rutas de relación son deterministas; es decir, los filtros siempre se propagan de la misma manera y sin variación aleatoria. Sin embargo, las relaciones pueden deshabilitarse o tener un contexto de filtro modificado por los cálculos del modelo que usan funciones DAX concretas. Para obtener más información, consulte el tema Funciones DAX pertinentes más adelante en este artículo.

Importante

Las relaciones de los modelos no garantizan la integridad de los datos. Para obtener más información, consulte el tema Evaluación de relaciones más adelante en este artículo, que explica cómo se comportan las relaciones de modelo cuando hay problemas de integridad de datos con los datos.

Este es el modo en que las relaciones propagan filtros con un ejemplo animado.

En este ejemplo, el modelo consta de cuatro tablas: Categoría, Producto, Año y Ventas. La tabla Category se relaciona con la tabla Product y la tabla Product se relaciona con la tabla Sales . La tabla Year también se relaciona con la tabla Sales . Todas las relaciones son de uno a varios (los detalles de los cuales se describen más adelante en este artículo).

Una consulta, posiblemente generada por una tarjeta visual de Power BI, solicita la cantidad total de ventas de pedidos de una sola categoría, Cat-A, y para un solo año, CY2018. Es por eso que puede ver los filtros aplicados en las tablas Categoría y Año . El filtro de la tabla Category se propaga a la tabla Product para aislar dos productos asignados a la categoría Cat-A. A continuación, los filtros de la tabla Product se propagan a la tabla Sales para aislar solo dos filas de ventas para estos productos. Estas dos filas de ventas representan las ventas de productos asignados a la categoría Cat-A. Su cantidad combinada es de 14 unidades. Al mismo tiempo, el filtro de la tabla Year se propaga para filtrar aún más la tabla Sales, lo que da como resultado solo la fila de ventas que corresponde a los productos asignados a la categoría Cat-A y que se pidieron en el año CY2018. El valor de cantidad devuelto por la consulta es de 11 unidades. Tenga en cuenta que cuando se aplican varios filtros a una tabla (como la tabla Sales de este ejemplo), siempre es una operación AND, lo que requiere que todas las condiciones sean verdaderas.

Aplicar principios de diseño de esquema de estrella

Se recomienda aplicar principios de diseño de esquema de estrella para generar un modelo que comprende tablas de dimensiones y hechos. Es habitual configurar Power BI para aplicar reglas que filtren las tablas de dimensiones, lo que permite que las relaciones del modelo propaguen eficazmente esos filtros a las tablas de hechos.

La siguiente imagen es el diagrama del modelo de datos de análisis de ventas de Adventure Works. Muestra un diseño de esquema de estrella que consta de una sola tabla de hechos denominada Ventas. Las otras cuatro tablas son tablas de dimensiones que admiten el análisis de medidas de ventas por fecha, estado, región y producto. Observe las relaciones del modelo que conectan todas las tablas. Estas relaciones propagan filtros (directa o indirectamente) a la tabla Sales .

Tablas desconectadas

Es poco frecuente que una tabla del modelo no esté relacionada con otra tabla del modelo. Esta tabla en un diseño de modelo válido se describe como una tabla desconectada. La tabla desconectada no pretende propagar filtros a otras tablas del modelo. En vez de ellos, acepta la "entrada del usuario" (quizás con un objeto visual de segmentación), lo que permite que los cálculos del modelo usen el valor de entrada de una manera significativa. Por ejemplo, considere una tabla desconectada que se carga con un intervalo de valores de tipo de cambio de moneda. Siempre que se aplique un filtro para filtrar por un valor de tasa único, una expresión de medida puede usar ese valor para convertir los valores de ventas.

El parámetro de hipótesis de Power BI Desktop es una característica que crea una tabla desconectada. Para más información, consulte Creación y uso de un parámetro de hipótesis para visualizar variables en Power BI Desktop.

Propiedades de relación

Una relación de modelo relaciona una columna de una tabla con una columna de otra tabla. (Hay un caso especializado en el que este requisito no es cierto y solo se aplica a las relaciones de varias columnas en los modelos de DirectQuery. Para obtener más información, consulte el artículo sobre la función DAX COMBINEVALUES ).

Nota:

No es posible relacionar una columna con una columna diferente en la misma tabla. A veces, este concepto se confunde con la capacidad de definir una restricción de clave externa de base de datos relacional que suponga una referencia de la tabla a sí misma. Puede usar este concepto de base de datos relacional para almacenar relaciones de elementos primarios y secundarios (por ejemplo, cada registro de empleado está relacionado con un empleado del que depende). Sin embargo, no puede usar relaciones de modelo para generar una jerarquía de modelos basada en este tipo de relación. Para crear una jerarquía de padre e hijo, consulte Funciones de padre e hijo.

Tipos de datos de columnas

El tipo de datos para las columnas "from" y "to" de la relación debe ser idéntico. Trabajar con relaciones definidas en columnas DateTime podría no comportarse según lo previsto. El motor que almacena datos de Power BI, solo usa tipos de datos DateTime ; Los tipos de datos Date, Time y Date/Time/Timezone son construcciones de formato de Power BI implementadas en la parte superior. Los objetos dependientes del modelo seguirán apareciendo como DateTime en el motor (como relaciones, grupos, etc.). Por lo tanto, si un usuario selecciona Fecha en la pestaña Modelado para estas columnas, todavía no se registra como la misma fecha, ya que el motor sigue considerando la parte de hora de los datos. Obtenga más información sobre cómo se controlan los tipos de fecha y hora. Para corregir el comportamiento, los tipos de datos de columna deben actualizarse en el Editor de Power Query para quitar la parte hora de los datos importados, por lo que cuando el motor controla los datos, los valores aparecerán iguales.

Cardinalidad

Cada relación de modelo está definida por un tipo de cardinalidad. Hay cuatro opciones de tipo de cardinalidad, que representan las características de los datos de las columnas relacionadas 'desde' y 'hasta'. El lado "uno" significa que la columna contiene valores únicos; el lado "varios" significa que la columna puede contener valores duplicados.

Nota:

Si una operación de actualización de datos intenta cargar valores duplicados en una columna de lado "uno", se producirá un error en la operación completa de actualización.

En la siguiente lista, se describen las cuatro opciones junto con sus anotaciones abreviadas:

• Uno a muchos (1:*)
• Varios a uno (*:1)
• Uno a uno (1:1)
• Varios a varios (*:*)

Cuando se crea una relación en Power BI Desktop, el diseñador detecta y establece automáticamente el tipo de cardinalidad. Power BI Desktop consulta el modelo para saber qué columnas contienen valores únicos. Para los modelos de importación, usa estadísticas de almacenamiento internas; para los modelos de DirectQuery, envía consultas de generación de perfiles al origen de datos. No obstante, Power BI Desktop puede equivocarse a veces. Esto sucede porque todavía tienen que cargarse los datos de las tablas o porque las columnas que espera que contengan valores duplicados actualmente contienen valores únicos. En cualquiera de estos casos, puede actualizar el tipo de cardinalidad, siempre que las columnas del lado "uno" contengan valores únicos (o la tabla aún se deba cargar con filas de datos).

Cardinalidad de uno a varios (y de varios a uno)

Las opciones de cardinalidad uno a varios y varios a uno son básicamente iguales y también son los tipos de cardinalidad más comunes.

A la hora de configurar una relación de uno a varios o de varios a uno, deberá elegir la que coincida con el orden en el que relacionó las columnas. Considere cómo configuraría la relación desde la tabla Product (Producto) a la tabla Sales (Ventas) mediante la columna ProductID (IdProducto) incluida en cada tabla. El tipo de cardinalidad sería uno a varios, ya que la columna ProductID de la tabla Product contiene valores únicos. Si relacionó las tablas en la dirección inversa, Sales a Product, entonces la cardinalidad sería de varios a uno.

Cardinalidad de uno a uno

Una relación de uno a uno significa que ambas columnas contienen valores únicos. Este tipo de cardinalidad no es común y probablemente representa un diseño de modelo poco óptimo debido al almacenamiento de datos redundantes.

Para obtener más información sobre el uso de este tipo de cardinalidad, vea Instrucciones para relaciones uno a uno.

Cardinalidad de varios a varios

Una relación de muchos a muchos significa que ambas columnas pueden contener valores duplicados. Este tipo de cardinalidad no se usa con frecuencia. Suele resultar útil cuando se diseñan requisitos de modelos complejos. Puede usarla para relacionar hechos de varios a varios o para relacionar hechos de mayor intervalo de agregación. Por ejemplo, cuando los datos de destinos de ventas se almacenan en el nivel de categoría de producto y la tabla de dimensiones de producto se almacena en el nivel de producto.

Para obtener instrucciones sobre el uso de este tipo de cardinalidad, vea Instrucciones para relaciones de varios a varios.

Nota:

El tipo de cardinalidad de varios a varios es compatible con los modelos desarrollados para Power BI Report Server de enero de 2024 y versiones posteriores.

Sugerencia

En la vista de modelo de Power BI Desktop, puede interpretar el tipo de cardinalidad de una relación si examina los indicadores (1 o *) en cualquiera de los lados de la línea de relación. Para determinar qué columnas están relacionadas, deberá seleccionar o mantener el cursor sobre la línea de relación para resaltar las columnas.

Dirección del filtro cruzado

Cada relación de modelo está definida con una dirección de filtro cruzado. El valor determina en qué direcciones se propagarán los filtros. Las posibles opciones de filtro cruzado dependen del tipo de cardinalidad.

Tipo de cardinalidad	Opciones de filtro cruzado
Uno a varios (o varios a uno)	Soltero Ambos
Uno a uno	Ambos
Varios a varios	Único (Tabla1 a Tabla2) Único (Tabla2 a Tabla1) Ambos

La dirección del filtro cruzado Único significa "dirección única" y Ambos se aplica a "ambas direcciones". Normalmente, una relación que filtra ambas direcciones se describe como bidireccional.

En el caso de las relaciones de uno a varios, la dirección del filtro cruzado siempre es desde el lado "uno" y, opcionalmente, desde el lado "varios" (bidireccional). En el caso de las relaciones de uno a uno, la dirección del filtro cruzado siempre es desde ambas tablas. Por último, en las relaciones de varios a varios, la dirección del filtro cruzado puede ser desde cualquiera de las tablas o desde ambas tablas. Tenga en cuenta que cuando el tipo de cardinalidad incluye un lado "uno", los filtros siempre se propagarán desde ese lado.

Cuando la dirección del filtro cruzado se establece en Ambos, otra propiedad estará disponible. Se puede aplicar el filtrado bidireccional cuando Power BI impone las reglas de seguridad de nivel de fila (RLS). Para más información sobre RLS, consulte Seguridad de nivel de fila (RLS) con Power BI Desktop.

Puede modificar la dirección del filtro cruzado de la relación, incluida la deshabilitación de la propagación de filtros, mediante un cálculo del modelo. Se logra mediante la función DAX CROSSFILTER .

Tenga en cuenta que las relaciones bidireccionales pueden afectar negativamente al rendimiento. Además, intentar configurar una relación bidireccional podría producir rutas de propagación de filtro ambiguas. En este caso, es posible que Power BI Desktop no pueda confirmar el cambio de relación y le avisará con un mensaje de error. Sin embargo, a veces Power BI Desktop puede permitir que se definan rutas de relación ambiguas entre las tablas. La ambigüedad en la ruta de relación se resuelve más adelante en este artículo.

Se recomienda usar el filtrado bidireccional solo cuando sea necesario. Para obtener más información, vea Instrucciones para relaciones bidireccionales.

Sugerencia

En la vista de modelo de Power BI Desktop, puede interpretar la dirección del filtro cruzado de una relación mediante las puntas de flecha a lo largo de la línea de relación. Una sola punta de flecha representa un filtro de dirección única en la dirección de la punta de flecha; una punta de flecha doble representa una relación bidireccional.

Activar esta relación

Solo puede haber una ruta de propagación de filtros activa entre dos tablas del modelo. Sin embargo, se pueden introducir rutas de relación adicionales, pero estas relaciones deben establecerse como inactivas. Las relaciones inactivas solo se pueden activar durante la evaluación de un cálculo del modelo. Esto se consigue mediante el uso de la función DAX USERELATIONSHIP.

Por lo general, se recomienda definir las relaciones activas siempre que sea posible. Amplían el ámbito y el potencial del modo en el que los autores de informes pueden usar el modelo. El uso de solo relaciones activas implica que las tablas de dimensión realizadoras de roles deben duplicarse en el modelo.

Sin embargo, en determinadas circunstancias, puede definir una o varias relaciones inactivas para una tabla de dimensión realizadora de roles. Puede plantearse el uso de este diseño cuando:

• No hay ningún requisito para que los objetos visuales de informes filtren simultáneamente por roles diferentes.
• La función DAX USERELATIONSHIP se usa para activar una relación específica para los cálculos de modelos pertinentes.

Para más información, consulte Instrucciones para elegir entre relaciones activas e inactivas.

Sugerencia

En la vista de modelo de Power BI Desktop, puede interpretar el estado activo o inactivo de una relación. Una relación activa se representa mediante una línea continua; una relación inactiva se representa como una línea discontinua.

Asumir integridad referencial

La propiedad Asumir integridad referencial solo está disponible para las relaciones de uno a varios y uno a uno entre dos tablas del modo de almacenamiento DirectQuery que pertenecen al mismo grupo de origen. Esta propiedad solo se puede habilitar cuando la columna del lado "many" no contiene valores NULL.

Cuando está habilitada, las consultas nativas enviadas al origen de datos combinan las dos tablas utilizando INNER JOIN en lugar de OUTER JOIN. La habilitación de esta propiedad mejora, por lo general, el rendimiento de la consulta, aunque depende de las características específicas del origen de datos.

Habilite siempre esta propiedad cuando exista una restricción de clave externa de base de datos entre las dos tablas. Incluso si no hay ninguna restricción de clave externa, considere la posibilidad de habilitar la propiedad si está seguro de la integridad de datos.

Importante

Si se pone en peligro la integridad de los datos, la combinación interna eliminará las filas no coincidentes entre las tablas. Por ejemplo, considere una tabla Sales de modelo con un valor de columna ProductID que no existía en la tabla Product relacionada. La propagación del filtro de la tabla Product (Producto) a la tabla Sales (Ventas) eliminaría las filas de ventas de los productos desconocidos. Esto daría lugar a una subestimación de los resultados de ventas.

Para más información, vea Configuración de Asumir integridad referencial en Power BI Desktop.

Funciones DAX pertinentes

Hay varias funciones DAX pertinentes para las relaciones de modelo. Cada función se describe brevemente en la siguiente lista con viñetas:

• RELATED: recupera el valor del lado "uno" de una relación. Es útil cuando se trata de cálculos de diferentes tablas que se evalúan en el contexto de las filas.
• RELATEDTABLE: recupera una tabla de filas del lado "varios" de una relación.
• USERELATIONSHIP: permite que un cálculo use una relación inactiva. (Técnicamente, esta función modifica el peso de una relación específica de modelo inactivo que ayuda a influir en su uso). Resulta útil cuando el modelo incluye una tabla de dimensiones de rol y decide crear relaciones inactivas a partir de esta tabla. También puede usar esta función para resolver la ambigüedad en las rutas de acceso del filtro.
• CROSSFILTER: modifica la dirección del filtro cruzado de la relación (a uno o ambos) o deshabilita la propagación del filtro (ninguna). Resulta útil cuando es necesario cambiar o omitir las relaciones del modelo durante la evaluación de un cálculo específico.
• COMBINEVALUES: combina dos o más cadenas de texto en una cadena de texto. El propósito de esta función es admitir relaciones de varias columnas en los modelos DirectQuery cuando las tablas pertenecen al mismo grupo de origen.
• TREATAS: aplica el resultado de una expresión de tabla como filtros a columnas de una tabla no relacionada. Resulta útil en escenarios avanzados cuando se desea crear una relación virtual durante la evaluación de un cálculo específico.
• Funciones de padre e hijo: una familia de funciones relacionadas que puede usar para generar columnas calculadas para naturalizar una jerarquía padre-hijo. Luego, puede usar estas columnas para crear una jerarquía de nivel fijo.

Evaluación de relaciones

Las relaciones de modelo, desde una perspectiva de evaluación, se clasifican como normales o limitadas. No se trata de una propiedad configurable de la relación; De hecho, se deduce del tipo de cardinalidad y el origen de datos de las dos tablas relacionadas. Es importante comprender el tipo de evaluación, porque puede haber implicaciones en el rendimiento o consecuencias si se pone en peligro la integridad de los datos. Estas implicaciones y consecuencias de integridad se describen en este tema.

En primer lugar, se necesita un poco de teoría de modelado para llegar a comprender las evaluaciones de las relaciones.

Un modelo de importación o DirectQuery origina todos sus datos desde la caché de Vertipaq o la base de datos de origen. En ambos casos, Power BI puede determinar que existe un lado «uno» de una relación.

Sin embargo, un modelo compuesto puede componer tablas con diferentes modos de almacenamiento (importación, DirectQuery o dual) o varios orígenes de DirectQuery. Cada origen, incluida la caché de Vertipaq de los datos importados, se considera un grupo de origen. Luego, las relaciones de modelo se pueden clasificar como intragrupo de origen o como entre grupos de origen. Una relación intra-grupo de origen relaciona dos tablas dentro de un mismo grupo de origen, mientras que una relación entre grupos de origen relaciona tablas entre dos grupos de origen diferentes. Tenga en cuenta que las relaciones en los modelos de importación o DirectQuery siempre son dentro del grupo de origen.

A continuación se muestra un ejemplo de un modelo compuesto.

En este ejemplo, el modelo compuesto consta de dos grupos de origen: un grupo de origen Vertipaq y un grupo de origen de DirectQuery. El grupo de origen Vertipaq contiene tres tablas y el grupo de origen directQuery contiene dos tablas. Existe una relación entre grupos de orígenes que vincula una tabla del grupo de origen Vertipaq con una tabla del grupo de origen DirectQuery.

Relaciones normales

Una relación de modelo es normal cuando el motor de consultas puede determinar el lado "uno" de la relación. Tiene la confirmación de que la columna del lado "uno" contiene valores únicos. Todas las relaciones de uno a muchos dentro del grupo fuente son relaciones habituales.

En el ejemplo siguiente, hay dos relaciones normales, ambas marcadas como R. Las relaciones incluyen la relación uno a varios contenida en el grupo de origen Vertipaq y la relación uno a varios contenida en el origen de DirectQuery.

En el caso de los modelos de importación, donde todos los datos se almacenan en la memoria caché de Vertipaq, Power BI crea una estructura de datos para cada relación normal en el momento de la actualización de datos. Las estructuras de datos están formadas por asignaciones indexadas de todos los valores de columna a columna y su finalidad es acelerar la combinación de las tablas en el momento de la consulta.

En el momento de la consulta, las relaciones regulares permiten que se produzca la expansión de la tabla . Esta expansión da como resultado la creación de una tabla virtual mediante la inclusión de las columnas nativas de la tabla base y, a continuación, su expansión en tablas relacionadas. Para las tablas de importación, la expansión de tablas se realiza en el motor de consultas; para las tablas de DirectQuery, se realiza en la consulta nativa que se envía a la base de datos de origen (siempre que la propiedad Asumir integridad referencial no esté habilitada). A continuación, el motor de consultas actúa sobre la tabla expandida, aplicando los filtros y agrupando según los valores de las columnas de la tabla expandida.

Nota:

También se expanden las relaciones inactivas, incluso si la relación no se utiliza en ningún cálculo. Las relaciones bidireccionales no tienen ningún impacto en la expansión de tablas.

En el caso de las relaciones de uno a varios, la expansión de tablas tiene lugar desde el lado "varios" al lado "uno" mediante la semántica LEFT OUTER JOIN. Cuando no existe un valor coincidente desde el lado "varios" hasta el lado "uno", se agrega una fila virtual en blanco a la tabla del lado "uno". Este comportamiento solo se aplica a las relaciones normales, no a las relaciones limitadas.

La expansión de tablas también se produce en las relaciones de uno a uno intragrupo de origen, pero mediante la semántica de FULL OUTER JOIN. Este tipo de unión garantiza que las filas virtuales en blanco se agregan en cualquiera de los lados, cuando es necesario.

Las filas virtuales en blanco son en efecto miembros desconocidos. Los miembros desconocidos representan infracciones de la integridad referencial en las que el valor del lado "varios" no tiene un valor correspondiente en el lado "uno". Lo ideal es que estos espacios en blanco no existan. Pueden eliminarse limpiando o reparando los datos de origen.

Aquí se muestra cómo funciona la expansión de tablas con un ejemplo animado.

En este ejemplo, el modelo consta de tres tablas: Category, Product y Sales (Categoría, Producto y Ventas). La tabla Category se relaciona con la tabla Product con una relación Uno a varios y la tabla Product se relaciona con la tabla Sales con una relación Uno a varios. La tabla Category (Categoría) contiene dos filas, la tabla Product (Producto) contiene tres filas y la tabla Sales (Ventas) contiene cinco filas. Hay valores coincidentes en ambos lados de todas las relaciones, lo que significa que no hay infracciones de integridad referencial. Se desvela una tabla expandida en tiempo de consulta. La tabla consta de las columnas de las tres tablas. Es, de hecho, una perspectiva desnormalizada de los datos incluidos en las tres tablas. Se agrega una nueva fila a la tabla Sales (Ventas), con un valor de identificador de producción (9) sin ningún valor coincidente en la tabla Product (Producto). Supone una infracción de la integridad referencial. En la tabla expandida, la nueva fila tiene valores (en blanco) para las columnas de tabla Category (Categoría) y Product (Producto).

Relaciones limitadas

Una relación modelo se limita cuando no hay un lado "único" garantizado. Una relación limitada puede ocurrir por dos razones:

• La relación usa una cardinalidad de muchos a muchos (incluso si una o ambas columnas contienen valores únicos).
• La relación es entre grupos de origen (lo que solo puede suceder en los modelos compuestos).

En el ejemplo siguiente, hay dos relaciones limitadas, ambas marcadas como L. Las dos relaciones incluyen la relación de varios a varios contenida dentro del grupo de origen Vertipaq y la relación cruzada de uno a varios entre grupos de origen.

En el caso de los modelos de importación, nunca se crean estructuras de datos para las relaciones limitadas. En ese caso, Power BI resuelve las combinaciones de tabla en el momento de la consulta.

En las relaciones limitadas tampoco se produce la expansión de las tablas. Las combinaciones de tabla se logran mediante la semántica de INNER JOIN, y por este motivo, no se agregan filas virtuales en blanco para compensar las infracciones de integridad referencial.

Hay otras restricciones relacionadas con las relaciones limitadas:

• No se puede usar la función RELATED para recuperar los valores de las columnas del lado "uno".
• La aplicación de RLS tiene restricciones de topología.

Sugerencia

En la vista modelo de Power BI Desktop, puede interpretar una relación como limitada. Una relación limitada se representa con marcas similares a paréntesis ( ) después de los indicadores de cardinalidad.

Resolución de ambigüedades en rutas de acceso de relación

Las relaciones bidireccionales pueden introducir varias rutas, y por tanto ambiguas, de propagación de filtro entre las tablas del modelo. Al evaluar la ambigüedad, Power BI elige la ruta de propagación del filtro según su prioridad y peso.

Prioridad

Los niveles de prioridad definen una secuencia de reglas que Power BI usa para resolver la ambigüedad de la ruta de relación. La primera coincidencia de regla determina la ruta de acceso que seguirá Power BI. Cada regla siguiente describe cómo fluyen los filtros de una tabla de origen a una tabla de destino.

1. Una ruta de acceso que consta de relaciones de uno a varios.
2. Una ruta de acceso que consta de relaciones de uno a varios o de varios a varios.
3. Una ruta de acceso que consta de relaciones de varios a uno.
4. Ruta que consiste en relaciones de uno a varios desde la tabla de origen hacia una tabla intermedia, seguida de relaciones de varios a uno desde la tabla intermedia hasta la tabla de destino.
5. Una ruta de acceso que consta de relaciones de uno a varios o de varios a varios de la tabla de origen a una tabla intermedia seguida de relaciones de varios a uno o de varios a varios de la tabla intermedia a la tabla de destino.
6. Cualquier otro camino.

Cuando se incluye una relación en todas las rutas de acceso disponibles, se quita de la consideración de todas las rutas de acceso.

Peso

Cada relación de una ruta de acceso tiene un peso. De forma predeterminada, cada peso de relación es igual a menos que se use la función USERELATIONSHIP . El peso del camino es el máximo de todos los pesos de relación a lo largo del camino. Power BI usa los pesos de ruta para resolver la ambigüedad entre varias rutas en el mismo nivel de prioridad. No elegirá una ruta con una prioridad más baja, sino la ruta con mayor peso. El número de relaciones de la ruta de acceso no afecta al peso.

Puede influir en el peso de una relación mediante la función USERELATIONSHIP . El peso viene determinado por el nivel de anidamiento de la llamada a esta función, donde la llamada más interna recibe el peso más alto.

Considere el ejemplo siguiente. La medida Product Sales asigna un peso mayor a la relación entre Sales[ProductID] y Product[ProductID], seguido de la relación entre Inventory[ProductID] y Product[ProductID].

Product Sales = 
CALCULATE(
    CALCULATE(
        SUM(Sales[SalesAmount]), 
        USERELATIONSHIP(Sales[ProductID], Product[ProductID])
    ),
    USERELATIONSHIP(Inventory[ProductID], Product[ProductID])
)

Nota:

Si Power BI detecta varias rutas de acceso que tienen la misma prioridad y el mismo peso, devolverá un error ambiguo de ruta de acceso. En este caso, debe resolver la ambigüedad influyenndo en los pesos de relación mediante la función USERELATIONSHIP o quitando o modificando las relaciones del modelo.

Preferencia de rendimiento

En la lista siguiente se ordena el rendimiento de la propagación de filtros, desde el rendimiento más rápido al más lento:

1. Relaciones intragrupo de origen de uno a varios
2. Relaciones de modelo de varios a varios logradas con una tabla intermediaria y que implican al menos una relación bidireccional
3. Relaciones de cardinalidad de varios a varios
4. Relaciones entre grupos de fuentes

Contenido relacionado

Para obtener más información sobre este artículo, consulte los siguientes recursos:

• Descripción del esquema de estrella y la importancia de Power BI
• Guía de relación uno a uno
• Instrucciones para relaciones de varios a varios
• Orientación sobre relaciones activas versus inactivas
• Guía de relación bidireccional
• Guía de solución de problemas de relaciones
• Vídeo: Lo que se debe y no se debe hacer en las relaciones de Power BI
• ¿Preguntas? Pruebe a preguntar a la comunidad de Power BI
• ¿Sugerencias? Ideas para contribuir a mejorar Power BI