Modéliser - Plusieurs tables de faits▶ Présenter

1234567891011

• Chaque table de faits a sa propre granularité, constante sur toutes ses lignes (une ligne par ligne de commande, une ligne par mois et par catégorie). Source
• Les tables de faits ne sont jamais reliées entre elles : elles communiquent par les dimensions qu'elles partagent.
• Les dimensions partagées sont appelées dimensions conformes : même clé, mêmes attributs, utilisées par toutes les étoiles. La table de dates en est l'exemple type. Source
• Les relations restent en un-à-plusieurs, à sens unique, de la dimension vers chaque table de faits.
• Les colonnes numériques des tables de faits sont masquées : on ne présente que des mesures.

• Reliez DimDate, DimProduct et DimStore à chacune des deux tables de faits (1:*, sens unique).
• Un segment sur DimProduct[Catégorie] filtre alors les ventes et les stocks en même temps.
• Les axes et segments d'un visuel qui combine les deux tables doivent toujours provenir des dimensions, jamais d'une table de faits.

Ventes = SUM ( FactSales[Montant] )

Stock fin de période =
CALCULATE (
    SUM ( FactInventory[Quantité] ),
    LASTDATE ( DimDate[Date] )
)

Taux de rotation = DIVIDE ( [Ventes], [Stock fin de période] )

• Stockez dans FactTarget le premier jour de la période (le 01/03/2026 pour mars 2026), en type Date.
• Créez une relation 1:* classique entre DimDate[Date] et FactTarget[Mois]. Source

• Dimension Catégorie dédiée : créez DimCategory (une ligne par catégorie), reliée en 1:* à FactTarget et à DimProduct. C'est la solution la plus lisible.
• Relation plusieurs-à-plusieurs DimProduct[Catégorie] *:* FactTarget[Catégorie], avec un filtrage unidirectionnel de DimProduct vers FactTarget. Source
• Relation virtuelle avec TREATAS, sans relation physique (cas 3).

Objectif =
IF (
    NOT ISFILTERED ( DimDate[Date] )
        && NOT ISFILTERED ( DimProduct[Produit] ),
    SUM ( FactTarget[Montant objectif] )
)

Écart à l'objectif = [Ventes] - [Objectif]
% Atteinte = DIVIDE ( [Ventes], [Objectif] )

Objectif (TREATAS) =
CALCULATE (
    SUM ( FactTarget[Montant objectif] ),
    TREATAS ( VALUES ( DimProduct[Catégorie] ), FactTarget[Catégorie] )
)

• Avantage : pas de relation supplémentaire, pas de risque d'ambiguïté.
• Inconvénient : la logique doit être reprise dans chaque mesure, et une relation virtuelle est généralement moins efficace qu'une relation physique sur de gros volumes. Source

• Ne reliez jamais deux tables de faits directement (relation *:* entre FactSales et FactTarget) : passez par des dimensions communes. Source
• Ne fusionnez pas des faits de granularités différentes dans une même table.
• N'activez pas le filtrage bidirectionnel pour « faire fonctionner » un visuel : chemins ambigus et performances dégradées. Source
• N'utilisez pas une colonne d'une table de faits comme axe ou segment : elle ne filtre pas les autres tables de faits.

• Une table de faits, une granularité.
• Les tables de faits communiquent uniquement par des dimensions conformes.
• Un fait plus agrégé se relie par le premier jour de la période et une dimension dédiée, ou une relation *:* unidirectionnelle.
• La mesure d'un fait agrégé renvoie BLANK sous sa granularité.

• Conseils sur les relations plusieurs-à-plusieurs. Source (Microsoft Learn)
• Modélisation dimensionnelle dans l'entrepôt Microsoft Fabric. Source (Microsoft Learn)
• Les fonctions DAX liées aux relations (TREATAS, USERELATIONSHIP, CROSSFILTER) sont détaillées dans la page DAX et relations de la sous-partie Calculer avec DAX.

1. Importez une table d'objectifs mensuels par catégorie (Mois au 1er du mois, Catégorie, Montant objectif).
2. Créez la dimension Catégorie ou la relation *:* unidirectionnelle.
3. Écrivez les mesures Objectif, Écart à l'objectif et % Atteinte.
4. Construisez une matrice Année / Mois × Catégorie et vérifiez qu'au jour ou au produit l'objectif est vide.
5. Refaites la mesure Objectif avec TREATAS et comparez les résultats dans l'analyseur de performances.