在讨论新建的角色到底是如何影响OALP数据库的XMLA代码之前，我们首先对SSAS中的Role做一番简单说明。下面是角色编辑界面的一个截图，虽然它有7个选项配置界面(不讨论挖掘结构界面)，但实际上所有的都可以归类到3个种类中：
1. 读取定义的权限
具有该种权限的人可以连接到OLAP数据库，然后它会看到数据库级别的维度以及Cube，但是除此之外它无法做其他事情
2. 处理数据库的权限
具有该权限的人可以Process多维数据库对象，但是无法查看数据，因为Process数据库首先需要看到数据库对象，所以一般会同时将读取定义及处理的权限同时赋给需要处理权限的角色
3. 读取数据的权限
具有该权限的人可以读取OLAP数据库对象的数据，OLAP数据库具有数据的对象其实只有维度跟CUBE，所以所谓的数据读取权限就是Cube数据跟维度数据。下面数字1标示的选项窗口允许我们在相应对象的最粗粒度上设置权限，Cube的话就是用户是否可以访问某个Cube的数据，对于维度来说就是用户是否可以访问某个维度的数据；而数字2标示的选项窗口允许我们在细粒度上控制权限，对Cube来说可以控制到某个Cube的Cell数据，对于维度来说可以控制到某个维度的某个Hierarchy甚至是某个Hierarchy的某个Member：
维度数据的访问权限有个比较绕的方面，因为维度首先是属于OLAP数据库的，我们称为OLAP Dimension，但是每个Cube又会引用所使用的OLAP维度，所以Cube级别也有Cube Dimension的概念，所以对于维度及维度成员权限的设置都可以再这两个级别上设置，如下图所示的。
通过上面的说明就会明白为什么在选了”Readdefinition”选项后，数据库级别的维度访问权限无法再设置了，因为Read definition规定了用户可以看到所有的数据库维度(只是看到有这个维度，但是不一定可以查看维度的数据)，所以维度选项窗口无法更改这一点。
我们假设当前的OLAP数据库中有一个名为OLAPINFOR的Cube，它有一个Date维度一个Partition维度。如果现在查看Cube的XMLA脚本，里面没有任何关于权限的代码。
然后首先我们创建一个名为CommonUser，然后为其附上ReadDefinition权限，并在Cube选项卡中将Read权限付给该角色：
然后现在查看Cube的XMLA脚本，会发现脚本中多出了一个<CubePermissions>标签，其中的每个<CubePermission>表示一个角色，对于当前的具有Read该Cube权限的CommonRole角色，它的内容如下：
然后我们在Cell Data界面配置做一下修改，然后查看Cube的XMLA脚本，就会发现在CubeDimension标签下面多了一个CellPermissions标签：
我们在维度选项窗口来设置该角色只能看到Partition维度，正如前面说的我们可以在数据库度或Cube维度级别上设置这种权限，如果是数据库维度的话，它会影响维度的XMLA角色而对Cube的脚本没有任何影响，我们会在Partition维度的XMLA脚本中发现下面一段：
如果我们设置的是OLAPINFOR这个Cube的Partition维度的访问权限的话，我们会在该Cube的XMLA脚本中发现如下代码：
对于维度成员的设置也是如此，如果是数据库维度成员的设置则影响相应的数据库维度XMLA脚本，如果是Cube的维度成员的设置则影响Cube的XMLA脚本。
原文地址：http://yubowang.blog.51cto.com/8929119/1562459
