Relaciones de modelos 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 importante sobre el diseño de modelos, esencial para ofrecer modelos intuitivos, precisos y óptimos.

Para una explicación más detallada sobre el diseño de modelos óptimos, incluidos los roles y las relaciones de tablas, consulte Descripción de un esquema de estrella e importancia para Power BI.

Finalidad de la relación

Una relación de modelo propaga los filtros aplicados en la columna de una tabla de modelos a otra tabla de modelos. 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 el contexto del filtro puede modificarse debido a los cálculos del modelo que usan funciones DAX concretas. Para más información, consulte el tema Funciones de DAX pertinentes, más adelante en este artículo.

Veamos, con un ejemplo animado, cómo las relaciones propagan los filtros.

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

Una consulta —tal vez generada por un objeto visual de tarjeta de Power BI— solicita las ventas totales correspondientes a los pedidos realizados para una sola categoría, Cat-A (Categoría A) y para un solo año, CY2018 (AC2018). Esta es la razón por la que se pueden ver filtros aplicados en las tablas Category (Categoría) y Year (Año). El filtro de la tabla Category (Categoría) se propaga a la tabla Product (Producto) para aislar dos productos asignados a la categoría Cat-A (Categoría A). A continuación, los filtros de la tabla Product (Producto) se propagan a la tabla Sales (Ventas) para aislar solo dos filas de ventas de estos productos. Estas dos filas de ventas representan las ventas de productos asignados a la categoría Cat-A (Categoría A). Su cantidad combinada es de 14 unidades. Al mismo tiempo, el filtro de la tabla Year (Año) se propaga para filtrar aún más la tabla Sales (Ventas), lo que da lugar a la única fila de ventas que corresponde a los productos asignados a la categoría Cat-A (Categoría A) solicitados en el año CY2018 (AC2018). El valor devuelto por la consulta es de 11 unidades. Tenga en cuenta que, cuando se aplican varios filtros a una tabla, (como en el caso de la tabla Sales [Ventas] en este ejemplo), siempre se trata de una operación AND, lo que significa que se deben cumplir todas las condiciones.

Aplicación de principios de diseño de esquemas de estrella

Se recomienda aplicar principios de diseño de esquemas de estrella para generar un modelo que comprenda tablas de hechos y de dimensiones. Es habitual configurar Power BI para aplicar reglas que filtran 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 Sales. 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. Este tipo de 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 su lugar, 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, pensemos en una tabla desconectada que se carga con un intervalo de valores de tasas de cambio de divisa. Suponiendo que se aplica un filtro para conseguir un valor de tasa único, este valor se puede usar en una expresión de medida para convertir 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 la relación

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

Tipos de datos de columnas

El tipo de datos para la columna "from" y "to" de la relación debe ser el mismo. Es posible que el trabajo con relaciones definidas en columnas DateTime no se comporte 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. Cualquier objeto dependiente del modelo seguirá apareciendo como DateTime en el motor (como las relaciones, los grupos, etc.). Por lo tanto, si un usuario selecciona Date en la pestaña Modelado de esas columnas, siguen sin registrarse como la misma fecha, porque el motor sigue usando la parte de los datos correspondiente a la hora. 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 se deben actualizar en el Editor de Power Query para quitar la parte Time de los datos importados a fin de que los valores aparezcan iguales cuando el motor controle los datos.

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 "de" y "a". El lado "uno" significa que la columna contiene valores únicos; el lado "varios" significa que la columna puede contener valores duplicados.

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

• Uno a varios (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. En el caso de los modelos de importación, utiliza estadísticas de almacenamiento internas; en el caso de los modelos 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 de uno a varios y varios a uno son esencialmente iguales y son también los tipos de cardinalidad más comunes.

A la hora de configurar una relación de uno a varios o de varios a uno, debe 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 de 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 varios a varios 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 usarlo para relacionar hechos de varios a varios o para relacionar hechos de un modo más pormenorizado. 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.

Dirección de 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.

La dirección del filtro cruzado Único significa "dirección única" y Ambos se aplica a "ambas direcciones". Una relación que filtra en ambas direcciones se describe normalmente 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, hay disponible una propiedad adicional. que puede aplicar el filtrado bidireccional cuando Power BI impone reglas de seguridad de nivel de fila (RLS). Para más información sobre la RLS, consulte Seguridad de nivel de fila (RLS) con Power BI Desktop.

Puede modificar la dirección del filtro cruzado de la relación, incluso deshabilitar la propagación del filtro, usando el cálculo de un modelo. Esto se consigue gracias el uso de 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 resolución de la ruta de acceso de relación se describe 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.

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 relaciones activas únicamente significa que las tablas de dimensiones realizadoras de roles deben duplicarse en el modelo.

No obstante, en determinadas circunstancias, puede definir una o varias relaciones inactivas para una tabla de dimensiones realizadoras 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.

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 "varios" 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 existe 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.

Funciones DAX pertinentes

Hay varias funciones DAX pertinentes para las relaciones de modelo. En la siguiente lista con viñetas se describe brevemente cada una de estas funciones:

• 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 de modelo inactiva específica, de modo 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 ambigüedades en las rutas de acceso de 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 u 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 sola. 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 en las columnas de una tabla no relacionada. Resulta útil en escenarios avanzados cuando quiere crear una relación virtual durante la evaluación de un cálculo específico.
• Funciones primarias y secundarias: familia de funciones relacionadas que se pueden usar para generar columnas calculadas y naturalizar una jerarquía de elementos primarios y secundarios. Luego, puede usar estas columnas para crear una jerarquía de nivel fijo.

Evaluación de las relaciones

Las relaciones de los modelos desde la perspectiva de la evaluación, se clasifican como normales o limitadas. No se trata de una propiedad configurable de la relación; en realidad, se deduce del tipo de cardinalidad y del 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. En este tema se describen estas implicaciones y las consecuencias respecto a la integridad.

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 consigue todos sus datos de la caché de Vertipaq o de 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 constar de tablas que usan diferentes modos de almacenamiento (importación, DirectQuery o dual) o varios orígenes de DirectQuery. Cada origen, incluida la caché de Vertipaq de datos de importación, 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 intragrupo de origen relaciona dos tablas dentro de un mismo grupo de origen, mientras que una relación entre grupos de origen relaciona las tablas de dos grupos de origen. Cabe mencionar que las relaciones en los modelos de importación o DirectQuery siempre son intragrupo.

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

En este ejemplo, el modelo compuesto consta de dos grupos de origen: uno de Vertipaq y otro de DirectQuery. El grupo de origen de Vertipaq contiene tres tablas y el de DirectQuery, dos. Existe una relación entre grupos de origen que relaciona una tabla del grupo de origen de Vertipaq con una tabla del grupo de origen de DirectQuery.

Relaciones normales

Una relación del 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 varios intragrupo de origen son relaciones normales.

En el ejemplo siguiente, hay dos relaciones normales, ambas marcadas como R. Hay una relación de uno a varios incluida dentro del grupo de origen de Vertipaq y otra relación de uno a varios en el de DirectQuery.

En el caso de los modelos de importación, donde todos los datos se almacenan en la 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.

Cuando se produce la consulta, las relaciones normales permiten que tenga lugar 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. En el caso de las tablas de importación, la expansión de la tabla se lleva a cabo en el motor de consultas; en el caso de las tablas de DirectQuery, se lleva a cabo 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.

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 del lado "varios" en el lado "uno", se agrega una fila virtual en blanco en 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 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 realidad, 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.

Veamos 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 (Categoría) está relacionada con la tabla Product (Producto) en una relación de uno a varios y la tabla Product (Producto) está relacionada con la tabla Sales (Ventas) también en una relación de 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 ninguna infracción de la 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 de modelo es limitada cuando no hay ningún lado "uno" garantizado. Una relación limitada puede ocurrir por dos razones:

• La relación usa un tipo de cardinalidad de varios a varios (aunque una o ambas columnas contengan 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 de VertiPaq y la relación 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 tablas se logran mediante la semántica INNER JOIN y, por este motivo, no se agregan filas virtuales en blanco para compensar las infracciones de integridad referencial.

Existen otras restricciones relacionadas con las relaciones limitadas:

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

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 acceso de propagación de filtros según su prioridad y peso.

Priority

Los niveles de prioridad definen una secuencia de reglas que Power BI usa para resolver ambigüedades en la ruta de acceso 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. Una ruta de acceso que consta de relaciones de uno a varios de la tabla de origen a una tabla intermedia seguida de relaciones de varios a uno de la tabla intermedia a 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 otra ruta de acceso.

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 manera predeterminada, el peso de cada relación es igual a menos que se use la función USERELATIONSHIP. El peso de la ruta de acceso es el máximo de todos los pesos de relación a lo largo de la ruta de acceso. Power BI usa los pesos de la ruta de acceso para resolver ambigüedades entre varias rutas de acceso con el mismo nivel de prioridad. No elegirá una ruta de acceso con una prioridad más baja, pero elegirá la ruta de acceso con el peso más alto. 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], seguida 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])
)

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 origen

Contenido relacionado

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

• Descripción de un esquema de estrella e importancia para Power BI
• Instrucciones para relaciones uno a uno
• Instrucciones para relaciones de varios a varios
• Instrucciones para elegir entre relaciones activas e inactivas
• Instrucciones para relaciones bidireccionales
• Instrucciones para solución de problemas de relaciones
• Vídeo: Qué se debe hacer y qué no con las relaciones de Power BI
• ¿Tiene alguna pregunta? Pruebe a preguntar a la comunidad de Power BI
• ¿Sugerencias? Ideas para contribuir a mejorar Power BI