Le choix d’un schéma de données conditionne la vitesse de vos rapports Power BI, la fiabilité de vos mesures DAX et la facilité avec laquelle votre équipe exploitera le modèle sémantique. Schéma en étoile, schéma en flocon, table aplatie : chaque option impose des compromis sur la connexion entre vos sources et vos visuels. Cet article compare ces architectures sur des critères concrets pour guider votre connexion plan BI.
Comparatif des schémas de données pour un modèle sémantique Power BI
Avant d’entrer dans l’analyse, un tableau synthétique permet de situer les trois schémas couramment utilisés dans un plan BI.
| Critère | Schéma en étoile | Schéma en flocon | Table aplatie (dénormalisée) |
|---|---|---|---|
| Nombre de tables | Modéré (1 table de faits + dimensions) | Élevé (sous-dimensions normalisées) | Minimal (souvent 1 seule table) |
| Complexité des relations | Faible (relations 1:N simples) | Forte (cascades de jointures) | Nulle (pas de relations) |
| Performance des requêtes DAX | Adaptée | Dégradée sur les filtres croisés | Correcte sur petits volumes, instable au-delà |
| Lisibilité pour les créateurs de rapports | Haute | Faible | Moyenne (colonnes nombreuses) |
| Maintenance lors d’ajout de sources | Bonne (ajout d’une dimension) | Complexe (cascade de sous-tables) | Difficile (colonnes dupliquées) |
Le schéma en étoile domine sur la majorité des critères. La documentation officielle Microsoft le recommande explicitement pour les modèles sémantiques Power BI, car le moteur Vertipaq compresse et interroge plus efficacement des tables de faits étroites reliées à des dimensions dédiées.
Schéma en étoile et connexion Power BI : pourquoi le moteur Vertipaq le privilégie
Le moteur de stockage de Power BI (Vertipaq, en mode Import) fonctionne en colonnes. Chaque colonne est compressée indépendamment, et les colonnes à faible cardinalité (comme une colonne « Catégorie » dans une table dimension) se compressent beaucoup mieux qu’une colonne mélangée dans une table aplatie.
Dans un schéma en étoile, la table de faits ne contient que des clés étrangères et des mesures numériques. Les colonnes textuelles, les hiérarchies et les attributs descriptifs sont isolés dans des tables de dimensions. Cette séparation produit deux effets mesurables sur vos rapports :
- Compression mémoire nettement inférieure : les clés entières dans la table de faits pèsent moins que des chaînes de caractères répétées, ce qui réduit l’empreinte du modèle sémantique en RAM.
- Filtrage par propagation de relations : quand un utilisateur sélectionne un filtre sur un visuel, Power BI propage le filtre de la dimension vers la table de faits via la relation. Ce mécanisme est optimisé pour des relations 1:N directes, pas pour des cascades de jointures.
- Calculs DAX simplifiés : les fonctions RELATED et RELATEDTABLE fonctionnent de manière prévisible avec des relations directes. Dès qu’une relation passe par une table intermédiaire (flocon), le comportement de propagation de filtre exige des ajustements manuels via CROSSFILTER ou USERELATIONSHIP.
Le schéma en flocon, qui normalise les dimensions en sous-tables (par exemple, une table « Sous-catégorie » reliée à une table « Catégorie » elle-même reliée à la table de faits), ajoute des niveaux de jointure. Power BI peut techniquement les gérer, mais chaque niveau supplémentaire ralentit la propagation des filtres et complique la lecture du modèle pour les analystes qui créent des rapports.
Modes de connexion aux données : Import, DirectQuery et modèles composites
Le schéma de données ne fonctionne pas indépendamment du mode de connexion choisi pour accéder aux sources. Ce mode influence directement la pertinence de votre architecture.
Import : le mode par défaut pour le schéma en étoile
En mode Import, Power BI Desktop charge les données en mémoire via Power Query. C’est le scénario où le schéma en étoile donne ses meilleurs résultats, car Vertipaq compresse et indexe chaque colonne pour des réponses quasi instantanées.
La limite apparaît sur les volumes importants : le rafraîchissement complet d’un modèle volumineux peut prendre du temps et consommer des ressources. Microsoft recommande alors de passer au rafraîchissement incrémentiel ou d’envisager un entrepôt de données en amont.
DirectQuery : quand le schéma source compte autant que le modèle
En DirectQuery, Power BI n’importe rien. Chaque interaction utilisateur génère une requête SQL vers la source. Le schéma de la base source influence directement la performance. Si votre base relationnelle est déjà en étoile avec des index adaptés, les requêtes générées par Power BI seront efficaces. Si la source est un schéma transactionnel normalisé (troisième forme normale), les jointures multiples ralentiront chaque visuel.
DirectQuery ne bénéficie pas de la compression Vertipaq. C’est la base source qui supporte la charge.
Modèles composites : la tendance qui change la donne
Depuis l’arrivée de Microsoft Fabric et de OneLake, les modèles composites mélangent Import, DirectQuery et Direct Lake dans un même modèle sémantique. La pratique recommandée consiste à placer les tables volumineuses en Direct Lake (lecture directe des fichiers Delta/Parquet dans OneLake) et les dimensions en Import pour conserver toutes les capacités de modélisation.
Cette approche hybride suppose un schéma en étoile bien défini. Les dimensions importées servent de filtres rapides, tandis que les tables de faits en Direct Lake évitent le coût de rafraîchissement complet. Un schéma aplati ou en flocon ne tire pas parti de cette flexibilité.
Connexion plan BI : les pièges à éviter lors de la modélisation
Plusieurs erreurs reviennent fréquemment lors de la mise en place d’un schéma de données pour des rapports Power BI.
La première concerne les relations bidirectionnelles activées par défaut. Power BI permet de configurer une relation en filtrage croisé bidirectionnel, mais cette option doit rester l’exception. Quand elle est généralisée, les filtres se propagent dans des directions inattendues et les mesures DAX renvoient des résultats incohérents.
La deuxième porte sur les tables de faits trop larges. Certaines équipes intègrent des colonnes descriptives directement dans la table de faits pour « simplifier » le modèle. Le résultat est une table qui pèse plus en mémoire et dont les colonnes textuelles dégradent la compression. Il est préférable d’extraire ces colonnes dans des dimensions, même si cela ajoute une table au modèle.
La troisième erreur concerne l’édition du modèle sémantique dans le service Power BI. Depuis 2023-2024, Microsoft permet de modifier un modèle directement dans le navigateur. Les améliorations de rafraîchissement côté service ne s’appliquent pas encore aux modèles contenant des tables en DirectQuery. Si votre plan BI repose sur un modèle composite, la gestion du schéma reste plus fiable depuis Power BI Desktop.
Quel schéma retenir selon votre contexte de rapport
Le schéma en étoile reste le choix par défaut pour la grande majorité des projets Power BI. Il aligne la structure du modèle sémantique avec le fonctionnement interne du moteur, simplifie la création de rapports et facilite l’intégration de nouvelles sources de données.
Le schéma en flocon ne se justifie que si votre source est un entrepôt normalisé et que vous interrogez exclusivement en DirectQuery, sans possibilité de créer une couche de transformation. La table aplatie convient aux prototypes rapides ou aux jeux de données de quelques milliers de lignes, pas à un plan BI destiné à durer.
Avec l’évolution vers les modèles composites et Direct Lake, le schéma en étoile devient encore plus pertinent : il permet de distribuer chaque table sur le mode de connexion le plus adapté, sans réécrire l’architecture quand les volumes augmentent.
