Utiliser des modèles composites dans Power BI

Les modèles sémantiques Power BI peuvent inclure des tables d’une ou plusieurs sources de données à l’aide de l’un des modes de stockage de tables pris en charge. Lorsque les tables utilisent différents modes de stockage, le modèle est un modèle sémantique composite. Pour le mode de stockage de table DirectQuery, le modèle est composite lorsque les tables DirectQuery utilisent différentes sources de données.

Par exemple, si vous vous connectez à un autre modèle sémantique Power BI à l’aide de DirectQuery (qui ajoute des tables en mode de stockage DirectQuery) et que vous disposez également de tables locales en mode Importation, votre modèle devient un modèle composite, car il contient des tables avec différents modes de stockage.

Notes

Les tables d’importation à partir d’une ou plusieurs sources de données ne sont pas des modèles composites tant que vous ne les mélangez pas avec des tables non importées. La même règle s’applique aux modèles sémantiques avec des tables Direct Lake à partir d’une ou plusieurs sources de données.

Notes

Pour les modèles composites, on suppose que le mode de stockage en table Direct Lake est configuré en tant que Direct Lake sur OneLake. Direct Lake en mode de stockage de table SQL est uniquement une source unique et ne peut pas être ajoutée à un modèle composite. Pour plus d’informations sur les différences du mode de stockage de table Direct Lake, consultez aka.ms/DirectLake.

Types de modèles composites

Différents types de modèles composites existent en fonction de la combinaison des modes de stockage de table dans le modèle sémantique. Chaque type a ses propres considérations relatives aux fonctionnalités et aux outils.

Type de modèle composite	Outils disponibles	Remarques
DirectQuery vers un autre modèle sémantique Power BI avec ou sans tables supplémentaires en mode d’importation ou de stockage DirectQuery	Power BI Desktop uniquement	Connectez-vous à un modèle sémantique Power BI, puis choisissez Apporter des modifications à ce modèle ou connectez-vous après l’ajout d’une table en mode d’importation ou de stockage DirectQuery.
Tables DirectQuery provenant de différentes sources de données	Power BI Desktop uniquement	Par exemple, la table A provient de la base de données SQL A et la table B provient de la base de données SQL B
Importer et DirectQuery des tables dans le même modèle sémantique	Power BI Desktop uniquement
Importer et diriger des tables dans le même modèle sémantique	Modélisation web Power BI uniquement	Les tables Import ou Direct Lake peuvent être ajoutées dans Desktop, mais uniquement combinées dans la modélisation web.
Tables DirectQuery et Direct Lake dans le même modèle sémantique	XMLA uniquement	Combinez l’utilisation d’un script XMLA ou d’outils communautaires XMLA. Peut être ouvert dans la modélisation web pour les modifications de modèle sémantique uniquement sans aucune option d’actualisation ou de modification des tables.

Créer des modèles composites dans Power BI Desktop

Dans Power BI Desktop, vous pouvez créer des modèles sémantiques avec des tables d’importation ou DirectQuery localement. Vous pouvez ensuite ajouter d’autres tables à partir du bouton Obtenir des données du ruban dans un autre mode de stockage pour créer un modèle composite.

Notes

Si l’importation et les tables DirectQuery se trouvent dans un modèle sémantique et proviennent de la même source de données, le mode de stockage double est disponible. Le mode double utilisé au lieu de DirectQuery peut éviter des relations limitées avec des tables d’importation. Pour plus d’informations, consultez le mode de stockage double.

L’ajout de tables DirectQuery à partir d’un autre modèle sémantique Power BI a deux chemins de création différents.

1. Dans un fichier Power BI vide, commencez par vous connecter au modèle sémantique Power BI. Une fois connecté en direct, vous avez la possibilité d’apporter des modifications à ce modèle. La sélection de Apporter des modifications à ce modèle à partir du ruban ou du pied de page convertit la connexion en direct en connexion DirectQuery. La connexion DirectQuery crée un modèle sémantique local avec les tables en mode de stockage DirectQuery. Vous pouvez ajouter de nouvelles tables en mode d’importation ou de stockage DirectQuery, ainsi que vous donner la possibilité de remplacer certaines propriétés de colonne sur le modèle sémantique source.

2. Dans un modèle sémantique avec des tables d’importation ou DirectQuery déjà, connectez-vous à un modèle sémantique Power BI et les tables que vous choisissez sont ajoutées en tant que DirectQuery.

Les modèles sémantiques créés avec des tables Direct Lake sont modifiés en direct dans Power BI Desktop. Vous pouvez ajouter d’autres tables Direct Lake. Pour ajouter des tables d’importation, ouvrez le modèle sémantique dans la modélisation web Power BI. Pour ajouter des tables DirectQuery, utilisez XMLA.

Vous pouvez modifier en direct un modèle sémantique Direct Lake et importer dans Desktop, mais vous ne pouvez pas ajouter d’autres tables. Vous pouvez uniquement ajouter des tables à partir de la modélisation web Power BI pour Direct Lake et importer des modèles composites.

Créer des modèles composites dans la modélisation web

Dans la modélisation web Power BI, vous pouvez créer des modèles sémantiques avec des tables d’importation ou Direct Lake. Vous ne pouvez pas ajouter de tables DirectQuery. Vous pouvez ajouter d’autres tables dans l’autre mode de stockage pour créer un modèle composite.

Utiliser des modèles composites

Avec les modèles composites, vous pouvez vous connecter à différentes sortes de sources de données quand vous utilisez Power BI Desktop ou le service Power BI. Vous pouvez établir ces connexions aux données de deux façons :

• En important des données dans Power BI, ce qui est la méthode la plus courante pour obtenir des données.
• En vous connectant directement aux données dans leur dépôt source d’origine à l’aide de DirectQuery. Pour en savoir plus sur DirectQuery, consultez DirectQuery dans Power BI.

Avec DirectQuery, les modèles composites permettent de créer un modèle Power BI, par exemple un fichier Power BI Desktop .pbix, qui effectue l’une des actions suivantes, ou les deux :

• Combine les données d’une ou de plusieurs sources DirectQuery.
• Combine les données de sources DirectQuery et d’importation.

Par exemple, avec des modèles composites, il est possible de générer un modèle qui combine les types de données suivants :

• Données de ventes d’un entrepôt de données d’entreprise.
• Données de cibles de ventes d’une base de données SQL Server d’un service.
• Les données ont été importées à partir d’une feuille de calcul.

Un modèle sémantique combinant des tables à partir de plusieurs sources DirectQuery, ou combinant DirectQuery, Direct Lake et des tables d’importation, est un modèle sémantique composite.

Vous pouvez créer des relations entre les tables comme vous le faites habituellement, même si ces tables proviennent de différentes sources. Toutes les relations entre les sources sont créées avec une cardinalité plusieurs-à-plusieurs, indépendamment de leur cardinalité réelle. Vous pouvez changer la cardinalité initiale à un-à-plusieurs, plusieurs-à-un ou un-à-un. Quelle que soit la cardinalité définie, les relations entre les sources ont un comportement différent. Il n’est pas possible d’utiliser des fonctions DAX (Data Analysis Expression) pour récupérer des valeurs du côté one à partir du côté many. Vous pouvez également constater un impact sur les performances par rapport aux relations plusieurs-à-plusieurs au sein de la même source.

Notes

Dans le contexte des modèles composites, toutes les tables importées sont en fait une source unique, indépendamment de la source de données sous-jacente réelle.

Exemple de modèle composite

Comme exemple de modèle composite, prenons un rapport qui se connecte à un entrepôt de données d’entreprise dans SQL Server à l’aide de DirectQuery. Dans cet exemple, l’entrepôt de données contient les données des ventes par pays (Sales by Country), trimestre (Quarter) et vélo (Bike (Product) ), comme illustré dans l’image suivante :

À ce stade, vous pouvez générer des visuels simples à l’aide des champs de cette source. L’image suivante montre le total des ventes par ProductName d’un trimestre sélectionné.

Mais que se passe-t-il si vous avez des données dans une feuille de calcul Excel sur le gestionnaire de produit affecté à chaque produit, avec la priorité marketing ? Si vous voulez voir le montant des ventes (Sales Amount) par chef de produit (Product Manager), il n’est peut-être pas possible d’ajouter ces données locales à l’entrepôt de données d’entreprise. Ou cela prendrait plusieurs mois dans le meilleur des cas.

Il peut être possible d’importer ces données de ventes à partir de l’entrepôt de données, au lieu d’utiliser DirectQuery. Les données de ventes peuvent ensuite être combinées aux données importées à partir de la feuille de calcul. Cette approche est néanmoins déconseillée pour les raisons qui ont conduit à utiliser DirectQuery en premier lieu. Les raisons sont notamment :

• Combinaison des règles de sécurité appliquées dans la source sous-jacente.
• Nécessité de pouvoir afficher les données les plus récentes.
• Échelle des données.

C’est ici que les modèles composites entrent en jeu. Les modèles composites vous permettent de vous connecter à l’entrepôt de données à l’aide de DirectQuery, puis d’utiliser Obtenir des données pour d’autres sources. Dans cet exemple, nous établissons d’abord la connexion DirectQuery à l’entrepôt de données d’entreprise. Nous utilisons Obtenir des données, choisissons Excel, puis accédons à la feuille de calcul contenant nos données locales. Enfin, nous importons la feuille de calcul contenant les valeurs Product Names (Noms des produits), Sales Manager (Responsable commercial) et Priority (Priorité).

Dans la liste Champs, vous pouvez voir deux tables : la table Bike d’origine provenant de SQL Server et une nouvelle table ProductManagers. La nouvelle table contient les données importées à partir d’Excel.

De même, dans l’affichage Relation de Power BI Desktop, nous voyons à présent une autre table appelée ProductManagers.

Nous devons maintenant associer ces tables aux autres tables du modèle. Comme toujours, nous créons une relation entre la table Bike à partir de SQL Server et la table ProductManagers importée. Autrement dit, la relation est établie entre Bike[ProductName] et ProductManagers[ProductName] . Comme nous l’avons vu précédemment, toutes les relations entre sources ont par défaut la cardinalité plusieurs à plusieurs.

Une fois cette relation établie, elle s’affiche comme prévu dans Vue de la relation dans Power BI Desktop.

Nous pouvons maintenant créer des visuels à l’aide de l’un des champs de la liste Champs. Cette approche fusionne facilement les données de plusieurs sources. Par exemple, le montant total des ventes (SalesAmount) pour chaque chef de produit (Product Manager) s’affiche dans l’image suivante :

L’exemple suivant montre un cas courant de table de dimension, comme Product ou Customer, étendue avec des données supplémentaires importées à partir d’un autre emplacement. Des tables peuvent également utiliser DirectQuery pour se connecter à différentes sources. Pour étendre notre exemple, imaginez que les tables Sales Targets (Cibles de ventes) par Country (Pays) et Period (Période) sont stockées dans une base de données distincte d’un service. Comme d’habitude, vous pouvez utiliser Obtenir des données pour vous connecter à ces données, comme l’illustre l’image suivante :

Comme nous l’avons fait précédemment, nous pouvons créer des relations entre la nouvelle table et d’autres tables du modèle. Nous pouvons ensuite créer des visuels qui combinent ces données. Examinons à nouveau Vue de la relation, où nous avons établi les nouvelles relations :

L’image suivante est basée sur les nouvelles données et les relations que nous avons créées. Le visuel en haut à gauche affiche le montant total des ventes (Sales Amount) par rapport aux cibles de ventes (Target), et le calcul de la variance montre la différence. Les données Sales Amount et Target proviennent de deux bases de données SQL Server différentes.

Définir le mode de stockage

Chaque table d’un modèle composite comporte un mode de stockage qui indique si la table est basée sur DirectQuery ou une importation. Vous pouvez afficher et modifier le mode de stockage dans le volet Propriétés . Pour afficher le mode de stockage :

1. En mode Modèle , sélectionnez la table.
2. Dans le volet Propriétés , développez la section Avancé , puis développez la liste des modes de stockage .

Vous pouvez également afficher le mode de stockage sur l’info-bulle de chaque table lorsque vous pointez dessus dans le volet Données .

Pour tout fichier Power BI Desktop (fichier .pbix) contenant des tables provenant de DirectQuery et des tables d’importation, la barre d’état affiche un mode de stockage appelé Mixte. Vous pouvez sélectionner ce terme dans la barre d’état et basculer facilement toutes les tables sur Importer.

Pour plus d’informations sur le mode de stockage, consultez Gérer le mode de stockage dans Power BI Desktop.

Notes

Vous pouvez utiliser le mode de stockage Mixte dans Power BI Desktop et dans le service Power BI.

Tables calculées

Vous pouvez ajouter des tables calculées à un modèle dans Power BI Desktop qui utilise DirectQuery. Le langage DAX (Data Analysis Expressions) qui définit la table calculée peut référencer des tables importées ou DirectQuery, ou une combinaison des deux.

Les tables calculées sont toujours importées et leurs données sont actualisées lorsque vous actualisez les tables. Si une table calculée référence une table DirectQuery, les visuels faisant référence à la table DirectQuery affichent toujours les valeurs les plus récentes dans la source sous-jacente. Autrement, les visuels faisant référence à la table calculée affichent les valeurs au moment de la dernière actualisation de la table calculée.

Important

Les tables calculées ne sont pas prises en charge dans le service Power BI à l’aide de cette fonctionnalité, sauf si vous répondez à des exigences spécifiques. Pour plus d’informations, consultez la section Working with a composite model based on a semantic model dans cet article.

Implications en matière de sécurité

Les modèles composites ont des implications sur la sécurité. Une requête envoyée à une source de données peut inclure des valeurs de données récupérées à partir d’une autre source. Dans l’exemple précédent, le visuel qui affiche (Sales Amount) par Product Manager envoie une requête SQL à la base de données relationnelle Sales. Cette requête SQL peut contenir le nom des chefs de produit (ProductManagers) et leurs produits (Products).

Ainsi, les informations stockées dans la feuille de calcul sont désormais incluses dans une requête envoyée à la base de données relationnelle. Si ces informations sont confidentielles, vous devez tenir compte des implications en matière de sécurité. En particulier, tenez compte des points suivants :

• Tout administrateur de la base de données qui peut afficher les traces ou les journaux d’audit peut afficher ces informations, même sans autorisations sur les données de sa source d’origine. Dans cet exemple, l’administrateur a besoin d’autorisations pour le fichier Excel.

• Paramètres de chiffrement pour chaque source. Il est préférable d’éviter que les informations ne soient récupérées à partir d’une source via une connexion chiffrée, puis incluses par inadvertance dans une requête envoyée à une autre source via une connexion non chiffrée.

Pour confirmer que vous avez considéré les implications de sécurité, Power BI Desktop affiche un message d’avertissement lorsque vous créez un modèle composite.

En outre, si un auteur ajoute Table1 du modèle A à un modèle composite (appelons-le Modèle C pour référence), un utilisateur qui consulte un rapport basé sur Modèle C peut interroger n’importe quelle table dans le modèle A qui n’est pas protégée par la sécurité au niveau des lignes (RLS).

Pour des raisons similaires, vous devez faire attention quand vous ouvrez un fichier Power BI Desktop envoyé à partir d’une source non fiable. Si le fichier contient des modèles composites, des informations que quelqu’un récupère à partir d’une source, à l’aide des informations d’identification de l’utilisateur qui ouvre le fichier, sont envoyées à une autre source de données dans le cadre de la requête. L’auteur malveillant du fichier Power BI Desktop peut afficher les informations. La première fois que vous ouvrez un fichier Power BI Desktop contenant plusieurs sources, Power BI Desktop affiche un avertissement. Cet avertissement est similaire à l’avertissement affiché lors de l’ouverture d’un fichier contenant des requêtes SQL natives.

Impact sur les performances

Lorsque vous utilisez DirectQuery, tenez toujours compte des performances. Assurez-vous que la source principale dispose de suffisamment de ressources pour offrir une bonne expérience aux utilisateurs. Une bonne expérience signifie que les visuels doivent s’actualiser en cinq secondes ou moins. Pour obtenir des conseils sur les performances, consultez DirectQuery dans Power BI.

L’utilisation des modèles composites s’accompagne d’autres considérations en matière de performances. Un seul visuel peut envoyer des requêtes à plusieurs sources. Souvent, une requête transmet ses résultats à une deuxième source. Cette situation peut se produire dans les scénarios d’exécution suivants :

• Requête source qui comprend un grand nombre de valeurs littérales : par exemple, un visuel qui demande le montant total des ventes pour un ensemble de gestionnaires de produits sélectionnés doit d’abord trouver les produits gérés par ces responsables de produits. Cette séquence doit se produire avant que le visuel envoie une requête SQL qui inclut tous les ID de produit dans une WHERE clause.

• Requête source effectuée à un niveau de granularité inférieur, les données étant par la suite agrégées localement : lorsque le nombre de produits (Products) correspondant aux critères de filtre de Chef de produit (Product Manager) devient important, il peut se révéler inefficace ou impossible d’inclure tous les produits dans une clause WHERE. Interrogez plutôt la source relationnelle au niveau inférieur des produits Products, puis agrégez les résultats localement. Si la cardinalité des produits dépasse une limite de 1 million, la requête échoue.

• Plusieurs requêtes sources, une par groupe par valeur : lorsque l’agrégation utilise DistinctCount et est regroupée par une colonne d’une autre source, et si la source externe ne prend pas en charge le passage efficace de nombreuses valeurs littérales qui définissent le regroupement, vous devez envoyer une requête SQL par valeur.

  Un visuel qui sollicite un nombre distinct de CustomerAccountNumber dans la table SQL Server, pour les gestionnaires de produits importés depuis la feuille de calcul, doit inclure les détails de la table Gestionnaires de produits dans la requête envoyée à SQL Server. Avec d’autres sources, par exemple Redshift, cette action n’est pas possible. Une requête SQL serait envoyée pour chaque responsable commercial (Sales Manager) jusqu’à une limite pratique, à laquelle la requête échouerait.

Chacun de ces cas comporte ses propres implications en termes de performances, et les détails exacts varient pour chaque source de données. Bien que la cardinalité des colonnes utilisées dans la relation qui joint les deux sources reste faible (quelques milliers), les performances ne doivent pas être affectées. À mesure que cette cardinalité augmente, faites plus attention à l’impact sur les performances résultantes.

Par ailleurs, avec les relations plusieurs à plusieurs, il faut envoyer des requêtes distinctes à la source sous-jacente pour chaque niveau total ou sous-total, au lieu d’agréger localement les valeurs détaillées. Un visuel de table simple avec des totaux envoie deux requêtes sources, plutôt qu’une seule.

Groupes de source

Un groupe source est une collection d’éléments, tels que des tables et des relations, provenant d’une source DirectQuery ou de toutes les sources d’importation impliquées dans un modèle de données. Un modèle composite est constitué d’un ou plusieurs groupes sources. Penchez-vous sur les exemples suivants :

• Modèle composite qui se connecte à un modèle sémantique Power BI appelé Sales et enrichit le modèle sémantique en ajoutant une mesure Sales YTD qui n’est pas disponible dans le modèle sémantique d’origine. Ce modèle se compose d’un groupe source.
• Modèle composite qui combine des données en important un tableau à partir d’une feuille Excel appelée Targets et d’un fichier CSV appelé Regions, et en établissant une connexion DirectQuery à un modèle sémantique Power BI appelé Sales. Il existe ici deux groupes sources, comme le montre l’image suivante :
  • Le premier groupe source contient les tableaux de la feuille Excel Targets, ainsi que le fichier CSV Regions.
  • Le deuxième groupe source contient les éléments du modèle sémantique Sales Power BI.

Si vous ajoutez une autre connexion DirectQuery à une autre source, telle qu’une connexion DirectQuery à une base de données SQL Server appelée Inventory, les éléments de cette source sont ajoutés en tant que groupe source :

Notes

L’importation de données à partir d’une autre source n’ajoute pas un autre groupe source, car tous les éléments de toutes les sources importées se trouvent dans un groupe source. Direct Lake et les tables d’importation sont également considérées comme le même groupe source.

Groupes et relations sources

Un modèle composite a deux types de relations :

• Les relations intra-groupe source. Ces relations connectent des éléments au sein d’un groupe source. Ces relations sont toujours des relations régulières, sauf si elles sont de type plusieurs-à-plusieurs, auquel cas elles sont limitées.
• Relations de groupe intersource. Ces relations commencent dans un groupe source et se terminent par un autre groupe source. Ces relations sont toujours des relations limitées.

En savoir plus sur la distinction entre les relations régulières et limitées et leur impact.

Par exemple, dans l’image suivante, nous avons ajouté trois relations entre les groupes sources, en associant des tables entre les différents groupes sources :

Local et distant

Tout élément d’un groupe source qui est un groupe source DirectQuery est distant, sauf si vous définissez l’élément localement dans le cadre d’une extension ou d’enrichissement à la source DirectQuery et qu’il ne fait pas partie de la source distante, comme une mesure ou une table calculée. Une table calculée basée sur une table du groupe source DirectQuery appartient au groupe source « Import » et est locale. Tout élément du groupe source « Importer » est local. Par exemple, si vous définissez la mesure suivante dans un modèle composite qui utilise une connexion DirectQuery à la source d’inventaire, la mesure est locale :

[Average Inventory Count] = Average(Inventory[Inventory Count])

Groupes de calcul, requête et évaluation des mesures

Les groupes de calcul vous aident à réduire le nombre de mesures redondantes et à regrouper les expressions de mesure courantes. Les cas d’usage classiques sont des calculs d’intelligence temporelle dans lesquels vous souhaitez passer des calculs réels à des calculs de mois à jour, de trimestre à jour ou d’année à date. Lorsque vous utilisez des modèles composites, il est important de connaître les interactions entre les groupes de calcul et de savoir si une mesure fait uniquement référence aux éléments d’un même groupe source distant. Si une mesure fait uniquement référence aux éléments d’un seul groupe source distant et que le modèle distant définit un groupe de calcul qui affecte la mesure, le groupe de calcul est appliqué, même si vous définissez la mesure dans le modèle distant ou dans le modèle local. Toutefois, si une mesure ne fait pas référence exclusivement aux éléments d’un seul groupe source distant, mais qu’elle fait référence aux éléments d’un groupe source distant sur lequel un groupe de calcul distant est appliqué, les résultats de la mesure peuvent toujours être affectés par le groupe de calcul distant. Prenons l’exemple suivant :

• Reseller Sales est une mesure définie dans le modèle distant.
• Le modèle distant contient un groupe de calcul qui modifie le résultat de Reseller Sales.
• Internet Sales est une mesure définie dans le modèle local.
• Total Sales est une mesure définie dans le modèle local et a la définition suivante :

[Total Sales] = [Internet Sales] + [Reseller Sales]

Dans ce scénario, la mesure Internet Sales n’est pas affectée par le groupe de calcul défini dans le modèle distant, car ils ne font pas partie du même modèle. Toutefois, le groupe de calcul peut modifier le résultat de la mesure Reseller Sales , car ils se trouvent dans le même modèle. Cela signifie que les résultats renvoyés par la mesure Total Sales doivent être évalués avec soin. Vous utilisez, par exemple, le groupe de calcul dans le modèle distant pour obtenir les résultats cumulatifs de l'année. Le résultat retourné par Reseller Sales est maintenant une valeur d’année à jour, tandis que le résultat retourné par Internet Sales est toujours un réel. Le résultat de Total Sales est maintenant probablement inattendu, car il ajoute un résultat réel à un résultat d’année à jour.

Modèles composites sur des modèles sémantiques Power BI et Analysis Services

En utilisant des modèles composites avec des modèles sémantiques Power BI et Analysis Services, vous pouvez créer un modèle composite à l’aide d’une connexion DirectQuery pour vous connecter à des modèles sémantiques Power BI, Azure Analysis Services (AAS) et SQL Server 2022 Analysis Services. Avec un modèle composite, vous pouvez combiner les données de ces sources avec d’autres données DirectQuery et importées. Les auteurs de rapports qui souhaitent combiner les données de leur modèle sémantique d’entreprise avec d’autres données qu’ils possèdent, comme une feuille de calcul Excel, ou qui souhaitent personnaliser ou enrichir les métadonnées à partir de leur modèle sémantique d’entreprise, recherchez cette fonctionnalité particulièrement utile.

Gestion des modèles composites sur des modèles sémantiques Power BI

Pour créer et utiliser des modèles composites sur des modèles sémantiques Power BI, votre locataire doit activer les commutateurs suivants :

• Autoriser les points de terminaison XMLA et l’analyse dans Excel avec les modèles sémantiques locaux. Si vous désactivez ce commutateur, vous ne pouvez pas établir de connexion DirectQuery à un modèle sémantique Power BI.
• Les utilisateurs peuvent utiliser des modèles sémantiques Power BI dans Excel à l’aide d’une connexion active. Si vous désactivez ce commutateur, les utilisateurs ne peuvent pas établir de connexions actives à des modèles sémantiques Power BI afin que les modifications apportées à ce bouton de modèle ne soient pas disponibles.
• Autoriser la connexion DirectQuery aux modèles sémantiques Power BI. Vous trouverez d’autres informations sur ce commutateur et l’effet de sa désactivation dans les paragraphes suivants.

En outre, pour les capacités Premium et Premium par utilisateur, le paramètre « Point de terminaison XMLA » doit être activé et défini sur « Lecture seule » ou « Lecture/écriture ».

Les administrateurs de locataires peuvent activer ou désactiver les connexions DirectQuery aux modèles sémantiques Power BI dans le portail d’administration. Bien que ce paramètre soit activé par défaut, il empêche les utilisateurs de publier de nouveaux modèles composites sur des modèles sémantiques Power BI sur le service.

Les rapports existants qui utilisent un modèle composite sur un modèle sémantique Power BI continuent de fonctionner. Les utilisateurs peuvent toujours créer le modèle composite dans Power BI Desktop, mais ne peuvent pas le publier sur le service. Au lieu de cela, lorsque vous créez une connexion DirectQuery au modèle sémantique Power BI en sélectionnant Apporter des modifications à ce modèle, vous voyez le message d’avertissement suivant :

De cette façon, vous pouvez toujours explorer le modèle sémantique dans votre environnement local Power BI Desktop et créer le modèle composite. Toutefois, vous ne pouvez pas publier le rapport dans le service. Lorsque vous publiez le rapport et le modèle, le message d'erreur suivant s'affiche et la publication est bloquée :

Les connexions actives à des modèles sémantiques Power BI ne sont pas influencées par le changement, ni les connexions dynamiques ou DirectQuery à Analysis Services. Ces connexions continuent de fonctionner indépendamment du paramètre de commutateur. En outre, tous les rapports publiés qui utilisent un modèle composite sur un modèle sémantique Power BI continuent de fonctionner même si le commutateur est désactivé après leur publication.

Création d’un modèle composite sur un modèle sémantique ou un modèle

Pour créer un modèle composite sur un modèle sémantique Power BI ou un modèle Analysis Services, votre rapport a besoin d’un modèle local. Vous pouvez démarrer à partir d’une connexion active et ajouter un modèle local (ou le mettre à niveau), ou démarrer avec une connexion DirectQuery ou des données importées, ce qui crée automatiquement un modèle local dans votre rapport.

Pour voir quelles connexions sont utilisées dans votre modèle, vérifiez la barre d’état dans le coin inférieur droit de Power BI Desktop. Si vous êtes connecté uniquement à une source Analysis Services, un message semblable à l’image suivante s’affiche :

Si vous êtes connecté à un modèle sémantique Power BI, un message vous indique le modèle sémantique Power BI auquel vous êtes connecté :

Si vous souhaitez personnaliser les métadonnées des champs dans votre modèle sémantique connecté en temps réel, sélectionnez Make changes to this model (Apporter des modifications à ce modèle) dans la barre d’état. Vous pouvez également sélectionner le bouton Make changes to this model (Apporter des modifications à ce modèle) dans le ruban, comme illustré dans l’image suivante. Dans l’affichage rapport , le bouton Apporter des modifications à ce modèle se trouve sous l’onglet Modélisation . En mode Modèle, le bouton se trouve sous l’onglet Accueil .

Lorsque vous sélectionnez le bouton, une boîte de dialogue s’affiche qui confirme l’ajout d’un modèle local. Sélectionnez Ajouter un modèle local pour activer la création de colonnes ou modifier les métadonnées des champs à partir de modèles sémantiques Power BI ou d’Analysis Services. L’image suivante montre la boîte de dialogue.

Quand vous êtes connecté en temps réel à une source Analysis Services, aucun modèle local n’est disponible. Afin d’utiliser DirectQuery pour des sources connectées en temps réel, par exemple des modèles sémantiques Power BI et Analysis Services, vous devez ajouter un modèle local à votre rapport. Lorsque vous publiez un rapport avec un modèle local sur le service Power BI, un modèle sémantique pour ce modèle local est également publié.

Chaînage

Les modèles sémantiques et les modèles sémantiques sur lesquels ils sont basés forment une chaîne. Ce processus, appelé chaînage, vous permet de publier un rapport et un modèle sémantique basé sur d’autres modèles sémantiques Power BI.

Par exemple, imaginez que votre collègue publie un modèle sémantique Power BI appelé Ventes et budget basé sur un modèle Analysis Services appelé Ventes, et l’associe à une feuille Excel appelée Budget. Ensuite, vous créez et publiez un modèle sémantique composite et un rapport, appelé Sales and Budget Europe, à l’aide du modèle sémantique Sales and Budget Power BI avec vos propres modifications. Ce modèle sémantique est troisième dans la chaîne.

1. La première chaîne est le modèle Sales Analysis Services.
2. La deuxième chaîne est le modèle sémantique composite Sales and Budget Power BI.
3. La troisième chaîne est votre modèle sémantique composite Sales and Budget Europe Power BI.

L’image suivante illustre ce processus de chaînage.

La longueur de la chaîne dans l’image précédente est de trois, c’est-à-dire la longueur maximale. L’extension d’une chaîne au-delà de trois éléments n’est pas prise en charge et génère des erreurs.

Autorisations et gestion des licences

Les utilisateurs accédant aux rapports à l’aide d’un modèle composite ont besoin d’autorisations appropriées pour tous les modèles et modèles sémantiques de la chaîne.

Le propriétaire du modèle composite a besoin de l’autorisation Build sur les modèles sémantiques utilisés comme sources afin que d’autres utilisateurs puissent accéder à ces modèles pour le compte du propriétaire. Par conséquent, la création de la connexion de modèle composite dans Power BI Desktop ou la création du rapport dans Power BI nécessite des autorisations de génération sur les modèles sémantiques utilisés comme sources.

Les utilisateurs qui affichent des rapports à l’aide du modèle composite ont généralement besoin d’autorisations de lecture sur le modèle composite lui-même et les modèles sémantiques utilisés comme sources. Les autorisations de génération peuvent être nécessaires si les rapports se trouvent dans un espace de travail Pro. Ces commutateurs de tenant doivent être activés pour l’utilisateur.

L’exemple suivant illustre les autorisations requises :

• Modèle composite A (appartenant au propriétaire A)

  • Source de données A1 : modèle sémantique B.
    Le propriétaire A doit disposer de l’autorisation Générer sur le modèle sémantique B pour permettre aux utilisateurs d’afficher le rapport qui utilise le modèle composite A.

• Modèle composite C (appartenant au propriétaire C)

  • Source de données C1 : modèle sémantique D
    Le propriétaire C doit disposer de l’autorisation Générer sur le modèle sémantique D pour permettre aux utilisateurs d’afficher le rapport qui utilise le modèle composite C.
  • Source de données C2 : modèle composite A
    Le propriétaire C doit disposer de l’autorisation de génération sur le modèle composite A et l’autorisation de lecture sur le modèle sémantique B.

Un utilisateur qui consulte des rapports qui utilisent le modèle composite A doit disposer d’autorisations de lecture pour le modèle composite A et le modèle sémantique B, tandis qu’un utilisateur qui consulte des rapports qui utilisent le modèle composite C doit disposer d’autorisations de lecture sur le modèle composite C, le modèle sémantique D, le modèle composite A et le modèle sémantique B.

Notes

Pour plus d’informations, consultez les autorisations requises pour les modèles composites sur les modèles sémantiques Power BI et les modèles Analysis Services.

Si un modèle sémantique de la chaîne se trouve dans un espace de travail Premium par utilisateur, l’utilisateur qui y accède a besoin d’une licence Premium par utilisateur. Si un modèle sémantique de la chaîne se trouve dans un espace de travail Pro, l’utilisateur qui y accède a besoin d’une licence Pro. Si tous les modèles sémantiques de la chaîne se trouvent sur des capacités Premium ou une capacité Fabric F64 ou supérieure, un utilisateur peut y accéder à l’aide d’une licence gratuite.

Avertissement de sécurité

Lorsque vous utilisez les modèles composites sur les modèles sémantiques Power BI et la fonctionnalité des modèles Analysis Services , vous voyez une boîte de dialogue d’avertissement de sécurité, illustrée dans l’image suivante.

Les données peuvent être envoyées d’une source de données à une autre source de données. Cet avertissement de sécurité s’applique à la combinaison de DirectQuery et d’importation de sources dans un modèle de données. Pour plus d’informations sur ce comportement, consultez l’utilisation de modèles composites dans Power BI Desktop.

Scénarios pris en charge

Vous pouvez créer des modèles composites à l’aide de données à partir de modèles sémantiques Power BI ou de modèles Analysis Services pour traiter les scénarios suivants :

• Se connecter aux données à partir de différentes sources : Importation (par exemple, fichiers), modèles sémantiques Power BI, modèles Analysis Services
• Créer des relations entre différentes sources de données
• Écrire des mesures qui utilisent des champs provenant de différentes sources de données
• Créer des colonnes pour les tables à partir de modèles sémantiques Power BI ou de modèles Analysis Services
• Créer des visuels qui utilisent des colonnes provenant de différentes sources de données
• Supprimez une table de votre modèle à l'aide de la liste des champs pour maintenir les modèles aussi concis et légers que possible (si vous vous connectez à une perspective, vous ne pouvez pas supprimer de tables du modèle)
• Spécifiez les tables à charger, plutôt que de devoir charger toutes les tables lorsque vous souhaitez uniquement un sous-ensemble spécifique de tables. Consultez Chargement d’un sous-ensemble de tables plus loin dans ce document.
• Spécifiez s’il faut ajouter des tables que vous ajoutez ultérieurement au modèle sémantique après avoir créé la connexion dans votre modèle.

Utilisation d’un modèle composite basé sur un modèle sémantique ou un modèle

Lorsque vous utilisez DirectQuery pour les modèles sémantiques Power BI et Analysis Services, tenez compte des éléments suivants :

• Si vous actualisez vos sources de données et que des erreurs apparaissent au niveau des noms de champs ou de tables en conflit, Power BI résout les erreurs pour vous.

• Vous ne pouvez pas modifier, supprimer ou créer de nouvelles relations dans le même modèle sémantique Power BI ou la même source Analysis Services. Si vous avez un accès en modification à ces sources, vous pouvez plutôt apporter les modifications directement dans la source de données.

• Vous ne pouvez pas modifier les types de données des colonnes chargées à partir d’un modèle sémantique Power BI ou d’une source Analysis Services. Si vous devez modifier le type de données, modifiez-le dans la source ou utilisez une colonne calculée.

• Pour générer des rapports dans le service Power BI sur un modèle composite basé sur un autre modèle sémantique, vous devez définir toutes les informations d’identification.

• Les connexions à un serveur Analysis Services SQL Server 2022 et ultérieur localement ou IAAS nécessitent une passerelle de données locale (mode Standard).

• Toutes les connexions aux modèles sémantiques Power BI distants utilisent l’authentification unique. L’authentification avec un principal de service n’est pas actuellement prise en charge.

• Les règles RLS s’appliquent à la source sur laquelle elles sont définies, mais ne s’appliquent pas à d’autres modèles sémantiques dans le modèle. Le RLS défini dans le rapport ne s’applique pas aux sources distantes, et le RLS défini sur les sources distantes ne s’applique pas aux autres sources de données. En outre, vous ne pouvez pas définir de RLS sur une table chargée à partir d’une source distante, et les RLS définies sur les tables locales ne filtrent pas les tables chargées à partir d’une source distante.

• Les indicateurs de performance clés, la sécurité au niveau des lignes et les traductions ne sont pas importés à partir de la source.

• Vous risquez de constater un comportement inattendu lors de l’utilisation d’une hiérarchie de dates. Pour résoudre ce problème, utilisez plutôt une colonne de date. Après avoir ajouté une hiérarchie de dates à un visuel, vous pouvez basculer vers une colonne de date en sélectionnant la flèche vers le bas dans le nom du champ, puis en sélectionnant le nom de ce champ au lieu d’utiliser la hiérarchie de dates :

  

  Pour plus d’informations sur l’utilisation des colonnes de date par rapport aux hiérarchies de dates, consultez Appliquer automatiquement la date ou l’heure dans Power BI Desktop.

• La longueur maximale d’une chaîne de modèles est de trois éléments. L’extension de la chaîne au-delà de trois éléments n’est pas prise en charge et génère des erreurs.

• Vous pouvez définir un indicateur de chaînage déconseillé sur un modèle pour empêcher la création ou l’extension d’une chaîne. Pour plus d’informations, consultez Gérer les connexions DirectQuery à un modèle sémantique publié.

• Power Query n’affiche pas la connexion à un modèle sémantique Power BI ou à un modèle Analysis Services.

Les limitations suivantes s’appliquent lors de l’utilisation de DirectQuery pour les modèles sémantiques Power BI et Analysis Services :

• Les paramètres pour les noms de base de données et de serveur sont actuellement désactivés.
• La définition de la sécurité au niveau des tables (RLS) d’une source distante n’est pas prise en charge.
• L’utilisation d’une des sources suivantes comme source DirectQuery n’est pas prise en charge :
  • Modèles tabulaires SQL Server Analysis Services (SSAS) avant la version 2022
  • Modèles multidimensionnels SSAS
  • SAP HANA
  • SAP Business Warehouse
  • Modèles sémantiques en temps réel
  • Exemple de modèles sémantiques
  • Actualisation d’Excel Online
  • Données importées à partir de fichiers Excel ou CSV sur le service
  • Métriques d'utilisation
  • Modèles sémantiques stockés dans « Mon espace de travail »
• L’utilisation de Power BI Embedded avec des modèles sémantiques qui incluent une connexion DirectQuery à un modèle Analysis Services externe (Azure Analysis Services/SQL Server Analysis Services) n’est actuellement pas prise en charge.
• La publication d’un rapport sur le web à l’aide de la fonctionnalité publier sur le web n’est pas prise en charge.
• Les groupes de calcul sur des sources distantes ne sont pas pris en charge, avec des résultats de requête non définis.
• Les tableaux et colonnes calculés qui font référence à un tableau DirectQuery à partir d’une source de données avec authentification unique (SSO) sont pris en charge dans le service Power BI avec une connexion cloud partageable attribuée et/ou un contrôle d’accès granulaire.
• Si vous renommez un espace de travail après avoir configuré la connexion DirectQuery, vous devez mettre à jour la source de données dans Power BI Desktop pour que le rapport continue de fonctionner.
• L’actualisation automatique de la page (APR) est prise en charge uniquement pour certains scénarios, en fonction du type de source de données. Pour plus d’informations, consultez Actualisation automatique des pages dans Power BI.
• La prise en charge d’un modèle sémantique qui utilise DirectQuery pour d’autres fonctionnalités de modèles sémantiques n’est pas prise en charge actuellement.
• Comme pour toute source de données DirectQuery, les hiérarchies définies dans un modèle Analysis Services ou un modèle sémantique Power BI ne s’affichent pas lors de la connexion au modèle ou au modèle sémantique en mode DirectQuery à l’aide d’Excel.

Lorsque vous utilisez DirectQuery pour les modèles sémantiques Power BI et Analysis Services, tenez compte des conseils suivants :

• Utiliser des colonnes à faible cardinalité dans les relations de groupes intersource : lorsque vous créez une relation entre deux groupes sources différents, les colonnes participant à la relation (également appelées colonnes de jointure) doivent avoir une cardinalité faible, idéalement 50 000 ou moins. Cette considération s’applique aux colonnes clés autres que les chaînes. Pour les colonnes clés de chaîne, consultez la considération suivante.
• Évitez d’utiliser des colonnes clés de chaînes volumineuses dans des relations de groupes intersource : lors de la création d’une relation de groupe intersource, évitez d’utiliser des colonnes de chaînes volumineuses comme colonnes de relation, en particulier pour les colonnes dont la cardinalité est supérieure. Lorsque vous devez utiliser des colonnes de chaînes comme colonne de relation, calculez la longueur de chaîne attendue pour le filtre en multipliant la cardinalité (C) par la longueur moyenne de la colonne de chaîne (A). Assurez-vous que la longueur de chaîne attendue est inférieure à 250 000, de sorte que A ∗ C < 250 000.

Pour obtenir d’autres considérations et conseils, reportez-vous à Conseils sur le modèle composite.

Considérations relatives aux locataires

Vous devez publier n’importe quel modèle avec une connexion DirectQuery à un modèle sémantique Power BI ou à Analysis Services dans le même tenant. Cette exigence est particulièrement importante lors de l’accès à un modèle sémantique Power BI ou à un modèle Analysis Services à l’aide d’identités invitées B2B, comme illustré dans le diagramme suivant.

Observez le diagramme suivant. Les étapes numérotées du diagramme sont décrites dans les paragraphes suivants.

Dans le diagramme, Ash fonctionne avec Contoso et accède aux données fournies par Fabrikam. Avec Power BI Desktop, Ash crée une connexion DirectQuery à un modèle Analysis Services que Fabrikam héberge.

Pour s’authentifier, Ash utilise une identité d’utilisateur invité B2B (étape 1 dans le diagramme).

Si Ash publie le rapport sur le service Power BI de Contoso (étape 2), le modèle sémantique publié dans le locataire Contoso ne peut pas s’authentifier correctement auprès du modèle Analysis Services de Fabrikam (étape 3). Ainsi, le rapport ne fonctionne pas.

Dans ce scénario, étant donné que Fabrikam héberge le modèle de Analysis Services, vous devez également publier le rapport dans le client de Fabrikam. Une fois la publication effectuée dans le locataire de Fabrikam (étape 4), le modèle sémantique peut accéder au modèle Analysis Services (étape 5) et le rapport fonctionne correctement.

Utilisation de la sécurité au niveau de l’objet

Lorsqu’un modèle composite obtient des données d’un modèle sémantique Power BI ou d’Analysis Services via DirectQuery, et que ce modèle source est sécurisé par une sécurité au niveau des objets, les consommateurs du modèle composite peuvent remarquer des résultats inattendus. La section suivante explique comment ces résultats peuvent être obtenus.

La sécurité au niveau de l’objet (OLS) permet aux auteurs de modèles de masquer les objets qui composent le schéma du modèle (c’est-à-dire les tables, les colonnes, les métadonnées, etc.) des consommateurs de modèles (par exemple, un générateur de rapports ou un auteur de modèle composite). Lors de la configuration d’OLS pour un objet, l’auteur du modèle crée un rôle, puis supprime l’accès à l’objet pour les utilisateurs disposant de ce rôle. Du point de vue de ces utilisateurs, l’objet masqué n’existe tout simplement pas.

OLS est défini pour le modèle source et s’applique à celui-ci. Vous ne pouvez pas le définir pour un modèle composite basé sur le modèle source.

Lorsque vous générez un modèle composite au-dessus d’un modèle sémantique Power BI protégé par OLS ou d’un modèle Analysis Services via la connexion DirectQuery, vous copiez le schéma du modèle à partir du modèle source dans le modèle composite. Ce que vous copiez dépend de ce que vous êtes autorisé à voir dans le modèle source en fonction des règles OLS qui s’y appliquent. Vous ne copiez pas les données dans le modèle composite : vous les récupérez toujours via DirectQuery à partir du modèle source si nécessaire. En d’autres termes, l’extraction de données renvoie toujours au modèle source, où les règles d’OLS s’appliquent.

Étant donné que le modèle composite n’est pas sécurisé par les règles OLS, les objets auxquels les consommateurs du modèle composite voient sont ceux que vous pouvez voir dans le modèle source plutôt que ce qu’ils eux-mêmes peuvent avoir accès. Cette situation peut entraîner les résultats suivants :

• Une personne qui consulte le modèle composite peut voir les objets qui sont masqués dans le modèle source par OLS.
• À l’inverse, il est possible qu’elle ne voie PAS un objet dans le modèle composite qu’elle PEUT voir dans le modèle source, car cet objet a été masqué par les règles d’OLS qui contrôlent l’accès au modèle source.

Un point important est que, malgré le cas décrit dans la premier point, les consommateurs du modèle composite ne verront jamais les données réelles qu’ils ne sont pas censés voir, car les données ne se trouvent pas dans le modèle composite. Au lieu de cela, grâce à DirectQuery, ce qui est nécessaire est récupéré dans le modèle sémantique source, où OLS bloque l’accès non autorisé.

En sachant cela, prenez en considération le scénario suivant :

1. Admin_user publie un modèle sémantique d’entreprise à l’aide d’un modèle sémantique Power BI ou d’un modèle Analysis Services qui a une table Customer et une table Territory. Admin_user publie le modèle sémantique dans le service Power BI et définit des règles d’OLS ayant les effets suivants :

   • Les utilisateurs du service financier ne peuvent pas voir la table Customer
   • Les utilisateurs du service marketing ne peuvent pas voir la table Territory

2. Finance_user publie un modèle sémantique nommé « Finance semantic model » et un rapport nommé « Finance report » qui se connecte via DirectQuery au modèle sémantique d’entreprise publié à l’étape 1. Le rapport financier comprend un visuel qui utilise une colonne de la table Territory.

3. Marketing_user ouvre le rapport financier. Le visuel qui utilise la table Territory s’affiche, mais retourne une erreur, car lorsque le rapport est ouvert, DirectQuery essaie de récupérer les données du modèle source à l’aide des informations d’identification de Marketing_user, qui ne peut pas voir la table Territory conformément aux règles d’OLS définies sur le modèle sémantique d’entreprise.

4. Marketing_user crée un rapport nommé « Marketing report » qui utilise le modèle sémantique Finance comme source. La liste des champs affiche les tables et les colonnes auxquelles Finance_user a accès. La table Territory apparaît donc dans la liste des champs, mais pas la table Customer. Toutefois, lorsque Marketing_user tente de créer un visuel qui utilise une colonne de la table Territory, une erreur est retournée, car à ce stade, DirectQuery essaie de récupérer des données du modèle source à l’aide des informations d’identification de Marketing_user, et les règles d’OLS s’appliquent à nouveau et bloquent l’accès. La même chose se produit lorsque Marketing_user crée un modèle sémantique et un rapport qui se connecte au modèle sémantique Finance avec une connexion DirectQuery. Il voit la table Territory dans la liste des champs, car c’est ce que Finance_user peut voir, mais lorsqu’il essaie de créer un visuel qui utilise cette table, il est bloqué par les règles d’OLS sur le modèle sémantique d’entreprise.

5. Supposons à présent que Admin_user met à jour les règles d’OLS sur le modèle sémantique d’entreprise pour empêcher le service financier de voir la table Territory.

6. Les règles OLS mises à jour n’apparaissent dans le modèle sémantique Finance qu’une fois celui-ci actualisé. Ainsi, lorsque Finance_user actualise le modèle sémantique Finance, la table Territory n’apparaît plus dans la liste des champs, et le visuel dans le rapport Finance qui utilise une colonne de la table Territory retourne une erreur pour Finance_user, car il n’est désormais plus autorisé à accéder à la table Territory.

Pour récapituler :

• Les consommateurs d’un modèle composite voient les résultats des règles d’OLS qui s’appliquaient à l’auteur du modèle composite lors de la création du modèle. Ainsi, lorsqu’un nouveau rapport est créé sur la base du modèle composite, la liste des champs affiche les tables auxquelles l’auteur du modèle composite avait accès lors de la création du modèle, indépendamment de ce à quoi l’utilisateur actuel a accès dans le modèle source.
• Vous ne pouvez pas définir de règles OLS sur le modèle composite lui-même.
• Un consommateur d’un modèle composite ne voit jamais les données réelles qu’ils ne sont pas censés voir, car les règles OLS pertinentes sur le modèle source les bloquent lorsque DirectQuery tente de récupérer les données à l’aide de leurs informations d’identification.
• Si le modèle source met à jour ses règles d’OLS, ces modifications n’affectent que le modèle composite lorsqu’il est actualisé.

Chargement d’un sous-ensemble de tables à partir d’un modèle sémantique Power BI ou d’un modèle Analysis Services

Lorsque vous vous connectez à un modèle sémantique Power BI ou à un modèle Analysis Services à l’aide d’une connexion DirectQuery, vous choisissez les tables à laquelle vous connecter. Vous pouvez également choisir d’ajouter automatiquement toute table susceptible d’être ajoutée au modèle sémantique ou au modèle, une fois que vous avez effectué la connexion à votre modèle. Lorsque vous vous connectez à une perspective, votre modèle contient toutes les tables figurant dans le modèle sémantique, et toutes les tables non incluses dans la perspective sont masquées. En outre, n’importe quelle table susceptible d’être ajoutée à la perspective est ajoutée automatiquement. Dans le menu Paramètres, vous pouvez décider de vous connecter automatiquement aux tables ajoutées au modèle sémantique après avoir configuré la connexion.

Cette boîte de dialogue ne s’affiche pas pour les connexions actives.

Notes

Cette boîte de dialogue s’affiche uniquement si vous ajoutez une connexion DirectQuery à un modèle sémantique Power BI ou à un modèle Analysis Services à un modèle existant. Vous pouvez également ouvrir cette boîte de dialogue en modifiant la connexion DirectQuery au modèle sémantique Power BI ou au modèle Analysis Services dans les paramètres de source de données après sa création.

Configuration des règles de déduplication

Vous pouvez spécifier des règles de déduplication pour conserver des noms de mesures et de tables uniques dans un modèle composite à l’aide de l’option Paramètres dans la boîte de dialogue affichée précédemment :

Dans l’exemple précédent, nous avons ajouté ' (marketing)' en tant que suffixe à n’importe quelle table ou nom de mesure qui est en conflit avec une autre source dans le modèle composite. Vous pouvez :

• Entrez un texte à ajouter au nom des tables ou des mesures en conflit.
• Spécifiez si vous souhaitez que le texte soit ajouté au nom de la table ou de la mesure en tant que préfixe ou suffixe.
• Appliquez la règle de déduplication aux tables, mesures ou les deux.
• Choisissez d’appliquer la règle de déduplication uniquement lorsqu’un conflit de noms se produit, ou bien appliquez la tout le temps. Par défaut, la règle s’applique uniquement en cas de duplication. Dans notre exemple, toute table ou mesure provenant de la source marketing qui n’a pas de doublon dans la source de vente n’obtient pas de modification de nom.

Après avoir établi les connexions et configuré la règle de déduplication, votre liste de champs affiche à la fois « Customer » et « Customer (marketing) » en fonction de la règle de déduplication configurée dans notre exemple :

Si vous ne spécifiez pas de règle de déduplication ou si les règles de déduplication que vous spécifiez ne résolvent pas le conflit de noms, les règles de déduplication standard sont toujours appliquées. Les règles de déduplication standard ajoutent un nombre au nom de l’élément en conflit. S’il existe un conflit de noms sur la table « Customer », l’une des tables « Customer » est renommée « Customer 2 ».

Modifications XMLA et modèles composites

Lorsque vous modifiez un modèle sémantique à l’aide de XMLA, mettez à jour les collections ChangedProperties et PBI_RemovedChildren pour l’objet modifié afin d’inclure les propriétés modifiées ou supprimées. Si vous ne mettez pas à jour ces collections, les outils de modélisation Power BI peuvent remplacer vos modifications la prochaine fois que le schéma se synchronise avec la source de données.

Pour plus d’informations sur les balises de traçabilité d’objet de modèle sémantique, consultez les balises de traçabilité pour les modèles sémantiques Power BI.

Observations et limitations

Les modèles composites présentent quelques considérations et limitations :

Connexions en mode mixte : lorsque vous utilisez une connexion en mode mixte qui contient des données en ligne (comme un modèle sémantique Power BI) et un modèle sémantique local (tel qu’un classeur Excel), vous devez établir un mappage de passerelle pour que les visuels apparaissent correctement.

Pour l’instant, l’actualisation incrémentielle est prise en charge pour les modèles composites qui se connectent aux sources de données SQL, Oracle et Teradata uniquement.

Les sources tabulaires Live Connect suivantes ne peuvent pas être utilisées avec des modèles composites :

• SAP HANA
• SAP Business Warehouse
• SQL Server Analysis Services antérieur à la version 2022
• Métriques d’utilisation (Mon espace de travail)

L’utilisation de modèles sémantiques en streaming n’est pas prise en charge dans les modèles composites.

Les limitations existantes concernant DirectQuery s’appliquent toujours quand vous utilisez des modèles composites. Plusieurs de ces limitations sont désormais appliquées par table, selon le mode de stockage de la table. Par exemple, une colonne calculée d’une table d’importation peut faire référence à d’autres tables qui ne sont pas dans DirectQuery, mais une colonne calculée d’une table DirectQuery ne peut toujours faire référence qu’à des colonnes de la même table. D’autres limitations s’appliquent au modèle dans son ensemble, si aucune des tables du modèle n’est de type DirectQuery. Par exemple, les fonctionnalités Quick Insights ne sont pas disponibles sur un modèle si l’une des tables qu’il contient a un mode de stockage de type DirectQuery.

Si vous utilisez la sécurité au niveau des lignes dans un modèle composite avec certaines des tables en mode DirectQuery, vous devez actualiser le modèle pour appliquer de nouvelles mises à jour à partir des tables DirectQuery. Par exemple, si une table Users en mode DirectQuery possède de nouveaux enregistrements utilisateur à la source, les nouveaux enregistrements sont inclus uniquement après l’actualisation suivante du modèle. Le service Power BI met en cache la requête Utilisateurs pour améliorer les performances et ne recharge pas les données de la source jusqu’à l’actualisation manuelle ou planifiée suivante.

Contenu connexe

Pour plus d’informations sur les modèles composites et DirectQuery, consultez les articles suivants :

• Appliquer des relations plusieurs à plusieurs dans Power BI Desktop
• Gérer le mode de stockage dans Power BI Desktop
• DirectQuery dans Power BI
• Sources de données Power BI
• Relations de modèle dans Power BI Desktop