Mode DirectQuery dans les modèles tabulaires
S’applique à :
SQL Server Analysis Services Azure Analysis Services Fabric/Power BI Premium
Cet article décrit le mode DirectQuery pour les modèles tabulaires Analysis Services aux niveaux de compatibilité 1200 et supérieurs. Le mode DirectQuery peut être activé pour les modèles que vous concevez dans Visual Studio, ou pour les modèles tabulaires qui ont déjà été déployés, vous pouvez passer au mode DirectQuery à l’aide de SQL Server Management Studio (SSMS). Avant de choisir le mode DirectQuery, il est important de comprendre les avantages et les limitations.
Avantages
Par défaut, les modèles tabulaires utilisent un cache mémoire pour stocker et interroger les données. Quand les modèles tabulaires interrogent des données en mémoire, même les requêtes complexes peuvent être extrêmement rapides. Toutefois, l’utilisation des données mises en cache présente certaines limitations, par exemple, les jeux de données très volumineux peuvent dépasser la mémoire disponible et le traitement (actualisation) des données de modèle en mémoire peut nécessiter des quantités excessives de ressources disponibles si nécessaire fréquemment.
DirectQuery permet de passer outre ces limites tout en exploitant les fonctionnalités SGBDR qui peuvent rendre l’exécution des interrogations plus efficace. Avec DirectQuery :
Les données sont à jour. Étant donné que les données sont toujours interrogées au niveau de la source de données, les applications de création de rapports client obtiennent toujours les données les plus récentes.
Il n’y a pas de surcharge de gestion supplémentaire liée à la maintenance d’une copie distincte des données (dans le cache en mémoire). Aucun traitement (actualisation) des données de modèle n’est nécessaire. Les modifications apportées aux données sources sous-jacentes peuvent être immédiatement reflétées dans des requêtes sur le modèle de données.
Les jeux de données peuvent être plus volumineux que la capacité de mémoire d’une ressource serveur Analysis Services.
DirectQuery peut tirer parti de l’accélération des requêtes côté fournisseur, telle que celle fournie par les index de colonne optimisés en mémoire.
La sécurité peut être appliquée par la base de données source principale à l’aide des fonctionnalités de sécurité au niveau des lignes de la base de données (vous pouvez également utiliser des règles de sécurité au niveau des lignes définies dans le modèle à l’aide de DAX).
Si le modèle contient des formules complexes qui peuvent nécessiter plusieurs requêtes, Analysis Services peut procéder à une optimisation pour garantir que le plan de requête pour la requête exécutée sur la base de données principale est aussi efficace que possible.
Limites
Les modèles tabulaires en mode DirectQuery présentent certaines limitations. Avant de changer de mode, déterminez si les avantages de l’exécution des requêtes sur le serveur principal l’emportent sur toute réduction des fonctionnalités. Si vous modifiez le mode d’un modèle existant dans Visual Studio, le concepteur de modèles tabulaires vous informera de toutes les fonctionnalités de votre modèle qui ne sont pas compatibles avec le mode DirectQuery. Gardez à l’esprit les limitations suivantes :
| Fonctionnalité | Restriction |
|---|---|
| Sources de données | Les modèles DirectQuery peuvent utiliser uniquement des données d’une base de données relationnelle unique des types suivants : Azure SQL Database, Azure Synapse Analytics, SQL Server, Oracle et Teradata. |
| Procédures stockées SQL | Pour les modèles DirectQuery, les procédures stockées ne peuvent pas être spécifiées dans une instruction SQL pour définir des tables. |
| Tables calculées | Les tables calculées ne sont pas prises en charge dans les modèles DirectQuery, au contraire des colonnes calculées. Si vous essayez de convertir un modèle tabulaire qui contient une table calculée, une erreur se produit indiquant que le modèle ne peut pas contenir de données collées. |
| Limites de requête | La limite de lignes par défaut est d’un million de lignes. Vous pouvez augmenter cette limite en spécifiant MaxIntermediateRowSize. Pour en savoir plus, consultez Propriétés DAX. |
| Formules DAX | Lors de l’interrogation d’un modèle tabulaire en mode DirectQuery, Analysis Services convertit les formules DAX et les définitions de mesure en instructions SQL. Les formules DAX contenant des éléments qui ne peuvent pas être convertis en syntaxe SQL retournent des erreurs de validation sur le modèle. Cette restriction est principalement limitée à certaines fonctions de table DAX. Pour les mesures, les formules DAX sont converties en opérations de basées sur des jeux par rapport à la base de données relationnelle. Cela signifie que toutes les mesures créées implicitement sont prises en charge. Quand une erreur de validation se produit, vous devez réécrire la formule en utilisant une autre fonction, ou utiliser des colonnes dérivées dans la source de données comme solution de contournement. Si un modèle tabulaire inclut des formules contenant des fonctions incompatibles, il est signalé lorsque vous passez en mode DirectQuery dans le concepteur. Remarque : Certaines formules du modèle peuvent être validées lorsque vous basculez le modèle en mode DirectQuery, mais retournent des résultats différents lorsqu’elles sont exécutées sur le cache et sur le magasin de données relationnelles. Cela est dû au fait que les calculs sur le cache utilisent la sémantique du moteur d’analyse en mémoire, qui contient des fonctionnalités destinées à émuler le comportement d’Excel, tandis que les requêtes sur les données stockées dans la source de données relationnelles utilisent la sémantique de SQL. |
| Cohérence des formules | Dans certains cas, la même formule peut retourner différents résultats dans un modèle mis en cache comparé à un modèle DirectQuery qui utilise uniquement la banque de données relationnelle. Ces différences sont une conséquence des différences sémantiques entre le moteur d’analyse en mémoire et la source de données. |
| Limitations de MDX | Aucun nom d’objet relatif. Tous les noms d’objet doivent être complets. Aucune instruction MDX pour une session (jeux nommés, membres calculés, cellules calculées, valeur totale affichée, membres par défaut, etc.), mais vous pouvez utiliser des constructions à l’échelle de la requête, telles que la clause ’WITH’. Aucun tuple avec des membres de différents niveaux dans ses clauses de sous-sélection MDX. Aucune hiérarchie définie par l’utilisateur. Aucune requête SQL native des (en règle générale, Analysis Services prend en charge un sous-ensemble T-SQL, mais pas pour des modèles DirectQuery). |
Connexion à une source de données
Lors de la conception d’un modèle DirectQuery dans Visual Studio, la connexion à une source de données et la sélection des tables et des champs à inclure dans votre modèle sont pratiquement identiques à celles des modèles en mémoire.
Si vous avez déjà activé DirectQuery mais que vous ne vous êtes pas encore connecté à une source de données, vous pouvez utiliser Obtenir des données (ou l’Assistant Importation de données pour les sources de données de fournisseur héritées) pour vous connecter à une source de données, sélectionner des tables et des champs, etc. La différence sera qu’une fois terminé, aucune donnée ne sera réellement importée vers le cache en mémoire.
Si vous avez déjà utilisé Obtenir des données pour importer des données, mais que vous n’avez pas encore activé le mode DirectQuery, dans ce cas, le cache en mémoire est effacé.
Ajout d’exemples de données à un projet de modèle DirectQuery
Par défaut, lorsque vous utilisez le Concepteur de modèles tabulaires dans Visual Studio (SSDT) pour concevoir un projet de modèle tabulaire DirectQuery, la base de données de l’espace de travail du modèle ne contient pas de données. Il existe une partition par défaut pour chaque table et cette partition dirige toutes les requêtes vers la source de données. Depuis l’introduction de DirectQuery, le concepteur de modèles tabulaires inclut une fonctionnalité Définir en tant qu’exemple dans le Gestionnaire de partitions. Cette fonctionnalité permet d’ajouter une partition de copie à des tables qui peuvent être utilisées pour importer une petite quantité d’exemples de données dans la base de données de l’espace de travail. Cette fonctionnalité est destinée à aider à valider les décisions de modélisation sans impacter la source de données.
Important
Actuellement, la fonctionnalité Définir en tant qu’exempledans le concepteur de modèles tabulaires n’est pas prise en charge. Ignorez table <TableName> ne contient pas d’exemple de partition ; pour utiliser des données dans SSDT, ajoutez un exemple d’avertissements de partition .
Déploiement de modèles DirectQuery
Les modèles DirectQuery sont déployés de la même façon que les modèles d’importation. Toutefois, contrairement aux modèles d’importation, si un modèle DirectQuery contient des éléments calculés tels que des colonnes calculées ou des groupes de calcul, après avoir été déployé, vous devez effectuer un calcul de processus sur toutes les tables. Pour plus d’informations, consultez Traiter une base de données, une table ou une partition.
Voir aussi
Activer le mode DirectQuery dans Visual Studio
Activer le mode DirectQuery dans SSMS
Définir des partitions dans les modèles DirectQueryTester un modèle en mode DirectQuery
Sources de données prises en charge dans Azure Analysis Services
Sources de données prises en charge dans SQL Server Analysis Services modèles tabulaires 1400 et versions ultérieures.