Fermer

    De quel département êtes-vous ?

    Vos informations générales

    Quel est votre objectif ?

    Quel est le nombre d'utilisateurs
    pour votre projet ?

    A quelle étape vous trouvez-vous actuellement ?

    Quel est le délais de mise en place que vous souhaitez ?

    Précédent

    Déclenchez le signal !
    Nous sommes les héros de Tableau Software, Microsoft Power BI et Alteryx ? Découvrez quelques unes de nos réalisations Let's rock ! Led Zeppelin et le basketball français en statistiques.

    Maîtrisez votre temps !
    Nous travaillons avec les outils Snowflake, Gathering Tools et Alteryx. Découvrez le retour de nos clientsOney Data et Keolis

    Votre futur vous attend !

    Découvrez notre Data Driven Journey et la solution Alteryx.

    Rassemblons vos forces !

    Découvrez notre Data Driven Journey et notre communauté. Renseignez-vous sur nos formation au Data-Universe.

    Drive your insights!

    Découvrez notre Communauté et nos réalisations Let's rock ! Led Zeppelin et la gestion d'une équipe de basketball en statistiques.

    Évoluez à l'infini et au-delà !

    Découvrez notre méthode exclusive : Data Driven Journey. Accédez à notre panel de formations.

     

    Article

    DAX : Les « clusters »
    et la notion « d’auto-exist »

    Rédigé par Julien Oudille – Consultant BI Actinvision

    Lorsque l’on créé un visuel avec Power BI, peu importe le mode de stockage ou la complexité des calculs, la requête DAX sous-jacente aura toujours la même structure qui repose sur l’utilisation de la fonction SUMMARIZECOLUMNS.

    Prenons par exemple le graphique ci-dessous avec un filtre basique :

    Graphique Power BI

    La requête DAX envoyée et exécutée par le moteur est la suivante :

    Requête DAX

    La fonction SUMMARIZECOLUMNS possède 3 types d’arguments : les champs de partitionnement (les axes du visuel), les filtres (arguments de tables) et les mesures.

    Dans cet article, nous allons voir de quelle manière Power BI interprète un système de filtres composé de plusieurs colonnes de la même table.

    CAS D’ETUDE :

    Considérons la table PRODUIT suivante dans le cadre de cette démonstration :

    Clusters et Auto-exist : Table Produit

    Dès lors qu’une table est appelée dans une expression DAX, Power BI crée ce qu’on appelle un cluster de données, qui correspond à l’ensemble des combinaisons de valeurs effectivement présentes dans la table.

    Un exemple avec la mesure suivante pour calculer le nombre de couleurs distinctes :

    DAX : cluster at auto-exist requête sql

    Cette requête nous retourne évidemment le nombre  4.

    DAX table cluster couleur

    Faisons un test en rajoutant un compteur du nombre de lignes au global dans la table temp_table.
    En supposant que le seul filtre posé ici est sur le champ Produit[Couleur], il suffirait d’ajouter l’expression suivante :

    DAX requête sql

    Un MAX sur cette table devrait donc toujours nous donner 8, or l’expression suivante nous donne le résultat :

    DAX résultat table

    Ceci est lié au comportement de la fonction SUMMARIZE, qui introduit systématiquement un cluster de données selon la table appelée.

    Pour chaque combinaison de valeurs des colonnes appelées, Power BI va également placer des filtres sur toutes les colonnes de la table appelée, en fonction des combinaisons de valeurs présentes dans la table.

    La table Produit, ici groupée par Couleur, contient les clusters suivants pour chaque couleur :

    DAX : groupement couleur

    Autrement dit, pour la couleur Blue, Power BI introduit le filtre suivant :

    (ID = 1 and Categorie = “Jean” and Taille = “M”)
    OR
    (ID = 4 and Categorie = “Jean” and Taille = “XS”)
    OR
    (ID = 7 and Categorie = “Boxer” and Taille = “L”)

    C’est pourquoi en enlevant le filtre sur Produit[Couleur] dans notre mesure, on obtient seulement 3, à savoir les 3 lignes ci-dessus.

    On peut introduire un test dans l’expression pour vérifier s’il y a bien un filtre direct appliqué sur la colonne Produit[ID] par exemple :

    DAX application filtre

    Le résultat est systématiquement TRUE.

    Prenons un autre exemple, avec une expression de filtre sur les champs Couleur et Taille :

    DAX résultat filtre couleur et taille

    Cette expression nous retourne 2, à savoir les 2 lignes suivantes :

    DAX résultat table filtre

    Nous avons à nouveau un filtre qui implique 2 colonnes de la même table. Ce principe de « clustering » s’applique à nouveau, et le FILTER  retourne une table qui contient les combinaisons de valeurs distinctes des colonnes Produit[Couleur] et Produit[Taille] en fonction du filtre appliqué.

    Ici, les clusters sont donc les suivants : {Blue,M},{Red,M}

    La valeur « S » n’est pas retournée car il n’existe aucune ligne de données {Blue,S} ou {Red,S}.
    C’est la notion d’auto-exist : en créant ses clsuters, Power BI ne retourne que les combinaisons de données effectivement présentes dans la table cible.

    Ainsi, l’expression suivante ne donne pas 4 comme on pourrait s’y attendre (les 4 lignes avec soit « » soit « »), mais bien :

    DAX résultat filtre couleur et tailleDAX nombre de lignes

    Toute fonction DAX qui retourne une table introduit des clusters de valeurs qui s’appuient sur la notion d’auto-exist.

    Ce comportement est le même lorsque le système de filtre est induit par des visuels, par le biais de la fonction SUMMARIZECOLUMNS qui va créer les clusters lorsque les colonnes filtrées proviennent d’une seule et même table.
    Prenons cette fois la mesure suivante :
    Segment DAX

    Si on configure les mêmes filtres sur les colonnes Couleur et Taille, on obtiendra exactement le même résultat, au lieu des 4 lignes attendues pour les tailles « M » et « S » :

    DAX Taille MS

    Pour aller plus loin dans l’analyse, lorsqu’un cluster est introduit avec un système de colonnes et que les valeurs d’une de ces colonnes sont remplacées ultérieurement par une autre expression, elles sont remplacées à l’intérieur du cluster préalablement introduit.

    Considérons la mesure suivante :

    DAX Mesure

    On introduit ici le cluster de valeurs suivantes sur les colonnes Categorie, Taille et Couleur :

    {Jacket,L,Yellow}, {Shirt,M,White}. La mesure retourne donc 2.

    Dax table produitDax nombre de lignes

    Effectuons une petite modification dans le calcul :

    Dax modification calcul

    En appliquant le filtre Produit[Taille] = S dans le calcul de manière ultérieure, on peut s’attendre à remplacer le précédent cluster par le cluster suivant :
    {Trouser,S,White}

    Dax Trouser white

    Il n’en est rien. Car seul le champ Produit[Taille] est impacté par ce nouveau filtre.
    Power BI va transformer les filtres appliqués de la manière suivante :
    {Jacket,L,Yellow}, {Shirt,M,White} à ({Jacket,Yellow}, {Shirt,White}) && {S}

    Au lieu de retourner la ligne {Trouser,S,White}, cette mesure retourne donc un (vide), car il n’y a aucune ligne correspondante.

    Dax case vide

    En conclusion lorsqu’une fonction DAX retourne une table ou lorsque plusieurs champs d’une même table sont filtrés, Power BI introduit un cluster de valeurs pour les colonnes filtrés, qui contient les combinaisons de valeurs distinctes présentes dans la table.

    Lors de l’évaluation d’un visuel, Power BI introduit systématiquement une fonction SUMMARIZECOLUMNS.

    DAX Query

    L’auto-exist s’applique alors sur les colonnes qui proviennent d’une seule et même table, de la même manière qu’avec une table appelée en argument de filtre d’un CALCULATE ou d’un CALCULATETABLE.

    Cette notion d’auto-exist permet d’améliorer la vitesse de traitement mais peut conduire à des résultats erronés lors de l’utilisation de fonction de contexte, comme REMOVEFILTER().

    C’est une des raisons pour lesquelles il faut privilégier une modélisation en étoiles sur Power BI.