Lire l'article
Vous avez les tables Ventes et Stocks, chacune avec son champ de date. Vous posez un segment sur la date des ventes : les ventes se filtrent, les stocks ne bougent pas. Vous ajoutez un second sélecteur sur la date des stocks, et vos lecteurs doivent régler deux fois la même période, en espérant ne pas se tromper.
La solution n'est pas un filtre de plus, c'est un endroit de moins à filtrer directement : un calendrier unique, relié aux deux, sur lequel vous posez l'unique sélecteur. Voici comment le mettre en place, et pourquoi c'est la bonne façon de faire.
Dans Power BI, un segment filtre la colonne qu'on lui donne, et ce filtre se propage le long des relations, de la table filtrée vers celles qui en dépendent. Ventes et Stocks ne sont pas reliées entre elles (et ne doivent pas l'être : ce sont toutes deux des tables de faits). Le filtre posé sur Ventes[Date] n'a donc aucun chemin pour atteindre Stocks[Date].
C'est la grande force de Power BI par rapport à Excel, à condition de modéliser : là où c'est Excel qui oblige à créer des segments spécifiques et à les connecter un par un, via les connexions de rapport, aux tableaux et graphiques croisés dynamiques, le modèle propage le filtre tout seul dès qu'une dimension commune existe. Dans Excel, les tableaux et les graphiques croisés dynamiques n'ont pas de calendrier partagé par défaut, et les courbes par année exigent une connexion manuelle. Savoir filtrer dans Power BI est un concept de modèle avant d'être une question de visuel.
L'idée tient en un schéma. Au lieu de filtrer chaque table de faits sur sa propre date, vous ajoutez à vos jeux de données une table de dates, Dim_Date, avec une colonne de toutes les dates de la période, et vous la reliez à Ventes et à Stocks. Un seul sélecteur posé dessus filtre les deux d'un coup, et il en irait de même avec une troisième table de faits demain.
« Les tables de calendrier : 3 bonnes raisons pour les utiliser », extrait du livre Microsoft Power BI en images, p. 123.
Dans Power BI Desktop, onglet Modélisation > Nouvelle table, puis saisissez :
Dim_Date = CALENDARAUTO()
CALENDARAUTO retourne une table qui contient une colonne Date, du 1er janvier de la date la plus ancienne du modèle au 31 décembre de la date la plus récente. Pour créer une nouvelle table avec un peu plus de colonnes (année, mois, nom du mois), utilisez ADDCOLUMNS autour de CALENDARAUTO ; notre [LIEN INTERNE : guide ultime du calendrier, https://www.mype-consulting.com/post/le-guide-ultime-pour-creer-un-une-table-de-dates-dans-power-bi] compare toutes les méthodes, DAX, Power Query et TMDL.
Sélectionnez Dim_Date dans le volet Données, puis Outils de table > Marquer comme table de dates, et indiquez la colonne Date. Ce marquage dit au moteur que cette table est la référence temporelle du modèle de données : les mesures DAX d'intelligence temporelle (cumul annuel, année précédente) s'appuient dessus, et il cesse de générer sa table date cachée pour chaque champ de date du modèle.
Dans la vue Modèle, glissez Dim_Date[Date] vers Ventes[Date], puis vers Stocks[Date]. Chaque relation doit être « Un à plusieurs », le côté 1 étant Dim_Date, avec le filtre dans un seul sens, du calendrier vers les faits. Si le côté 1 est refusé, c'est que la date de la table de faits contient des heures : passez-la en type Date dans Power Query, ou créez une colonne Dates sans heure.
En vidéo : les différentes relations entre les tables, expliquées depuis la vue Modèle
Dans le rapport, ajoutez un segment et glissez-y Dim_Date[Date], jamais Ventes[Date]. Choisissez le style « Entre » pour une plage, ou « Relatif » pour « les 30 derniers jours ». Ce sélecteur filtre maintenant les ventes et les stocks à la fois, et tous les visuels de la page suivent.
Dernier réflexe : dans les visuels, utilisez toujours les colonnes de Dim_Date pour les axes (année, mois), et plus jamais leurs colonnes de dates d'origine. Masquez Ventes[Date] et Stocks[Date] pour que personne ne les glisse par erreur.
Certaines tables portent plusieurs dates : un contrat a une date de début et une date de fin, une commande une date de commande et une date de livraison. Une seule relation peut être active vers Dim_Date ; la seconde apparaît en pointillés, inactive.
Deux façons de gérer les dates de début et de fin :
Livraisons = CALCULATE([Nb commandes], USERELATIONSHIP(Commandes[Date livraison], Dim_Date[Date])). Le filtre s'applique alors aux données à la date de livraison pour cette mesure seulement.Toutes les solutions de filtrage ne se valent pas, et le sélecteur n'est pas toujours le bon outil :
Dans les trois cas, si Dim_Date n'est pas reliée aux deux, aucun de ces filtres n'atteindra les stocks. Le modèle d'abord, les options de filtrage ensuite.
Ajoutez un visuel Table avec Dim_Date[Date], Somme de la colonne Ventes[Montant] et la même somme pour Stocks[Quantité]. Bougez le sélecteur : les trois colonnes doivent se réduire ensemble. Si une colonne reste à sa valeur de table entière, la relation avec la table de faits concernée manque ou est inactive.
Pour ajouter des champs de données à ce test, glissez aussi Dim_Date[Année] : les courbes par année doivent afficher les deux mesures côte à côte, ce qui était impossible tant que chacune portait son propre axe.
Faut-il vraiment un calendrier, ou puis-je relier Ventes et Stocks directement ? Il faut un calendrier. Relier des tables de faits entre elles crée une relation plusieurs-à-plusieurs, qui double les chiffres ou les bloque. La dimension commune est le seul chemin propre.
Et dans Power Pivot, sous Excel ? Même principe : Conception > Calendrier > Nouveau crée la table de données temporelle, que vous reliez aux deux dans la vue Diagramme. Le sélecteur du tableau de bord Excel se connecte alors au calendrier, et filtre tous les tableaux croisés qui en dépendent.
Mon calendrier s'arrête avant mes dernières ventes, que faire ? CALENDARAUTO se recalcule à chaque actualisation des données de Power BI, donc la plage suit. Si vous avez utilisé CALENDAR avec des bornes fixes, remplacez la borne haute par TODAY() ou par MAX(Ventes[Date]).
Puis-je filtrer sans calendrier ? Oui, mais avec seulement la table à filtrer à la fois, jamais deux. Dès que plusieurs tables partagent une période, le calendrier devient indispensable. C'est aussi ce que Microsoft recommande dans sa documentation : un modèle, un seul calendrier, marqué comme tel.
