juin 6, 2022Lire l'article
Votre CRM exporte une table Clients avec le nom et le numéro, une table Adresses avec la ville et le pays, une table Segments avec la catégorie commerciale. Trois morceaux, trois identifiants client, et dans Power BI trois relations qui partent de vos ventes vers trois directions. Dès que vous voulez un visuel « chiffre d'affaires par pays et par segment », rien ne se filtre correctement.
La bonne réponse tient en une phrase : les trois tables décrivent la même chose, un client, donc elles n'ont pas à rester trois. On les fusionne dans l'éditeur de requêtes pour n'en garder qu'une, que l'on relie ensuite à la table de faits. Cela vaut aussi pour ce qui traîne : chaque table intermédiaire disparaîtra du modèle. Et cela vaut pour Power BI comme pour les outils qui l'ont précédé : des outils comme Power Query existaient déjà dans Excel. Voici comment faire, et surtout comment ne pas confondre fusionner, ajouter et relier, trois gestes qui se ressemblent et qui ne servent pas à la même chose.
Dans les bases de données, découper l'information client entre différentes tables est une bonne pratique : on l'appelle la normalisation, et elle évite de répéter l'adresse sur chaque ligne. Dans Power BI, cette logique se retourne contre vous.
D'abord, chaque morceau supplémentaire exige une relation entre les tables, et le filtre ne circule que le long de ces relations. Si Adresses est reliée à Clients et Clients à Ventes, un filtre sur le pays doit traverser un maillon intermédiaire avant d'atteindre les ventes. Cela fonctionne, mais lentement, et ce n'est plus possible si vous activez un filtrage dans l'autre sens.
Ensuite, les identifiants ne sont pas toujours propres : un client présent deux fois dans Adresses (déménagement, deux agences) et Power BI vous propose une relation plusieurs à plusieurs. La cardinalité plusieurs à plusieurs est acceptée, mais elle masque ces doublons au lieu de les révéler, et vos totaux se dédoublent en silence.
Enfin, les modèles de données lisibles ont une forme connue : le schéma en étoile, une table de faits au centre, une table de dimension par sujet autour. Plusieurs morceaux pour un seul sujet, c'est plusieurs branches là où il en faut une.
« Concepts à ne pas confondre : Normalisation vs Dénormalisation », extrait du livre Microsoft Power BI en images, p. 93.
Avant d'ouvrir l'éditeur, posez-vous la question de ce que contiennent vos tables.
Le critère est simple : ce qui décrit le même sujet se fusionne ou s'ajoute ; ce qui décrit un sujet et ses événements se relie.
« Concepts à ne pas confondre : Fusionner vs Ajouter / Combiner », extrait du même livre, p. 83.
Prenons Clients (ID_Client, Nom, Téléphone), Adresses (ID_Client, Ville, Pays) et Segments (ID_Client, Segment). Après avoir cliqué sur Transformer les données pour importer les données dans l'éditeur, repérez les colonnes communes entre vos tables, ici ID_Client : c'est la clé.
Vous obtenez Dim_Client, dimension unique avec toutes ses colonnes de dimension, et ces 2 colonnes clés qui ne servent qu'aux relations peuvent être masquées plus tard. Fermez et appliquez.
« Fusion de requêtes », extrait du même livre, p. 149.
En vidéo : les différentes fusions (jointures) de requêtes, expliquées pas à pas
Une fois les données dans Power BI, ouvrez la vue Modèle dans Power BI (icône sur le bord gauche). Toutes les tables intermédiaires ont disparu ; il ne reste à connecter que Dim_Client et votre table de faits, Fact_Ventes. Créer des relations entre ces tables prend dix secondes.
Glissez ID_Client de Dim_Client vers ID_Client de Fact_Ventes. Power BI crée la relation entre les deux tables. Vérifiez trois points dans la boîte de dialogue :
Si vous avez deux tables de faits, par exemple Ventes et Réclamations, ne reliez pas les tables de faits directement entre elles : reliez chacune à Dim_Client, qui devient la table partagée, avec Ventes et Réclamations comme tables associées. C'est elle qui permet de comparer chiffre d'affaires et réclamations par client dans un même visuel.
En vidéo : les différentes relations entre les tables, expliquées depuis le modèle
La tentation existe : puisque fusionner marche si bien, pourquoi ne pas ramener aussi Nom, Ville et Segment directement dans Fact_Ventes, et n'avoir plus qu'un bloc unique ? Parce que la table de faits contient généralement de grandes quantités de données : répéter le nom et l'adresse du client sur chacune de ses milliers de lignes de vente alourdit le modèle et ralentit les visuels, alors qu'une relation laisse ces colonnes dans leur table d'origine.
La règle : on fusionne ce qui décrit le même sujet (nos morceaux de table Clients), on relie une dimension et ses faits. Notre article : Croiser des sources : faut-il fusionner ou créer une relation ?, détaille les deux méthodes.
« Concepts à ne pas confondre : Fusion vs Relation », extrait du même livre, p. 77.
Fusionner sur des colonnes de types différents. Un ID_Client en texte d'un côté et en nombre de l'autre : la fusion s'exécute sans erreur et ne trouve aucune correspondance. Alignez les types avant de fusionner.
Oublier une clé composée. Si le client n'est unique que par la combinaison Code_Agence + Numéro, sélectionnez les deux colonnes (Ctrl enfoncé) dans la fenêtre de fusion. Les noms de colonnes peuvent différer entre deux tables, seule la position compte.
Relier là où il fallait fusionner. Des morceaux de la table Clients reliés en chaîne à Fact_Ventes fonctionnent en apparence, mais les mesures DAX deviennent fragiles et chaque nouveau visuel réclame une relation de plus. Établir des relations entre des morceaux d'un même sujet est le signe qu'une fusion manque en amont.
Résoudre par une colonne calculée ce qui se règle en amont. Une colonne RELATED en DAX pour rapatrier le pays dans les ventes marche, mais elle est recalculée à chaque actualisation et grossit le modèle. La création de colonnes descriptives se fait via Power Query, pas dans le modèle.
Et si mes morceaux viennent de sources différentes (CRM, Excel, SQL) ? La méthode ne change pas. L'éditeur sait fusionner des requêtes issues de diverses sources de données, à condition que la clé soit identique. Nettoyez-la dans chaque requête avant de fusionner.
Puis-je fusionner directement dans Power BI Service ? Non, la fusion se fait dans Power BI Desktop (ou dans un flux de données côté service). Le rapport publié embarque déjà la table fusionnée.
Et Power Pivot dans Excel ? Même logique : les relations entre les tables se créent dans le modèle, et les fusions dans l'éditeur de requêtes d'Excel. Les deux outils partagent le même moteur.
Où mettre mes mesures ? Dans une table de mesures dédiée, sans relation. Un bloc isolé dans le modèle n'est pas une erreur, c'est une bonne pratique de modélisation pour la création de rapports.
