Configuración de relaciones
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 da este requisito y solo se aplica a las relaciones de varias columnas en los modelos de DirectQuery. Este tema se trata en la siguiente unidad.
Nota
No es posible relacionar una columna con una columna diferente de 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 se pueden usar relaciones de modelo para generar una jerarquía de modelos basada en este tipo de relación. Para crear una jerarquía de elementos primarios y secundarios, consulte Funciones primarias y secundarias.
Establecimiento de la cardinalidad de las relaciones
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.
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 varios (1:*)
Varios a uno (*:1)
Uno a uno (1:1)
De 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. 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 de uno a varios y de varios a uno son 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, 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, porque 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. A menudo, es mejor usar Power Query para consolidar las dos tablas en una.
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.
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. Si quiere determinar qué columnas están relacionadas, debe seleccionar (o mover el cursor sobre) la línea de la relación para resaltar las columnas.
Establecimiento de la 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 |
|---|---|
| De uno a varios (o de varios a uno) | Simple Ambos |
| Uno a uno | Ambos |
| Varios a varios | Simple (Table1 a Table2) Simple (Table2 a Table1) Ambos |
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 seguridad de nivel de fila, consulte el artículo 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. Se consigue con la función DAX CROSSFILTER, que se describe en la unidad 3.
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. Las reglas de precedencia que afectan a la detección de ambigüedad y a la resolución de rutas se describen en la unidad 4.
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.
Establecimiento de relaciones activas frente a relaciones inactivas
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. Se consigue con la función DAX USERELATIONSHIP, que se describe en la unidad 3.
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
USERELATIONSHIPse 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.
Establecimiento de la propiedad 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 haya una restricción de clave externa de base de datos de una columna 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, imagine una tabla de modelo Sales con un valor en la columna ProductID que no existe en la tabla relacionada Product. 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.