系统权限设计

 

 

一个应用系统的权限可以分为两部分：Responsibility、Position。

Responsibility实现操作员的系统功能授权，Position实现操作员的系统数据授权。

 

Responsibility：

名词解释：

       Function_Resource：系统资源，可以是URL、Button等资源。

System_Function：系统功能，是一组系统资源的组合。

 

Responsibility对应一组系统功能（System_Function），每一个系统功能对应一组系统资源（Function_Resource）。

Example：

       Responsibility_01有“固定资产管理”、“用户管理”的功能；Responsibility_02有“图书管理”、“会议管理”的功能。

       “用户管理”包含以下资源（可以理解为页面上的Button）：

Ø         用户查询

Ø         用户新增

Ø         用户删除

Ø         用户修改

“图书管理”包含以下资源：

Ø         图书查询

Ø         图书借阅

Ø         图书归还

Ø         图书挂失

“固定资产管理”、 “会议管理”也包含各自的资源，在此不一一举例。

 

       操作员01有Responsibility_01和Responsibility_02，所以他能够操作界面上：“固定资产管理”、“用户管理”、 “图书管理”、“会议管理”下面的所有Button，如：用户查询、用户新增、用户删除、用户修改、图书查询、图书借阅、图书归还、图书挂失 ……

       操作员02有Responsibility_02，所有他能够操作界面上：“图书管理”、“会议管理”下面的所有Button，如：图书查询、图书借阅、图书归还、图书挂失 ……，但是不能操作界面上的用户查询、用户新增、用户删除、用户修改。

 

       这样就从功能层面上对操作员的权限进行了控制。

 

Position：

对于一个系统权限要求很严格的系统，除了在系统功能上进行强授权控制外，还需要在数据层面上进行权限的控制。

如，一个图书管理的查询页面，用户A和用户B都要有查询的权限，可以通过Responsibility将查询的权限开放给用户A和B。但是Responsibility没有办法控制住查询的内容，即A和B要查看不同的图书信息Responsibility是没有办法控制的。

所以有些系统在业务数据上增机一个字段：Employee_ID，以实现不同的用户看到不同的数据。

但是，对于一个复杂的业务系统来说，业务需求往往不限在这样简单的模式上：

Ø         要求数据的开放实现层次结构，即上级岗位可以看到本级以及所有下级岗位的数据

Ø         业务数据不捆绑到员工，以实现在员工离职等情况下，数据迅速转移到合适人员

Ø         通过灵活、方便的模式实现调整员工对数据的访问权限

在这样的需求下，建议引进Position的概念，因为Position可以支撑上面的所有需求。下面就对Position实现以上需求的方式进行阐述。

根据DB的设计，Position实现了以下的结构：

P1下面的直接岗位为P11、P12；

P11下面的直接岗位为P111、P112

P12下面的直接岗位为P121、P122

按照这种结构，如果Employee在这些岗位上的话，数据权限的开放方式展现为：

P1能看到所有的数据

P11能看到P11、P111、P112的数据；

P12能看到P21、P121、P122的数据；

P111、P112、P121、P122能看到自己的数据。

如果员工既要看到P111的数据，又要看到P121的数据，那么将员工与P111、P121建立关系，即将员工同时放到岗位P111、P121上。

业务数据表中，不再放类似Employee这样的字段，而是创建Position列。这样每条记录都将归到一个岗位上。因为员工与岗位之间建立了关系，所以就能实现员工访问业务数据的功能。

       如上图所示，在图书表中，置Position字段，将图书与Position挂钩，而员工与Position也建立了关系，那么员工就能查询到这条记录。

       通过这种方式，实现了：

Ø         数据权限上的层次结构，对于企业来说，公司各级经理都能有与自己级别匹配的不同数据进行统计查询。

Ø         当某员工不再使用系统的时候，数据也不会因为员工的流失而流失（Book_Basic中没有放Employee，而是Position），只需要将流失的员工与Position之间的关系打断，并将合适的员工放到此岗位上，那么新员工马上就能接受这些数据。

Ø         可以灵活配置员工与岗位之间的关系，这样就实现了灵活的数据的权限控制。

 

注意点：

Ø         有些系统中可能会根据实际的业务部门关系，建立类似Department的概念，似乎与Position非常类似。但是有的时候业务上的结构关系是难以实现系统数据层面的要求的，如：部门A与部门B下面的某几个雇员，临时由部门C的经理进行业务量考核，但是保持其行政律属保持不变。这种情况下，靠Department是难以实现的，引入Position，建立ABC之间的关系，就能较为简单的解决问题。

Ø         不是所有的业务表都要放Position字段，有些完全私人的数据，如个人事务，这种表中还是建议放Employee字段。