Déterminer quand développer un modèle DirectQuery

  • 9 minutes

Un modèle DirectQuery comprend des tables dont la propriété de mode de stockage est définie sur DirectQuery, et qui appartiennent au même groupe source.

Un groupe source est un ensemble de tables de modèle qui se rapportent à une source de données. Il en existe deux types :

  • Importer : représente toutes les tables du mode de stockage Importer, y compris les tables calculées. Il ne peut y avoir qu’un seul groupe source d’importation dans un modèle.
  • DirectQuery : représente toutes les tables du mode stockage DirectQuery qui se rapportent à une source de données spécifique.

Notes

Un modèle Importer et un modèle DirectQuery ne comprennent qu’un seul groupe source. Quand il existe plusieurs groupes sources, l’infrastructure de modèle est appelée modèle composite. Les modèles composites sont décrits dans l’Unité 5.

Avantages du modèle DirectQuery

Le développement d’un modèle DirectQuery offre plusieurs avantages.

Modéliser des sources de données volumineuses ou changeant rapidement

Un modèle DirectQuery est un excellent choix d’infrastructure lorsque vos données sources présentent certaines caractéristiques de volume et/ou de vélocité. Les tables DirectQuery ne nécessitant pas d’actualisation, elles sont bien adaptées aux magasins de données volumineux, comme un entrepôt de données. Il est peu pratique et inefficace, voire impossible, d’importer un entrepôt de données entier dans un modèle. Lorsque les données sources changent rapidement et que les utilisateurs doivent voir les données actuelles, un modèle DirectQuery peut fournir des résultats de requête en quasi-temps réel.

Quand un rapport interroge un modèle DirectQuery, Power BI transmet ces requêtes à la source de données sous-jacente.

Diagram shows a star schema DirectQuery model. When a Power B I report queries the model, Power B I passes those queries to the underlying data source, in this case an Azure S Q L Database.

Appliquer la RLS source

DirectQuery est également utile lorsque la base de données source applique la sécurité au niveau des lignes (RLS). Au lieu de répliquer des règles RLS dans votre modèle Power BI, la base de données source peut appliquer ses règles. Cette approche ne fonctionne que pour certaines bases de données relationnelles, et implique la configuration de l’authentification unique pour la source de données du jeu de données. Pour plus d’informations, consultez Azure SQL Data Warehouse avec DirectQuery.

Restrictions de souveraineté des données

Si votre organisation dispose de stratégies de sécurité qui restreignent les données quittant ses locaux, il n’est pas possible d’importer des données. Un modèle DirectQuery qui se connecte à une source de données locale peut être approprié. (Vous pouvez également envisager d’installer Power BI Report Server pour les rapports locaux.)

Créer des jeux de données spécialisés

En règle générale, le mode DirectQuery prend en charge les sources de base de données relationnelle. Cela est dû au fait que Power BI doit traduire des requêtes analytiques en requêtes natives que la source de données comprend.

Toutefois, il existe une exception puissante. Vous pouvez vous connecter à un jeu de données Power BI (ou modèle Azure Analysis Services) et le convertir en modèle local DirectQuery. Un modèle local est un terme relatif qui décrit la relation d’un modèle à un autre. Dans ce cas, le jeu de données d’origine est un modèle distant et le nouveau jeu de données est le modèle local. Ces modèles sont chaînés, ce qui est le terme utilisé pour décrire des modèles associés. Vous pouvez chaîner jusqu’à trois modèles de cette façon.

Cette capacité à chaîner des modèles sous-tend le potentiel de personnaliser et/ou d’étendre un modèle distant. La chose la plus simple à faire est de renommer des objets, comme des tables ou des colonnes, ou d’ajouter des mesures au modèle local. Vous pouvez également étendre le modèle avec des colonnes ou des tables calculées, ou ajouter de nouvelles tables Importer ou DirectQuery. Toutefois, ces extensions entraînent la création de nouveaux groupes sources, ce qui signifie que le modèle devient un modèle Composite. Ce scénario est décrit dans l’Unité 5.

Pour plus d’informations, consultez Utilisation de DirectQuery pour les jeux de données Power BI et Azure Analysis Services.

Limitations du modèle DirectQuery

Il existe de nombreuses limitations liées aux modèles DirectQuery que vous devez garder à l’esprit. Voici les principales :

  • Toutes les sources de données ne sont pas prises en charge. En règle générale, seuls des systèmes de base de données relationnelle majeurs sont pris en charge. Les jeux de données Power BI et modèles Azure Analysis Services sont également pris en charge.

  • Toutes les transformations Power Query (M) ne sont pas possibles, car ces requêtes doivent se traduire en requêtes natives que les systèmes sources comprennent. Par exemple, il n’est pas possible d’utiliser des transformations pivot ou unpivot.

  • Les performances des requêtes analytiques peuvent être lentes, en particulier si les systèmes sources ne sont pas optimisés (avec des index ou des vues matérialisées), ou si les ressources sont insuffisantes pour la charge de travail analytique.

  • Les requêtes analytiques peuvent avoir un impact sur les performances du système source. Cela pourrait conduire à une expérience plus lente pour toutes les charges de travail, y compris les opérations OLTP.

Améliorer les performances du modèle DirectQuery

Quand il existe une justification pour développer un modèle DirectQuery, vous pouvez atténuer certaines limitations de deux façons.

Optimisations de source de données

Vous pouvez optimiser la base de données source pour vous assurer que la charge de travail de requête analytique attendue s’effectue correctement. Plus précisément, vous pouvez créer des index et des vues matérialisées, et vous assurer que la base de données dispose de ressources suffisantes pour toutes les charges de travail.

Conseil

Nous vous recommandons de travailler toujours en collaboration avec le propriétaire de la base de données. Il est important qu’il comprenne la charge de travail supplémentaire qu’un modèle DirectQuery peut faire peser sur sa base de données.

Tables d’agrégation définies par l’utilisateur DirectQuery

Vous pouvez ajouter des tables d’agrégation définies par l’utilisateur à un modèle DirectQuery. Les tables d’agrégation définies par l’utilisateur sont des tables de modèle spéciales masquées (aux utilisateurs, aux calculs et à RLS). Elles fonctionnent de façon optimale quand elles satisfont des requêtes analytiques de grain supérieur sur des tables de faits volumineuses. Lorsque vous définissez la table d’agrégation pour utiliser le mode de stockage DirectQuery, elle peut interroger une vue matérialisée dans la source de données. Vous pouvez également définir une table d’agrégation pour utiliser le mode de stockage Importer ou activer des agrégations automatiques, et ces options sont décrites dans l’Unité 4.

Pour plus d’informations, consultez l’Aide sur le modèle DirectQuery dans Power BI Desktop.