DAX: L’utile fonction USERELATIONSHIP

Une question posée sur le forum m’a inspiré l’article suivant, qui démontrera l’utilité de la fonction USERELATIONSHIP en DAX, le langage utilisé par Power Pivot et Power BI.

Données de départ et objectif visé

Un usager du forum a fourni des données de départ semblables à celles ci-dessous (nous les avons simplifiées pour fins de démonstration). On y retrouve différentes tâches, à différentes dates. Ces tâches sont reçues par un agent (AgentRec) et sont ensuite traitées par ce même agent ou par un autre agent (AgentTrait). Dans cette même table, l’usager avait ajouté deux colonnes calculées. La première, LuiMeme, affiche un “O” lorsque l’agent traitant la demande est le même que l’agent recevant la demande et un “N” dans le cas contraire. La deuxième, Autre, affiche un “O” lorsque l’agent traitant la demande est différent de celui qui la reçoit et un “N” dans le cas contraire. À noter qu’une seule colonne aurait été suffisante pour réaliser cette tâche. Mieux encore, on aurait pu éviter d’ajouter ces colonnes (ce qui est toujours préférable en DAX) et utiliser plutôt une mesure itérative.

Toutefois, pour les fins de cet exemple, nous avons repris les données de l’usager du forum. Donc, dans mes visualisations de données ci-dessous, vous apercevez un 1 vis-à-vis les tâches traitées par l’agent qui les as reçues (dans la colonne ParLui) et un 1 vis-à-vis les tâches traitées par un autre agent (dans la colonne ParAutre). Ces deux colonnes sont générées par des mesures (ParLui et ParAutre) qui seront présentées plus loin.

L’objectif était d’obtenir les trois informations suivantes, par le biais d’un seul et même segment, permettant aux usagers d’obtenir les informations pour un agent en particulier:

On peut effectivement valider, dans le tableau de départ, que le nombre de tâches reçues et traitées par l’agent A est égal à 3.

De même, on peut valider que le nombre de tâches reçues par l’agent A et traitées par un autre agent sont de l’ordre de 6.

Et finalement, on peut aussi valider que le nombre de tâches qui ont été reçues par un autre agent que l’agent A et qui ont été traitées par l’agent A sont au nombre de 4.

Vous devez analyser de grandes quantités de données et les présenter dans des rapports et tableaux de bord, avec des indicateurs de performance pertinents ? Développez vos compétences avec nos formations en Power BI.

Modèle de données

La première grande problématique rencontrée dans les données soumises par l’usager du forum était liée à ses données sources, qui logeaient dans une seule et même table, plutôt que dans un modèle de données. Pour utiliser Power BI ou Power Pivot de façon efficace, tout usager devrait d’abord apprendre à créer des modèles de données qui respectent les meilleurs pratiques d’affaires. À cet effet, je vous recommande notre formation Excel – Introduction à Power Pivot et aux modèles de données.

J’ai donc corrigé la situation et généré le modèle de données ci-dessous. Notez qu’il y a deux relations entre la table de faits Tâches et la table de dimension DimAgents.

Plus précisément, la première relation est établie entre le champ Agents de la table DimAgents et le champ AgentRec de la table Tâches.

Et la deuxième relation est établie entre le champ Agents de la table DimAgents et le champ AgentTrait de la table Tâches.

Notez toutefois qu’il n’est pas possible d’avoir deux relations “actives” en même temps entre deux tables du modèle de données. La deuxième relation est donc présentée en pointillée et n’est donc pas active. Cela signifie que par défaut, toutes les mesures en DAX utiliseront la relation active. Mais il y aura toutefois un moyen, quand les circonstances l’exigeront, d’utiliser la relation inactive et cela, grâce à la fonction USERELATIONSHIP.

Utilisation de la fonction USERELATIONSHIP

Dans un premier temps, il est plutôt aisé de calculer le nombre de tâches qu’un agent sélectionné a reçues et traitées lui-même et le nombre de tâches qu’il a reçues et n’a pas traitées lui-même. Cela est possible grâce aux mesures suivantes:

ParLui = CALCULATE(COUNT(Taches[Lui-même]),Taches[Lui-même]=”O”)

Étant donné que par défaut, les mesures ci-dessus vont utiliser la relation active entre la table  DimAgents et la table Tâches, ce qui se passe, c’est que le segment où l’usager choisit l’agent (dans notre image, l’agent A), filtre la table de tâches sur la colonne AgentRec. Ce faisant, toutes les lignes qui présentent l’agent B, dans cette colonne, sont écartées. Par la suite, les deux mesures ci-dessus ajoutent un deuxième filtre. La première mesure ajoute un filtre sur la colonne Taches[Lui-même] et la deuxième mesure ajoute un filtre sur la colonne Taches[Autres]. Tout fonctionne donc à merveille.

Toutefois, pour le troisième résultat recherché, i.e. le nombre de tâches traitées par l’agent A mais qui n’ont pas été reçues par l’agent A, on a un problème. En effet, on part avec un modèle qui par défaut, est filtré sur la colonne AgentRec pour l’agent A. Et ce que l’on cherche à obtenir, c’est justement l’inverse, i.e. les lignes où l’agent qui reçoit la demande n’est pas l’agent A. Il faut donc ici cesser d’utiliser la relation active et utiliser plutôt la relation inactive, en insérant la fonction USERELATIONSHIP dans notre fonction CALCULATE.

Indirect = CALCULATE(

COUNT(Taches[AgentTrait]),

USERELATIONSHIP(Taches[AgentTrait],DimAgents[Agents]),

Taches[Autre]=”O”)

Pour utiliser la relation inactive, on doit donc insérer la fonction USERELATIONSHIP et indiquer le champ de la table de faits et le champ de la table de dimension que l’on souhaite utiliser dans la relation. Ceci nous permettra de filtrer le modèle de données pour ne conserver que les lignes qui présentent l’agent A dans la colonne AgentTrait. Ensuite, le filtre Taches[Autre]=”O” permet de vérifier si l’agent qui reçoit la demande est le même que l’agent qui la traite. Nous, on veut qu’ils soient différents donc on cherche les “O”.

Fichier d’accompagnement VIP à télécharger

Pour télécharger le fichier utilisé dans ce tutoriel, devenez membre VIP du CFO masqué.

Formation recommandée

Encore une fois, on peut constater ici que pour être en mesure de créer les visualisations de données que l’on souhaite, il s’avère important de maîtriser le langage DAX. Pour apprendre la langage DAX, je vous propose notre formation Introduction au langage DAX (Power Pivot et Power BI Desktop).

Voici quelques commentaires d’apprenants ayant suivi cette formation :

La mission du CFO masqué est de développer les compétences techniques des analystes et des contrôleurs de gestion en informatique décisionnelle avec Excel et Power BI et favoriser l’atteinte de leur plein potentiel, en stimulant leur autonomie, leur curiosité, leur raisonnement logique, leur esprit critique et leur créativité.