Cálculos semanales de DAX: problemas de inteligencia de tiempo de LuckyTemplates

En el tutorial de hoy, proporcionaré algunas técnicas y consejos sobre cómo tratar los problemas comunes causados ​​por la granularidad semanal de DAX en los cálculos de inteligencia de tiempo. Puedes ver el video completo de este tutorial en la parte inferior de este blog.

Recientemente hice un tutorial sobre cómo obtener los valores de la semana anterior en LuckyTemplates. Desde entonces, tengo varias preguntas relacionadas con la inteligencia de tiempo y, en particular, con los valores semanales de DAX. Eso no es sorprendente porque las semanas son realmente la granularidad que se comporta peor en la esfera de la inteligencia del tiempo.

En el caso de los meses, siempre tienes 12 meses en un año. En el caso de las monedas de veinticinco centavos, siempre tienes cuatro monedas de veinticinco centavos. Las semanas son diferentes porque hay siete días en una semana y 52 semanas en un año, eso es 364 días. Entonces, tienes ese día extra pasando el rato allí. En años bisiestos, tienes dos días extra.

Entonces, eso en realidad termina en algunos años, basado en el esquema de numeración para el número de semana ISO, para tener a veces 52 semanas, a veces 53 semanas. La semana 53 es la que más problemas va a causar.

Tabla de contenido

• Problemas de inteligencia de tiempo de un cálculo semanal de DAX
• Conclusión

Problemas de inteligencia de tiempo de un cálculo semanal de DAX

En este ejemplo, estoy usando el precio total al contado. Con los totales, es más fácil visualizar y hablar.

En este caso, para cada uno de los años, queremos mostrar una línea para la semana 53, ya sea que haya una semana 53 en ese año o no. Entonces, pueden ver en 2018 y 2019, no hay semana 53, pero en 2020 sí. Queremos que sea consistente para que la línea 53 esté presente cada año. Pero entonces, la métrica estaría en blanco para los años en los que no hubo un año 53.

Una de las formas comunes en que lo hacemos es ir a Mostrar elementos sin datos y asegurarnos de que esté activado. En este caso, está activado, pero no ayudará porque funciona cuando tienes una fila física, pero no hay datos asociados con esa fila. En este caso, ni siquiera tenemos la fila.

Las técnicas como usar o Eliminar filtros no funcionarán porque no hay nada que eliminar. El filtro en esa fila simplemente no existe. Entonces, la pregunta es ¿cómo insertamos esa fila en cada año en el que no existe? Y luego, esto realmente se convierte en un problema de modelado de datos.

Una de las cosas que podemos hacer potencialmente es ir a un esquema de copo de nieve donde filtramos la tabla de Fechas por algo que forzará esa semana 53 en nuestro visual cada año. La función que me viene a la mente para esto es .

CROSSJOIN se usa para hacer coincidir dos campos que pueden o no tener una relación. No tienen que tener una relación a diferencia de la mayoría o u otras funciones de tabla.

En este caso, CROSSJOIN toma dos columnas y crea cada combinación de esas dos columnas, ya sea que exista en el conjunto de datos o no. Eso es exactamente lo que queremos.

Tenemos nuestros para crear una tabla a partir de la columna. CROSSJOIN toma dos tablas y luego VALUES en el número de semana ISO, y simplemente los emparejamos. Eso nos dará 53 semanas cada año.

Y luego, estamos agregando una tercera columna a la tabla. Podríamos hacer esto en Power Query, pero es más fácil mostrarle la lógica en DAX. Lo que estamos haciendo aquí es tomar y concatenar el año con un guión y luego el número de la semana, de modo que tengamos un campo clave para unirlo a la tabla de fechas.

Sin embargo, tenemos que trabajar un poco más aquí porque la forma en que funciona el campo clave en la tabla Fechas es un guión Año de cuatro dígitos y luego una semana de dos dígitos. Entonces, en los casos en que el número de semana ISO tiene dos dígitos, podemos hacer la concatenación simple. En los casos en que es un dígito, debemos tomar el número del año y luego concatenarlo con un guión, luego un cero inicial y luego el número de la semana.

Una vez que tengamos eso, podemos tomar esa tabla en el modelo de datos y encontrar nuestra columna Semana y Año. Luego, los unimos en una relación de uno a muchos. Siempre me gusta activar esta opción en los campos relacionados con Pin en la parte superior de la tarjeta para que cuando la marquemos, podamos verla de inmediato.

Si volvemos a lo visual, tenemos que cambiar las filas. En lugar del número de año y semana, queremos usar el número de año y semana de la tabla CROSSJOIN. Y ahora, tenemos la semana 53 de 2018 con un espacio en blanco y la semana 53 de 2019 con un espacio en blanco. En 2020, tenemos un número real ya que tiene la semana 53.

Podríamos detenernos aquí, excepto por el hecho de que ahora nos hemos alejado del modelo Star Schema. Cada vez que se aleja del esquema en estrella en LuckyTemplates, se sale del ámbito de lo que generalmente se considera la mejor práctica.

Y así, para Snowflake Schema, no es una gran violación. Hay casos en los que definitivamente querrás usarlo, pero si puedes evitarlo, inténtalo. Reduce la duplicación, pero no necesariamente el tamaño. Le permite usar medidas de conteo directo, pero hay problemas de rendimiento y posibles problemas de usabilidad, y definitivamente aumenta la complejidad de DAX. Le impide crear jerarquías entre tablas, y probablemente el más problemático es que realmente puede estropear su capacidad para sincronizar segmentaciones en diferentes campos.

Entonces, si bien esto resuelve el problema, lo hace de una manera que no es excelente. Veamos si podemos hacerlo mejor que esto. Pasemos a otro modelo de datos. En este modelo, he tomado exactamente los mismos datos, las fechas y el precio al contado, pero esta vez he quitado la tabla CROSSJOIN. Todavía existe, pero no está conectado.

Pero si observamos el DAX, veremos que es exactamente el mismo DAX que creó esa tabla en el otro informe. Entonces, en lugar de conectarlo en una relación física y luego violar el esquema de estrella y convertirlo en un esquema de copo de nieve, podemos mantener el esquema de estrella y simplemente usar una relación virtual.

Para hacer eso, usaremos una función llamada . Crea esa relación entre tablas pero lo hace virtualmente. Hacemos eso usando porque vamos a cambiar el contexto. En este caso, el contexto va a ser con respecto a la relación. Entonces, tenemos nuestro precio total al contado, y luego tenemos TRATAMIENTOS. Tenemos para convertir esa columna en una tabla.

Y luego, tenemos el campo Año y semana, que es la clave que creamos. Lo tenemos unido de forma virtual a Week & Year en la tabla Dates. Así que ahora tenemos esa tabla Crossjoint filtrando la tabla Dates de la misma manera que lo hacía cuando teníamos una relación física, pero sin violar el Star Schema.

Ahora podemos tomar y soltar ese TREATAS de precio total al contado en la matriz y lo que vemos son exactamente los mismos totales. De esta forma, lo hemos hecho sin interrumpir nuestro modelo de datos y sin incurrir en ninguna de las desventajas de las que hablamos en relación con el esquema Snowflake.

Obtener valores de la semana anterior de LuckyTemplates con DAX y Power Query
Calcular ventas semanales con DAX en LuckyTemplates
Inteligencia de tiempo en DAX: cómo seleccionar dinámicamente el período de inicio

Conclusión

En este tutorial, le mostré un par de formas de abordar el problema del cálculo semanal de DAX en LuckyTemplates. Una es usando CROSSJOIN, pero tiene algunas desventajas. La segunda forma es mediante el uso de TREATAS, creando una relación virtual y sin violar el enfoque Star Schema.

Esa es una técnica bastante útil para lidiar con el problema de la semana 53. Espero que lo hayas encontrado útil. Quiero saber tu opinión sobre esto. Déjame saber abajo en los comentarios.

Mis mejores deseos,