Rôles (SSAS Tabulaire)

Les rôles, dans les modèles tabulaires, définissent des autorisations de membre pour un modèle. Chaque rôle contient des membres, par nom d’utilisateur Windows ou par groupe Windows et des autorisations (lecture, processus, administrateur). Les membres du rôle peuvent effectuer des actions sur le modèle comme défini par l’autorisation de rôle. Les rôles définis avec des autorisations de lecture peuvent également fournir une sécurité supplémentaire au niveau des lignes à l’aide de filtres au niveau des lignes.

Les informations contenues dans cette rubrique sont destinées aux auteurs de modèles tabulaires qui définissent des rôles à l’aide de la boîte de dialogue Gestionnaire de rôles dans SQL Server Data Tools (SSDT). Les rôles définis pendant la création de modèle s’appliquent à la base de données de l’espace de travail du modèle. Une fois qu’une base de données de modèle a été déployée, les administrateurs de base de données de modèle peuvent gérer (ajouter, modifier, supprimer) des membres de rôle à l’aide de SQL Server Management Studio. Pour en savoir plus sur la gestion des membres des rôles dans une base de données déployée, consultez Rôles de modèle tabulaire (SSAS Tabulaire)

La modélisation tabulaire (didacticiel Adventure Works) inclut des informations et des leçons supplémentaires sur l’utilisation de cette fonctionnalité.

Sections de cette rubrique :

• Présentation des rôles

• Autorisations

• Filtres de lignes

• Test des rôles

• Tâches associées

Présentation des rôles

Les rôles sont utilisés dans Microsoft SQL Server Analysis Services pour gérer la sécurité pour Analysis Services et les données. Il existe deux types de rôles dans Analysis Services :

• Rôle serveur, rôle fixe qui fournit l’accès administrateur à une instance d’Analysis Services.

• Rôles de base de données, rôles définis par les auteurs de modèles et les administrateurs pour contrôler l’accès à une base de données et données de modèle pour les utilisateurs non administrateurs.

Les rôles définis pour un modèle tabulaire sont des rôles de bases de données. Autrement dit, les rôles contiennent des membres constitués d’utilisateurs ou de groupes Windows disposant d’autorisations spécifiques qui définissent l’action que ces membres peuvent entreprendre sur la base de données de modèle. Un rôle de bases de données est créé en tant qu’objet distinct dans la base de données et s’applique uniquement à la base de données dans laquelle il est créé. Les utilisateurs windows et/ou les groupes Windows sont inclus dans le rôle par l’auteur du modèle, qui, par défaut, dispose des autorisations d’administrateur sur le serveur de base de données de l’espace de travail ; pour un modèle déployé, par un administrateur.

Les rôles dans les modèles tabulaires peuvent être définis avec des filtres de lignes. Les filtres de lignes utilisent des expressions DAX pour définir les lignes d’une table et toutes les lignes associées dans les nombreuses directions qu’un utilisateur peut interroger. Les filtres de lignes utilisant des expressions DAX ne peuvent être définis que pour les autorisations Lecture et Lecture et Traitement. Pour plus d’informations, consultez Filtres de lignes plus loin dans cette rubrique.

Par défaut, lorsque vous créez un projet de modèle tabulaire, le projet de modèle n'a aucun rôle. Les rôles peuvent être définis à l’aide de la boîte de dialogue Gestionnaire de rôles dans SQL Server Data Tools. Lorsque les rôles sont définis lors de la création de modèles, ils sont appliqués à la base de données de l’espace de travail du modèle. Lorsque le modèle est déployé, les mêmes rôles sont appliqués au modèle déployé. Une fois qu’un modèle a été déployé, les membres du rôle serveur (Administrateur Analysis Services) et les administrateurs de base de données peuvent gérer les rôles associés au modèle et les membres associés à chaque rôle à l’aide de SQL Server Management Studio.

Autorisations

Chaque rôle dispose d’une autorisation de base de données définie unique (à l’exception de l’autorisation de lecture et de processus combinée). Par défaut, un nouveau rôle aura l’autorisation None. Autrement dit, une fois que les membres sont ajoutés au rôle avec l’autorisation None, ils ne peuvent pas modifier la base de données, exécuter une opération de processus, interroger des données ou voir la base de données, sauf si une autre autorisation est accordée.

Un groupe ou un utilisateur Windows peut être membre de n’importe quel nombre de rôles, chaque rôle disposant d’une autorisation différente. Lorsqu’un utilisateur est membre de plusieurs rôles, les autorisations définies pour chaque rôle sont cumulatives. Par exemple, si un utilisateur est membre d’un rôle avec l'autorisation Lecture, ainsi qu’un membre d’un rôle disposant d’une autorisation Aucune, cet utilisateur aura les autorisations de lecture.

Chaque rôle peut avoir l’une des autorisations suivantes définies :

Filtres de lignes

Les filtres de lignes définissent les lignes d’une table qui peuvent être interrogées par les membres d’un rôle donné. Les filtres de lignes sont définis pour chaque table dans un modèle à l'aide de formules DAX.

Les filtres de lignes peuvent être définis uniquement pour les rôles avec des autorisations de Lecture et de Lecture et processus. Par défaut, si un filtre de lignes n’est pas défini pour une table particulière, les membres d’un rôle disposant d’une autorisation Lecture ou Lecture et Processus peuvent interroger toutes les lignes de la table, sauf si le filtrage croisé s’applique à partir d’une autre table.

Une fois qu’un filtre de lignes est défini pour une table particulière, une formule DAX, qui doit évaluer une valeur TRUE/FALSE, définit les lignes qui peuvent être interrogées par les membres de ce rôle particulier. Les lignes non incluses dans la formule DAX ne peuvent pas être interrogées. Par exemple, pour les membres du rôle Sales, la table Customers avec l’expression de filtres de lignes suivante, =Customers [Country] = « USA », membres du rôle Sales, ne pourra voir que les clients aux États-Unis.

Les filtres de lignes s’appliquent aux lignes spécifiées ainsi qu’aux lignes associées. Si une table possède plusieurs relations, les filtres appliquent la sécurité de la relation qui est active. Les filtres de lignes sont croisés avec d’autres fichiers de lignes définis pour les tables associées, par exemple :

L’effet net de ces autorisations sur la table Transactions est que les membres seront autorisés à interroger des lignes de données où le client se trouve aux États-Unis, et que la catégorie de produit est vélos, et que l’année est 2008. Les utilisateurs ne pourront pas interroger des transactions en dehors des États-Unis, des transactions qui ne sont pas des vélos, ou des transactions qui n'ont pas eu lieu en 2008, sauf s'ils sont membres d'un autre rôle accordant ces autorisations.

Vous pouvez utiliser le filtre, = FALSE(), pour refuser l’accès à toutes les lignes pour une table entière.

Sécurité dynamique

La sécurité dynamique permet de définir la sécurité au niveau des lignes en fonction du nom d’utilisateur de l’utilisateur actuellement connecté ou de la propriété CustomData retournée à partir d’une chaîne de connexion. Pour implémenter la sécurité dynamique, vous devez inclure dans votre modèle une table avec des valeurs de connexion (nom d’utilisateur Windows) pour les utilisateurs, ainsi qu’un champ qui peut être utilisé pour définir une autorisation particulière ; par exemple, une table dimEmployees avec un ID de connexion (domaine\nom d’utilisateur) ainsi qu’une valeur de service pour chaque employé.

Pour implémenter la sécurité dynamique, vous pouvez utiliser les fonctions suivantes dans le cadre d’une formule DAX pour renvoyer le nom d’utilisateur de l’utilisateur actuellement connecté ou la propriété CustomData dans une chaîne de connexion :

Vous pouvez utiliser la fonction LOOKUPVALUE pour retourner des valeurs pour une colonne dans laquelle le nom d’utilisateur Windows est identique au nom d’utilisateur retourné par la fonction USERNAME ou une chaîne retournée par la fonction CustomData. Les requêtes peuvent ensuite être restreintes lorsque les valeurs retournées par LOOKUPVALUE correspondent aux valeurs de la même table ou associée.

Par exemple, à l’aide de cette formule :

='dimDepartmentGroup'[DepartmentGroupId]=LOOKUPVALUE('dimEmployees'[DepartmentGroupId], 'dimEmployees'[LoginId], USERNAME(), 'dimEmployees'[LoginId], 'dimDepartmentGroup'[DepartmentGroupId])

La fonction LOOKUPVALUE retourne des valeurs pour la colonne dimEmployees[DepartmentId] où le dimEmployees[LoginId] est identique à l’ID de connexion de l’utilisateur actuellement connecté, retourné par USERNAME et les valeurs de dimEmployees[DepartmentId] sont identiques aux valeurs de dimDepartmentGroup[DepartmentId]. Les valeurs de DepartmentId retournées par LOOKUPVALUE sont ensuite utilisées pour restreindre les lignes interrogées dans la table dimDepartment et toutes les tables associées par DepartmentId. Seules les lignes où DepartmentId se trouvent également dans les valeurs de DepartmentId retournées par la fonction LOOKUPVALUE sont retournées.

dimEmployees

dimDepartment

Test des rôles

Lors de la création d’un projet de modèle, vous pouvez utiliser la fonctionnalité Analyser dans Excel pour tester l’efficacité des rôles que vous avez définis. Dans le menu Modèle du concepteur de modèles, lorsque vous cliquez sur Analyser dans Excel, avant l’ouverture d’Excel, la boîte de dialogue Choisir les informations d’identification et perspective s’affiche. Dans cette boîte de dialogue, vous pouvez spécifier le nom d’utilisateur actuel, un nom d’utilisateur différent, un rôle et une perspective avec laquelle vous allez utiliser pour vous connecter au modèle d’espace de travail en tant que source de données. Pour plus d’informations, consultez Analyser dans Excel (SSAS Tabulaire).

Tâches associées

Voir aussi

Perspectives (SSAS Tabulaire)
Analyser dans Excel (SSAS Tabulaire)
USERNAME, fonction (DAX)
LOOKUPVALUE, fonction (DAX)
CUSTOMDATA, fonction (DAX)