Lire l'article
Dans Power BI, lorsqu’il faut croiser des sources de données, 2 solutions s’offrent à vous : fusionner les requêtes dans Power Query, ou bien créér une relation dans Power BI Desktop, en passant par la vue « Modèle ». Etant donné que le rapprochement de plusieurs sources est un besoin FONDAMENTAL, cet article très complet propose un tour d’horizon des 2 méthodes.
La première méthode est proche de la formule Recherche V et va développer une ou plusieurs colonnes issues d’une table vers une autre table alors que la deuxième méthode va établir un lien entre 2 tables tout en gardant les colonnes dans leur emplacement d’origine. Cette dernière est bien connue dans les systèmes de gestion de bases de données relationnelles (SGBDR), notamment Microsoft Access ou SAP Business Objects.
Quelques définitions d’abord : il est nécessaire de rappeler ce qu’est une table de faits et une table de dimension.
Une table de faits est une table qui contient des données à analyser (les fameux faits, ou enregistrements, par exemple des ventes ou des stocks) et une table de dimension contient des axes d’analyse des faits, comme les dates, les pays, les magasins, les établissements, les produits …
La table de faits est caractérisée par le fait que les valeurs de pays, de produit, de magasin sont répétées étant donné qu’il y a un historique, et donc une colonne date.
La table de dimension est caractérisée par la présence d’un référentiel, c’est-à-dire d’une liste avec des valeurs uniques.
La cardinalité des données fait référence à l'unicité des valeurs contenues dans une colonne de base de données.
Maintenant que les définitions sont faites, quelle est LA meilleure solution ?
Si vous souhaitez rapprocher 2 tables de faits ensemble, (par exemple, la table Fact_Ventes et la Fact_Marge, ou bien Fact_Ventes et Fact_Evenements), une fusion sera préférable car celle-ci permet d’avoir une cardinalité de plusieurs à plusieurs.
En d’autres termes, vous pouvez croiser les sources de données entre deux tables qui contiennent des valeurs multiples. Il vous faudra sélectionner une ou plusieurs colonnes communes (qu’on appelle clés) afin de générer un identifiant unique pour être capable d’établir une jointure entre les tables.

Exemple de fusion sur Power Query en sélectionnant plusieurs colonnes communes
Lors d’une fusion, Microsoft vous permettra également d’activer un type de jointure approximatif, ce qui peut être intéressant si les valeurs ne sont pas exactement les mêmes dans chaque table. Vous pourrez ainsi sélectionner le degré d’approximation que vous souhaitez, le nombre de résultats par ligne que vous souhaitez, et vous aurez aussi la possibilité de faire appel à une table de transformation si les valeurs sont trop éloignées sur chaque table (ex : pour faire correspondre les nationalités « Grec » et « Hellénique », une table de transformation est nécessaire).
De plus, le type de jointure est personnalisable : fusion externe gauche (utilisée par défaut, conserve chaque ligne de la table initiale), fusion interne (ne conserve que les lignes correspondantes, idéal pour du testing par exemple), jointure externe entière (conserve l’intégralité des lignes, même s’il n’y a pas de résultat).

En revanche, effectuer une fusion va « alourdir » la table de Faits car celle-ci va désormais contenir les nouvelles colonnes qui auront été rapatriées (Microsoft utilise le terme « développer ») à l’intérieur de celle-ci.
Il est d’ailleurs important de rappeler que le chargement de l’autre requête fusionnée devra être désactivé, afin de réduire le nombre de requêtes chargées dans la vue Modèle pour alléger la taille du fichier et améliorer la durée d’actualisation des données.
NB : Une colonne ayant été fusionnée, même avec beaucoup de lignes (1 million de lignes par exemple), peut avoir des conséquences minimales sur la taille du fichier PBIX si elle contient peu de valeurs distinctes (exemple : moins de 10 valeurs distinctes), et reste ultra-rapide à filtrer ou à regrouper (de l'ordre de quelques secondes tout au plus). Pour en savoir plus, vous pouvez vous renseigner sur l'algorithme de compression du moteur Vertipaq.
La relation, elle, est une autre méthode pour croiser des données, et doit être effectuée plus en aval, une fois les données chargées dans Power BI Desktop. Elle vise à constituer une base de données relationnelle, c’est-à-dire un modèle constitué de plusieurs tables reliées les unes aux autres.
Dans un modèle en étoile, qui est le plus répandu dans l’univers de la BI (informatique décisionnelle ou Business Intelligence), ces tables peuvent être des tables de faits ou de dimension.

Exemple de Modèle en étoile avec une table de Faits au centre et plusieurs tables de dimension reliées autour.
La relation permettra d’ajouter des axes d’analyse (magasins, produits, pays …) aux faits, sans alourdir la base données qui contiendra toujours le même nombre de colonnes. En effet, dans l’exemple d’une entreprise qui aurait des milliers de transactions par jour, chaque nouvelle colonne supplémentaire dans la table de faits peut avoir un impact sur la taille du modèle.
La relation répond donc à une double exigence : enrichir le rapport en apportant de nouvelles dimensions d’analyse tout en ayant un modèle le plus léger possible.
Les relations qui existent ne peuvent pas être créées entre 2 tables de faits car il y aurait des valeurs multiples des 2 cotés. Etant donné qu’une table doit filtrer l’autre (ex : Dim_Date doit filtrer les ventes sur 2023 ou Dim_Pays doit filtrer les ventes sur la France), il est nécessaire qu’une des 2 tables reliées contienne des valeurs uniques. C’est le cas de la table de dimension.
Dans certains cas, des tables de dimension ne contiennent pas assez d’informations et doivent elles-mêmes être liées à d’autres tables de dimension. C’est ce qui arrive par exemple si on relie la table Dim_Produit à Dim_CategorieProduit. La cardinalité passe alors de 1 à 1, c’est-à-dire qu’il y a des valeurs uniques de chaque coté.
Un tel modèle porte le nom de modèle en flocon. (des tables de dimension sont reliées à d’autres tables de dimension qui sont reliées à la table de faits).

Exemple de modèle en Flocon dans lequel Dim_Country est relié à Dim_Contry_Icons MYPE Tous droits réservés
En conclusion, la fusion et la relation sont 2 méthodes différentes afin de rapprocher des sources de données.
De manière générale, une relation est préférable à une fusion car les colonnes souhaitées pour l’analyse restent hébergées dans leur table d’origine, alors qu’une fusion va alourdir la table de faits puisque les colonnes y sont rajoutées dans cette table, qui contient généralement un très grand nombre de lignes.
Cependant, effectuer une fusion dans Power Query peut s’avérer nécessaire si la correspondance des données n’est pas exacte, ou si vous avez besoin de travailler sur Power Query avec les colonnes à rapprocher (pour faire des regroupements, des calculs…), ou si la vue Modèle / Power Pivot contient déjà un trop grand nombre de tables reliées.

