在上一篇笔记中我已经说了如何利用FM自带的机制配合我们已经通过验证的用户空间的组来实现行级数据安全的控制，但是由于上一个方法存在的缺点是以后如果对该对象增加基于用户或者角色的访问权限就需要开发人员去FM模型添加操作，这样就大大的增加了我们系统的维护成本,下面我们就来说一下另外一种方法：基于用户级别的中间表机制实现行级数据安全
ps:这种方法命名只是笔者的一种定义说法，属个人想法而已，各位千万不要拿来铭记,重要的是过程，至于名字，就让他随风飘吧.
下面我们就走入正题，如何利用基于用户级别的中间表机制来实现行级数据安全管理呢?
1：定义权限标准
也就是说在定义行级数据安全的时候，我们是根据部门还是根据产品类型来定义数据安全的。比如我们让属于不同部门的用户访问属于自己部门的数据，总经理可以访问所有部门的数据，再比如我们让不同产品类型的经销商访问自己销售产品类型的数据，让区域经理访问所属区域销售的所有产品类型的数据等等。而在实际的操作中，上面所提的部门、产品类型、区域划分等等在报表设计的过程中就体现为一张维度表。在本文中，我们把部门作为一个权限标准。
--1.1下面给出部门表(pdept)的结构
字段解析：部门key、部门名称 根据需要自定义即可
2：设计基于用户的中间表用户部门表
表(access_table)结构如下图所示
字段解析：username来自CJP认证中的用户表中的username、departid来自pdept
3:在FM中创建关联关系
--3.1创建事实表和权限标准直接的多对一关系（pdept 1:n product）
--3.2创建事实表和用户部门表之间的多对一关系（access_table 1:n product）
--3.3给用户部门表添加过滤器，此步骤很重要
代码解析：[physical layer].[ACCESS_TABLE].[USERNAME] =#sq($account.personalInfo.userName)#
#sq($account.personalInfo.userName)#表示利用会话参数取到当前用户的username
经过以上操作，保存模型，发布到cognos connection。
4：在设计报表的查询中添加明细过滤器
如下图所示
该步骤主要是让用户部门中间表和分析中的部门维度关联起来，实现用户级别的部门ID过滤，然后和部门维度进行关联，这就起到了
只显示和用户相关部门的数据的作用.在以后的管理中我们只要管理好access_table用户和部门之间的关系，给该报表添加数据访问新
用户的时候，在页面维护access_table表即可.
5:查看效果
--5.1：使用用户名为zhangsan的用户登录，可以看到张三信托一、二、三部门的数据都可以访问
--5.2：使用用户名为lisi的用户登录，可以看到李四只可以看到信托一部的数据
--5.3：使用用户名为test切具有管理员权限的用户登录，可以看到测试用户没有访问此报表的权限(因为test没有在access_table中分配任何权限)
测试用户：
查看结果：
ps:从5.3可以看出此种设置数据权限的方法只依赖于用户部门表access_table，和用户是否是管理员无关，当然我们如果想给管理员所有权限的话，增加管理员的所有权限到access_table即可，比如在access_table中增加下面的三条记录，测试用户就可以访问这个报表的所有数据了.
test 1
test 2
test 3
6：优缺点分析
--6.1优点
此方法可以保证在以后给该报表增加访问用户的时候不在修改FM模型即可，提供一个简单的界面维护access_table用户部门中间表即可
--6.2缺点
个人认为这种基于用户级别的操作比较繁琐，每次增加一个用户都要维护access_table，用户过多就会有些麻烦
--6.3期待
可以根据本文的思路，去设计一个基于角色的，让具体的每一个角色可以访问那些部门的数据，然后用户只要维护用户和角色之间的关系即可，本质上也是功能分配给角色，然后角色分配给用户，这样只要角色还在，就可以基于该角色添加多个用户。
