Événements
31 mars, 23 h - 2 avr., 23 h
L’événement de la communauté Power BI, Fabric, SQL et AI ultime. 31 mars - 2 avril. Utilisez le code MSCUST pour une remise de 150 $. Les prix montent le 11 février.
Inscrivez-vous aujourd’huiCe navigateur n’est plus pris en charge.
Effectuez une mise à niveau vers Microsoft Edge pour tirer parti des dernières fonctionnalités, des mises à jour de sécurité et du support technique.
Cet article s’adresse aux modélisateurs de données qui développent des modèles composites Power BI Desktop. Il décrit les cas d’utilisation des modèles composites et donne des conseils de conception. Plus précisément, il vous permet de déterminer si un modèle composite est adapté à votre solution. Si c’est le cas, cet article vous aidera également à concevoir des modèles et des rapports composites optimaux.
Notes
L’introduction aux modèles composites n’est pas abordée dans cet article. Si vous ne connaissez pas les modèles composites, nous vous recommandons de lire d’abord l’article Utiliser des modèles composites dans Power BI Desktop.
Étant donné que les modèles composites se composent d’au moins une source DirectQuery, il est également important de bien comprendre les relations entre les modèles, les modèles DirectQuery et l’aide à la conception de modèles DirectQuery.
Par définition, un modèle composite combine plusieurs groupes de sources. Un groupe source peut représenter des données importées ou une connexion à une source DirectQuery. Une source DirectQuery peut être une base de données relationnelle ou un autre modèle tabulaire, qui peut être un modèle sémantique Power BI ou un modèle tabulaire Analysis Services. Lorsqu’un modèle tabulaire se connecte à un autre modèle tabulaire, on parle de chaînage. Pour plus d’informations, consultez Utilisation de DirectQuery pour les modèles sémantiques Power BI et Analysis Services.
Notes
Lorsqu’un modèle se connecte à un modèle tabulaire mais ne l’étend pas avec des données supplémentaires, il ne s’agit pas d’un modèle composite. Dans ce cas, il s’agit d’un modèle DirectQuery qui se connecte à un modèle distant - il ne comprend donc qu’un groupe source. Vous pouvez créer ce type de modèle pour modifier les propriétés des objets du modèle source, comme le nom d’une table, l’ordre de tri des colonnes ou une chaîne de format.
La connexion à des modèles tabulaires est particulièrement pertinente lors de l’extension d’un modèle sémantique d’entreprise (qu’il s’agisse d’un modèle sémantique Power BI ou d’un modèle Analysis Services). Un modèle sémantique d’entreprise est fondamental pour le développement et le fonctionnement d’un entrepôt de données. Il fournit une couche d’abstraction sur les données de l’entrepôt de données afin de présenter les définitions et la terminologie métier. Il est couramment utilisé en tant que lien entre les modèles de données physiques et les outils de reporting, comme Power BI. Dans la plupart des organisations, il est géré par une équipe centrale, et c’est pourquoi il est décrit comme entreprise. Pour plus d’informations, consultez le scénario d’utilisation BI d’entreprise.
Vous pouvez développer un modèle composite dans les situations suivantes.
Notes
Les modèles composites ne peuvent pas inclure de connexions à certaines bases de données analytiques externes. Ces bases de données incluent SAP Business Warehouse, et SAP HANA lorsque l’on traite SAP HANA en tant que source multidimensionnelle.
Bien que pouvant résoudre des problèmes de conception particuliers, les modèles composites Power BI contribuent parfois à ralentir les performances. En outre, dans certaines situations, des résultats de calcul inattendus peuvent se produire (voir plus loin dans cet article). Pour ces raisons, évaluez les autres options de conception du modèle lorsqu’elles existent.
Dans la mesure du possible, il est préférable de développer un modèle en mode d’importation. Ce mode offre une plus grande flexibilité de conception et des performances optimales.
Toutefois, les modèles d’importation ne peuvent pas toujours résoudre les problèmes liés aux gros volumes de données ou aux rapports basés sur des données en quasi temps réel. Dans ces deux cas, vous pouvez envisager un modèle DirectQuery, à condition que vos données soient stockées dans une source de données unique prise en charge par le mode DirectQuery. Pour plus d’informations, consultez Modèles DirectQuery dans Power BI Desktop.
Conseil
Si votre objectif est uniquement d’étendre un modèle tabulaire existant avec davantage de données, ajoutez, dans la mesure du possible, ces données à la source de données existante.
Dans un modèle composite, vous pouvez définir le mode de stockage pour chaque table (à l’exception des tables calculées).
Plusieurs scénarios sont possibles lorsque Power BI interroge un modèle composite.
Suivez par conséquent les recommandations suivantes :
Vous pouvez ajouter des agrégations définies par l’utilisateur aux tables DirectQuery. Leur fonction est d’améliorer les performances des requêtes à grain élevé.
Lorsque les agrégations sont mises en cache dans le modèle, elles se comportent comme des tables d’importation (bien qu’elles ne soient pas utilisables comme une table de modèle). L’ajout d’agrégations d’importation à un modèle DirectQuery donne lieu à un modèle composite.
Notes
Les tables hybrides ne prennent pas en charge les agrégations, car certaines des partitions fonctionnent en mode d’importation. Il n’est pas possible d’ajouter des agrégations au niveau d’une partition DirectQuery individuelle.
Nous vous recommandons de suivre une règle de base pour l’agrégation : son nombre de lignes doit être au moins 10 fois plus petit que la table sous-jacente. Par exemple, si la table sous-jacente stocke un milliard de lignes, la table d’agrégation ne doit pas dépasser 100 millions de lignes. Cette règle garantit un gain de performances adapté au coût de création et de maintenance de l’agrégation.
Lorsqu’une relation de modèle s’étend sur des groupes sources, elle est appelée relation de groupes de sources croisées. Les relations entre groupes de sources croisées sont également des relations limitées car il n’y a pas de côté « unique » garanti. Pour plus d’informations, consultez Évaluation des relations.
Notes
Dans certains cas, vous pouvez éviter de créer une relation de groupes de sources croisées. Consultez la rubrique Utiliser les segments de synchronisation plus loin dans cet article.
Lorsque vous définissez des relations entre les groupes de sources croisées, tenez compte des recommandations suivantes.
Avertissement
Comme Power BI Desktop ne valide pas entièrement les relations de groupes de sources croisées, il est possible de créer des relations ambiguës.
Envisagez un scénario de conception de relation complexe et la façon dont elle pourrait produire des résultats différents, mais valides.
Dans ce scénario, la table Region du groupe source A possède une relation avec la table Date et la table Sales du groupe source B. La relation entre la table Region et la table Date est active, tandis que la relation entre la table Region et la table Sales est inactive. Il existe également une relation active entre la table Region et la table Sales, qui font toutes deux partie du groupe source B. La table Sales comprend une mesure appelée TotalSales, et la table Region comprend deux mesures appelées RegionalSales et RegionalSalesDirect.
Voici les définitions des mesures.
TotalSales = SUM(Sales[Sales])
RegionalSales = CALCULATE([TotalSales], USERELATIONSHIP(Region[RegionID], Sales[RegionID]))
RegionalSalesDirect = CALCULATE(SUM(Sales[Sales]), USERELATIONSHIP(Region[RegionID], Sales[RegionID]))
Notez comment la mesure RegionalSales fait référence à la mesure TotalSales, à la différence de la mesure RegionalSalesDirect. Au lieu de cela, la mesure RegionalSalesDirect utilise l’expression SUM(Sales[Sales])
, qui est l’expression de la mesure TotalSales.
La différence est subtile dans le résultat. Lorsque Power BI évalue la mesure RegionalSales, il applique le filtre du tableau Region aux tables Sales et Date. Par conséquent, le filtre se propage également de la table Date à la table Sales. En revanche, en évaluant la mesure RegionalSalesDirect, Power BI ne propage le filtre que de la table Region à la table Sales. Les résultats renvoyés par la mesure RegionalSales et la mesure RegionalSalesDirect peuvent différer même si les expressions sont sémantiquement équivalentes.
Important
Chaque fois que vous utilisez la fonction CALCULATE
avec une expression qui est une mesure dans un groupe source distant, testez minutieusement les résultats du calcul.
Envisagez un scénario dans lequel une relation de groupe de sources croisées a des colonnes de relation à cardinalité élevée.
Dans ce scénario, la table Date est liée à la table Sales sur les colonnes DateKey. Le type de données des colonnes DateKey est un nombre entier, stockant des nombres entiers qui utilisent le format aaaammjj. Les tables appartiennent à des groupes de sources différents. En outre, il s’agit d’une relation à cardinalité élevée car la première date de la table Date est le 1er janvier 1900 et la dernière date le 31 décembre 2100. La table contient donc un total de 73 414 lignes (une ligne pour chaque date de la période 1900-2100).
Deux cas nous intéressent.
Tout d’abord, lorsque vous utilisez les colonnes de la table Date comme filtres, la propagation des filtres filtre la colonne DateKey de la table Sales pour évaluer les mesures. Lors d’un filtrage d’une seule année, par exemple 2022, la requête DAX inclut une expression de filtre telle que Sales[DateKey] IN { 20220101, 20220102, …20221231 }
. La taille du texte de la requête peut devenir extrêmement importante lorsque le nombre de valeurs dans l’expression du filtre est élevé, ou lorsque les valeurs du filtre sont de longues chaînes de caractères. Il est coûteux pour Power BI de générer la longue requête et pour la source de données d’exécuter la requête.
Deuxièmement, lorsque vous utilisez des colonnes de table Date, comme Année, Trimestre ou Mois, en tant que colonnes de regroupement, il en résulte des filtres qui incluent toutes les combinaisons uniques d’année, de trimestre ou de mois et les valeurs de la colonne DateKey . La taille de la chaîne de la requête, qui contient des filtres sur les colonnes de regroupement et la colonne de relation, peut devenir extrêmement importante. Cela est particulièrement vrai lorsque le nombre de colonnes de regroupement et/ou la cardinalité de la colonne de jointure (colonne DateKey) est élevé.
Pour résoudre tout problème de performance, vous pouvez :
Envisagez un scénario dans lequel il n’y a pas de valeurs correspondantes entre les tables dans une relation de groupe de sources croisées.
Dans ce scénario, la table Date du groupe source B a une relation avec la table Ventes de ce groupe source, ainsi qu’avec la table Cible du groupe source A. Toutes les relations sont de type un-à-plusieurs à partir de la table Date qui relie les colonnes Année. La table Sales comprend une colonne SalesAmount qui enregistre les montants des ventes, tandis que la table Target comprend une colonne TargetAmount qui enregistre les montants cibles.
La table Date stocke les années 2021 et 2022. La table Ventes stocke les montants des ventes pour les années 2021 (100) et 2022 (200), tandis que la table Cible stocke les montants cibles pour 2021 (100), 2022 (200) et 2023 (300), une année dans le futur.
Lorsqu’un visuel de table Power BI interroge le modèle composite en regroupant sur la colonne Year de la table Date et en additionnant les colonnes SalesAmount et TargetAmount, il n’affiche pas de quantité cible pour 2023. Cela est dû au fait que la relation de groupes de sources croisées est une relation limitée et qu’elle utilise donc la sémantique INNER JOIN
, qui élimine les lignes sans valeur correspondante des deux côtés. Cela produira toutefois un montant total cible correct (600), car le filtre de la table Date ne s’applique pas à son évaluation.
Si la relation entre la table Date et la table Cible est une relation intragroupe source (en supposant que la table Cible appartient au groupe source B), le visuel comprendra une année vide (Blank) pour indiquer le montant cible de 2023 (et de toute autre année non appariée).
Important
Pour éviter les erreurs de rapport, assurez-vous que les colonnes de relation comportent des valeurs correspondantes lorsque les tables de dimensions et de faits résident dans des groupes sources différents.
Pour plus d’informations sur les relations limitées, voir Évaluation des relations.
Vous devez tenir compte des limitations spécifiques lorsque vous ajoutez des colonnes calculées et des groupes de calcul à un modèle composite.
Les colonnes calculées ajoutées à une table DirectQuery avec leurs données provenant d’une base de données relationnelle, comme Microsoft SQL Server, sont limitées aux expressions qui opèrent sur une seule ligne à la fois. Ces expressions ne peuvent pas utiliser les fonctions d’itérateur DAX, comme SUMX
, ou les fonctions de modification du contexte de filtrage, comme CALCULATE
.
Notes
Il n’est pas possible d’ajouter des colonnes calculées ou des tableaux calculés qui dépendent de modèles tabulaires chaînés.
Une expression de colonne calculée sur une table DirectQuery distante est limitée à l’évaluation intra-ligne uniquement. Bien que vous puissiez créer une telle expression, celle-ci entraîne une erreur lorsqu’elle est utilisée dans un visuel. Par exemple, si vous ajoutez une colonne calculée à une table DirectQuery distante nommée DimProduct en utilisant l’expression [Product Sales] / SUM (DimProduct[ProductSales])
, vous pourrez enregistrer l’expression dans le modèle. Cependant, elle entraînera une erreur lorsqu’elle sera utilisée dans un visuel car elle viole la restriction d’évaluation intra-rangée.
En revanche, les colonnes calculées ajoutées à une table DirectQuery distante qui est un modèle tabulaire, qui est soit un modèle sémantique Power BI, soit un modèle Analysis Services, sont plus flexibles. Dans ce cas, toutes les fonctions DAX sont autorisées car l’expression sera évaluée dans le modèle tabulaire source.
De nombreuses expressions nécessitent Power BI pour matérialiser la colonne calculée avant de l’utiliser en tant que groupe ou filtre, ou de l’agréger. Lorsqu’une colonne calculée est matérialisée sur une grande table, elle peut être coûteuse en termes de processeur et de mémoire, en fonction de la cardinalité des colonnes dont dépend la colonne calculée. Dans ce cas, nous vous recommandons d’ajouter ces colonnes calculées au modèle source.
Notes
Lorsque vous ajoutez des colonnes calculées à un modèle composite, veillez à tester tous les calculs du modèle. Les calculs en amont peuvent ne pas fonctionner correctement parce qu’ils n’ont pas pris en compte leur influence sur le contexte du filtre.
Si des groupes de calcul existent dans un groupe source qui se connecte à un modèle sémantique Power BI ou à un modèle Analysis Services, Power BI peut renvoyer des résultats inattendus. Pour plus d’informations, consultez Groupes de calcul, évaluation des requêtes et des mesures.
Pour optimiser un modèle Power BI, vous devez adopter une conception de schéma en étoile.
Conseil
Pour plus d’informations, consultez Comprendre le schéma en étoile et son importance pour Power BI.
Veillez à créer des tables de dimensions distinctes des tables de faits afin que Power BI puisse interpréter correctement les jointures et produire des plans de requête efficaces. Bien que s’appliquant à tous les modèles Power BI, ces conseils sont essentiels pour les modèles qui deviendront le groupe source d’un modèle composite. Celui-ci permettra une intégration plus simple et plus efficace d’autres tables dans les modèles en aval.
Dans la mesure du possible, évitez d’avoir des tables de dimension dans un groupe source qui se rapportent à une table de faits dans un groupe source différent. En effet, il est préférable d’avoir des relations intra groupe source que de groupes de sources croisées, en particulier pour les colonnes de relations à forte cardinalité. Comme décrit précédemment, les relations de groupes de sources croisées dépendent de l’existence de valeurs correspondantes dans les colonnes de relation, sinon des résultats inattendus peuvent apparaître dans les visuels du rapport.
Si votre modèle comprend des agrégations définies par l’utilisateur, des colonnes calculées sur des tables d’importation ou des tables calculées, assurez-vous que toute sécurité au niveau des lignes (RLS) est configurée correctement et testée.
Si le modèle composite se connecte à d’autres modèles tabulaires, les règles RLS ne sont appliquées que sur le groupe source (modèle local) où elles sont définies. Elles ne seront pas appliquées à d’autres groupes sources (modèles distants). En outre, vous ne pouvez pas définir les règles de sécurité au niveau des lignes sur une table à partir d’un autre groupe source, ni les définir sur une table locale qui a une relation avec un autre groupe source.
Dans certaines situations, vous pouvez améliorer les performances d’un modèle composite en concevant une mise en page de rapport optimisée.
Dans la mesure du possible, créez des visuels qui utilisent des champs provenant d’un seul groupe source. En effet, les requêtes générées par des visuels seront plus performantes lorsque le résultat est extrait d’un seul groupe source. Envisagez de créer deux visuels placés côte à côte qui récupèrent les données de deux groupes sources différents.
Dans certaines situations, vous pouvez configurer des segments de synchronisation pour éviter de créer une relation de groupes de sources croisées dans votre modèle. Cela peut vous permettre de combiner visuellement les groupes de sources qui peuvent être plus performants.
Considérons un scénario dans lequel votre modèle comporte deux groupes sources. Chaque groupe de sources dispose d’une table de dimension de produit utilisée pour filtrer les ventes des revendeurs et d’Internet.
Dans ce scénario, le groupe source A contient la table Product qui est liée à la table ResellerSales. Le groupe source B contient la table Product2 qui est liée à la table InternetSales. Il n’y a pas de relations entre les groupes de sources croisées.
Dans le rapport, vous ajoutez un segment qui filtre la page en utilisant la colonne Color de la table Product. Par défaut, le segment filtre la table ResellerSales, mais pas la table InternetSales. Vous ajoutez ensuite un segment masqué à l’aide de la colonne Color de la table Product2. En définissant un nom de groupe identique (trouvé dans les Options avancées des segments de synchronisation), les filtres appliqués au segment visible se propagent automatiquement au segment masqué.
Notes
Si l’utilisation de segments de synchronisation permet d’éviter la création d’une relation de groupe de sources croisées, elle accroît la complexité de la conception du modèle. Veillez à expliquer aux autres utilisateurs pourquoi vous avez conçu le modèle avec des tableaux de dimensions en double. Évitez toute confusion en masquant les tables de dimension que vous ne voulez pas que les autres utilisateurs utilisent. Vous pouvez également ajouter un texte de description aux tableaux cachés pour documenter leur objectif.
Pour plus d’informations, consultez Synchroniser des segments distincts.
Voici d’autres conseils pour vous aider à concevoir et à maintenir des modèles composites.
Pour plus d’informations en rapport avec cet article, consultez les ressources suivantes.
Événements
31 mars, 23 h - 2 avr., 23 h
L’événement de la communauté Power BI, Fabric, SQL et AI ultime. 31 mars - 2 avril. Utilisez le code MSCUST pour une remise de 150 $. Les prix montent le 11 février.
Inscrivez-vous aujourd’huiEntrainement
Parcours d’apprentissage
Utiliser des modèles sémantiques dans Microsoft Fabric - Training
La conception de rapports à l’échelle de l’entreprise nécessite plus qu’une simple connexion aux données. Pour une implémentation d’entreprise réussie, il est essentiel de comprendre les modèles sémantiques et les stratégies pour la scalabilité et la gestion de cycle de vie. Ce parcours d’apprentissage vous aide à vous préparer à la certification Fabric Analytics Engineer.
Certification
Microsoft Certified: Power BI Data Analyst Associate - Certifications
Démontrez des méthodes et les meilleures pratiques qui s’alignent sur les exigences métier et techniques pour la modélisation, la visualisation et l’analyse des données avec Microsoft Power BI.