Le DAX (Data Analysis Expressions) est un langage de formules principalement utilisé dans les produits Microsoft tels que Power BI, Analysis Services et Power Pivot dans Excel. DAX est conçu pour effectuer des opérations de traitement des données en mémoire et fournir des analyses avancées grâce à des fonctions de calcul et de requête.
Mais qu’est-ce que ses concepteurs ont voulu accomplir ? Est-ce que c’est réellement plus pratique de n’utiliser que des fonctions, et jamais d’instructions directes à la machine ? Pourquoi se sentir aussi limité avec ? Comment identifier ce langage ? Comment identifier les langages de traitement de données ?
Les concepts du langage DAX
Chaque langage possède des concepts propres qui lui permettent d’articuler du sens. Par exemple, le français est un langage genré, dénombré, temporalisé (qui comporte passé et futur), souvent articulé comme Sujet/Verbe/Complément, en plusieurs phrases.
Ce n’est pas le cas du langage pirahã. Ce langage ne possède ni genre, ni passé, ni futur, ni nombres ! Cela s’explique car les habitants de cette tribu d’Amazonie n’ont pas d’histoire, ne possèdent pas assez pour compter, ne sont pas assez nombreux pour distinguer père, mère, frère etc… Ce langage est leur manière la plus efficace de communiquer rapidement les informations essentielles dans une jungle très bruyante.
De la même manière, certains langages informatiques possèdent des fonctionnalités limitées par leur portée. Plus un langage est généraliste, plus il dispose de fonctionnalités et est flexible dans son utilisation, mais plus il est lent car l’ordinateur doit faire attention à bien interpréter ce que nous voulons dire à chaque ligne tant les possibilités sont nombreuses.
Dax est dans la position unique d’être uniquement utilisé dans un contexte de traitement de données. Explorons ses caractéristiques et comparons-le à d’autres langages ayant le même but, SQL, R et Python.
Le paradigme fonctionnel du langage DAX
Un paradigme peut-être résumé comme une méthode ou une doctrine de programmation. Le plus courant est le paradigme impératif, il s’agit de donner à l’ordinateur une série d’instructions sur comment exécuter un programme :
- Fais ça
- Puis fais ça
- ..
Le DAX est (presque) uniquement fonctionnel, ce qui signifie que toutes les instructions données à l’ordinateur sont sous forme de transformation d’une entrée en une sortie. Ainsi, on se concentre sur le quoi plutôt que le comment, les grandes idées plutôt que les détails, DAX s’occupe du reste à l’aide de code .NET très optimisé.
Les principes directeurs sont l’immuabilité (les données ne sont pas modifiées mais on crée une copie modifiée des données originelles) et l’absence d’effets secondaires (les fonctions agissent sur l’entrée qu’on leur présente, et absolument rien d’autre).
Exemples de fonctions DAX
- Fonction : Requête de données
- Entrée : une requête Power Query
- Sortie : une table de données
- Fonction : Faire une somme
- Entrée : La colonne d’une table de données
- Sortie : La somme de toutes les valeurs de cette colonne
- Fonction : Faire une moyenne
- Entrée : Les sommes de toutes les colonnes d’une table
- Sortie : La moyenne de ces sommes
Le code perd en flexibilité mais chaque fonction est identifiable, simple, et surtout reproductible. On a donc découpé une série d’instructions en bloc qu’on a appelées fonction, dont l’entrée sera toujours définie de manière identique, et la sortie sera prévisible si on connaît l’entrée.
Or, le but de DAX est de définir des transformations de données, si possible en permettant un diagnostic rapide d’un mauvais résultat en fin de traitement :
> Telle fonction est en échec car elle attendait une entrée numérique, mais une série de données textuelles lui a été donnée. Des mauvaises données ont donc été présentées fonction.
Aussi, cette méthode permet de factoriser et d’optimiser plus facilement des séries de transformations.
Comparaison avec d’autres langages
- SQL a un paradigme déclaratif qui regroupe tous les langages qui s’intéressent plus au quoi qu’au comment. Il n’est pas plus particulier que ça dans son paradigme. Cela fait toujours sa popularité malgré son âge (50 ans !) car il est simple et optimisé puisque réservé uniquement à la requête de données (contrairement à DAX)
- R est aussi fonctionnel mais est beaucoup plus flexible pour d’autres raisons que nous allons évoquer plus tard
- Python est… multi-paradigme. Oui, avec Python on peut faire de la programmation fonctionnelle, mais aussi purement déclarative ou impérative, mais aussi Orienté-Objet (nous ne rentrerons pas dans les détails) ou un peu tout à la fois, mais c’est une très mauvaise pratique.
Typage dans le langage DAX
Toutes les données ont une caractéristique clé, leur type. Est-ce qu’il s’agit d’un nombre ou d’un texte ? D’une chaîne de caractères ou d’une date ? D’une date au format anglais ou considérant l’heure et les décalages horaires ?
Deux distinctions doivent être faites :
Fortement typé vs. Faiblement typé :
-
- Fortement typé: Une fois qu’une variable est déclarée, on précise son type. Il ne peut pas être changé sans une conversion explicite. Si vous essayez d’utiliser une valeur d’un type inapproprié (par exemple, en ajoutant une chaîne de caractères à un nombre), une erreur se produira.
- Faiblement typé: Le système tente de deviner le type que vous voulez utiliser et effectue des conversions automatiquement si c’est possible. Dans certains langages faiblement typés, si vous ajoutez une chaîne de caractères à un nombre, le langage peut essayer de convertir la chaîne en un nombre.
Typage statique vs. Typage dynamique
-
- Typage statique: Le type de chaque variable est déterminé à lors de la traduction finale du code en instruction machine. Les langages à typage statique exigent généralement des déclarations de type explicites.
- Typage dynamique: Le type d’une variable est déterminé à l’exécution. Les variables n’ont pas de types fixes, mais les valeurs qu’elles référencent en ont.
Le DAX est assez difficile à catégoriser pour d’excellentes raisons.
Tout d’abord, en plus des types habituels de données (nombre, texte, date…) il comporte également un type « table » et un type « colonne ». Cela lui permet d’identifier et donc d’optimiser le traitement de nombreuses données d’un même type (car chaque colonne ne contient des valeurs que d’un seul type). Il ne comporte pas non plus de type « null » ou « vide » mais une valeur « blanche » qui mérite un article à elle seule, et qui représente son propre type.
Quand au typage en lui-même :
- Ajouter un nombre à un texte représentant un nombre résultera en une addition, ce qui suggère un typage faible.
- Mais ajouter une date à un texte représentant des nombres résultera en une erreur, ce qui suggère un typage fort.
Cela répond à une exigence de domaine.
Quelles conclusions en tirer ?
Il est pratique dans 99% des cas de conclure que le premier cas résulte en une addition, et évident dans 99% des cas de conclure qu’ajouter une date à un nombre est une erreur, car ce langage s’adresse à des développeurs qui connaissent les jeux de données qu’ils manipulent.
Il n’y a donc besoin que de faciliter leurs actions (premier cas) tout en évitant les combinaisons obscures de données (second cas). Ces dernières restent possibles, mais demande un effort de la part du développeur, comme de convertir chacun des types de données au type nombre pour les additionner, afin d’être certain que c’est volontaire.
Dans beaucoup de langages, un cas par défaut est défini et le développeur doit faire avec. DAX cherche à trouver un juste milieu pour un métier « bien défini » : Développeur data.
Sinon, il s’agit d’un typage statique. Le type est in fine choisi lors de la transmission des instructions à la machine afin d’optimiser l’exécution. Il n’est cependant pas « déclaré » lors de la création de la donnée mais lors de son traitement, dans la pure tradition fonctionnelle.
Qu’en est-il des autres langages ?
- SQL est fortement typé avec déclaration explicite, à l’époque de sa création (années 70) les langages faiblement typés étaient encore expérimentaux.
- R est faiblement et dynamiquement typé, et comporte un très grand nombre de types et de fonctions uniques à chaque type ce qui contribue à sa flexibilité
- Python est fortement typé car il refuse des conversions qui résultent en une perte de donnée ou une ambiguïté mais est très dynamique. La valeur d’une donnée peut varier au cours de l’exécution. C’est typique d’un langage à portée généraliste.
En conclusion
Il reste plusieurs points de comparaison que nous pourrions traiter, tels que la performance, la portabilité et l’extensibilité. Ce sont des particularités de chaque langage intimement liées à la tâche qu’ils doivent remplir.
- SQL a toujours été très optimisé car dédié à une seule et unique tâche, requêter des bases de données. Il n’a donc pas besoin d’être extensible sur demande.
- R a été créé par et pour des scientifiques.
- Ses calculs sont faits pour être reproductibles, donc son paradigme fonctionnel est essentiel.
- Il doit être très extensible et interopérable pour permettre une grande variété d’opérations de recherche. Ce dernier poids lui permet définitivement d’être très flexible.
- Il doit aussi également être performant pour pouvoir fonctionner sur des machines peu puissantes.
- Mais malheureusement, pour atteindre ce dernier objectif, toutes les données doivent être stockées dans la RAM ce qui rend le traitement de larges quantités de données complètement impossibles…
- Le Python a une portée généraliste et est un langage de développement.
- Ses calculs peuvent être reproductibles en utilisant un paradigme fonctionnel
- Sa bibliothèque de fonction est connue pour être très extensible et interopérable
- Malheureusement, il est peu performant, car généraliste.
Enfin, le DAX possède un moteur très puissant et reposant sur la structure du modèle de donnée. Il contient aussi de nombreux concepts autour de cette spécificité, comme les mesures, le contexte d’évaluation, la fonction CALCULATE… Mais cela le rend aussi sûr que dépendant de la qualité des ingénieurs de Microsoft. Il est également non extensible et avec l’interopérabilité que la dernière mise à jour a bien voulu lui fournir.
Mais cela s’explique car DAX répond à un besoin : celui de fournir de l’analyse de donnée rapide, pratique, sûre pour les propriétaires des données et simple pour les développeurs.
En bref, il m’arrive aussi de pester contre la rigidité et l’exotisme de DAX. Mais n’oublions pas que plus un outil est performant, plus il est spécialisé et restreint. Il s’agit là d’une des frontières technologiques à franchir pour l’informatique moderne. Une frontière qu’essaient de franchir de nouveaux langages très performants, comme le Julia !
Si vous souhaitez en savoir davantage sur le langage DAX de Power BI, n’hésitez pas à prendre contact avec nos experts dès maintenant !