En el anterior blog comentamos cómo podíamos usar los filtros en cascada en nuestros informes para que los slicers se filtraran entre sí, sin necesidad de utilizar relaciones bidireccionales que, como ya sabemos, pueden generar comportamientos indeseados en nuestros datos, por lo que hay que tener mucho cuidado a la hora de hacer uso de ellas.

En este blog vamos a generar exactamente el mismo comportamiento que en el anterior artículo, pero utilizando métricas que van a filtrar nuestros slicers. Este método es mucho más práctico y sencillo que el que mostramos en su día pero, por aquel entonces, Power BI no nos permitía aplicar este tipo de filtrado sobre los slicers.

Nueva solución al problema

Si recordamos el anterior blog, teníamos el siguiente modelo, en el cual, buscábamos la manera de conseguir que, por ejemplo, la dimensión “Warehouse” nos filtrara la dimensión “Country” sin hacer uso de relaciones bidireccionales.

power bi comportamiento filtros modelo

Como decíamos anteriormente, haremos uso de la nueva funcionalidad que se añadió en junio de 2019 (Visual level filters for slicers) que nos permite añadir filtros al objeto visual Slicer. Para ello, crearemos una métrica llamada “#Sales” que tendrá la siguiente fórmula DAX en nuestra tabla de hechos:

#Sales = COUNT(Sales[LineID])

Power BI: Comportamiento en cascada de los filtros 2.0

¿Qué estamos haciendo con esta fórmula y qué queremos conseguir? Simplemente estamos contando el número de ventas que hay en nuestra tabla de hechos para, posteriormente, descartar de las dimensiones todos aquellos atributos que no tienen ventas registradas.

A continuación, añadiremos al informe los slicers que necesitamos. En nuestro caso, son “CountryName”, “WarehouseName” y “EmployeeName”. Después, le aplicaremos el mismo filtro a los 3 visuales haciendo uso de la medida creada anteriormente, de esta forma, vamos a indicarle que queremos mostrar solo aquellos valores que son mayor que 0.

power bi comportamiento filtros sales 2

De esta manera, obtenemos el mismo resultado que veíamos en la Figura 9 del anterior blog cuando filtrábamos por la empleada “Brenda Díaz”. Además, así, tampoco tendremos los atributos que no tienen relación en la tabla de hechos.

Power BI: Comportamiento en cascada de los filtros 2.0

Pero, ¿cómo es posible que funcione este filtrado por el simple hecho de haber creado y utilizado como filtro del slicer una métrica?

La respuesta es sencilla: cuando hemos usado la métrica como filtro del slicer, lo que se hace es calcular la métrica bajo el contexto de filtros actual, es decir, la métrica se está viendo afectada por el resto de filtros del informe. Es por este motivo por el cual se consigue el efecto de cascada.

Prueba de Rendimiento

En esta ocasión, para explicar y demostrar el desarrollo de una forma más consistente y con una volumetría de datos más real, se va a utilizar un fichero .pbix con un conjunto de datos muy superior al que se usó anteriormente. En concreto, se hará uso de un fichero .pbix que contiene una base de datos de Contoso.

El modelo de Contoso que usaremos es el siguiente, que es un copo de nieve igual que el usado en el anterior blog.

Power BI: Comportamiento en cascada de los filtros 2.0

El motivo de usar este fichero es debido a que contiene un dataset alrededor de 2 millones de registros, lo cual nos va a permitir validar si el desarrollo creado es óptimo o no. Para ello, haremos uso de la funcionalidad Performance Analyzer de Power BI.

Opción 1. Método empleado en el anterior blog (utilizando una tabla auxiliar)

En esta opción se contempla el desarrollo del anterior blog. Hemos creado un fichero .pbix de la forma que se explicó en ese artículo:

    • Tenemos una tabla llamada “Filters” que contiene todas las combinaciones de atributos posibles.
    • Tenemos los filtros por duplicado, haciendo uso de la ocultación y la sincronización entre ellos.

A continuación, vamos a lanzar un análisis de rendimiento filtrando los siguientes campos:

    • “RegionCountryName”: Spain
    • “StoreName”: Contoso Madrid Store
    • “ProductCategory”: TV and Video
power bi comportamiento tabla auxiliar

Opción 2. Utilizando una métrica como filtro del slicer

En esta opción se contempla el desarrollo explicado en este blog. Hemos creado un fichero .pbix de la forma que explica en este artículo:

    • Hemos creado una medida en DAX que nos devuelve un contador de registros de nuestra tabla de hechos.
    • Hemos añadido esta métrica como filtro del slicer.

A continuación, vamos a lanzar un análisis de rendimiento filtrando los siguientes campos (los mismos que en el apartado anterior):

    • “RegionCountryName”: Spain
    • “StoreName”: Contoso Madrid Store
    • “ProductCategory”: TV and Video
power bi comportamiento tabla slicer

Si sumamos las diferentes duraciones que nos muestra el Performance Analyzer, obtenemos el siguiente valor: 1’897s.

Opción 3. Utilizando relaciones bidireccionales

En esta opción hemos creado un fichero .pbix creando relaciones bidireccionales, tal y como se muestra a continuación:

power bi comportamiento tabla bidireccional

A continuación, vamos a lanzar un análisis de rendimiento filtrando los siguientes campos (los mismos que en apartados anteriores):

    • “RegionCountryName”: Spain
    • “StoreName”: Contoso Madrid Store
    • “ProductCategory”: TV and Video
Power BI: Comportamiento en cascada de los filtros 2.0

Si sumamos las diferentes duraciones que nos muestra el Performance Analyzer, obtenemos el siguiente valor: 3’892s.

Conclusiones

A continuación, se muestra una tabla resumen de los resultados obtenidos en las pruebas de rendimiento realizadas:

power bi comportamiento query

Tal y como hemos podido ver a lo largo de las tres pruebas de rendimiento, queda claro que la mejor forma de obtener un comportamiento en cascada de los filtros es haciendo uso de la lógica explicada durante el artículo.

Según la Tabla 1, para la combinación de filtros que hemos hecho, vemos que nuestra query es 2x veces más rápida que si usáramos relaciones bidireccionales (que ya sabemos que pueden producir comportamientos indeseados) y hasta 4x veces más rápida que usando una tabla auxiliar.

Además, hay que remarcar que utilizando este método no será necesario modificar el modelo ni añadir complejidad para dar solución a este tipo de problemas, es decir, no sería necesario añadir una tabla auxiliar con todas las combinaciones de atributos posibles ni tener todos los filtros por duplicado y sincronizados en nuestro informe.

Por último, hay que tener en cuenta que emplear una fórmula DAX demasiado compleja repercutirá negativamente en el rendimiento del informe.

¿Quieres Ahorrar Tiempo A La Hora De Generar Informes?

Conviértete en un experto en Power BI con nuestro curso en la herramienta líder en analítica avanzada. Porque cuando el informe es bueno, las decisiones son acertadas.

Quiero saber más
0 Shares:
Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

You May Also Like

Particionado de tablas en SQL Server 2014

Tradicionalmente el particionado de datos no ha sido muy de mi agrado por las implicaciones de mantenimiento que se tenian asociadas. Tareas como reindexar, mover particiones entre tablas, actualizar estadísticas,…no eran tarea sencilla en entornos con carga 24x7 en el momento en el que particionabas una tabla.