Hace un tiempo que quiero hacer un post que hable de las relaciones con cardinalidad varios a varios en PowerBI y la verdad es que por una razón o por otra, nunca me había puesto hasta ahora. Además, era algo que le debía a un buen amigo del grupo de WhatsApp de PowerBI Barcelona (Augusto) al que le prometí que escribiría sobre este tema hace ya algún tiempo. Augusto, esto va por ti!

El enfoque de este artículo se basa en la identificación de este tipo de relaciones y en las posibles alternativas de solución que podemos aplicar.

Comenzamos definiendo una relación con una cardinalidad de tipo Varios a Varios como una relación en la que el motor VertiPaq no es capaz de identificar cuál de las tablas relacionadas contiene valores únicos para la columna que se establece como columna de relación, en pocas palabras, es una relación donde ninguna de las 2 columnas implicadas tiene valores sin repetir.

Vamos a analizar diferentes casos dónde esto nos puede ocurrir y veremos también posibles soluciones.

PRIMER CASO: Dimensiones con filas duplicadas

Este primer ejemplo que vamos a analizar es seguramente el más sencillo de corregir y se produce cuando tenemos una dimensión que contiene tiene valores repetidos en su columna clave principal (2 clientes tienen el mismo idCliente)

Como vemos en la imagen anterior, la dimensión Clientes tiene una fila repetida.

Cuando cargamos estos datos en PowerBI y establecemos las relaciones entre las Dimensiones y la tabla de hechos, veremos como la relación entre DimProductos y FactVentas es correcta y sin errores, en cambio, la relación entre DimClientes y FactVentas nos muestra un mensaje de error.

El aviso mostrado no es por si mismo un error ya que nos permite continuar y aceptar si no que es un aviso con respecto a la cardinalidad detectada sobre la relación. Si aceptamos la pantalla, veremos como la relación se establece, aunque con algunos matices.

Las 2 puntas de la relación tienen el símbolo *, la dirección de la relación es bidireccional y en cada una de las puntas de la línea hay una pequeña discontinuidad. Esto nos indica que se trata de una relación limitada.

Relación Varios a Varios entre 2 tablas. Relación de tipo limitada

Solución:

En este contexto de trabajo la solución es sencilla, bastará con quitar la fila duplicada de la dimensión Clientes. Como todos sabemos, en una dimensión no deben existir filas repetidas.

Esta operación se puede realizar de forma sencilla desde PowerQuery

Opción de quitar filas duplicadas en PowerQuery

Como resultado obtendremos la dimensión clientes sin valores repetidos y podremos modificar la relación, por ejemplo, desde la nueva pestaña de propiedades existente en la vista del Modelo de PowerBI Desktop aparecida a partir de la versión de Noviembre de 2022

Resultado de quitar duplicados y cambio de las opciones de la relación

SEGUNDO CASO: Relación intrínseca varios a varios

Este segundo caso a analizar es un poco más complejo de resolver y se produce cuándo la relación que tenemos que generar entre 2 de nuestras tablas es una relación natural de tipo varios a varios.

Supongamos que tenemos una tabla de personas junto a otra tabla de aficiones.

Relaciones entre personas y aficiones

Como podemos observar en la imagen, una persona puede tener varias aficiones, pero a la vez, una afición puede gustarle a varias personas, esto es una relación intrínseca de Varios a Varios.

Este tipo de relaciones las podemos encontrar también en otros contextos de trabajo como por ejemplo, cuentas bancarias y titulares de las cuentas ya que una persona puede ser titular de varias cuentas bancarias a la vez que una determinada cuenta bancaria puede tener diferentes titulares o también  cuándo se necesiten relacionar personas con equipos y roles de trabajo o cuándo se determinen accionistas y empresas… existen muchos casos como vemos.

Si nos centramos en el caso primer caso que nos ocupaba, dónde debemos relacionar personas y aficiones, necesitaremos encontrar la solución creando una nueva tabla que servirá de unión (puente) entre las 2 tablas de personas y aficiones que queremos relacionar. Esta tabla intermedia se conoce como tabla puente (BridgeTable) o también como tabla de hechos sin hechos (Factless FactTable).

Esta tabla puente es una tabla que debe contener únicamente aquellas combinaciones EXISTENTES de identificadores de personas y aficiones. Obviamente, estos datos deben existir en nuestro origen de datos de alguna forma y debemos traerlos a nuestro modelo en forma de tabla puente.

Como ejemplo de nuestro caso donde:

• A Juan le gusta el deporte y pasear
• A Iago le gusta el deporte y la lectura

La tabla puente debería ser así:

Tabla puente que relaciona personas y aficiones

A partir de aquí, vamos a integrar estas tablas en un sencillo modelo existente donde tendremos una tabla de hechos donde aparecerán las compras de productos por personas. El modelo será el siguiente:

Modelo completo con ventas de productos, personas y aficiones

Si a este modelo le creamos una sencilla medida para sumar los valores de la columna unidades de la FactVentas:

Ya podríamos crear una tabla o gráfico que mostrara la cantidad de unidades de producto que ha comprado cada persona.

Tabla de unidades vendidas por persona

Pero cuando intentamos crear una tabla que nos indique las unidades vendidas según aficiones, nos encontramos con esto…

Tabla de unidades vendidas por afición

Para todas las aficiones nos muestra el total de unidades vendidas. Tenemos un problema con el modelo de datos porque el filtro no se propaga desde tabla DimAficion y la tabla FactVentas

Para poder resolver esta casuística existen diferentes opciones, pero en este primer post optaremos por la utilización de la función CROSSFILTER.

Uso de la función CROSSFILTER.

La función CROSSFILTER de DAX es una función que permite cambiar de forma puntual la dirección de filtrado de una relación. De esta forma, podremos aplicar nuestro cálculo modificando la dirección del filtrado con CROSSFILTER.

CROSSFILTER tiene la siguiente sintaxis:

CROSSFILTER ( Columna1 , Columna2 , Dirección )

Los parámetros Columna1 y Columna2 son los campos que se utilizan en la relación y

El parámetro Dirección tiene que tener alguno de estos valores predeterminados:

• NONE: No hay filtrado
• BOTH: Los filtros se transfieren a los 2 lados de la relación
• ONEWAY: Los filtros se transfieren de forma natural de 1 a varios
• OneWay_LeftFiltersRight: Los filtros de Columna1 se transfieren a la Columna2
• OneWay_RightFiltersLeft: Los filtros de la Columna2 se transfieren a la Columna1

En nuestro caso, vamos a aplicar el parámetro BOTH tal como se muestra en la siguiente medida:

Medida con CROSSFILTER

Como vemos ahora, el resultado de la medida en nuestro informe sería este:

Tabla con resultados de medida con CROSSFILTER

Conclusiones:

Saber cuáles son las preguntas de negocio que debemos contestar y realizar un análisis exahustivo de nuestros datos antes de comenzar a trabajar es básico para el éxito de cualquier proyecto.

Si en este análisis detectamos problemáticas cómo las que hemos comentado de relaciones Varios a Varios, deberemos aplicar soluciones que nos ayuden superarlas.

Espero que este post os haya resultado útil!

#SigueElCaminoDeLaEstrella