First N Business Days Revisited - Une solution de langage de codage DAX

Reprenons le problème abordé dans ce tutoriel , qui comparait dynamiquement les N premiers jours ouvrés de chaque mois. Ce problème était basé sur une requête d'un membre de LuckyTemplates sur notre forum, où il voulait rechercher et comparer dynamiquement les 5, 10, 15 et 20 premiers jours facturables (les non-week-ends et les jours fériés) pour un mois donné contre le mois précédent.

Au lieu d'utiliser PowerQuery, nous proposerons une solution de langage de codage DAX. Vous pouvez regarder la vidéo complète de ce tutoriel au bas de ce blog.

Dans la première vidéo , j'ai trouvé une solution de requête de puissance sur la façon de résoudre ce problème. Mais ensuite, l'un de nos experts LuckyTemplates, Antriksh Sharma, a proposé une mesure brillamment efficace qui vaut également la peine d'être approfondie. Nous discuterons de certaines des techniques qu'il a utilisées pour développer une mesure, ce qui vous fournira des outils supplémentaires dans votre boîte à outils DAX.

Cela a certainement été le cas pour moi et pour certains des autres experts qui se sont penchés sur la question. La comparaison à l'identique de jours ouvrables comparables sur plusieurs mois est un modèle précieux en général qui peut être utilisé dans de nombreuses situations.

Plongeons-nous dans la requête de puissance et regardons ce qu'Antriksh a fait ici. Nous avons le mois et l'année , les ventes totales et enfin, les ventes totales pour N jours ouvrables que nous avons sélectionnés à l'aide d'une requête de puissance basée sur le paramètre de simulation que nous avons développé.

Antriksh a adopté une approche très différente, où il a utilisé une mesure étonnamment courte pour résoudre tout ce problème. La première chose que j'ai remarquée à ce sujet était l'utilisation de la commande .

Il s'agit d'une fonction DAX que je n'utilise pas très souvent, mais qui convient parfaitement à ce type de problème. Si nous jetons un coup d'œil au guide SQL BI DAX, il est dit que la fonction GENERATE est une fonction de table qui utilise comme entrée deux tables différentes, puis fait un équivalent de la commande SQL CROSS APPLY.

Il prend donc une table de base (Table1) et itère dessus, puis prend une deuxième expression de table et l'évalue pour chaque ligne de la première table, puis revient à la table en tant que sortie.

Prenons la mesure d'Antriksh et déposons-la dans le tableau. Nous pouvons voir qu'il produit exactement les mêmes résultats que la solution de requête de puissance que nous avons faite la dernière fois. C'est donc bien et valide assez bien les deux mesures.

Démontons cette mesure. Le premier filtre appliqué ici est Dates[IsBusinessDay] = TRUE. Cela supprime toutes les dates autres que les week-ends et les jours fériés en fonction du champ IsBusinessDay de la table de dates étendue.

Nous en parlons beaucoup plus dans le premier tutoriel , où nous avons également expliqué comment lier cela à notre table de vacances.

La partie intéressante de cela vient vraiment des deux entrées de table. Le premier tableau est juste un tableau à une colonne du champ Mois et année dans le tableau Date.

Mais la deuxième entrée de table est l'endroit où se produisent les choses intéressantes. Antriksh a utilisé une , puis a utilisé notre paramètre dynamique comme nombre de lignes dans le TOPN.

La mesure Total Sales est attachée à la deuxième table, puis appliquée à la première table.

Table des matières

• Comprendre une mesure complexe à l'aide du langage de codage DAX
• Utilisation de la table GENERATE dans le langage de codage DAX
• Ajuster dynamiquement le titre de la mesure
• Conclusion

Comprendre une mesure complexe à l'aide du langage de codage DAX

L'un des moyens les plus simples de comprendre ce que fait une mesure complexe comme celle-ci est d'aller dans Tabular Editor . Nous pouvons jeter un œil à cette expression et comprendre ce que fait cette expression TOPN en premier.

Copions la partie TOPN et créons une nouvelle requête DAX . N'oubliez pas que les requêtes DAX commencent par EVALUATE.

Lorsque nous collons la partie TOPN, nous verrons que cela extrait les 5 premières dates de la table des commandes client. Il y a une table dans le TOPN qui est composée des valeurs de toutes les dates de commande dans la table des ventes.

Cette fonction TOPN prend la valeur du paramètre de simulation (qui dans ce cas est 5) et l'applique au champ de date de la commande client. Ensuite, il extrait les 5 premières dates dans le contexte du filtre dans un ordre croissant basé sur ce champ.

Étant donné qu'il n'y a pas de contexte de filtre supplémentaire, il extrait simplement ces 5 premières dates de l'ensemble du tableau.

La colonne @Sales ajoute simplement le total des ventes dans le contexte de filtre approprié à la table TOPN.

Jusqu'à présent, nous avons le premier tableau du mois et de l'année, le deuxième tableau du TOPN des premières N dates de la table des ventes, puis le total des ventes associées à cela.

Utilisation de la table GENERATE dans le langage de codage DAX

Voyons ce que fait cette table GENERATE. Nous allons revenir dans Tabular Editor et créer une nouvelle requête DAX.

Nous allons commencer comme nous le faisons toujours avec EVALUATE, coller la partie GENERATE du code et cliquer sur 5.

Nous pouvons voir que pour chaque ligne de la première table, il itère et rejoint les 5 lignes de la table TOPN évaluées en contexte avec la fonction @Sales.

Cela a pris les 5 premiers jours ouvrables d'avril, les 5 premiers jours ouvrables de mai, les 5 premiers jours ouvrables de juin, et ainsi de suite jusqu'à ce qu'il arrive à la fin du premier tableau.

C'est exactement ce dont nous avons besoin, et maintenant il devient relativement simple d'additionner ces valeurs. Nous avons le résultat (qui est la variable de table des résultats GENERATE) et nous devons ensuite résumer la fonction @Sales.

Dans le contexte, nous résumons maintenant les 5 premiers jours ouvrables d'avril, les 5 premiers jours ouvrables de mai, et ainsi de suite jusqu'à ce que nous arrivions à notre total de 23 737 430 $, auquel cas il n'a pas de contexte de mois et d'année pour fonctionner .

Cela résume toute la colonne @Sales et nous donne exactement le même total que celui que nous avions dans notre solution de requête de puissance.

Vous pouvez voir que si nous changeons le slicer en 10, nous obtenons dynamiquement les mêmes résultats avec le langage de codage DAX que nous avons obtenus dans PowerQuery.

Nous avons également le graphique à barres en bas qui s'ajuste dynamiquement pour refléter les changements que nous avons apportés.

Ajuster dynamiquement le titre de la mesure

Il y a une autre astuce supplémentaire que je voulais vous montrer. Vous pouvez créer un ajustement dynamique sur votre paramètre de simulation et le lier dynamiquement à un titre de mesure.

Par exemple, si nous changeons le segment en haut en 15, il changera dynamiquement le nom de la mesure en bas en Total Sales for the First 15 Business Days of Each Month .

Il existe un moyen simple de le faire dans DAX en utilisant la mise en forme conditionnelle . Nous prenons simplement trois cordes. Le premier est Total Sales for First , puis concaténez-le avec la valeur que nous récoltons à partir du paramètre what-if, puis liez-le simplement au reste du titre.

Ensuite on rentre dans le visuel, on passe à la mise en forme conditionnelle du titre, et on clique sur fx .

Nous formaterons par valeur de champ et choisirons cette mesure de titre dynamique. Cela changera la sélection du paramètre de simulation.

Conclusion

Nous avons maintenant une solution complète utilisant le langage de codage DAX. Nous avons discuté d'une manière vraiment créative et efficace de le faire en utilisant la fonction GENERATE. Je tiens à remercier Antriksh d'avoir partagé avec nous ses brillantes connaissances DAX. J'ai beaucoup appris en parcourant sa solution DAX, et j'espère que vous aussi.