Mode DirectQuery (SSAS Tabulaire)

Analysis Services vous permet de récupérer des données et de créer des rapports à partir d’un modèle tabulaire en récupérant des données et des agrégats directement à partir d’un système de base de données relationnelle, à l’aide du mode DirectQuery. Cette rubrique présente les différences entre les modèles tabulaires standard qui résident uniquement dans la mémoire et les modèles tabulaires qui peuvent interroger une source de données relationnelle et explique comment créer et déployer un modèle à utiliser en mode DirectQuery.

Sections de cette rubrique :

• Avantages du mode DirectQuery

• Création de modèles à utiliser avec le mode DirectQuery

  • Sources de données pour les modèles DirectQuery

  • Restrictions de validation et de conception pour le mode DirectQuery

  • Compatibilité des formules pour les modèles DirectQuery

  • Sécurité en mode DirectQuery

  • Sécurité en mode DirectQuery

• Propriétés DirectQuery

• Rubriques et tâches connexes

Avantages du mode DirectQuery

Par défaut, les modèles tabulaires utilisent un cache en mémoire pour stocker et interroger des données. Étant donné que les modèles tabulaires utilisent des données qui résident en mémoire, même les requêtes complexes peuvent être extrêmement rapides. Toutefois, il existe certains inconvénients à l’utilisation de données mises en cache :

• Les données ne sont pas actualisées lorsque les données sources changent. Vous devez traiter le modèle pour obtenir des mises à jour des données.

• Lorsque vous désactivez l’ordinateur qui héberge le modèle, le cache est enregistré sur le disque et doit être rouvert lorsque vous chargez le modèle ou ouvrez le fichier PowerPivot. Les opérations d’enregistrement et de chargement peuvent prendre du temps.

En revanche, le mode DirectQuery utilise des données stockées dans une base de données SQL Server. En règle générale, vous importez l’ensemble ou un petit échantillon des données dans le cache lors de la création du modèle, et lorsque vous déployez le modèle, vous spécifiez que la source de données pour les requêtes sur le modèle doit être SQL Server, et non les données mises en cache. Toutes les requêtes DAX sur les données sont traduites par Analysis Services en instructions SQL équivalentes par rapport à la source de données relationnelle spécifiée.

Il existe de nombreux avantages pour déployer un modèle à l’aide du mode DirectQuery :

• Il est possible d’avoir un modèle sur des jeux de données trop volumineux pour tenir dans la mémoire sur le serveur des Services d'analyse.

• Les données sont garanties d’être up-to-date et il n’existe aucune surcharge de gestion supplémentaire d’avoir à conserver une copie distincte des données. Les modifications apportées aux données sources sous-jacentes peuvent être immédiatement reflétées dans les requêtes sur le modèle de données.

• DirectQuery peut tirer parti de l’accélération des requêtes côté fournisseur, par exemple celle fournie par les index de colonne à mémoire optimisée xVelocity.

• Toute sécurité appliquée par la base de données principale est garantie d’être appliquée à l’aide de la sécurité au niveau des lignes. En revanche, si vous utilisez des données mises en cache, il peut être difficile de s’assurer que le cache est sécurisé exactement comme sur le serveur.

• Si le modèle contient des formules complexes qui peuvent nécessiter plusieurs requêtes, Analysis Services peut effectuer une optimisation pour vous assurer que le plan de requête pour la requête exécutée sur la base de données principale sera aussi efficace que possible.

Création de modèles à utiliser avec le mode DirectQuery

Les modèles tabulaires sont créés à l’aide du concepteur de modèles SQL Server Data Tools (SSDT). Le concepteur de modèles crée tous les modèles en mémoire, ce qui signifie que lorsque vous modélisez, si vos données sont trop volumineuses pour s’adapter à la mémoire, vous devez importer uniquement un sous-ensemble de données dans le cache utilisé par la base de données de l’espace de travail.

Lorsque vous êtes prêt à basculer vers le mode DirectQuery, vous pouvez modifier une propriété qui active le mode DirectQuery. Pour plus d’informations, consultez Activer le mode création DirectQuery (SSAS Tabulaire).

Lorsque vous effectuez cette opération, le concepteur de modèles configure automatiquement la base de données de l’espace de travail pour qu’elle s’exécute en mode hybride, ce qui vous permet de continuer à utiliser les données mises en cache. Le concepteur de modèles vous informe également des fonctionnalités de votre modèle incompatibles avec le mode DirectQuery. La liste suivante récapitule les principales exigences à garder à l’esprit :

• Sources de données : Les modèles DirectQuery peuvent uniquement utiliser des données à partir d’une seule source de données SQL Server. Lorsque le mode DirectQuery a été activé pour un modèle, vous ne pouvez utiliser aucun autre type de données dans le concepteur de modèles, y compris les tables ajoutées par les opérations de copie-collage. Toutes les autres options d’importation sont désactivées. Toutes les tables incluses dans une requête doivent faire partie de la source de données SQL Server. Pour plus d’informations, consultez Sources de données pour les modèles DirectQuery.

• Prise en charge des colonnes calculées : Les colonnes calculées ne sont pas prises en charge pour les modèles DirectQuery. Toutefois, vous pouvez créer des mesures et des indicateurs de performance clés, qui fonctionnent sur des jeux de données. Pour plus d’informations, consultez la section sur la validation .

• Utilisation limitée des fonctions DAX : Certaines fonctions DAX ne peuvent pas être utilisées en mode DirectQuery. Vous devez donc les remplacer par d’autres fonctions ou créer les valeurs à l’aide de colonnes dérivées dans la source de données. Le concepteur de modèles fournit une validation au moment du design pour toutes les erreurs qui surviennent lorsque vous créez des formules incompatibles avec le mode DirectQuery. Pour plus d’informations, consultez les sections suivantes : Validation.

• Compatibilité des formules : Dans certains cas connus, la même formule peut retourner des résultats différents dans un modèle mis en cache ou hybride par rapport à un modèle DirectQuery qui utilise uniquement le magasin de données relationnelle. Ces différences sont une conséquence des différences sémantiques entre le moteur d’analytique en mémoire xVelocity (VertiPaq) et SQL Server. Pour plus d’informations sur ces différences, consultez cette section : Compatibilité des formules.

• Sécurité: Vous pouvez utiliser différentes méthodes pour sécuriser les modèles en fonction de la façon dont ils sont déployés. Les données mises en cache pour les modèles tabulaires sont sécurisées à l’aide du modèle de sécurité de l’instance Analysis Services. Les modèles DirectQuery peuvent être sécurisés à l’aide de rôles, mais vous pouvez également utiliser la sécurité définie dans le magasin de données relationnelle. Le modèle peut être configuré afin que les utilisateurs qui ouvrent un rapport basé sur un modèle DirectQuery uniquement puissent voir uniquement les données qui leur sont autorisées sous leurs autorisations dans SQL Server. Pour plus d’informations, consultez cette section : Sécurité.

• Restrictions du client : Lorsqu’un modèle est en mode DirectQuery, il ne peut être interrogé qu’à l’aide de DAX. Vous ne pouvez pas utiliser MDX pour créer des requêtes. Cela signifie que vous ne pouvez pas utiliser le client pivot Excel, car Excel utilise MDX.

  Toutefois, vous pouvez créer des requêtes sur un modèle DirectQuery dans SQL Server Management Studio si vous utilisez une requête de table DAX dans le cadre d’une instruction XMLA Execute. Pour plus d’informations, consultez [Référence de syntaxe de requête DAX](/dax-syntax-reference)(/dax-syntax-reference

Lorsque vous avez résolu tous les problèmes de conception et testé votre modèle, vous êtes prêt pour le déploiement. À ce stade, vous pouvez définir la méthode préférée pour répondre aux requêtes sur le modèle. Voulez-vous que les utilisateurs aient accès au cache ou utilisent toujours la source de données relationnelle ?

Si vous déployez le modèle en mode hybride, le cache est toujours disponible et peut être utilisé pour les requêtes. Un mode hybride vous offre de nombreuses options :

• Lorsque le cache et la source de données relationnelles sont disponibles, vous pouvez définir la méthode de connexion préférée, mais c'est finalement le client qui contrôle la source utilisée, en utilisant la propriété de chaîne de connexion DirectQueryMode.

• Vous pouvez également configurer des partitions sur le cache de telle sorte que la partition principale utilisée pour le mode DirectQuery n’est jamais traitée et doit toujours référencer la source relationnelle. Il existe de nombreuses façons d’utiliser des partitions pour optimiser la conception du modèle et l’expérience de création de rapports. Pour plus d’informations, consultez Partitions et mode DirectQuery (SSAS Tabulaire) .

• Une fois le modèle déployé, vous pouvez modifier la méthode de connexion par défaut. Par exemple, vous pouvez utiliser un mode hybride pour les tests et basculer le modèle vers le mode DirectQuery uniquement après avoir testé soigneusement les rapports ou requêtes qui utilisent le modèle. Pour plus d’informations, consultez Définir ou Modifier la Méthode de Connexion Préférée pour DirectQuery.

Sources de données pour les modèles DirectQuery

Dès que vous modifiez l’environnement de conception pour activer le mode DirectQuery, les sources de données de la base de données de l’espace de travail sont validées pour s’assurer qu’elles proviennent d’une seule source de données SQL Server. Les données provenant d’autres sources, y compris les données copiées, ne sont pas autorisées dans les modèles DirectQuery.

Si vous envisagez d’utiliser le modèle en mode DirectQuery, vous devez vous assurer que toutes les données dont vous avez besoin pour la création de rapports sont stockées dans la base de données SQL Server spécifiée. Si les données dont vous avez besoin pour la modélisation ne sont pas disponibles dans cette source, envisagez d’utiliser Integration Services ou d’autres outils d’entreposage de données pour importer les données dans une base de données SQL Server qui sert de source de données DirectQuery.

Restrictions de validation et de conception pour le mode DirectQuery

Lorsque vous créez un modèle à utiliser en mode DirectQuery, vous devez initialement charger une partie des données dans le cache. Si les données que vous utiliserez éventuellement sont trop volumineuses pour s’adapter à la mémoire, vous pouvez utiliser l’option Aperçu et Filtre dans l’Assistant Importation de table pour sélectionner un sous-ensemble de données, ou écrire un script SQL pour obtenir les données souhaitées.

Pour afficher et résoudre les erreurs de validation, ouvrez la liste d’erreurs dans SQL Server Data Tools. Les erreurs critiques qui empêchent l’utilisation du mode DirectQuery s’affichent sous l’onglet Erreurs . Vous devez corriger ces erreurs avant de passer au mode DirectQuery. Les erreurs de validation plus difficiles à résoudre sont généralement liées aux formules qui ne sont pas prises en charge en mode DirectQuery. Consultez la section Compatibilité des formules pour obtenir une vue d’ensemble des erreurs liées aux formules et aux colonnes calculées.

La liste suivante décrit d’autres considérations à prendre en compte lors de la création d’un modèle pour l’accès DirectQuery :

• En mode DirectQuery uniquement , les résultats d’un rapport peuvent varier en fonction du contexte de sécurité de l’utilisateur qui affiche les résultats. Vous devez tester des modèles avec des informations d’identification différentes pour vous assurer que les utilisateurs obtiennent les résultats attendus.

• Si vous configurez un modèle pour fonctionner en mode hybride, ce qui permet l’utilisation du cache ou des données de SQL Server, vous devez être conscient de la possibilité que les clients se connectant à chaque source puissent voir des résultats différents, en fonction du mode spécifié dans la chaîne de connexion. Si vous devez vous assurer que vos utilisateurs de rapports voient uniquement les données de SQL Server, vous devez effacer le cache ou modifier le modèle en DirectQueryOnly.

Compatibilité des formules pour les modèles DirectQuery

Certains modèles peuvent contenir des formules qui ne sont pas prises en charge en mode DirectQuery, et le modèle doit être repensé pour empêcher les erreurs de validation. Les restrictions sur les formules prises en charge en mode DirectQuery sont les suivantes :

• Les colonnes calculées ne sont pas prises en charge dans un modèle tabulaire sur lequel le mode DirectQuery est activé, pas même les modèles hybrides. Si vous avez besoin de colonnes calculées pour un modèle, envisagez de les convertir en colonnes dérivées à l’aide de Transact-SQL dans votre définition d’importation.

• Les modèles DirectQuery prennent en charge l’utilisation de formules DAX utilisées dans des mesures, qui sont converties en opérations basées sur des ensembles dans le store de données relationnel. Toutes les mesures que vous créez à l’aide de mesures implicites sont prises en charge.

• Toutes les fonctions ne sont pas prises en charge. Étant donné que Analysis Services convertit toutes les formules et définitions de mesures DAX en instructions SQL lors de l’interrogation d’un modèle DirectQuery, toute formule contenant des éléments qui ne peuvent pas être convertis en Transact-SQL déclenche des erreurs de validation sur le modèle. Par exemple, les fonctions Time Intelligence ne sont pas prises en charge. Même les fonctions prises en charge peuvent se comporter différemment, telles que les fonctions statistiques. Pour obtenir la liste complète des problèmes de compatibilité, consultez Compatibilité des formules en mode DirectQuery.

• 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’ils sont exécutés sur le cache par rapport au 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 xVelocity (VertiPaq), qui contient de nombreuses fonctionnalités destinées à émuler le comportement d’Excel, tandis que les requêtes sur les données stockées dans le magasin de données relationnelles utilisent nécessairement la sémantique de SQL Server. Pour obtenir la liste des fonctions DAX qui peuvent retourner des résultats différents lorsque le modèle est déployé en temps réel, consultez Compatibilité des formules en mode DirectQuery.

Connexion à des modèles DirectQuery

Les clients qui utilisent MDX comme langage de requête ne peuvent pas se connecter aux modèles qui utilisent le mode DirectQuery. Par exemple, si vous tentez de créer une requête MDX sur un modèle DirectQuery, vous obtenez une erreur indiquant que le cube est introuvable ou n’a pas été traité. Vous pouvez créer des requêtes sur des modèles DirectQuery à l’aide de Power View, de formules DAX ou de requêtes XMLA. Pour plus d’informations sur la façon dont vous pouvez effectuer des requêtes ad hoc sur des modèles tabulaires, consultez Accès aux données du modèle tabulaire.

Si vous utilisez un modèle hybride, vous pouvez spécifier si les utilisateurs se connectent au cache ou utilisent des données DirectQuery en spécifiant la propriété de chaîne de connexion, DirectQueryMode.

Sécurité en mode DirectQuery

Lors de la création de modèles, vous spécifiez les autorisations utilisées pour récupérer les données sources. Il s’agit souvent de vos propres informations d’identification ou d’un compte utilisé pour le développement. Toutefois, lorsque vous changez de modèle pour utiliser le mode DirectQuery, le contexte de sécurité est plus complexe :

• Déterminez si les utilisateurs ont le niveau d’accès nécessaire aux données dans le magasin de données relationnelles.

• Les utilisateurs qui affichent le même modèle ou rapport peuvent voir des données différentes, en fonction du contexte de sécurité de l’utilisateur.

• Si le cache du modèle a été conservé, le cache est sécurisé à l’aide du modèle de sécurité Analysis Services (rôles). Le cache peut contenir des données que le concepteur de modèles est privilégié pour voir, mais pas l’utilisateur. Les concepteurs de modèles et de rapports doivent effacer le cache ou sécuriser ces données en contrôlant l’accès via des rôles.

• Un modèle qui répond aux requêtes du cache ne peut pas emprunter l’identité de l’utilisateur actuel lors de la connexion à la source de données. Si vous souhaitez emprunter l’identité de l’utilisateur actuel lors de la connexion à la source de données, vous devez utiliser le mode DirectQuery.

• Si votre modèle de rapport nécessite une sécurité, vous avez deux options : vous pouvez utiliser des rôles Analysis Services ou définir des autorisations au niveau des lignes sur la source de données. La sécurité dans la source de données relationnelle est utilisée pour contrôler l’accès aux tables et la sécurité au niveau des colonnes n’est pas prise en charge. Par conséquent, si les utilisateurs d’une région n’ont pas l’autorisation d’afficher les chiffres de ventes provenant de différentes régions, un rapport qui inclut une mesure basée sur la table Sales retourne des vides ou une erreur.

La propriété des paramètres d’emprunt d’identité spécifie les informations d’identification utilisées pour se connecter à un modèle via DirectQuery, que ce soit pour un modèle uniquement basé sur DirectQuery ou pour un modèle hybride répondant aux requêtes avec DirectQuery. La propriété a les valeurs suivantes :

Par défaut
Utilise les informations d'identification spécifiées dans l'assistant d'importation pour se connecter à la source de données. Il peut s’agir d’un utilisateur Windows spécifique ou du compte de service.

ImpersonateCurrentUser
Utilise les informations d’identification de l’utilisateur actuel pour se connecter à la source de données.

Pour plus d’informations sur la définition de ces propriétés, consultez Scénarios de déploiement DirectQuery (SSAS Tabulaire) .

Propriétés DirectQuery

Le tableau suivant répertorie les propriétés que vous pouvez définir dans SQL Server Data Tools, et dans SQL Server Management Studio, pour activer DirectQuery et contrôler la source de données utilisée pour les requêtes sur le modèle.

En outre, si votre modèle inclut des partitions, vous devez choisir une partition à utiliser comme source pour les requêtes en mode DirectQuery. Pour plus d’informations, consultez Partitions et mode DirectQuery (SSAS Tabulaire) .

Rubriques et tâches connexes

Voir aussi

Partitions (SSAS Tabulaire)
Projets de modèle tabulaire (SSAS Tabulaire)
Analyser dans Excel (SSAS Tabulaire)