Tutoriel sur la modélisation des données dans Power BI

De bonnes pratiques de modélisation des données sont essentielles pour construire des rapports Power BI optimisés en performance et capables de passer à l’échelle selon les besoins.

Ce tutoriel s’appuie sur un jeu de données exemple fourni par Microsoft, adapté pour illustrer les bonnes pratiques de modélisation que nous allons aborder. Vous pouvez télécharger le jeu de données ici.

Qu’est-ce que la modélisation des données ?

La modélisation des données consiste à représenter visuellement les liens entre des structures de données, en précisant les attributs contenus dans chacune de ces structures.

Lorsqu’on parle de modélisation des données, le terme que vous entendrez le plus souvent est le schéma en étoile. Il s’agit d’une approche largement adoptée pour concevoir des entrepôts de données et des bases relationnelles, également recommandée dans Power BI.

Deux avantages majeurs du schéma en étoile :

• Ergonomie : le schéma en étoile rend votre modèle plus clair et structuré, et votre rapport plus facile à utiliser.
• Performance : il permet de faire évoluer aisément le rapport vers de très gros volumes de données. Les mesures DAX se calculent plus vite et l’actualisation globale est plus rapide.

Comment fonctionne un schéma en étoile ?

Un schéma en étoile se compose d’une table de faits centrale, reliée à plusieurs tables de dimensions, à la manière d’une étoile. Idéalement, il est recommandé d’avoir une seule table de faits dans un modèle. Toutefois, Power BI permet d’en inclure plusieurs.

Schéma en étoile dans Power BI. Image par l’auteur

Une table de faits contient des valeurs agrégables ainsi qu’une ou plusieurs clés reliant les tables de dimensions. La clé sert à établir les connexions entre tables. Pour des modèles complexes ou des volumes importants, il est préférable d’utiliser des clés numériques plutôt que des chaînes de texte, afin d’améliorer les performances.

Les tables de faits doivent être très étroites, avec le moins de colonnes possible. Toute colonne décrivant les caractéristiques d’un jeu de données (par exemple, Nom du produit ou Catégorie de produit) doit être extraite de la table de faits (si ce n’est pas déjà le cas dans l’entrepôt) et placée dans sa table de dimension dédiée. Ce processus est la normalisation des données, dont l’objectif est d’éviter les répétitions.

Les tables de dimensions décrivent les caractéristiques du jeu de données, regroupées logiquement dans des tables séparées pour éviter d’alourdir une seule table ou de compliquer la création des relations. Elles doivent contenir des valeurs uniques pour les attributs décrits, et leurs colonnes servent à filtrer ou à regrouper les données dans le rapport Power BI.

Une extension du schéma en étoile est le schéma en flocon. Ici, les tables de dimensions sont encore subdivisées si une caractéristique possède des catégories ou sous-catégories. Dans notre cas, la table Produits contient l’ID produit, le nom du produit et la catégorie de produit. En schéma en flocon, cette table Produits ne contiendrait que l’ID produit et le nom ; la catégorie serait déplacée dans sa propre table avec un ID de catégorie et la catégorie correspondante.

Schéma en flocon dans Power BI. Image par l’auteur

Cependant, le schéma en flocon peut complexifier inutilement votre modèle : ces tables supplémentaires peuvent dégrader les performances et rendre les relations plus difficiles et confuses.

Comment créer des relations dans Power BI

Deux méthodes permettent de créer une relation dans Power BI :

1. Sélectionnez un champ d’une table et faites-le glisser sur le champ de la seconde table avec lequel vous souhaitez établir la relation.
2. Dans le ruban, sélectionnez Gérer les relations, puis « Nouveau » pour ajouter une relation à l’aide de la même fenêtre que celle décrite ci-dessous (en partant d’une page vierge).

Par défaut, Power BI tente d’inférer des relations entre tables ; ce n’est pas toujours pertinent, vous pouvez donc désactiver cette option dans les paramètres ou supprimer les relations créées automatiquement. Pour modifier une relation, faites un clic droit sur la ligne de connexion et choisissez « Propriétés ».

Cette fenêtre propose deux réglages importants : la cardinalité et la direction du filtrage croisé. Les choix effectués ont un impact fort sur le rapport final, donc soyez attentif. Voyons chacun de ces réglages.

Création de relations dans Power BI. Image par l’auteur

Cardinalité

Quatre choix sont possibles : plusieurs-à-un, un-à-un, un-à-plusieurs ou plusieurs-à-plusieurs.

Lors de la création des relations, il est recommandé que le champ de jointure contienne des valeurs uniques dans au moins une des tables. Cela permet d’utiliser les options un-à-plusieurs ou plusieurs-à-un dans le modèle.

Dans nos données, la relation entre Financials et Products s’appuie sur le champ ID produit. La table Products comporte des valeurs uniques pour le produit (chaque produit n’apparaît qu’une fois). En revanche, la table Financials peut contenir plusieurs occurrences du même produit par date, pays, segment, etc.

L’option plusieurs-à-plusieurs est la plus délicate : utile pour des modèles complexes, elle ne doit être choisie que si vous en maîtrisez pleinement les implications.

Pour illustrer les écueils potentiels, créons une table d’objectifs de ventes annuels par catégorie de produit. Nous devons afficher, dans une même visuel, les ventes et leurs objectifs. Cela peut se faire via une relation plusieurs-à-plusieurs entre la table des objectifs et la table Product.

Relations plusieurs-à-plusieurs dans Power BI. Image par l’auteur

Dans le visuel tableau ci-dessous, on voit les ventes et les objectifs côte à côte pour chaque catégorie de produit.

Catégorie de produit, ventes et montant. Image par l’auteur

En revanche, si l’on descend au niveau Produit, les valeurs d’objectif deviennent totalement incorrectes. En cause : des granularités différentes. Les objectifs n’existant qu’au niveau de la catégorie, Power BI ne peut pas les répartir de façon fiable au niveau produit ; ils sont donc simplement dupliqués pour chaque produit de la catégorie. Ignorer cette conséquence d’une relation plusieurs-à-plusieurs peut poser de sérieux problèmes pour le reporting.

Catégorie de produit, ventes et montant. Image par l’auteur

Directionnalité

L’option de direction du filtrage croisé offre le choix entre sens unique ou bidirectionnel. Les relations s’écoulent de la table aux valeurs uniques vers la table aux valeurs multiples. Dans notre cas, de Products vers Financials. En mode sens unique, Financials peut être filtrée par les champs produit et catégorie de produit de Products. En revanche, Products ne peut pas être filtrée via l’ID produit de Financials, ni via d’autres caractéristiques présentes dans d’autres dimensions.

Le sens unique est recommandé dans la plupart des cas. Les relations bidirectionnelles (« les deux ») dégradent les performances du modèle et peuvent introduire des ambiguïtés lors du filtrage.

Dans notre exemple, considérez les relations entre Product, Countries et Financials. Ce sont des relations un-à-plusieurs à sens unique. Filtrer le rapport par pays ne filtrera donc pas, en retour, la table Product. Comme le montrent les segments ci-dessous, sélectionner un pays (par exemple USA) ne restreint pas automatiquement la liste des produits aux seuls produits pertinents pour ce pays.

Segments dans Power BI. Image par l’auteur

En passant la relation entre Products et Financials en bidirectionnelle, le filtrage peut s’appliquer à Products. On constate alors que le produit Carretera n’apparaît pas dans le segment Produits, faute de ventes aux États-Unis.

Segments dans Power BI. Image par l’auteur

Autre option, pour éviter les relations bidirectionnelles : ajoutez un filtre au visuel de segment pour exclure les éléments vides. Notez qu’il faudra l’appliquer à chaque visuel exploitant des champs issus de plusieurs dimensions.

Filtres et segments dans Power BI. Image par l’auteur

Comment optimiser votre modèle Power BI

Le facteur clé d’optimisation reste l’application de bonnes pratiques de modélisation, comme celles présentées dans ce tutoriel. Très souvent, un bon modèle suffit à faire évoluer un rapport Power BI vers des millions, voire des milliards de lignes tout en conservant des performances correctes.

En complément, vous pouvez appliquer les leviers suivants :

• Désactiver l’intelligence temporelle : cette fonctionnalité crée automatiquement des hiérarchies de dates à chaque ajout d’un champ date dans un visuel. Chaque hiérarchie revient à ajouter une table au modèle, ce qui peut l’alourdir considérablement, ralentir l’affichage des visuels et augmenter le temps d’actualisation. Mieux vaut la désactiver et utiliser une table de dates dédiée pour toutes les hiérarchies temporelles.
• Ne charger que les colonnes nécessaires : dans Power Query, supprimez les colonnes dont vous n’avez pas besoin dans le rapport. Un champ souvent conservé « au cas où » est l’identifiant de ligne (par ex. Order ID pour chaque transaction). Souvent stocké en texte, il gonfle encore davantage le modèle. S’il n’est pas utilisé dans une relation, il n’est généralement pas nécessaire de le charger.
• Ne charger que les lignes utiles : évitez d’importer l’intégralité de l’historique de l’entreprise dans votre rapport. Si votre activité est ancienne, cela peut ajouter des données que personne ne consultera. Échangez avec les utilisateurs métier pour connaître la profondeur historique réellement utile. Si des données anciennes sont nécessaires, envisagez d’importer une version synthétisée plutôt que chaque transaction.