Comparaison de mesures explicites aux groupes de calcul dans des modèles tabulaires

Avec l’avènement des UDF, nous devrions repenser la manière d’utiliser les groupes de calcul.

Ces deux fonctionnalités sont essentielles pour simplifier un modèle sémantique en modularisant la logique et en réduisant la duplication de la logique métier.

Alors que les FDU sont très utiles pour standardiser la logique métier et ne les avoir qu’une seule fois par modèle de données, les groupes de calcul sont utiles aux concepteurs de rapports pour appliquer la logique métier aux mesures.

Les groupes de calcul sont visibles pour les concepteurs de rapports, mais les UDF ne sont utilisables que dans les expressions DAX et ne sont pas utilisables sur le front-end.

Vous pouvez trouver des ressources sur la combinaison des FDU et des groupes de calcul dans la section Références ci-dessous.

La question est de savoir si il faut ajouter des mesures explicites ou proposer uniquement des groupes de calcul aux utilisateurs.

Voici un exemple :

Je dois offrir la possibilité de calculer la valeur de l’année précédente.

• Je peux proposer un élément de calcul que l’utilisateur peut utiliser pour obtenir le résultat souhaité.
• Je peux ajouter une mesure explicite pour le résultat PY.

La question est : lequel offre le plus de flexibilité et est le plus facile à utiliser ?

C’est la question à laquelle je vais tenter de répondre ici.

Le point de vue de l’utilisateur

Tout d’abord, qui est l’utilisateur ?

Il existe deux groupes d’utilisateurs :

• Concepteurs de rapports qui utilisent nos modèles sémantiques et doivent comprendre facilement le modèle sémantique
• Les consommateurs de rapports doivent comprendre ce que nous montrons dans les visualisations sans beaucoup de place à l’interprétation.

En fin de compte, nous devons prendre en charge les deux groupes d’utilisateurs lorsque nous construisons un modèle sémantique.

Dans la section de conclusion ci-dessous, vous trouverez ma principale ligne directrice lors de la conception d’un modèle sémantique.

Mais voyons d’abord les effets des deux approches pour nos utilisateurs.

Utiliser les visualisations matricielles

Tout d’abord, j’ai construit une matrice.

La matrice doit contenir la hiérarchie du calendrier sous forme de lignes et les mesures pour les ventes en ligne, PY et PM dans les colonnes.

De plus, je souhaite découper les résultats par marque.

Tout d’abord, je l’ai fait avec des éléments de calcul :

Le résultat est à la hauteur des besoins.

Notez que je dois filtrer les éléments de calcul pour exclure l’élément PY (semaine), car cela provoquerait une erreur lorsqu’il est utilisé avec les trimestres et les mois.

Ensuite, je l’ai fait avec des mesures explicites :

Comme vous pouvez le constater, les résultats sont identiques.

Mais notez que la première colonne affiche le nom de la mesure au lieu du nom de l’élément de calcul, comme vous pouvez le voir sur la première capture d’écran.

Les mesures explicites me permettent de modifier le nom affiché dans le visuel. Par exemple, les mesures pour PY et PM ont un nom différent :

Ceci est impossible lors de l’utilisation d’éléments de calcul. Les visuels affichent toujours les noms des éléments de calcul, et je ne peux pas les renommer.

Je ne vois même pas le nom de la mesure originale.

Par conséquent, je dois ajouter un titre significatif au visuel. Mais je recommande de le faire quand même.

Utiliser d’autres types de visualisation (colonnes ou barres)

Ensuite, je l’ai fait avec des visuels de colonnes :

Le visuel supérieur utilise les éléments de calcul et le visuel inférieur contient les mesures explicites.

Ici, nous avons la même situation que précédemment :

• Je dois ajouter un filtre sur les éléments de calcul pour le visuel du haut.
• Je peux renommer les mesures dans le visuel du bas.

Mais les résultats sont toujours les mêmes.

J’ai laissé la position par défaut du titre et de la légende. Vous pouvez voir qu’ils doivent être modifiés, car ils contiennent des informations en double. De plus, dans la variante supérieure, vous pouvez voir le terme « Fonction temporelle » dans le sous-titre, qui n’a aucun sens pour tout utilisateur de rapports.

Hormis les titres et sous-titres, les différences sont encore plus faibles par rapport au visuel matriciel.

Tableaux croisés dynamiques dans Excel

Voyons maintenant comment cela fonctionne dans les tableaux croisés dynamiques Excel :

Mais ici, nous avons un problème avec l’élément de calcul PY :

Ce qui ne change pas, c’est la nécessité de filtrer les éléments de calcul pour ne conserver que les éléments nécessaires :

Comme vous pouvez le constater, la colonne PY est vide, même s’il existe des données pour l’année 2022.

En essayant cela avec des mesures explicites, j’ai obtenu ce résultat :

Même avec des mesures explicites, le problème du PY persiste.

J’ai ensuite ajouté une mesure PY utilisant l’intelligence temporelle classique, et cela a fonctionné, comme indiqué ci-dessus avec les valeurs surlignées en vert.

Cela indique un problème avec Excel et l’intelligence temporelle basée sur le calendrier.

Mais je peux toujours renommer les noms des mesures, comme dans Power BI.

Il n’y a donc aucune différence entre les deux variantes.

Le point de vue de l’utilisateur – encore une fois

Lorsque nous examinons le consommateur du rapport, nous pouvons créer les mêmes rapports sans voir de différence.

Au moins pour les exemples simples que j’ai montrés ci-dessus.

Pour le concepteur du rapport, c’est une autre histoire.

Ce type d’utilisateur doit savoir utiliser le modèle de données et les groupes de calcul.

Il s’agit d’un obstacle à la BI en libre-service, dans laquelle les développeurs mettent le modèle de données à disposition et les autres utilisateurs créent leurs propres rapports.

Une bonne documentation sur la façon d’utiliser le modèle de données, ainsi qu’une éducation et une formation, sont impératives lorsque l’on utilise uniquement des groupes de calcul au lieu de proposer des mesures explicites.

Mais on atteint des limites, par exemple, quand on essaie de filtrer les données par une mesure inexistante, car elle n’est disponible qu’avec une rubrique de calcul.

Il en va de même pour les utilisateurs d’Excel qui souhaitent créer des rapports Excel avec des tableaux croisés dynamiques basés sur le modèle sémantique.

Encore une fois, nous devons les informer sur la manière d’utiliser correctement le modèle de données.

Cela est beaucoup plus facile lorsque nous matérialisons toutes les mesures nécessaires et les plaçons dans des dossiers d’affichage bien structurés.

Les utilisateurs peuvent choisir les mesures nécessaires et travailler avec elles.

Conclusion

Comme vous l’avez vu, la création de mesures explicites peut bénéficier au concepteur de rapports qui travaille avec nos modèles sémantiques.

Ma ligne directrice lors de la création de modèles sémantiques est la suivante :

Les besoins de l’utilisateur passent avant tout.
Les raisons techniques passent toujours au second plan.
Aucun gain technique ne l’emporte sur la convivialité et la compréhensibilité du résultat.

Maintenant c’est votre tour.

Quelles sont vos lignes directrices lors de la création d’un modèle sémantique ?

Quel est votre raisonnement le plus important pendant la phase de conception ?

Références

L’article SQLBIqui compare l’UDF et les groupes de calcul et montre comment les combiner.

Et voici la vidéo de cet article :

Ici, la vidéo de Guys in a cube sur le même sujet avec une vue légèrement différente :

Comme dans mes articles précédents, j’utilise l’exemple de jeu de données Contoso. Vous pouvez télécharger gratuitement l’ensemble de données ContosoRetailDW depuis Microsoft. ici.

Les données Contoso peuvent être utilisées librement sous la licence MIT, comme décrit dans ce document. J’ai mis à jour l’ensemble de données pour déplacer les données vers des dates contemporaines et supprimé toutes les tables non nécessaires pour cet exemple.