Les concepts clés

La connaissance du DAX est une clé que se doit de posséder tout créateur de rapport dans Power BI, c’est un langage
constamment enrichi, qui fait l’objet de nombreuses sources d’information - et qui repose sur quelques concepts-clés.

Mesures et colonnes

La mesure comme la colonne permettent de créer de nouvelles données à partir des données existantes, à l’aide d’une
formule DAX ou d’un assistant. Et dans certains cas, une même formule peut servir à construire soit une mesure soit
une colonne.

Une différence fondamentale entre la colonne et la mesure est le moment où le calcul est effectué : pour la colonne, il
est effectué une fois, au chargement des données (ou à l’actualisation), lors du remplissage de la colonne créée.

Pour la mesure, il est effectué à chaque fois qu’elle est ajoutée à un visuel, ou que des segments sont modifiés par
l’utilisateur du rapport.

Conséquence de cette différence : la colonne est physiquement stockée dans le fichier, dont le poids est donc augmenté,
alors que la mesure ne prend pas de place, mais utilise la puissance du processeur pour ses calculs.

La vue Données présentant les tables, il est très tentant (en particulier pour un utilisateur venant d’Excel ou de tout
autre tableur) de créer des champs calculés sous forme de colonne : dans la vue Données, le résultat est immédiatement
visible, et permet de vérifier que le calcul est valide.

Mais si le recours à des champs calculés est fréquent (comme c’est le plus souvent le cas), le nombre de colonnes
ajoutées va finir par être conséquent, et entraîner des problèmes de taille du fichier et de temps d’actualisation (puisque
c’est à ce moment que les colonnes sont calculées).

De plus, la formule générant la colonne est calculée pour chaque ligne de la table : si le nombre de lignes de la table est
important, le nombre de fois où le calcul est effectué l’est tout autant.

Créer une mesure plutôt qu’une colonne présente donc trois avantages significatifs : la formule n’étant calculée qu’au
moment de son utilisation, le temps d’actualisation est plus court, et le poids du fichier n’augmente pas. De plus, si la
formule est utilisée dans un visuel filtré (ce qui est le plus souvent le cas), le calcul n’est effectué que pour les lignes
résultant du filtrage, et par conséquent pour un ensemble de lignes réduit par rapport à la table (ou aux tables) initiale.

Il est essentiel pour les utilisateurs de tableurs (Excel) d’acquérir le réflexe de créer des mesures plutôt que des
colonnes.

-1-
 Vous allez être amené à créer de nombreuses mesures dans ce chapitre. La démarche est toujours la
même : en vue Rapport, la mesure est créée par un clic droit sur le nom de la table où vous souhaitez
ranger la mesure, puis Nouvelle mesure. Vous pouvez également changer la mesure de table en
sélectionnant la mesure dans le volet Champ et en modifiant la Table principale à la gauche de l’onglet
Outil de mesure.

Présentation du DAX

Du point de vue le plus large, le DAX est un ensemble de fonctions permettant de construire une formule à l’aide de
fonctions, de paramètres et de données, évaluée dans le cadre d’un contexte.

Le résultat de cette formule peut être un nouvel indicateur chiffré, un nouveau champ texte ou date ou encore une
nouvelle table à part entière (DAX permet donc de travailler aussi sur le modèle des données).

L’éditeur de formule DAX repose sur IntelliSense, un moteur de langage qui, comme c’est le cas dans Excel, suggère
les fonctions, mots-clés, ou références en fonction de la formule et de ce qu’elle vous autorise à saisir.

Le DAX est utilisé dans Power BI, dans Excel, dans SSAS Tabular, dans Azure AS, etc.

De très nombreux sites proposent de l’aide sur les fonctions DAX. Nous vous
recommandons notamment :

https://dax.guide/

https://docs.microsoft.com/fr-fr/dax/

Note : il existe deux options pour la syntaxe du DAX, que vous trouverez dans le menu Fichier, puis Options et
paramètres, puis Options et enfin dans la rubrique Paramètres régionaux et Séparateurs DAX : les séparateurs
recommandés (la virgule pour séparer les paramètres de la fonction) ou les séparateurs localisés (le point-virgule,
comme dans Excel). Nous utiliserons dans cet ouvrage la première option.

Composants

Les composants d’une formule DAX sont :

-2-
 ˇ les fonctions : plus de 200 au moment où nous écrivons ce livre,
ˇ les paramètres, qui peuvent être soit des valeurs uniques, soit des colonnes, soit des tables (des ensembles
de valeurs) - on parle de fonctions scalaires dans le premier cas, tabulaires dans le second,
ˇ les paramètres incluent également les indications permettant à la formule de fonctionner.

La convention d’écriture veut que le nom d’une colonne soit toujours précédé du nom de la table, alors que le nom
d’une mesure ne l’est pas. Le nom d’une table est entre simples guillemets lorsqu’il contient des espaces ou des
accents.

Formalisme

Les formules DAX pouvant être rapidement complexes, il est fortement recommandé de suivre un certain formalisme
lors de leur écriture (passage à la ligne, indentation, commentaires, alignement de la parenthèse fermante avec le début
du nom de la fonction) : le site https://www.daxformatter.com/ permet d’automatiser cette mise en forme, et de corriger
plus facilement certaines erreurs, mais l’habitude de la faire directement vient très vite.

Les lignes de commentaires, les espaces et les retours à la ligne EntrØe Shift sont encouragés.

Voici un exemple très simple de formule non formatée, suivie de la même formule correctement formatée :

Nbre de pages par commande = CALCULATE(SUM(Livres[Nbre de pages]),

CROSSFILTER('Détail des commandes'[Numéro livre], Livres[Numéro livre], Both))

Nous voyons bien ici que la fonction CALCULATE a deux arguments (SUM et CROSSFILTER) et que cette dernière en
a trois

-3-
Variables

Les formules peuvent également incorporer des variables : il s’agit de calculs utilisés plusieurs fois dans la formule.
Plutôt que de refaire le calcul à chaque fois (ce qui est coûteux en temps, surtout sur des tables importantes), le déclarer
en variable permet de ne l’effectuer qu’une seule fois, et de le stocker en mémoire tout le temps de l’exécution de la
formule.

Une variable est déclarée de la manière suivante :

VAR mavar1 = SUM('Détail des commandes'[Prix de vente])

VAR mavar2 = SUM('Détail des commandes'[Quantité]) RETURN

Chaque variable créée dans une formule est définie sur une ligne débutant par VAR.

Le mot-clé RETURN déclenche le calcul de toutes les variables déclarées juste au-dessus, et permet le stockage en
mémoire du résultat pendant toute la durée du calcul de la formule dans son ensemble.

Deux raisons sont avancées pour la création de variables : d’abord le fait que le calcul est effectué une seule fois,
d’autre part le fait que la formule elle-même sera beaucoup plus lisible si elle fait référence à des noms de variables
plutôt qu’aux fonctions et calculs dont elles sont le résultat.

Commentaires

Et pour terminer, une formule DAX peut (doit !) contenir des commentaires : ils permettent de documenter et de mieux
comprendre la construction de la formule. C’est notamment particulièrement important pour des rapports que vous
reprenez pour les modifier, longtemps après leur création initiale.

Les commentaires sont introduits de trois manières :

ˇ Par un double tiret (--) : toute la ligne est en commentaire.

ˇ Par un double // : toute la ligne est en commentaire.
ˇ Par /* puis */ : toutes les lignes entre ces deux signes sont en commentaire.

Exemple d’une formule

Voici une formule DAX illustrant ces différents points :

Ventes avec SELECTEDVALUE =

-- création d'une variable pour clarifier la formule

VAR promo = MAX(Promotion[PromotionName]) RETURN

-- début du calcul
IF (

-4-
 SELECTEDVALUE ( Promotion[PromotionName] ) = promo,
SUM ( Sales[SalesAmount] ), 0
)

Le nom de la variable est indiqué avant le signe =. Ici, Ventes avec SELECTEDVALUE.

Vient ensuite un commentaire (précédé de deux tirets).

La formule fait appel à une variable - dont l’intérêt ici est de rendre la formule plus lisible. La création de la variable est
confirmée par RETURN.

Enfin, le calcul a lieu : il s’agit ici d’un calcul conditionnel (IF).

La formule respecte un formalisme qui en facilite la lecture et la compréhension.

Contexte de ligne et contexte de filtre

Le concept fondamental pour comprendre le fonctionnement des formules DAX est celui du contexte : avant que la
formule ne soit calculée, elle est évaluée dans un environnement défini essentiellement par les filtres qui s’y appliquent
et par la table ou les tables auxquelles elle fait appel.

Il y a deux types de contextes dans Power BI : le contexte de filtre et le contexte de ligne, qui ont tous deux pour effet
de filtrer le résultat du calcul demandé. Les deux contextes peuvent s’appliquer isolément ou simultanément.

Le contexte de ligne

Le contexte de ligne s’applique uniquement lors de la création d’une colonne ou lors de l’utilisation d’une fonction
itérative (SUMX, AVERAGEX, COUNTX, etc., ainsi que la fonction FILTER).

Ainsi, lors de la création d’une colonne dans une table de 100 lignes, le calcul sera effectué 100 fois, avec un contexte
de ligne différent à chaque fois.

Dans la formule :

Ventes promotions ASP =

SUMX (
FILTER (
Sales,
RELATED ( Promotion[PromotionName] ) = "ASP"

-5-
 ),
Sales[SalesAmount]
)

Cette formule est donnée à titre d’exemple : l’utilisation de la fonction CALCULATE

est préférable dans ce cas de figure.

La fonction FILTER génère une table à partir de la table Sales ne retenant que les lignes pour lesquelles la promotion
(dans une table liée) est ASP ; cette table est passée en argument à la fonction SUMX qui additionne la colonne
SalesAmount.

L’intérêt d’utiliser ici la fonction SUMX est qu’elle reçoit une table en
argument (résultat de la fonction FILTER) : cela nous permet donc préalablement
de filtrer la table SALES.

Le contexte de filtre

Pour chaque calcul effectué (c’est-à-dire, chaque cellule d’un tableau, ou la hauteur de chaque barre d’un
histogramme), le contexte de filtre est évalué et défini implicitement. Il peut être affecté :

ˇ par les autres données du visuel (par exemple, ligne et colonne d’une matrice, axe X d’un histogramme),
ˇ par les segments,
ˇ par les autres visuels,

ˇ par les filtres de visuel, de page ou de rapport.

Mais le contexte de filtre peut également être défini explicitement, par le recours aux fonctions DAX, comme nous le
verrons plus loin, et notamment par le recours à la fonction CALCULATE. Lorsque le filtre implicite et le filtre
explicite portent sur la même colonne, c’est le filtre explicite qui prend le dessus.

-6-
La règle d’or est la suivante : le contexte d’abord, le calcul ensuite

Dans le tableau ci-dessous, la mécanique de calcul permettant d’obtenir $111 550 625,29 (montant des ventes pour
l’Asian Spring Promotion, vendu via Internet - Online) est la suivante :

ˇ À l’arrivée sur la ligne du tableau, le contexte de filtre est vidé (remis à zéro).
ˇ Puis il est évalué : dans cet exemple, le contexte de filtre est défini par le canal de vente Online et le nom
de la promotion Asian Spring Promotion.
ˇ En l’absence de filtre explicite, il est maintenu en l’état.
ˇ La table dont est issue la donnée à calculer (le montant) est filtrée.
ˇ Enfin, seulement le calcul est effectué : les lignes restantes sont additionnées.

Ainsi, dans ces visuels :

ˇ le résultat en blanc ($ 932,6 M) est obtenu en appliquant un contexte de filtre vide (étant admis qu’il n’y a
pas de segments ou d’autres filtres),
ˇ le résultat en noir est obtenu en appliquant un contexte de filtre défini par le canal de vente (Online ou
Store) et sans aucun autre filtre - en d’autres termes, ce n’est pas l’addition des chiffres des trois lignes
au-dessus,
ˇ le résultat en gris est obtenu en appliquant un contexte de filtre défini par le canal de vente et le nom de la
promotion.

-7-
En définitive, chacune des neuf apparitions du montant (indépendante des autres) est une somme définie par un
contexte de filtre spécifique.

Et voici un exemple qui permet de creuser encore un peu ces notions.

Dans la table ci-dessous a été utilisée la variable définie par :

Ventes avec SELECTEDVALUE =

IF (
SELECTEDVALUE ( Promotion[PromotionName] ) = "Asian Spring Promotion",
"n/a",
SUM ( Sales[SalesAmount] )
)

La fonction SELECTEDVALUE() vérifie la présence dans le contexte de filtre, d’un filtre

Promotion[PromotionName] = "Asian Spring Promotion" sur la cellule où est affiché le calcul. En présence de ce
filtre, la variable renvoie n/a, sinon elle renvoie le calcul SUM.

Voici la table :

Il est essentiel de comprendre que le total est indépendant des lignes situées au-dessus, et qu’aucun filtre portant sur le
nom de la promotion ne s’y appliquant, le calcul intègre les ventes de Asian Spring Promotion !

La clé pour bien comprendre le fonctionnement de la formule est donc d’avoir une idée très claire de la façon dont les
filtres se propagent de table en table, depuis la dimension filtrée (dans l’exemple ci-dessus, le nom de la promotion)
vers la table où sont enregistrées les transactions (Sales).

Dans le cas des exemples que nous allons développer sur la base du fichier Livres - dax.pbix, il est donc important de
rappeler la structure des tables et les relations qui les lient et la règle de propagation d’un filtre :

-8-
En disposant dans la partie supérieure de l’écran les tables de dimensions (qui sont le plus souvent à l’origine des
filtres, implicites ou explicites) et dans la partie inférieure la table montrant le détail des transactions (la table la plus «
profonde » dans le modèle), il est facile de voir la manière dont se propage le filtre.

La règle d’or est que le filtre se propage automatiquement à tout le modèle le long des relations de type 1 à N, et ne
s’arrête que lorsqu’il rencontre une relation en sens inverse (N à 1).

Ainsi, dans notre modèle, un filtre posé implicitement ou explicitement sur le mode de paiement CA (cartes bancaires),
se propage automatiquement le long de la relation 1 à N vers la table des commandes, qu’il filtre par conséquent,
déterminant un ensemble de numéros de commandes qui lui aussi se propage vers la table Détail des commandes, le
long de la relation 1 à N. Cette table est donc à son tour filtrée.

En revanche, le filtrage s’arrête là, puisque le filtre ne peut pas naturellement se propager dans le sens N à 1 (il existe
des fonctions DAX qui forcent le filtre à emprunter la relation N à 1).

-9-
En d’autres termes, la disposition que nous vous proposons permet de dire que le filtre « descend » automatiquement,
mais ne peut pas « remonter » : ceci facilite considérablement l’analyse de la propagation du filtre, au cœur de la
compréhension de la mécanique de calcul de Power BI.

Visuellement, ceci est encore renforcé par la présence d’une icône flèche sur la
relation, qui indique clairement le sens de circulation.

Les relations à double sens et le contexte de filtre

De nombreuses techniques permettent de modifier le comportement « normal » de la propagation du filtre : la mise en

place d’une relation à double sens, grâce à laquelle le filtre se propage dans les deux sens, ou encore son équivalent en
langage DAX, la fonction CROSSFILTER, qui force elle aussi le passage du filtre dans le sens N à 1.

Dans l’exemple ci-dessous, nous cherchons à calculer le total de pages par commandes (la somme du nombre de pages
des livres constituant la commande). À l’origine, la relation de la table Livres à la table Détail des commandes est de
type 1 à N :

- 10 -
La mise en place d’un tableau affichant des données provenant de la table Commandes et/ou de la table Table Dates,
ainsi que Nbre de pages issu de la table Livres, génère un résultat faux :

- 11 -
La propagation du filtre s’étant arrêté à la table Détail des commandes, le nombre de pages résulte d’un calcul sans
filtre (102552 est le nombre total de pages de tous les livres de la base).

En revanche, une solution consiste à mettre en place une relation à double sens, en modifiant les propriétés de la
relation dans la vue Modèle (voir chapitre Se connecter aux données) :

- 12 -
La relation de la table Détail des commandes à la table Livres est maintenant à double sens Une telle

relation est représentée dans la vue Modèle par une flèche à deux sens :

- 13 -
Cette relation, qui permet au filtre de continuer à passer, rétablit le tableau :

- 14 -
Attention toutefois, ces relations à double sens peuvent rapidement s’avérer complexes et générer des résultats
incohérents, et il est préférable de recourir aux fonctions DAX dans ce type de situation :

La quatrième colonne du tableau est correcte, malgré la relation à un sens du modèle initial :

- 15 -
La relation à un sens entre les tables Livres et Détail des commandes est remplacée lors de l’utilisation de la variable,
et uniquement à ce moment-là, par une relation à double sens.

Dans cet exemple, cette variable ne sera utilisée que pour la génération de ce
tableau.

- 16 -