Calculs hebdomadaires DAX - Problèmes dintelligence temporelle de LuckyTemplates

Dans le didacticiel d'aujourd'hui, je vais fournir quelques techniques et conseils sur la façon de traiter les problèmes courants causés par la granularité hebdomadaire DAX dans les calculs d'intelligence temporelle. Vous pouvez regarder la vidéo complète de ce tutoriel au bas de ce blog.

J'ai récemment fait un tutoriel sur l'obtention des valeurs de la semaine précédente dans LuckyTemplates. Depuis lors, j'ai plusieurs questions liées à l'intelligence temporelle et particulièrement liées aux valeurs hebdomadaires DAX. Ce n'est pas surprenant car les semaines sont vraiment la granularité la plus mal comportée dans la sphère de l'intelligence temporelle.

Dans le cas des mois, vous avez toujours 12 mois dans une année. Dans le cas des quarts, vous avez toujours quatre quarts. Les semaines sont différentes car il y a sept jours dans une semaine et 52 semaines dans une année, soit 364 jours. Donc, vous avez cette journée supplémentaire qui traîne là-bas. Dans les années bissextiles, vous avez deux jours supplémentaires.

Donc, cela finit en fait dans certaines années, sur la base du schéma de numérotation du numéro de semaine ISO, d'avoir parfois 52 semaines, parfois 53 semaines. La semaine 53 est celle qui va causer le plus de problèmes.

Table des matières

• Problèmes d'intelligence temporelle d'un calcul hebdomadaire DAX
• Conclusion

Problèmes d'intelligence temporelle d'un calcul hebdomadaire DAX

Dans cet exemple, j'utilise le prix total au comptant. Avec les totaux, il est plus facile de visualiser et d'en parler.

Dans ce cas, pour chacune des années, nous souhaitons afficher une ligne pour la semaine 53, qu'il y ait eu ou non une semaine 53 cette année-là. Donc, vous pouvez voir qu'en 2018 et 2019, il n'y a pas de semaine 53, mais en 2020, il y en a. Nous voulons qu'il soit cohérent afin que la 53e ligne soit présente chaque année. Mais alors, la métrique serait vide pour les années où il n'y a pas eu de 53e année.

L'une des méthodes les plus courantes consiste à afficher les éléments sans données et à s'assurer qu'ils sont activés. Dans ce cas, il est activé, mais cela ne va pas aider car cela fonctionne lorsque vous avez une ligne physique, mais aucune donnée associée à cette ligne. Dans ce cas, nous n'avons même pas la ligne.

Des techniques telles que ou Remove Filters ne fonctionneront pas car il n'y a rien à supprimer. Le filtre sur cette ligne n'existe tout simplement pas. Et donc, la question est de savoir comment insérer cette ligne dans chaque année où elle n'existe pas ? Et puis, cela devient vraiment un problème de modélisation de données.

L'une des choses que nous pouvons potentiellement faire est d'utiliser un schéma de flocon de neige dans lequel nous filtrons le tableau Dates par quelque chose qui forcera cette 53e semaine dans notre visuel chaque année. La fonction qui me vient à l'esprit pour cela est .

CROSSJOIN est utilisé pour faire correspondre deux champs qui peuvent ou non avoir une relation. Ils n'ont pas besoin d'avoir une relation contrairement à la plupart des ou , ou d'autres fonctions de table.

Dans ce cas, CROSSJOIN prend deux colonnes et crée chaque combinaison de ces deux colonnes, qu'elle existe ou non dans l'ensemble de données. C'est exactement ce que nous voulons.

Nous avons nos pour créer une table à partir de la colonne. CROSSJOIN prend deux tables, puis VALUES sur le numéro de semaine ISO, et nous les faisons correspondre ensemble. Cela va nous donner 53 semaines chaque année.

Et puis, nous ajoutons une troisième colonne au tableau. Nous pourrions le faire dans Power Query, mais il est simplement plus facile de vous montrer la logique dans DAX. Ce que nous faisons ici, c'est que nous prenons et concaténons l'année avec un trait d'union, puis le numéro de la semaine, de sorte que nous ayons un champ clé pour le joindre à la table Dates.

Cependant, nous devons faire un peu plus de travail ici car la façon dont le champ clé fonctionne dans la table Dates est un tiret Année à quatre chiffres, puis une semaine à deux chiffres. Ainsi, dans les cas où le numéro de semaine ISO est à deux chiffres, nous pouvons simplement faire la simple concaténation. Dans les cas où il s'agit d'un chiffre, nous devons prendre le numéro de l'année, puis le concaténer avec un trait d'union, puis un zéro non significatif, puis le numéro de la semaine.

Une fois que nous avons cela, nous pouvons prendre cette table dans le modèle de données et trouver notre colonne Semaine et année. Ensuite, nous les rejoignons dans une relation un-à-plusieurs. J'aime toujours activer cette option sur les champs liés à l'épingle en haut de la carte afin que lorsque nous le vérifions, nous puissions le voir tout de suite.

Si nous revenons au visuel, nous devons changer les lignes. Au lieu du numéro d'année et de semaine, nous voulons utiliser le numéro d'année et de semaine de la table CROSSJOIN. Et maintenant, nous avons cette 53e semaine en 2018 avec un blanc, et la 53e semaine en 2019 avec un blanc. En 2020, nous avons un nombre réel puisqu'il a la 53e semaine.

Nous pourrions nous arrêter ici, sauf que nous sommes maintenant sortis du modèle Star Schema. Chaque fois que vous vous éloignez du schéma en étoile dans LuckyTemplates, vous sortez du domaine de ce qui est généralement considéré comme la meilleure pratique.

Et donc, pour Snowflake Schema, ce n'est pas une énorme violation. Il y a des cas où vous voudrez certainement l'utiliser, mais si vous pouvez l'éviter, essayez de le faire. Cela réduit la duplication, mais pas nécessairement la taille. Il vous permet d'utiliser des mesures de comptage direct, mais il existe des problèmes de performances et des problèmes d'utilisation potentiels, et augmente définitivement la complexité DAX. Cela vous empêche de créer des hiérarchies entre les tables, et le plus problématique est probablement que cela peut vraiment gâcher votre capacité à synchroniser les trancheuses sur différents champs.

Ainsi, bien que cela résolve le problème, il le fait d'une manière qui n'est pas géniale. Voyons si nous pouvons faire mieux que cela. Passons à un autre modèle de données. Dans ce modèle, j'ai pris exactement les mêmes données, les dates et le prix au comptant, mais cette fois j'ai supprimé la table CROSSJOIN. Il existe toujours, mais il n'est pas connecté.

Mais si nous regardons le DAX, nous verrons que c'est exactement le même DAX qui a créé cette table dans l'autre rapport. Ainsi, au lieu de le connecter dans une relation physique, puis de violer le schéma en étoile et de le convertir en un schéma en flocon de neige, nous pouvons maintenir le schéma en étoile et simplement utiliser une relation virtuelle.

Pour ce faire, nous allons utiliser une fonction appelée . Il crée cette relation entre les tables mais le fait virtuellement. Nous faisons cela en utilisant parce que nous allons changer le contexte. Dans ce cas, le contexte va être en ce qui concerne la relation. Donc, nous avons notre prix total au comptant, puis nous avons TREATAS. Nous avons le pour transformer cette colonne en table.

Et puis, nous avons le champ Année et semaine, qui est la clé que nous avons créée. Nous avons cela joint de manière virtuelle à Semaine et année dans le tableau Dates. Nous avons donc maintenant cette table Crossjoint qui filtre la table Dates de la même manière que lorsque nous avions une relation physique, mais sans violer le Star Schema.

Nous pouvons maintenant prendre et déposer ce prix total au comptant TREATAS dans la matrice et ce que nous voyons est exactement les mêmes totaux. De cette façon, nous l'avons fait sans perturber notre modèle de données et sans subir l'un des inconvénients dont nous avons parlé en relation avec le schéma Snowflake.

Obtenir les valeurs de la semaine précédente LuckyTemplates à l'aide de DAX et de Power Query
Calcul des ventes hebdomadaires avec DAX dans LuckyTemplates
Time Intelligence In DAX : Comment sélectionner dynamiquement la période de début

Conclusion

Dans ce didacticiel, je vous ai montré plusieurs façons de résoudre le problème de calcul hebdomadaire DAX dans LuckyTemplates. L'une consiste à utiliser CROSSJOIN, mais elle présente certains inconvénients. La deuxième méthode consiste à utiliser TREATAS, à créer une relation virtuelle et à ne pas violer l'approche Star Schema.

C'est une technique qui est très utile pour traiter ce problème de la semaine 53. J'espère que vous avez trouvé cela utile. Je veux connaître votre opinion à ce sujet. Faites-le moi savoir dans les commentaires ci-dessous.

Tous mes vœux,