Dans Power BI, les mesures DAX les plus sophistiquées ne valent rien si les fondations relationnelles sont défaillantes. Si vos visuels affichent des montants identiques sur toutes les lignes d'un tableau ou si certains filtres refusent de s'appliquer, le problème ne vient presque jamais de vos formules, mais de la structure de vos relations.
Dans cette leçon, nous découvrons les règles d'or de la modélisation en étoile et la mécanique de propagation des filtres dans la vue Modèle.
🌟 L'Anatomie du Schéma en Étoile (Star Schema)#
Le schéma en étoile organise vos données selon deux catégories de tables clairement identifiées :
┌────────────────────────────────────────────────────────┐
│ LES TABLES DE DIMENSIONS (Dim) │
│ • Qui ? Quoi ? Où ? Quand ? (Contexte métier) │
│ • Contiennent des colonnes de texte descriptives │
│ • Clé primaire UNIQUE sans aucun doublon │
│ • Exemples : Dim_Clients, Dim_Produits, Dim_Calendrier │
└──────────────────────────┬─────────────────────────────┘
│ Côté "Un" (1)
│ Filtrage naturel vers le bas 🠗
│ Côté "Plusieurs" (*)
┌──────────────────────────┴─────────────────────────────┐
│ LA TABLE DE FAITS (Fact) │
│ • Combien ? (Événements numériques observables) │
│ • Contient les montants, quantités, remises, coûts │
│ • Clés étrangères multiples liant chaque dimension │
│ • Exemple : Fact_Ventes, Fact_Commandes │
└────────────────────────────────────────────────────────┘
🔗 Les 3 Types de Cardinalités#
Lorsque vous reliez deux tables dans la vue Modèle (en glissant un champ clé vers un autre), Power BI analyse l'unicité des valeurs et définit la cardinalité :
1. Un-à-Plusieurs (1:*) — Le Standard Absolu#
C'est la relation idéale en Business Intelligence.
- Côté 1 : La table de dimension possède chaque identifiant de manière unique (ex: CustomerID = 1001 n'apparaît qu'une seule fois dans Dim_Clients).
- Côté * : La table de faits peut enregistrer plusieurs commandes pour ce même client.
2. Plusieurs-à-Plusieurs (:) — À Manipuler avec une Extrême Précaution#
Survient lorsque les deux tables contiennent des doublons sur la clé de liaison.
[!WARNING] Les relations
*:*dégradent fortement les performances et peuvent générer des ambiguïtés de calcul. Si vous avez une relation plusieurs-à-plusieurs (ex: des étudiants inscrits à plusieurs cours et des cours suivis par plusieurs étudiants), la bonne pratique consiste à intercaler une table de pont (Bridge Table) intermédiaire qui rétablit deux relations1:*propres.
3. Un-à-Un (1:1) — Souvent Superflue#
Chaque ligne de la table A correspond à une seule ligne de la table B. Dans 95 % des cas, cela signifie que ces deux tables auraient dû être fusionnées directement en amont dans Power Query.
🧭 Le Sens de Propagation du Filtre Croisé (Cross-filter Direction)#
Observez attentivement la flèche située au milieu de la ligne de relation : elle indique dans quel sens les filtres se propagent.
┌──────────────────────┐ ┌──────────────────────┐
│ Dim_Clients ├──(1)──►(*)│ Fact_Ventes │
└──────────────────────┘ └──────────────────────┘
Le filtre s'écoule UNIQUEMENT de Dim_Clients vers Fact_Ventes.
Si vous filtrez sur la ville "Paris", Fact_Ventes est filtrée.
Mais filtrer Fact_Ventes ne filtre PAS Dim_Clients !
Le Danger du Filtrage Bidirectionnel (Both)#
Power BI permet de configurer le filtre en mode Bidirectionnel (Les deux).
[!CAUTION] Pourquoi le filtrage bidirectionnel est-il dangereux ?
1. Chemins ambigus : Dès que votre modèle comporte plus de 5 tables, le filtrage bidirectionnel crée des boucles de dépendance (Circular Dependencies). Power BI ne sait plus par quel chemin propager le filtre et désactive arbitrairement certaines relations. 2. Chute de performance : Chaque interaction sur un visuel force le recalcul de toutes les tables du modèle.Règle d'or : Laissez toujours le filtre en sens Unique (Single). Si vous devez filtrer une dimension à partir d'une autre de façon exceptionnelle, faites-le dans une mesure DAX ciblée avec
CROSSFILTER().
⚡ Les Relations Inactives et la Fonction USERELATIONSHIP()#
Dans une table de faits d'entreprise, il est fréquent d'avoir plusieurs dates :
- OrderDate (Date de commande)
- ShipDate (Date d'expédition)
Power BI interdit d'avoir deux relations actives directes entre deux mêmes tables. La première relation créée devient Active (ligne continue), et la seconde devient Inactive (ligne en pointillés) :
┌──────────────────────┐
│ Dim_Calendrier │
└──────────┬───────────┘
Relation ACTIVE (1) │ (Date)
(Ligne continue) │
▼
┌────────────────────────────────────────┐
│ Fact_Ventes │
│ [OrderDate] ◄─── Relation ACTIVE │
│ [ShipDate] ┄┄┄ Relation INACTIVE (·) │
└────────────────────────────────────────┘
Par défaut, tous vos visuels et mesures calculent selon la date de commande. Mais comment calculer les ventes expédiées ?
Grâce à la fonction DAX USERELATIONSHIP(), vous pouvez réveiller ponctuellement la relation inactive pour un calcul précis :
Montant Ventes Expédiées =
CALCULATE(
[Montant Ventes],
USERELATIONSHIP(Fact_Ventes[ShipDate], Dim_Calendrier[Date])
)
Dans ce calcul, le filtre du calendrier est temporairement dérivé vers ShipDate au lieu de OrderDate !
📐 Organiser Visuellement la Vue Modèle#
Une vue Modèle propre fait gagner des heures de travail : 1. Placez vos tables de dimensions en haut de l'écran. 2. Placez votre ou vos tables de faits au centre/en bas. 3. Les flèches de filtrage s'écoulent ainsi naturellement du haut vers le bas. 4. Créez des dispositions (Layouts) thématiques si votre modèle dépasse 15 tables.
Le schéma en étoile est en place, les relations sont saines et les filtres circulent sans ambiguïté. Dans la prochaine leçon, nous entrons dans le réacteur analytique : l'écriture des mesures DAX !
Commentaires