Scénarios d’utilisation de Power BI : gestion avancée des modèles de données

Notes

Cet article fait partie de la série d’articles sur la planification de l’implémentation de Power BI. Cette série se concentre principalement sur la charge de travail Power BI au sein de Microsoft Fabric. Pour une introduction à la série, consultez Planification de l’implémentation de Power BI.

Ce scénario d’utilisation est axé sur la gestion avancée des modèles de données, c’est-à-dire lorsqu’un créateur de contenu Power BI s’appuie sur un outil tiers pour développer, gérer ou optimiser des modèles de données. Certains outils tiers sont des outils externes, que Power BI Desktop prend en charge directement. Vous pouvez également gérer un modèle de données publié (modèle sémantique, précédemment appelé « jeu de données ») en communiquant directement avec le point de terminaison XMLA dans le service Power BI.

Les modèles de données sont hébergés dans le service Power BI, dans Azure Analysis Services (AAS) ou dans SQL Server Analysis Services (SSAS). Ce scénario d’utilisation est axé sur l’utilisation du point de terminaison XMLA dans le service Power BI.

Conseil

De nombreuses personnes font référence aux outils tiers comme des outils externes. Toutefois, il existe des distinctions dans la façon dont différents outils peuvent être utilisés. La connexion à un modèle de données local dans Power BI Desktop est l’interprétation la plus littérale du terme outil externe. Ce scénario d’utilisation de gestion avancé des modèles de données est axé sur la connexion à un modèle de données distant (un modèle sémantique hébergé dans le service Power BI) à l’aide du point de terminaison XMLA. Vous trouverez plus d’informations sur les différentes façons d’utiliser des outils tiers plus loin dans cet article.

Vous pouvez obtenir une connectivité à un modèle de données à l’aide du protocole XML for Analysis (XMLA). Le protocole XMLA est un protocole standard du secteur pris en charge par plus de 25 fournisseurs, notamment Microsoft. Tous les outils, y compris les outils tiers, conformes au protocole XMLA utilisent des bibliothèques de client Microsoft pour lire et/ou écrire des données dans un modèle de données. La connectivité est obtenue avec un point de terminaison XMLA, qui est une API exposée par un modèle de données qui étend les fonctionnalités de développement et de gestion disponibles pour les créateurs de modèles sémantiques.

Remarque

Ce scénario d’utilisation de gestion avancée des modèles de données est l’un des scénarios de gestion et de déploiement de contenu. Pour obtenir la liste complète des scénarios d’utilisation en libre-service, consultez Scénarios d’utilisation de Power BI.

Par souci de concision, certains aspects décrits dans la rubrique Scénarios de collaboration et de distribution de contenu ne sont pas abordés dans cet article. Pour une couverture complète, lisez d’abord ces articles.

Schéma du scénario

Le focus de ce scénario d’utilisation de gestion avancée des modèles de données consiste à utiliser l’Éditeur tabulaire pour gérer le modèle de données. Vous pouvez publier un modèle de données sur le service Power BI à l’aide du point de terminaison XMLA, disponible avec Power BI Premium.

Important

Cet article fait parfois référence à Power BI Premium ou à ses abonnements de capacité (références SKU P). Sachez que Microsoft regroupe actuellement des options d’achat et met hors service les références SKU Power BI Premium par capacité. Les clients nouveaux et existants doivent plutôt envisager l’achat d’abonnements de capacité Fabric (références SKU F).

Pour plus d’informations, consultez Importante mise à jour à venir des licences Power BI Premium et FAQ sur Power BI Premium.

Conseil

Nous vous recommandons de passer en revue le scénario d’utilisation de publication de contenu en libre-service si vous n’êtes pas familiarisé avec celui-ci. Le scénario de gestion avancée des modèles de données s’appuie sur ce scénario.

Remarque

Parfois, les termes modèle sémantique et modèle de données sont utilisés de manière interchangeable. Généralement, du point de vue du service Power BI, on parle de modèle sémantique. Du point de vue du développement, c’est le terme modèle de données (ou simplement modèle) qui est employé. Dans cet article, les deux termes ont le même sens. De même, un créateur de modèle sémantique et un modélisateur de données ont la même signification.

Le diagramme suivant illustre une vue d’ensemble générale des actions utilisateur et outils les plus courants qui peuvent vous aider à développer, gérer ou optimiser des modèles de données.

Conseil

Nous vous encourageons à télécharger le diagramme de scénario si vous souhaitez l’incorporer dans votre présentation, documentation ou billet de blog ou encore l’imprimer en tant qu’affiche murale. Étant donné qu’il s’agit d’une image SVG (Scalable Vector Graphics), vous pouvez la mettre à l’échelle vers le haut ou vers le bas sans aucune perte de qualité.

Le diagramme de scénario décrit les actions utilisateur, outils et fonctionnalités qui suivent :

Item	Description
	Les créateurs de modèles développent des modèles de données à l’aide de l’Éditeur tabulaire. Il est courant que le travail de conception initial (comme le travail Power Query) soit effectué dans Power BI Desktop avant de passer à l’Éditeur tabulaire (non représenté dans le diagramme de scénario).
	Le modèle de données se connecte aux données d’une ou plusieurs sources de données.
	Certaines sources de données peuvent nécessiter une passerelle de données locale ou une passerelle de réseau virtuel pour l’actualisation des données, comme celles qui résident dans un réseau d’organisation privé.
	Le développement du modèle de données s’effectue dans l’Éditeur tabulaire. La modification des scripts Power Query (M) est prise en charge. Les créateurs de modèles peuvent utiliser des scripts C# pour accélérer le développement.
	Une fois qu’il est prêt, les créateurs de modèles sémantiques publient le modèle de données de l’Éditeur tabulaire vers le service Power BI à l’aide du point de terminaison XMLA de l’espace de travail cible.
	Le modèle de données est publié dans un espace de travail dédié au stockage et à la sécurisation de modèles sémantiques partagés. L’accès à l’espace de travail à l’aide du point de terminaison XMLA n’est possible que lorsque le mode de licence de l’espace de travail est défini sur capacité Fabric, capacité Premium, Premium par utilisateur ou Incorporé.
	Les créateurs de rapports créent des rapports à l’aide d’une connexion active au modèle sémantique partagé.
	Les créateurs de rapports créent leurs rapports dans Power BI Desktop. Outre la séparation entre les rapports et les modèles sémantiques, les créateurs de contenu suivent le processus de création de rapport classique.
	Lorsqu’ils sont prêts, les créateurs de rapports publient leur fichier Power BI Desktop (.pbix) ou leur fichier projet Power BI (.pbip) dans le service Power BI.
	Les rapports sont publiés dans un espace de travail dédié au stockage et à la sécurisation des rapports et des tableaux de bord.
	Les rapports publiés restent connectés au modèle sémantique partagé qui est stocké dans un espace de travail différent. Toutes les modifications apportées au modèle sémantique partagé affectent tous les rapports dépendants.
	Les outils tiers peuvent utiliser le point de terminaison XMLA pour interroger le modèle sémantique partagé. D’autres outils compatibles XMLA, tels que DAX Studio, Semantic Link des notebooks Fabric ou Windows PowerShell, peuvent être utilisés pour interroger ou mettre à jour le modèle sémantique partagé. Power BI Desktop, Excel et Report Builder peuvent également se connecter à l’aide du point de terminaison XMLA (non représenté dans le diagramme de scénario).
	D’autres outils Microsoft et tiers peuvent utiliser le point de terminaison XMLA pour gérer le modèle sémantique et assurer la gestion du cycle de vie des applications. Pour plus d’informations, consultez Outils clients basés sur un point de terminaison XMLA.
	Les administrateurs Fabric gèrent le paramètre de locataire pour activer l’utilisation du point de terminaison XMLA. L’administrateur doit activer le point de terminaison XMLA pour les capacités Fabric, les capacités Premium et les paramètres Premium par utilisateur.
	Les administrateurs de structure supervisent et surveillent l’activité dans le portail Fabric.

Points clés

Voici quelques points clés à souligner concernant le scénario de gestion avancée des modèles de données.

Applications et outils tiers

Les équipes BI Entreprise utilisent généralement des outils clients, tels que l’Éditeur tabulaire (illustré dans le diagramme de scénario et décrit dans la rubrique suivante), pour les aider à gérer les modèles sémantiques centralisés. Toutefois, tout créateur de modèle sémantique qui souhaite utiliser des fonctionnalités de modélisation avancée peut tirer parti des méthodes décrites dans ce scénario d’utilisation.

Il existe plusieurs façons d’utiliser des applications tierces :

• Se connecter à un modèle de données distant à l’aide du point de terminaison XMLA : certains outils tiers peuvent se connecter directement à un modèle de données distant dans le service Power BI (ou Analysis Services). Une fois la connexion au point de terminaison XMLA établie, toutes les opérations de modèle objet tabulaire (TOM) sont prises en charge. Cette approche est le principal objet de ce scénario d’utilisation.
• Se connecter à un modèle de données local dans Power BI Desktop : certains outils tiers peuvent se connecter à un modèle de données local ouvert dans Power BI Desktop (non représenté dans le diagramme de scénario). Toutefois, il existe certaines limitations, et les fonctionnalités des outils externes ne sont pas toutes officiellement prises en charge.
• Se connecter à un fichier de modèle dans Power BI Desktop : certains outils tiers distribuent leurs fonctionnalités de manière allégée à l’aide d’un fichier de modèle Power BI Desktop (.pbit) (non représenté dans le diagramme de scénario).

Éditeur tabulaire

L’Éditeur tabulaire est représenté dans le diagramme de scénario. Il s’agit d’un outil tiers qui est aujourd’hui largement adopté par la communauté Power BI. Voici quelques avantages offerts par la gestion des modèles de données tabulaires avec l’Éditeur tabulaire :

• Configuration de fonctionnalités de modèle de données non prises en charge dans Power BI Desktop : l’Éditeur tabulaire fournit une interface permettant de configurer une sécurité au niveau de l’objet, des groupes de calcul, des perspectives, des traductions et des partitions.
• Prise en charge du développement de modèle simultané : les outils de développement de modèle de données Microsoft, tels que les projets Visual Studio avec Analysis Services, stockent l’intégralité de la définition du modèle de données dans un fichier Model.bim. Avec ce fichier unique, il peut être difficile pour une équipe de développeurs de travailler ensemble sur un modèle de données unique. L’Éditeur tabulaire a une fonctionnalité nommée Sérialisation des dossiers. La sérialisation des dossiers déconstruit le fichier Model.bim en fichiers distincts propres à l’objet au sein d’une structure de dossiers organisée. Différents modélisateurs de données peuvent ensuite travailler sur différents fichiers avec moins de risque de remplacement des efforts des uns par les autres.
• Intégration avec le contrôle de code source : la sérialisation des dossiers permet au système de contrôle de code source de détecter facilement les modifications du modèle de données, ce qui facilite les fusions de sources et la résolution des conflits.
• Amélioration de la qualité et de la conception du modèle de données : L’Éditeur tabulaire s’intègre à Best Practices Analyzer (BPA). BPA aide les modélisateurs de données grâce à un ensemble de règles personnalisables qui peuvent améliorer la qualité, la cohérence et les performances des modèles de données. Vous pouvez télécharger un ensemble de règles de bonnes pratiques (fournies par Microsoft) à partir de GitHub.
• Productivité accrue lors du développement de modèles de données : l’interface de l’Éditeur tabulaire permet d’effectuer des modifications par lots et un débogage, et d’afficher les dépendances du modèle de données. L’Éditeur tabulaire est différent de Power BI Desktop car il fonctionne en mode déconnecté. Vous pouvez apporter des modifications de modèle de données en mode déconnecté, et les valider en tant que lot de modifications. Travailler de cette façon permet d’accélérer le développement et la validation, en particulier pour les modélisateurs de données expérimentés. Il est également possible de créer des scripts C# et de les enregistrer en tant que macros. Ces scripts peuvent vous aider à améliorer l’efficacité de la gestion et de la synchronisation de plusieurs modèles de données.

Point de terminaison XMLA

Le point de terminaison XMLA utilise le protocole XMLA pour exposer toutes les fonctionnalités d’un modèle de données tabulaire, y compris certaines opérations de modélisation des données qui ne sont pas prises en charge par Power BI Desktop. Vous pouvez utiliser l’API TOM pour apporter des modifications programmatiques à un modèle de données.

Le point de terminaison XMLA fournit également une connectivité. Vous pouvez vous connecter à un modèle sémantique uniquement quand le mode de licence de l’espace de travail est défini sur Premium par utilisateur, Premium par capacité ou Embedded. Une fois qu’une connexion est établie, un outil compatible XMLA peut opérer sur le modèle de données de deux façons :

• Écrire des données et des métadonnées : l’utilisation en lecture/écriture du point de terminaison XMLA autorise ce qui suit :
  • Fonctionnalités de modélisation des données qui ne sont pas prises en charge par Power BI Desktop, telles que la sécurité au niveau de l’objet (OLS), les groupes de calcul, les perspectives, les traductions et la gestion des partitions.
  • Déploiements plus complexes. Par exemple, un déploiement partiel ou un déploiement de métadonnées uniquement qui publie une seule nouvelle mesure.
  • Actualisation asynchrone du modèle sémantique. Par exemple, l’actualisation d’une table ou d’une partition unique.
• Lire des données et des métadonnées : l’utilisation en lecture seule du point de terminaison XMLA autorise ce qui suit :
  • Monitoring, débogage et suivi des modèles sémantiques et des requêtes.
  • Autoriser les outils de création de rapports de données tiers à visualiser les données provenant d’un modèle sémantique partagé. Cette technique est un excellent moyen d’étendre les avantages et les investissements dans le décisionnel en libre-service managé.

Avertissement

Une fois que vous avez modifié ou publié un modèle sémantique à l’aide du point de terminaison XMLA, vous ne pouvez plus le télécharger à partir du service Power BI en tant que fichier Power BI Desktop.

Paramètres XMLA par capacité

Chaque capacité Power BI Premium et Power BI Embedded a un paramètre pour contrôler si le point de terminaison XMLA est en lecture seule, en lecture/écriture ou désactivé. Ce paramètre est également disponible pour tous les espaces de travail Premium par utilisateur dans le locataire Power BI. L’accès XMLA en lecture/écriture doit être activé pour chaque capacité qui contient des modèles sémantiques que vous souhaitez gérer avec un outil autre que Power BI Desktop.

Conseil

Le paramètre de point de terminaison XMLA (lecture/écriture, lecture seule ou désactivé) s’applique à tous les espaces de travail et modèles sémantiques attribués à une capacité particulière. Vous pouvez configurer plusieurs capacités afin de décentraliser et/ou personnaliser la façon dont le contenu est géré pour chaque capacité.

Paramètre de locataire XMLA

Outre les paramètres de point de terminaison XMLA, un administrateur Power BI doit utiliser les paramètres de locataire pour autoriser les points de terminaison XMLA et Analyser dans Excel avec des modèles sémantiques locaux. Lorsque cette option est activée, vous pouvez autoriser tous les utilisateurs, ou des groupes de sécurité spécifiques, à utiliser la fonctionnalité de point de terminaison XMLA.

Notes

Toutes les fonctionnalités de sécurité et de protection des données standard s’appliquent toujours pour spécifier les utilisateurs qui peuvent afficher et/ou modifier du contenu.

Outils tiers

Power BI Desktop peut gérer les besoins de bout en bout pour la plupart des créateurs de contenu en libre-service. Toutefois, les outils tiers offrent d’autres fonctions et fonctionnalités d’entreprise. Pour cette raison, les outils tiers, tels que l’Éditeur tabulaire, sont aujourd’hui répandus dans la communauté Power BI, en particulier pour les créateurs de contenu avancé, les développeurs et les professionnels de l’informatique.

Conseil

Ce billet de blog décrit comment les outils tiers permettent à l’équipe de produit Power BI de réévaluer ses priorités de développement, d’augmenter la portée de la plateforme Power BI et de satisfaire les demandes plus sophistiquées et diverses de la communauté des utilisateurs.

Notes

Certains outils tiers nécessitent une licence payante, telle que l’Éditeur tabulaire 3. D’autres outils de la communauté sont gratuits et open source (tels que l’Éditeur tabulaire 2, DAX Studio et ALM Toolkit). Nous vous recommandons d’évaluer soigneusement les fonctionnalités de chaque outil, le coût et le modèle de support, afin que vous puissiez proposer un support adéquat à votre communauté de créateurs de contenu.

Gestion des modèles de données

Dans ce scénario d’utilisation, l’accent est mis sur le créateur de contenu qui utilise l’Éditeur tabulaire pour gérer un modèle de données. Pour les exigences de gestion avancée de modèles de données peu fréquentes, comme la gestion occasionnelle des partitions, vous pouvez choisir d’utiliser un outil tel que SQL Server Management Studio (SSMS). Il est également possible pour un développeur .NET de créer et de gérer des modèles sémantiques Power BI à l’aide de l’API TOM.

Conseil

Quand vous utilisez le point de terminaison XMLA pour la gestion des modèles de données, nous vous recommandons d’activer le paramètre de format de stockage de modèles sémantiques volumineux. En cas d’activation, le format de stockage de modèles sémantiques volumineux peut améliorer les performances des opérations d’écriture XMLA.

Séparation du modèle de données et des rapports

Pour que ce scénario d’utilisation réussisse, vous devez séparer les rapports du modèle de données. Cette approche implique la gestion de fichiers Power BI Desktop distincts, comme décrit dans le scénario d’utilisation du décisionnel en libre-service managé. Même si la même personne est responsable de tout le développement, la séparation des modèles sémantiques et des rapports est importante, car l’Éditeur tabulaire n’a pas connaissance du contenu du rapport.

Configuration de la passerelle

En général, une passerelle de données est nécessaire pour accéder à des sources de données qui résident dans le réseau organisationnel privé ou dans un réseau virtuel. La passerelle de données locale devient pertinente une fois qu’un modèle de données est publié sur le service Power BI. Les deux objectifs d’une passerelle sont les suivants : actualiser les données importées ou afficher un rapport qui interroge une connexion active ou un modèle sémantique DirectQuery (non représenté dans le diagramme du scénario).

Remarque

Une passerelle de données centralisée en mode standard est fortement recommandée sur les passerelles en mode personnel. En mode standard, la passerelle de données prend en charge la connexion dynamique et les opérations DirectQuery (en plus des opérations programmées d’actualisation des données).

Pour plus d’informations, consultez Passerelle de données locale (mode standard).

Supervision du système

Le journal d’activité enregistre les activités utilisateur qui se produisent dans le service Power BI. Les administrateurs Power BI peuvent utiliser les données du journal d’activité qui sont collectées pour effectuer un audit afin de mieux comprendre les activités qui se connectent via des points de terminaison XMLA.

Contenu connexe

Pour d’autres scénarios utiles qui vous aideront dans les décisions d’implémentation de Power BI, consultez l’article Scénarios d’utilisation de Power BI.