日子过得好苦逼，我过的很好，只是缺少￥.时间在变，而问题始终未变，你解不解决它都在那里一动不动.不知不觉已经发现手机的中央，电脑的右下角已经出现了201411的字样，突然从桌子上爬起来，差点忘记了自己还是一个上进的人，吹了几分钟牛逼了，接下来我们还是开始说一说这次的问题吧，往下看你会很快看到解决问题的方法的哦........
在本系列文章的第3篇文章中我们已经在6.3的扩展中写下了这么一段话，接下来我们先熟悉一下
--6.3扩展--------------------------------------------------------------------------------------------------------------------------------------------------------------------------
当然，随着业务的扩展，权限指标可能会多起来，不仅仅局限于部门,也可能是产品类型、所属区域等等,这样的话我们可以考虑在access_role增加一个字段比如下面的结构
只是在设计报表的时候多增加一个过滤条件即可 where accesstype=''
--6.3扩展----------------------------------------------------------------------------------------------------------------------------------------------------------------------------
熟悉了上篇文章的思路，那么接下来我们进入正题吧.
[1]：问题分析
在本系列的文章2、3中我们实现了基于用户、角色配置表的行级数据安全，可以通过在FM之外控制访问数据的权限,但是配置表的结构都只是针对一个权限标准的，那就是部门，而在实际的场景中这个就显得很单薄。
实际的工作中我们可能遇到这样的情况：
1：分析数据中存在产品表product、部门表pdept、产品类型表ptype
2：有三个用户分别是king、zhangsan、test
3：king可以访问‘信托一部’和‘信托二部’的数据，并且产品类型只能为‘单一’的数据
4：zhangsan只可以访问‘信托二部’的数据，并且产品类型只能为‘集合’的数据
5：test没有权限访问此数据
[2]：解决问题
毫无疑问，在文章3中的办法是可以解决这个问题的，接下来我们就说一下具体的步骤
--2.1创建拥有多个权限指标的数据安全配置表，如下图
字段解释：
roleid:来自CJP认证中的角色id
accessid:来自分析数据中的维度表的id
accesstype:判断accessid的类型，是来自部门维度还是来自产品类型维度，即我们所说的权限指标类型
--2.2在FM物理层中改写已导入的维度表
a:改写部门表查询主题定义处的sql脚本
b:改写产品类型表查询主题定义处的sql脚本
c:主要代码解析
(1):ACCESS_TABLE.ACCESSTYPE='产品类型' --过滤为产品类型的id
(2):#sq(CAMIDList())# like '%'||ACCESS_TABLE.ROLEID||'%'--从配置表中过滤出所有当前登录用户所拥有角色的所有维度id
(3):#sq(CAMIDList())#--利用宏函数取出当前登录用户所拥有的所有权限的id
d:保证所有维度表和事实表已经建立了正常的1:n关系
本文中不在多说，所指为
pdept 1:n product
ptype 1:n product
--2.3在cognos connection门户中设计报表
a:设计报表界面，随意拖拉出一个交叉表的层次即可
b：设计无数据提示界面,红圈的地方是设置无数据时页面提醒的，具体配置如下
解析：1处选中3的地方就显示高级了，2的地方选择为空时显示页面4的地方下面可以放一个提示图片或者自定义一些提示文字都可以.
c:设计查询，如下图
解释：与此系列的第2、3篇文章不同的是，查询这里就是拖拉之后的查询效果，没有添加任何任何维度和access_table之间的关系,因为关系已经在维度表
的sql中指定好了，详情请看2.a
[3]:查看效果
--3.1权限关系分析
执行下列语句，来了解一下每一个角色的权限
123456789101112131415select r1.role_id,r1.role_name,r1.deptname,r2.typename from(select r.role_id,r.role_name,d.deptname from access_table ainner join cognos.org_role r on a.roleid=r.role_idinner join wxj.pdept d on a.accessid=d.deptkey and a.accesstype='部门'group by r.role_id,r.role_name,d.deptname) r1inner join(select r.role_id,r.role_name,t.typename from access_table ainner join cognos.org_role r on a.roleid=r.role_idinner join wxj.ptype t on a.accessid=t.typekey and a.accesstype='产品类型'group by r.role_id,r.role_name,t.typename) r2 on r1.role_name=r2.role_name and r1.role_id=r2.role_idorder by r1.role_id
结果为：
又因在CJP认证中:
用户king对应的角色id为10000,
用户zhangsan对应的角色id为10001，
用户test对应的角色id为10004
所以king可以访问信托一、信托二部且产品类型为单一的数据
所以zhangsan可以访问信托二部且产品类型为集合的数据.
所以test无权访问此数据，因为test所对应的角色id-1004为在access_table中做任何配置
ps:如果一个报表中同时存在多个权限指标，要想让一个角色拥有看到此报表数据的权限，则
需要在access_table中同时给出这多个权限指标的全部或者部分关联关系，比如报表有部门、
又有类型，则需要至少给此角色一个部门对关系一个类型对应关系.才有可能让用户看到数据,
当然这一切都是根据报表的结构而言的.
--3.2登录测试
a:用户king(国王)登录，查看数据，ok
b:用户zhangsan(张三)登录，查看数据，ok
c:用户test(测试)登录，查看数据，ok
[4]：优缺点比较
--4.1优点
a:考虑的比较周全,可以在一张配置表设计多种权限指标多层级的、更详细的、针对每一个维度的数据权限控制
b:无需为每一个权限指标都创建一张类似access_table的表
c:无需在每一个报表设计界面的明显过滤器中添加维度id和accessid的对应关系
d:无需对access_table本身设置过滤器
e:无需对access_table和事实表创建关联关系，在维度层实现权限控制.
access_table只是在重写维度sql时用到了，本身和FM模型没有什么关系，模型只要保持维度和事实表的1：n关系就好了
--4.2缺点
a:需要对一个配置表维护多个字段设置多个行,比如:给一个角色新增访问权限，就需要考虑多个权限指标是否都要配置关系
而且还需要指定该accessid的所属维度类型.
-----------------至此为止------------------
Framework数据安全系列文章我想可以告一段落了