Compartir a través de

Guía sobre la gestión de relaciones activas e inactivas

  • Artículo

Este artículo está dirigido a los modeladores de datos que trabajan con Power BI Desktop. Proporciona instrucciones sobre cuándo crear relaciones de modelo activas o inactivas. De forma predeterminada, las relaciones activas propagan filtros a otras tablas. Sin embargo, la relación inactiva solo propaga los filtros cuando una expresión DAX activa (usa) la relación.

Nota

En este artículo no se incluye una introducción a las relaciones de modelos. Si no está familiarizado con las relaciones, sus propiedades o cómo configurarlas, se recomienda que primero lea el artículo Relaciones de modelos en Power BI Desktop.

También es importante que tenga conocimientos sobre el diseño de esquemas de estrella. Para más información, vea Descripción de un esquema de estrella e importancia para Power BI.

Relaciones activas

Por lo general, se recomienda definir relaciones activas siempre que sea posible. Amplían el ámbito y el potencial de cómo los creadores de informes y los usuarios que trabajan con Q&A pueden utilizar el modelo.

Piense, por ejemplo, en un modelo de importación diseñado para analizar la puntualidad de una línea aérea. El modelo tiene una tabla Flight , que es una tabla de hechos que almacena una fila por paquete piloto. Cada fila registra la fecha del vuelo, el número de vuelo, los aeropuertos de salida y llegada, y cualquier hora de retraso (en minutos). También hay una tabla de Airport, que es una tabla de dimensiones que almacena una fila por aeropuerto. Cada fila describe el código del aeropuerto, el nombre del aeropuerto y el país o región.

Este es un diagrama de modelo parcial de las dos tablas.

Diagrama que muestra un modelo que contiene dos tablas: Vuelo y Aeropuerto. El diseño de la relación se describe en el párrafo siguiente.

Hay dos relaciones de modelo entre las tablas Flight y Airport. En la tabla Flight, las columnas DepartureAirport y ArrivalAirport se relacionan con la columna Airport de la tabla Airport. En el diseño del esquema de estrella, la tabla Airport se describe como una dimensión de rol. En este modelo, los dos roles son aeropuerto de salida y aeropuerto de llegada.

Aunque este diseño funciona bien para los diseños de esquemas de estrella relacionales, no funciona bien para los modelos de Power BI. Esto se debe a que las relaciones del modelo son rutas para la propagación de filtros y estas rutas deben ser deterministas. Para obtener más información sobre cómo asegurarse de que las rutas de propagación de filtros sean deterministas, consulte Resolución de ambigüedades en rutas de acceso de relación. Por lo tanto, como se muestra en este ejemplo, una relación está activa mientras la otra está inactiva (representada por la línea de guiones). En concreto, es la relación con la columna ArrivalAirport que está activa, lo que significa que los filtros aplicados a la tabla de Airport se propagan automáticamente a la columna ArrivalAirport de la tabla Flight.

Este diseño de modelo impone limitaciones graves sobre cómo se pueden notificar los datos. En concreto, no es posible filtrar la tabla Airport para aislar automáticamente los detalles de los vuelos de un aeropuerto de salida. Dado que los informes necesitan filtrar (o agrupar) por aeropuertos de salida y llegada al mismo tiempo, se requieren dos relaciones activas. Traducir este requisito en un diseño de modelo de Power BI significa que el modelo debe tener dos tablas de aeropuerto.

Este es el diseño mejorado del modelo.

Diagrama que muestra un modelo que contiene cuatro tablas: Fecha, Vuelo, Aeropuerto de salida y Aeropuerto de llegada.

El modelo ahora tiene dos tablas de aeropuerto: Departure Airport y Arrival Airport. Cada relación de modelo entre estas tablas y la tabla Flight está activa. Observe también que los nombres de columna de las tablas de Departure Airport y Arrival Airport tienen el prefijo de salida o de llegada.

El diseño de modelos mejorado admite la generación del siguiente diseño de informe.

Diagrama en el que se muestra una página de informe con dos segmentaciones y un objeto visual de tabla. Las segmentaciones son el mes y el aeropuerto de salida.

La página del informe filtra por Melbourne como aeropuerto de salida y los grupos de objetos visuales de la tabla por aeropuertos de llegada.

Nota

En el caso de los modelos de importación, la adición de otra tabla de dimensiones ha provocado un aumento del tamaño del modelo y tiempos de actualización más largos. Por lo tanto, contradice las recomendaciones descritas en el artículo sobre técnicas de reducción de datos para el modelado de importación. Sin embargo, en el ejemplo, el requisito de tener solo relaciones activas invalida estas recomendaciones.

Además, es habitual que las tablas de dimensiones almacenen recuentos de filas bajos en relación con los recuentos de filas de tabla de hechos. Por lo tanto, es probable que el aumento del tamaño del modelo y los tiempos de actualización no sean demasiado grandes.

Metodología de refactorización

A continuación se muestra una metodología para refactorizar un modelo de una sola tabla de dimensión realizadora de roles a un diseño con una tabla por rol.

  1. Quite las relaciones inactivas.

  2. Considere la posibilidad de cambiar el nombre de la tabla de dimensiones de juego de roles para describir mejor su rol. En el ejemplo de este artículo, la tabla Airport está relacionada con la columna ArrivalAirport de la tabla Flight, por lo que se cambia el nombre de Arrival Airport.

  3. Cree una copia de la tabla de rol, dándole un nombre que refleje su función. Si se trata de una tabla import, se recomienda crear una tabla calculada. Si se trata de una tabla DirectQuery, puede duplicar la consulta de Power Query.

    En el ejemplo, la tabla Departure Airport se creó mediante la siguiente definición de tabla calculada.

    Departure Airport = 'Arrival Airport'

  4. Cree una relación activa para relacionar la nueva tabla.

  5. Considere la posibilidad de cambiar el nombre de las columnas de las tablas para que reflejen con precisión su rol. En el ejemplo de este artículo, todas las columnas tienen como prefijo la palabra de salida o de llegada . Estos nombres garantizan que los objetos visuales de informe, de forma predeterminada, tengan etiquetas autodescriptivas y no ambiguas. También mejora la experiencia de Q&A, permitiendo a los usuarios escribir fácilmente preguntas precisas.

  6. Considere la posibilidad de agregar descripciones a las tablas de rol. (En el panel Datos, aparece una descripción en una información sobre herramientas cuando un autor del informe mantiene el cursor sobre la tabla). De este modo, puede comunicar otros detalles de propagación de filtros a los autores de informes.

Relaciones inactivas

En circunstancias específicas, las relaciones inactivas pueden satisfacer necesidades de informes específicas.

Considere los distintos requisitos de modelo e informes:

  • Un modelo de ventas contiene una tabla de Sales que tiene dos columnas de fecha: OrderDate y ShipDate.
  • Cada fila de la tabla Sales registra un único pedido.
  • Los filtros de fecha se aplican casi siempre a la columna OrderDate, que siempre almacena una fecha válida.
  • Solo una medida requiere la propagación del filtro de fecha a la columna ShipDate, que puede contener espacios en blanco (hasta que se envíe el pedido).
  • No es necesario filtrar (o agrupar) simultáneamente los períodos de fecha de envío de los pedidos y.

Este es un diagrama de modelo parcial de las dos tablas.

Diagrama que muestra un modelo que contiene dos tablas: Sales y Date. La tabla Sales incluye seis medidas.

Hay dos relaciones de modelo entre las tablas Sales y Date. En la tabla Sales, las columnas OrderDate y ShipDate se relacionan con la columna Date de la tabla Date. En este modelo, los dos roles de la tabla Date son fecha de pedido y fecha de envío. La relación con la columna OrderDate es la que está activa.

Todas las seis medidas (excepto una) deben filtrarse por la columna OrderDate. Sin embargo, la medida Orders Shipped debe filtrar por la columna ShipDate.

Esta es la definición de medida Orders. Simplemente cuenta las filas de la tabla Sales dentro del contexto de filtro. Los filtros aplicados a la tabla Date se propagan a la columna OrderDate.

Orders = COUNTROWS(Sales)

Esta es la definición de medida Orders Shipped. Usa la función USERELATIONSHIP DAX, que activa la propagación de filtros para una relación específica, pero solo durante la evaluación de la expresión. En este ejemplo, se usa la relación con la columna ShipDate.

Orders Shipped =
CALCULATE(
    COUNTROWS(Sales)
    ,USERELATIONSHIP('Date'[Date], Sales[ShipDate])
)

Este diseño de modelo admite la generación del siguiente diseño de informe.

Diagrama en el que se muestra una página de informe con una segmentación y un objeto visual de tabla. La segmentación es Quarter (Trimestre) y el objeto visual de tabla muestra las estadísticas de ventas mensuales.

La página del informe filtra por trimestre 2019 Q4. El objeto visual de la tabla agrupa por mes y muestra varias estadísticas de ventas. Las medidas Orders y Orders Shipped producen resultados diferentes. Cada uno usa la misma lógica de resumen (recuento de filas de la tabla Sales), pero diferente propagación del filtro de la tabla Date.

Observe que la segmentación de trimestres incluye una opción en blanco. Esta opción de segmentación aparece como resultado de la expansión de tabla. Aunque cada fila de la tabla Sales tiene una fecha de pedido válida, algunas filas tienen una fecha de envío vacía; estos pedidos aún no se han enviado. La expansión de tablas también tiene en cuenta las relaciones inactivas, por lo que pueden aparecer espacios en blanco por haber espacios en blanco en la mayoría de la relación (o debido a problemas de integridad de los datos).

Nota

Los filtros de seguridad de nivel de fila (RLS) solo se propagan a través de relaciones activas. Los filtros RLS nunca se propagan para las relaciones inactivas, incluso cuando una definición de medida usa la función DAX USERELATIONSHIP.

Recomendaciones

Se recomienda definir relaciones activas siempre que sea posible, especialmente cuando se definen roles de RLS para el modelo de datos. Amplían el ámbito y el potencial de uso del modelo por los autores de informes y por los usuarios que trabajan con Q&A. Esto 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 considerar este enfoque 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.

Contenido relacionado

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