Relations et modélisation des données Power BI

Objectif pédagogique : Maîtriser la structuration des données et les relations entre tables pour des analyses fiables dans Power BI.

À la fin de ce chapitre, tu seras capable de…

• Identifier les clés primaires et étrangères dans un modèle de données
• Configurer les relations entre tables selon leur cardinalité
• Utiliser Power Query pour analyser la distribution des colonnes
• Optimiser la structure des données pour les visualisations
• Implémenter la logique métier via des relations cohérentes

💡 Prérequis : Maîtrise de l’importation de données et de l’interface Power BI Desktop

Mise en contexte

Vous avez importé vos données dans Power BI, mais sans relations correctes entre vos tables Client et Commandes, vos analyses risquent d’être faussées. Tu vas apprendre à identifier les clés primaires comme l’ID_Client, à configurer des relations un-à-plusieurs fiables, et à utiliser les outils de profilage Power Query pour garantir l’intégrité de ton modèle de données.

En pratique, cela implique :

• Configurer et optimiser les relations entre les tables afin que les filtres et agrégations fonctionnent correctement à travers les visuels.
• Créer des calculs analytiques via le langage DAX (Data Analysis Expressions), que ce soit sous forme de mesures, colonnes calculées ou tables calculées, pour traduire la logique métier.
• Organiser les tables selon des schémas de modélisation efficaces (par exemple en étoile), afin de garantir performance, cohérence et évolutivité des rapports.

Dans un modèle de données Power BI, les relations entre tables sont essentielles pour garantir que les calculs et les visualisations reflètent fidèlement les résultats métier. Une relation crée un lien logique entre des colonnes de deux tables afin que Power BI sache comment lier et filtrer les données lors de l’analyse ou de la création de rapports.

Quand on relie deux tables, la cardinalité de la relation dépend de la manière dont les enregistrements correspondent :

• Un-à-un (1:1) : chaque ligne de la Table X correspond à une seule ligne de la Table Y, et vice-versa. Ce type de relation est rare mais utile lorsque les entités sont fortement couplées.
• Un-à-plusieurs (1:*) : une ligne de la Table X peut correspondre à plusieurs lignes de la Table Y. C’est le type de relation le plus fréquent, par exemple lorsqu’un client possède plusieurs commandes.
• Plusieurs-à-plusieurs (:) : les lignes de chaque table peuvent se relier à plusieurs lignes de l’autre table. Power BI prend en charge ce type de relation pour des scénarios avancés à l’aide de tables de pont ou de cardinalité spéciale.

Avant de créer une relation, il faut identifier les colonnes clés dans chaque table :

La figure ci-dessous montre comment identifier une clé primaire candidate dans Power Query à l’aide de la fonctionnalité Distribution des colonnes (profilage des données).

• Une table n’est pas obligée d’avoir une clé primaire formelle, mais pour des relations fiables et des agrégations correctes, il est fortement recommandé de disposer d’une colonne unique identifiée comme telle.
• Les relations permettent à Power BI de propager des filtres d’une table à l’autre, ce qui est crucial pour des calculs analytiques précis dans vos visuels.
• En l’absence de clé unique valide, Power BI peut créer une relation avec une cardinalité inattendue, ou vous demander d’ajuster vos données avant de la définir.
• Pour rendre les informations de Distribution des colonnes plus précises, il faut modifier le profilage des colonnes pour qu’il soit calculé sur l’ensemble du jeu de données, comme illustré à la figure 2. Sélectionnez cette option en cliquant sur le pied de page (barre d’état).

À partir de nos tables, nous pouvons créer d’autres relations :

• DimClients (clé : id_client) → factures (FK : id_client) (1:*)
• DimClients → reservations (FK : id_client) (1:*)
• agences (clé : id_agence) → vehicules (FK : id_agence_proprietaire) (1:*)
• comptes (clé : id_compte) → ecriture_comptables (FK : id_compte) (1:*)
• Etc…

Configurez les relations dans Modélisation > Gérer les relations et vérifiez la cardinalité et la direction (sens unique vs sens double). La figure ci-dessous illustre la création de relations entre les différentes tables.

Dans certains cas, vous devez ajouter de nouvelles tables basées sur des données déjà chargées dans le modèle. Ces tables peuvent être créées à l’aide de DAX.

Vous pouvez également utiliser un constructeur de table en DAX pour créer une table calculée. Le constructeur de table n’est pas une fonction ; il s’agit d’un ensemble de caractères permettant de créer une table en DAX. Par exemple, l’expression DAX suivante crée une table avec une seule colonne comme le montre la Figure 6 ci-dessous.

Vous pouvez utiliser des accolades {} pour construire une table. Il s’agit d’une forme simple d’utilisation du constructeur de table en DAX. Voici comment cela fonctionne :

En DAX, cette syntaxe génère une table calculée contenant une colonne unique appelée Valeur (Value) si une seule expression est indiquée.

Vous pouvez utiliser n’importe quelle expression DAX scalaire comme valeur. L’exemple ci-dessous crée une autre table calculée en utilisant le constructeur de table ainsi que la fonction DATE().

Une expression scalaire en DAX correspond à une expression qui retourne une valeur unique (texte, nombre, date, booléen, etc.), ce qui est requis pour alimenter les valeurs d’un constructeur de table.

Calculated Table 2 =

{DATE(2020, 7, 22), DATE(2020, 7, 23), DATE(2020, 8, 2)}

La figure 7 montre les résultats de l’exécution de l’expression DAX ci-dessus :

L’expression DAX suivante constitue une autre forme du constructeur de table : lorsque vous définissez des lignes d’enregistrements à l’aide de parenthèses (), les valeurs étant séparées par des virgules. Comme illustré dans la figure 8, vous pouvez utiliser des valeurs constantes ou des expressions scalaires pour définir les lignes.

CalculatedTable3 =

{

( « A », 1.5, DATE(2017, 1, 1), CURRENCY(199.99) ),

( « B », 2.5, DATE(2017, 1, 2), CURRENCY(249.99) ),

( « C », 3.5, DATE(2017, 1, 3), CURRENCY(299.99) )

}

Comme indiqué précédemment, lors de la définition des lignes au sein du constructeur de table, les noms de colonnes par défaut sont attribués sous la forme Value1, Value2, Value3, etc… Nous avons également précisé qu’il est possible d’utiliser toute fonction DAX retournant une table comme les fonctions itératives. Les cas d’usage sont nombreux. Par exemple, si vous souhaitez créer une table calculée affichant :

Australian Customers Sales =

SUMMARIZECOLUMNS (

DimCustomer[CustomerKey]

, FILTER(

VALUES(DimGeography[EnglishCountryRegionName])

, DimGeography[EnglishCountryRegionName] = « Australia »)

, « Customer Full Name », CONCATENATEX(DimCustomer, DimCustomer[FirstName] &  »  » & DimCustomer[LastName])

, « Sales Amount », SUM(FactInternetSales[SalesAmount])

)

• Les colonnes calculées étendent une table existante en ajoutant des valeurs dérivées de données existantes.
• Elles sont statiques à l’exécution: leurs valeurs ne changent pas en fonction des interactions de l’utilisateur dans le rapport.
• Elles sont calculées à l’actualisation des données et stockées dans le modèle, ce qui peut augmenter la taille du modèle et impacter les performances si elles sont utilisées sans nécessité.
• Elles peuvent être utilisées dans des segments, des filtres, des lignes ou des colonnes d’un visuel, car elles produisent un champ réel du modèle à chaque ligne.

• Vous avez besoin d’une colonne dérivée qui doit être présente au niveau des lignes, par exemple pour segmentation, tri ou regroupement dans un visuel.
• Vous souhaitez exploiter les relations du modèle pour obtenir des valeurs qui ne sont pas disponibles directement dans la source.

Les mesures sont généralement des calculs analytiques : sommes, moyennes, minima, maxima, décomptes, etc. Vous pouvez utiliser ces mesures au sein des visuels Power BI. Le résultat d’une mesure est dynamique : il varie selon les interactions et le contexte de chaque visuel. Tout comme pour les colonnes calculées, vous disposez de plusieurs méthodes pour créer une mesure, que ce soit depuis l’affichage du rapport ou l’affichage table(la vue Données). Voici la procédure pour créer une mesure.

Dans certains cas, la création de calculs analytiques ne se limite pas à une simple somme. Il est souvent nécessaire de définir d’autres mesures pour répondre aux exigences métier, certaines pouvant être plus complexes. Power BI facilite grandement la mise en œuvre de ces calculs grâce aux Mesures rapides (Quick Measures), que vous découvrirez plus en détail dans la partie suivante :

La procédure est la même que celle de calcul de mesure :

Imaginez la situation suivante :

Votre tableau de bord affiche un chiffre d’affaires de 50 000 € ce mois-ci.

Est-ce une bonne performance ?

Impossible à dire sans contexte temporel :

• Par rapport au mois précédent ?
• Par rapport à la même période l’an dernier ?
• Par rapport à un objectif ou à une tendance ?

Un chiffre seul n’a pas de sens métier sans le facteur temps.

La Time Intelligence (intelligence temporelle) désigne un ensemble de fonctions DAX permettant d’analyser les données dans le temps, notamment pour :

• des calculs de cumul (Month-To-Date, Year-To-Date),
• des comparaisons temporelles (même période l’année précédente),
• des analyses d’évolution (mois sur mois, année sur année).

La Time Intelligence permet de répondre à des questions essentielles pour le pilotage :

• Sommes-nous en croissance ?
• Quelle est la tendance globale de notre activité ?
• La performance s’améliore-t-elle ou se dégrade-t-elle ?
• Avons-nous atteint nos objectifs dans le temps ?

Les fonctions de Time Intelligence ne fonctionnent correctement que si une table de dates valide est utilisée dans le modèle.

Sans table de dates conforme :

• les résultats peuvent être incorrects,
• les comparaisons temporelles deviennent peu fiables,
• certaines fonctions DAX peuvent mal se comporter sans erreur visible.

Une table de dates est une table de dimension qui contient :

• une ligne par jour, sans interruption,
• des attributs calendaires tels que :
  • Année
  • Trimestre
  • Mois
  • Jour
  • Numéro de semaine

Elle constitue la référence temporelle centrale du modèle Power BI.

Les fonctions de Time Intelligence nécessitent une table de dates valide pour fonctionner correctement.

La table de dates permet :

• d’assurer une continuité temporelle parfaite (aucun jour manquant),
• de partager une chronologie unique entre plusieurs tables de faits,
• d’activer correctement et de fiabiliser les calculs DAX temporels.

Utilisation directe de colonnes de dates présentes dans les tables de faits n’est pas recommandée comme bonne pratique car:

Ces colonnes :

• contiennent souvent des dates manquantes,
• ne couvrent pas toutes les périodes,
• ne sont pas adaptées aux fonctions de Time Intelligence.

👉

Créer et utiliser une table de dates dédiée, unique, continue et reliée au modèle.

💡 À retenir :

La table de dates est le socle de toute analyse temporelle fiable dans Power BI.

La fonctionnalité Date/heure automatique (Auto Date/Time) est activée par défaut dans Power BI Desktop.

Lorsqu’elle est active, Power BI :

• crée automatiquement une table de dates cachée pour chaque colonne de type Date,
• génère une hiérarchie temporelle : Année → Trimestre → Mois → Jour.

• Très simple à utiliser
• Aucune configuration nécessaire
• Idéal pour découvrir Power BI ou faire des analyses rapides

• Une table cachée par colonne de date impacte négativement le modèle: modèle plus lourd
• Peu ou pas de personnalisation possible :
  • calendrier fiscal
  • jours fériés
  • règles métier spécifiques
• Non adapté aux modèles professionnels ou industriels

💡 À retenir :

Auto Date/Time est pratique pour apprendre, mais insuffisant pour piloter un business.

Microsoft recommande explicitement de créer une table de dates dédiée.

Deux méthodes principales sont recommandées :

• Transformation en amont du modèle
• Excellentes performances
• Table réutilisable et standardisable

💡 Exercice :

L’objectif de cet exercice est de comprendre la logique de construction d’une table de dates, étape par étape, à partir d’un script existant. Vous disposez d’un script Power Query (langage M) complet, prêt pour une exploitation métier. En analysant le code, identifiez clairement :

• la définition du périmètre temporel,
• la génération de la liste de dates,
• la transformation de la liste en table,
• l’application du type de données approprié,
• l’ajout des principales colonnes calendaires.

Pour chaque bloc, expliquez ce qu’il fait et pourquoi il est nécessaire dans un modèle Power BI professionnel.

Voici le script M :

let
 DateDebut = #date(2020, 1, 1),
 DateFin = #date(2025, 12, 31),
 ListeDates =
 List.Dates(
 DateDebut,
 Duration.Days(DateFin - DateDebut) + 1,
 #duration(1, 0, 0, 0)
 ),
 TableDates =
 Table.FromList(
 ListeDates,
 Splitter.SplitByNothing