En créant des tableaux de bord sur Excel ou sur Power BI, l'une des premières questions que nous nous posons est probablement : comment fonctionnent les liens entre les tables ? Ensuite vient la seconde question : pourquoi opter pour un modèle en étoile, alors que je peux simplement ajouter une colonne sur Power Query ? Définissons d'abord les différents éléments de ce comparatif.

• La table de faits : un tableau de données quantitatives dans lequel nous cherchons à suivre directement ces données.
• La table de dimensions : un tableau qui apporte du contexte à la table (ou aux tables) de faits. Pour un fonctionnement correct sur Power Pivot (et par extension, sur Power BI), il faut un lien 1-* (un vers plusieurs) entre la colonne reliée au niveau de la table de dimensions et celle reliée au niveau de la table de faits. Le modèle en étoile est donc une table de faits entourée d'une ou plusieurs tables de dimensions reliées.
• Une fusion de requêtes s'effectue au niveau de Power Query et non de Power Pivot. C'est simplement l'action de fusionner deux tableaux en un seul. Le résultat est une table de faits avec plus de colonnes, mais une table de dimensions en moins. Nous pouvons considérer cet outil comme une version plus puissante de RECHERCHEV, mais sur Power Query.

1) Définition du couple faits-dimensions

‍

Que signifie réellement le lien 1-* ? Cela veut simplement dire que chaque valeur présente dans la colonne de liaison (la clé) n'apparaît qu'une seule fois. Par exemple, si notre table de dimensions est un calendrier, chaque date ne doit apparaître qu'une seule fois. Sinon, il devient difficile de faire des calculs statistiques liés à cette date quand elle figure sur plusieurs lignes différentes. Donc, le "1" est du côté de la dimension. Du côté des faits, partons du principe que nous ne contrôlons pas forcément les données à mesurer, d'où le "plusieurs". Par exemple, si je suis les ventes hebdomadaires de ma boutique, j'espère réaliser plus d'une vente par jour.

Voici l'exemple, illustré sur Power Pivot :

Cette approche permet de suivre les ventes sur le calendrier plutôt que de ralentir les calculs en utilisant directement les dates présentes dans la table des ventes, qui ont potentiellement une cardinalité faible (c'est-à-dire peu de valeurs uniques).

À noter : le lien se fait bien au niveau de la colonne de dates entre les deux tables. Pour relier des tables (comme pour la fusion de requêtes d'ailleurs), il faut disposer d'une colonne commune où toutes les valeurs de la table de faits sont présentes dans la table de dimensions. Si ce n'est pas le cas, les lignes concernées seront comptabilisées sous la catégorie « vide ».

2) Les cas où la fusion de requêtes directe n'est pas possible

‍

Dans le cas de la fusion de requêtes comme dans celui des tables reliées, nous avons besoin d'une clé commune. En d'autres termes, si aucune colonne n'est commune entre deux tables, il est impossible de les combiner en une seule table, à moins de fusionner d'abord la première requête avec une table de dimensions, puis de refusionner avec la seconde table. Dans ce cas, la simple fusion devient impossible.

Un autre cas où l'on pourrait avoir l'illusion de pouvoir fusionner, mais qui ne donnerait finalement pas un résultat satisfaisant, concerne la fusion entre deux tables de faits. Bien qu'il semble y avoir une colonne commune (par exemple : une table de factures et une table d'objectifs mensuels), souvent, il n'est ni possible de fusionner, ni de relier ces tables efficacement. Si nous reprenons notre exemple de factures et d'objectifs : Power Query trouvera des correspondances entre les factures et les objectifs, mais comme il n'y a qu'un objectif par mois, celui-ci ne serait pris en compte que sur une journée. Pour contourner ce problème tout en gardant la même méthode, il faudrait modifier les dates des factures pour les faire correspondre à la date de chaque objectif. Cette approche pourrait rendre certaines analyses incorrectes, voire impossibles — par exemple, il deviendrait impossible de calculer un délai de paiement si toutes les données sont rapportées à la même date.

3) Les avantages et les inconvénients de chaque méthode

‍

En réalité, plus nos volumes de données sont importants, plus nous voudrons adopter le couple faits–dimensions. Comparons ces approches sous forme de tableau, selon 6 critères : le volume de données nécessaire, l'efficience du stockage de données, la vitesse de calcul, la taille du modèle, l'optimisation pour inclure du DAX (pour mesurer les indicateurs) et les volumes de données finales.

a. Pour les grands volumes de données qui nécessitent une analyse quantitative

‍

b. Pour les volumes plus petits

‍

À première vue, les fusions de requêtes semblent à proscrire, particulièrement avec de gros volumes de données. Néanmoins, elles offrent certains avantages lorsqu'il s'agit de préparer l'analyse plutôt que de l'effectuer directement. Voici quelques situations où la fusion de requêtes devient particulièrement intéressante :

4) Pour résumer tout ça

‍

Nous l’avons donc compris, le choix va se faire par rapport à l’utilisation, ainsi que par rapport aux données traitées. Voici un tableau de résumé (ici, je coche ce que je trouve le plus rentable en termes de performances, ainsi qu’en termes de facilité de mise en place) :