Utiliser des modèles composites dans Power BI Desktop

Dans Power BI Desktop, lorsque l’on utilisait le mode DirectQuery dans un rapport, aucune autre connexion de données (DirectQuery ou d’importation) n’était autorisée pour ce rapport. Avec les modèles composites, cette restriction est levée. Un rapport peut inclure en toute transparence des connexions de données provenant de plusieurs connexions de données DirectQuery ou d’importation, dans la combinaison de votre choix.

La fonctionnalité des modèles composites dans Power BI Desktop se compose de trois fonctionnalités connexes :

• Modèles composites : cette option permet à un rapport d’avoir plusieurs connexions de données à partir de différents groupes sources. Ces groupes sources peuvent être constitués d’une ou plusieurs connexions DirectQuery et d’une connexion d’importation, de plusieurs connexions DirectQuery, ou de toute combinaison de celles-ci. Cet article décrit en détail les modèles composites.

• Relations plusieurs à plusieurs : avec les modèles composites, vous pouvez établir des relations plusieurs à plusieurs entre les tables. Cette approche supprime la nécessité d’avoir des valeurs uniques dans les tables. Les solutions de contournement précédentes, comme la présentation de nouvelles tables uniquement pour établir des relations, sont également supprimées. Pour plus d’informations, consultez Appliquer des relations plusieurs à plusieurs dans Power BI Desktop.

• Mode de stockage : il est maintenant possible d’indiquer quels visuels interrogent les sources de données back-end. Cette fonctionnalité permet d’améliorer les performances et de réduire la charge du back-end. Avant, même les visuels simples, comme les segments, lançaient des requêtes à des sources back-end. Pour plus d’informations, consultez Gérer le mode de stockage dans Power BI Desktop.

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.
• Données importées à partir d’une feuille de calcul.

Un modèle combinant les données de plusieurs sources DirectQuery ou DirectQuery avec des données d’importation est appelé modèle 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 connecté à 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 chef 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. Le mode de stockage peut être affiché et modifié dans le volet Propriété. Pour afficher le mode de stockage, cliquez avec le bouton droit sur une table dans la liste Champs, puis sélectionnez Propriétés. L’illustration suivante montre le mode de stockage pour la table SalesTargets.

Le mode de stockage peut également être consulté dans l’info-bulle de chaque table.

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 en même temps que 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 qui utilise cette fonctionnalité. Pour plus d’informations, consultez la section Utilisation d’un modèle composite basé sur un modèle sémantique de 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 qui ont été récupérées à partir d’une autre source. Dans l’exemple précédent, le visuel qui montre le montant des ventes (SalesAmount) par chef de produit (ProductManagers) 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 capable d’afficher les traces ou les journaux d’audit peut voir ces informations, même s’il ne dispose pas des autorisations pour accéder aux données de la source d’origine. Dans cet exemple, l’administrateur a besoin d’autorisations pour le fichier Excel.

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

Afin de confirmer que les implications en matière de sécurité ont bien été prises en compte, Power BI Desktop affiche un message d’avertissement lors de la création d’un modèle composite.

En outre, si un auteur ajoute la Table1 du Modèle A à un modèle composite (que nous appellerons ici Modèle C), un utilisateur qui consulte un rapport basé sur le Modèle C peut interroger n’importe quelle table du Modèle A qui n’est pas protégée par la sécurité au niveau des lignes.

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, les informations récupérées à partir d’une source en utilisant les 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. Les informations peuvent être vues par l’auteur malveillant du fichier Power BI Desktop. 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

Quand vous utilisez DirectQuery, tenez toujours compte des performances pour garantir avant tout que la source backend dispose de ressources suffisantes pour assurer 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 entraîner l’envoi de requêtes vers plusieurs sources, souvent en passant les résultats d’une requête à une deuxième source. Cette situation peut se produire dans les scénarios d’exécution suivants :

• Requête source incluant un grand nombre de valeurs littérales : par exemple, un visuel demandant le montant total des ventes (Sales Amount) pour un groupe spécifique de chefs de produit (Product Managers) doit d’abord identifier les produits (Products) gérés par ces chefs de produit. Cette séquence doit se produire avant que le visuel n’envoie une requête SQL contenant tous les ID produit dans une clause WHERE.

• 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.

• Requêtes sources multiples, une par groupe et par valeur : lorsque l’agrégation utilise des données DistinctCount regroupées par une colonne d’une autre source, si la source externe ne gère pas une transmission efficace des nombreuses valeurs littérales qui définissent le regroupement, il est nécessaire d’envoyer une requête SQL par groupe et par valeur.

  Un visuel demandant un décompte distinct de la valeur CustomerAccountNumber de la table SQL Server par chef de produit (ProductManagers) importée de la feuille de calcul doit passer les détails de la table ProductManagers 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. Même si la cardinalité des colonnes utilisées dans la relation qui unit les deux sources reste faible (quelques milliers), les performances ne devraient pas être affectées. À mesure que cette cardinalité augmente, vous devez examiner de plus près l’impact sur les performances.

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 simple visuel de table avec des totaux envoie deux requêtes sources plutôt qu’une.

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 avez ajouté 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 seront ajoutés en tant que groupe source :

Remarque

L’importation de données à partir d’une autre source n’ajoute pas d’autre groupe source, car tous les éléments de toutes les sources importées se trouvent dans un même groupe source.

Groupes et relations sources

Il existe deux types de relations dans un modèle composite :

• Les relations intra-groupe source. Ces relations associent 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 groupes sources, reliant les tables des différents groupes sources :

Local et distant

Tout élément qui se trouve dans un groupe source correspondant à un groupe source DirectQuery est considéré comme distant, sauf si cet élément a été défini localement dans le cadre d’une extension ou d’un enrichissement de la source DirectQuery et 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 « Importer » et est considérée comme locale. Tout élément qui se trouve dans le groupe source « Importer » est considéré comme 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 considérée comme locale :

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

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

Les groupes de calcul permettent de réduire le nombre de mesures redondantes et de regrouper les expressions de mesure courantes. Les cas d’usage classiques sont les calculs Time Intelligence dans lesquels vous souhaitez pouvoir passer des chiffres réels aux calculs mensuels, trimestriels ou annuels. 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 même groupe source distant et que le modèle distant définit un groupe de calcul qui a un impact sur la mesure, ce groupe de calcul est appliqué, même si la mesure a été définie dans le modèle distant ou dans le modèle local. En revanche, si une mesure ne fait pas exclusivement référence aux éléments d’un même groupe source distant, mais qu’elle fait aussi 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 encore ê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. Imaginez que nous utilisons le groupe de calcul dans le modèle distant pour retourner les résultats d’une année à l’autre. 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

À l’aide de 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 aux modèles sémantiques Power BI, à Azure Analysis Services (AAS) et à SQL Server Analysis Services 2022. À l’aide d’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 de leur modèle sémantique d’entreprise, trouveront cette fonctionnalité particulièrement utile.

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

Pour permettre la création et la consommation de modèles composites sur des modèles sémantiques Power BI, votre locataire doit avoir les commutateurs suivants activés :

• Autoriser les points de terminaison XMLA et l’analyse dans Excel avec les modèles sémantiques locaux. Si ce commutateur est désactivé, il est impossible d’établir une 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 ce commutateur est désactivé, les utilisateurs ne peuvent pas établir de connexions actives aux modèles sémantiques Power BI. Le bouton Apporter des modifications à ce modèle n’est donc pas accessible.
• 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.

Par ailleurs, 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 cette option soit activée par défaut, sa désactivation empêchera effectivement les utilisateurs de publier de nouveaux modèles composites sur des modèles sémantiques Power BI vers le service.

Les rapports existants qui exploitent un modèle composite sur un modèle sémantique Power BI continueront de fonctionner et les utilisateurs pourront toujours créer le modèle composite en utilisant Desktop, mais ne seront pas en mesure de 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 verrez apparaître 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. Cependant, vous ne pourrez pas publier le rapport sur le service. Lorsque vous publierez le rapport et le modèle, vous verrez le message d’erreur suivant et la publication sera bloquée :

Notez que 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. Elles continueront à fonctionner même si le commutateur a été désactivé. En outre, tous les rapports publiés qui exploitent un modèle composite sur un modèle sémantique Power BI continueront de fonctionner même si le commutateur a été 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 doit disposer 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, consultez 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 s’affiche vous indiquant 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 la vue Rapport, le bouton Make changes to this model (Apporter des modifications à ce modèle) se trouve dans l’onglet Modélisation. Dans la vue Modèle, le bouton se trouve dans l’onglet Accueil.

La sélection du bouton affiche une boîte de dialogue confirmant l’ajout d’un modèle local. Sélectionnez Ajouter un modèle local pour permettre la création de nouvelles colonnes ou la modification des métadonnées, pour les champs de modèles sémantiques Power BI ou Analysis Services. L’image suivante montre la boîte de dialogue qui s’affiche.

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 dans 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 jeux de données Power BI, une caractéristique qui n’était pas possible auparavant.

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.

Lorsque vous publiez un nouveau rapport (et un modèle sémantique) appelé Ventes et budget Europe basé sur le modèle sémantique Power BI Ventes et budget publié par votre collègue, en y apportant des modifications ou en y ajoutant des extensions, vous ajoutez en fait un rapport et un modèle sémantique à une chaîne de 3 éléments, qui commence par le modèle Analysis Services Ventes et se termine par votre modèle sémantique Power BI Ventes et budget Europe. L’image suivante illustre ce processus de chaînage.

La chaîne représentée dans l’image précédente se compose de trois éléments, ce qui correspond à 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 qui accèdent à des rapports à l’aide d’un modèle composite doivent disposer des autorisations appropriées pour tous les modèles et modèles sémantiques de la chaîne.

Le propriétaire du modèle composite nécessite l’autorisation de génération 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écessitent 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 nécessitent généralement des autorisations de lecture sur le modèle composite 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.

Les autorisations nécessaires peuvent être illustrées avec l’exemple suivant :

• 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 de génération sur le modèle sémantique B pour permettre aux utilisateurs d’afficher le rapport à l’aide du 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 de génération sur le modèle sémantique D pour permettre aux utilisateurs d’afficher le rapport à l’aide du 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 à l’aide du 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 à l’aide du 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.

Remarque

Consultez ce billet de blog pour obtenir des informations importantes sur les autorisations nécessaires pour les modèles composites basés sur des modèles sémantiques Power BI et des modèles Analysis Services.

Si un jeu de données contenu dans 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 jeu de données contenu dans 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 jeux de données contenus dans la chaîne se trouvent sur des capacités Premium ou une capacité Fabric F64 ou supérieure, un utilisateur peut y accéder en utilisant une Licence gratuite.

Avertissement de sécurité

L’utilisation de la fonctionnalité DirectQuery pour les modèles sémantiques Power BI et Analysis Services affiche une boîte de dialogue d’avertissement de sécurité, comme le montre l’image suivante.

Les données peuvent être envoyées d’une source de données vers une autre, ce qui génère le même avertissement de sécurité pour combiner DirectQuery et importer des sources dans un modèle de données. Pour en savoir plus sur ce comportement, consultez 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 :

• Connexion à des données provenant de diverses sources : importation (telles que des fichiers), modèles sémantiques Power BI, modèles Analysis Services
• Création de relations entre différentes sources de données
• Écriture de mesures qui utilisent des champs de différentes sources de données
• Création de nouvelles colonnes pour les tables à partir de modèles sémantiques Power BI ou de modèles Analysis Services
• Création de visuels utilisant des colonnes de différentes sources de données
• Vous pouvez supprimer une table de votre modèle à partir de la liste des champs. Cela vous aide à conserver les modèles aussi concis que possible (si vous vous connectez à une perspective, vous ne pouvez pas supprimer les tables du modèle)
• Vous pouvez choisir les tables à charger, plutôt que de charger toutes les tables, lorsque vous avez uniquement besoin d’un sous-ensemble spécifique de tables. Consultez Chargement d’un sous-ensemble de tables plus loin dans ce document.
• Vous pouvez spécifier les tables qui devront être ensuite ajoutées au modèle sémantique après l’établissement de 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, toutes les informations d’identification doivent être définies.

• 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 sont établies à l’aide de l’authentification unique. L’authentification avec un principal de service n’est pas actuellement prise en charge.

• Des règles RLS seront appliquées à la source sur laquelle elles sont définies, mais elles ne seront pas appliquées à d’autres modèles sémantiques du modèle. Les règles RLS définies dans le rapport ne seront pas appliquées aux sources distantes, et celles définies sur des sources distantes ne seront pas appliquées à d’autres sources de données. En outre, vous ne pouvez pas définir de sécurité au niveau des lignes (RLS) sur une table chargée depuis une source distante, et la sécurité au niveau des lignes définie sur des tables locales ne filtre pas les tables chargées depuis une source distante.

• Les indicateurs de performance clés, la sécurité au niveau des lignes et les traductions ne seront 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 cliquant sur la flèche vers le bas dans le nom du champ, puis en cliquant sur le nom de ce champ au lieu d’utiliser 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.

• Un indicateur de type décourager le chaînage peut être défini 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é.

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

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 n'est actuellement pas prise en charge.
• La publication d’un rapport sur le web à l’aide de la fonction de publication 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 tables calculées ne sont pas prises en charge dans le service qui utilise cette fonctionnalité. Si vous tentez d’effectuer une actualisation sur un modèle sémantique avec une table calculée ou une colonne calculée qui fait référence à une source de données de requête directe, le message d’erreur « Les informations d’identification d’authentification unique (SSO) ne sont pas fournies » s’affiche.
• Si vous renommez un espace de travail après que la connexion DirectQuery a été établie, vous devrez mettre à jour la source de données dans Power BI Desktop pour que le rapport continue à 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 l’article Actualisation automatique des pages dans Power BI.
• La prise en charge d’un modèle sémantique qui utilise la fonctionnalité DirectQuery sur d’autres modèles sémantiques n’est actuellement pas prise en charge.
• 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.

Il existe d’autres éléments à prendre en compte lors de l’utilisation de DirectQuery pour les modèles sémantiques Power BI et Analysis Services :

• 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

Tout modèle avec une connexion DirectQuery à un modèle sémantique Power BI ou à Analysis Services doit être publié dans le même locataire, ce qui est particulièrement important en cas d’accès à un modèle sémantique Power BI ou à un modèle Analysis Services avec des identités d’invité B2B, comme illustré dans le diagramme suivant. Consultez Utilisateurs invités pouvant modifier et gérer du contenu pour rechercher l’URL de locataire en vue de la publication.

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

Dans le diagramme, Ash utilise 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 hébergé dans le locataire de Fabrikam.

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

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

Dans ce scénario, le modèle Analysis Services utilisé étant hébergé dans le locataire de Fabrikam, le rapport doit également être publié dans ce locataire. 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 des objets (OLS) permet aux créateurs de modèles de masquer les objets qui composent le schéma de modèle (à savoir, les tables, colonnes, métadonnées, etc.) pour les consommateurs de modèles (par exemple, un générateur de rapports ou l’auteur d’un 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. Il ne peut pas être défini pour un modèle composite basé sur le modèle source.

Lorsqu’un modèle composite est créé sur un modèle sémantique Power BI protégé par OLS ou un modèle Analysis Services via une connexion DirectQuery, le schéma de modèle du modèle source est copié dans le modèle composite. Ce qui est copié dépend de ce que l’auteur du modèle composite est autorisé à voir dans le modèle source conformément aux règles d’OLS qui s’y appliquent. Les données elles-mêmes ne sont pas copiées dans le modèle composite. Elles sont toujours récupérées 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 d’OLS, les objets que les consommateurs du modèle composite voient sont ceux que l’auteur du modèle composite peut voir dans le modèle source plutôt que ceux auxquels ils peuvent avoir accès. Cela peut entraîner les situations suivantes

• 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 première puce, 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 a publié 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 contient 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 financier 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.
• Les règles d’OLS ne peuvent pas être définies sur le modèle composite lui-même.
• Le consommateur d’un modèle composite ne verra jamais les données réelles qu’il n’est pas censé voir, car les règles d’OLS pertinentes sur le modèle source les bloquent lorsque DIrectQuery essaie 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

Quand vous vous connectez à un modèle sémantique Power BI ou à un modèle Analysis Services à l’aide d’une connexion DirectQuery, vous pouvez choisir les tables auxquelles vous souhaitez 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 contiendra toutes les tables figurant dans le modèle sémantique ou le modèle, et toutes les tables non incluses dans la perspective seront masquées. En outre, toute table susceptible d’être ajoutée à la perspective sera 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 ou au modèle après avoir configuré la connexion.

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

Remarque

Cette boîte de dialogue s’affiche uniquement si vous ajoutez à un modèle existant une connexion DirectQuery à un modèle sémantique Power BI ou à un modèle Analysis Services. Vous pouvez également ouvrir cette boîte de dialogue en remplaçant la connexion DirectQuery par le modèle sémantique Power BI ou le 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 décidé d’ajouter « (marketing) » en tant que suffixe à n’importe quelle table ou nom de mesure en conflit avec une autre source dans le modèle composite. Notez que vous pouvez :

• entrez un texte à ajouter au nom des tables ou des mesures en conflit
• spécifier si vous souhaitez que le texte soit ajouté au nom de la table ou de la mesure en tant que préfixe ou suffixe
• appliquer la règle de déduplication aux tables, aux mesures ou aux 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 de source marketing qui n’a pas de doublon dans la source vente ne verra pas son nom modifié.

Après avoir établi les connexions et configuré la règle de déduplication, votre liste de champs affiche à la fois « Client » et « Client (marketing) », selon 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 avez spécifiées ne résolvent pas le conflit de nom, 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. En cas de conflit de noms sur la table « Client », l’une des tables « Client » sera renommée « Client 2 ».

Considérations et limitations

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

Connexions en mode mixte : lors de l’utilisation d’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 disposer d’un mappage de passerelle établi pour que les éléments 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 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.

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