Guía sobre la gestión de relaciones activas e inactivas
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.
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.
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.
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.
Quite las relaciones inactivas.
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 columnaArrivalAirport
de la tablaFlight
, por lo que se cambia el nombre deArrival Airport
.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'
Cree una relación activa para relacionar la nueva tabla.
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.
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
yShipDate
. - 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.
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.
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: