The impact of the SSAS role on XMLA

Introduction to Roles

Before discussing how the newly created role affects the XMLA code of the Oalp database, we start with a brief description of role in SSAS. Here is one of the character editing interfaces, although it has 7 options to configure the interface (not to discuss the mining structure interface), but in fact all can be categorized into 3 categories:

1. Read the defined Permissions

Someone with that permission can connect to the OLAP database, and then it sees the database-level dimension and the cube, but otherwise it can't do anything else

2. Handling permissions for a database

A person with this permission can process a multidimensional database object, but cannot view the data because the process database first needs to see the database object, so the read definition and processing permissions are also assigned to the role that needs to handle permissions at the same time

3. Permission to read data

The person with this permission can read the OLAP database object data, the OLAP database has the data object actually only the dimension and the cube, so so-called data Read permission is the cube data and the dimension data.

The following number 1 indicates the option window allows us to set permissions on the maximum granularity of the corresponding object, cube is whether the user can access a cube's data, for the dimension is the user can access a dimension of data, and the number 2 marked by the option window allows us to control the fine granularity of permissions, For the cube, you can control the cell data for a cube, and for a dimension you can control one of the hierarchy of a dimension or even some member of a hierarchy:

The access rights of the dimension data have a relatively round aspect, because the dimension first belongs to the OLAP database, we call OLAP Dimension, but each cube references the OLAP dimension used, so the cube level also has the concept of cube Dimension, So settings for dimension and dimension member permissions can be set at these two levels, as shown in.

The above instructions will understand why the database-level dimension access is no longer set after the "Read definition" option is selected because the read definition specifies that the user can see all the database dimensions (just see this dimension, However, the Dimension Options window cannot be changed because the dimension's data is not necessarily viewable.

Impact of roles on XMLA

We assume that the current OLAP database has a cube named Olapinfor, which has a date dimension of one partition dimension. If you look at the XMLA script for cube Now, there is no code for permissions.

Cube and Cell permissions

We then first create a named Commonuser, and then attach read definition permissions to it, and in the Cube tab, pay the Read permission to the role:

Now look at the XMLA script for the cube, and you'll find an extra <CubePermissions> tag in the script, where each <CubePermission> represents a role, For the current commonrole role with the Read cube permission, its contents are as follows:

Then we make a change in the cell data interface configuration and then look at the XMLA script of Cube, and we find a cellpermissions tag underneath the cubedimension tag:

Dimension and dimension member permissions

We set the role in the dimension Options window to see only the partition dimension, as we said earlier, we can set this permission at the database degree or cube dimension level, and if it is a database dimension, it affects the XMLA role of the dimension and has no effect on the cube's script. We will find the following paragraph in the XMLA script in the partition dimension:

If we set Olapinfor access to the cube's partition dimension, we will find the following code in the cube's XMLA script:

The same is true for dimension members, and if the setting for a database dimension member affects the corresponding database dimension XMLA script, the setting of the dimension member for cube affects the XMLA script of Cube.

The impact of the SSAS role on XMLA