通用用户权限系统设计

做了n多的MIS系统，很久以前就有这种想法，想把MIS系统中的用户权限管理和审批流管理独立出来，做成单独的组件，但是因为各种各样的原因，都没有去做，也许是太懒了。今天终于痛下决心，一定要把这两个东西给做成组件，说干就干。因为代码还没有写完，今天暂时就把数据库设计发上来，等代码搞好了，并且把代码搞的好看点后，我以后可能会把这个权限管理组件和审批流管理组件开源。

今天暂时就看权限管理系统的数据库表设计吧。子系统表，因为我这里设计的为了能够集成公司内部以后所有的系统的，所以建了子系统这张表，如果单个项目，这张表可以去掉。

模块表，系统中的各个模块。

模块功能表，模块中的各个功能（可以有两种功能，一种是页面的进入权限，一种是页面上的按钮事件）

用户表

角色表

用户分组表

用户部门表

用户权限表（也可以直接对用户赋予权限）

角色权限表（对角色赋予权限）

用户和分组关系表（一个用户可以属于多个分组）

用户和角色关系表（一个用户可以拥有多个角色）

用户分组和角色关系表（一个分组可以拥有若干角色）

非常抱歉，在前几天发的那篇《通用用户权限系统设计》中，文字描述没有表达清楚我的意思，草草的贴出了数据库的表设计，请园子里的朋

友见谅。现在我针对一些朋友提的意见做一些回答，已经把上篇文章中缺少的页面怎么控制的部分，补上去。

首先回答几个主要的问题：

1、一个人是否可以在多个部门？

我这里的设计是不能在多个部门的。虽然我想现实中一个人属于多个部门的情况实存在的，但是在我们的系统里面可以把他放到一个部门里，也不会造成问题，因为我这里的部门仅仅只是让人家看这个用户是属于哪个部门的，跟权限没有关系。权限只跟角色和所属用户组有关系。

2、角色和用户组是否已经重复了？

刚开始我也这么觉得过，后来考虑了再三，并且在网上搜了一些资料，还是留下来了。事实上用户组和角色区别比较小，我自己说不清楚，我借用IT难民的这篇文章《用户、用户组、角色的区别和联系 》来做回答，可能更容易说明问题一点。

3、页面控制权限到底怎么做的？

这个别急好吗，我下面会详细解释。也有朋友问道会不会判断权限会不会频繁读取数据库，我的回答是不会的，在用户登录的时候，我就把所有权限放到session里面，用到的时候，直接判断，不会跟数据库打交道。

4、关于数据的权限控制？

我原来做这个设计的时候，就没有考虑要设计数据权限控制，所以在我这里设计里面这个需求是做不到的。可能都怪我“通用”这个词语吧，其实我的本意是大部分MIS系统都能拿来用的功能权限控制。也有些朋友提到，我的用户表字段肯定是不行的，还有把子系统表去掉等等。我想我这个权限系统只有权限控制部分是可以公用的，用户表肯定每个系统都不一样。好了，回答了朋友们的问题。接下来，我相对完整的讲讲我这个权限控制的思路吧，包括页面级怎么控制功能。

1、权限定义

其实也有朋友提到，权限定义和权限控制是需要分开的，其实我也是这么想的，我们可以把权限定义做成一个专门的工具，最好不要集成在用户系统里面。

我们一起来看看需要定义哪些信息。子系统编号，模块编号，功能编号（用于控制树型菜单是否显示），功能名称，描述，页面名称（用于控制页面是否能够进入），按钮名称(用于控制功能按钮是否可用)（不好意思，上次弄的时候，把这个字段弄丢了）

2、给用户或者角色赋予权限；

3、在用户登录的时候，把用户所属角色，用户组，用户本身的权限都取出来，放到一起，存到session里面中去。

4、在我们的页面基类里面重写onload方法，在里面写上判断权限的代码。判断当前用户的session中是否有访问该页面的权限（没有权限则弹出提示，并且返回到请求页），以及该页面上的按钮（没有权限则置为不可用）

5、在导航树型菜单里面，把当前用户没有的菜单项去掉（其实就是功能编号）

6、这样的话，相当于把权限控制全部封装到基类里面了，业务模块不需要关心权限问题，只需要把做好的业务模块的权限注册到权限表中去就可以了（第1步）。大概就这样子说吧，如果说的还明白，请朋友们跟贴。代码暂时还没有弄好，特别是页面，比较麻烦，最近时间也不是很多，请大家见谅。

 

-------------------

通用数据权限管理系统设计（一）

 

作者：逸云

 

前言：

 本文提供一种集成功能权限和数据权限的解决方法，以满足多层次组织中权限管理方面的集中控制。本方法是RBAC（基于角色的访问控制方法）的进一步扩展和延伸，即在功能权限的基础上增加数据权限的管理，实现数据权限和功能权限的集中处理。

 

解释：

 功能权限：能做什么的问题，如增加销售订单；

 数据权限：能在哪里干什么的问题，如察看北京分公司海淀销售部张三的销售订单；

 

术语：

 资源：系统中的资源，主要是各种业务对象，如销售单、付款单等；

 操作类型：对资源可能的访问方法，如增加、删除、修改等；

 功能：对资源的操作，是资源与操作类型的二元组，如增加销售单、修改销售单等；

 数据类型：业务系统中常用的数据权限类型，如公司、部门、项目、个人等；

 数据对象：具体的业务对象，如甲公司、乙部门等等，包括所有涉及到数据权限的对象值；

 权限：角色可使用的功能，分角色的功能权限和角色的数据权限；

 角色：特定权限的集合；

 用户：参与系统活动的主体，如人，系统等。

 

 

通用数据权限管理系统设计（二）

 

方法说明：

 在实际应用中，数据权限的控制点一般相对固定，如针对公司、部门、个人、客户、供应商等，也就是说数据权限一般针对指定数据类型下的一些数据对象。

 

 本方法中，数据权限的依赖于功能权限，是对功能权限的进一步描述，说明角色在指定的功能点上的数据控制权限。

本方法中采用“没有明确规定即视为有效”的原则，如果没有定义功能的数据权限，则说明该角色具有该功能的全部的权限。如果定义了功能的某种类型的数据权限，则该用户只具有该类型下指定数据的数据权限。

 

 这段话比较绕口，下面举个例子实际例子。

 

 某公司有北京销售部、上海销售部和广州销售部三个销售部，现在需要定义几种角色：

    销售总监      -- 能察看所有销售部的销售订单；

    北京销售经理 -- 只能察看北京销售部的所有销售订单；

    上海销售经理 -- 只能察看上海销售部的所有销售订单；  

    广州销售经理 -- 只能察看广州销售部的所有销售订单；  

 

 上述角色的定义如下：

 

     -------------------------------------------------------------------

     角色名称             功能             数据类型     数据对象  

     -------------------------------------------------------------------

     销售总监           察看销售订单                                 

     北京销售经理       察看销售订单         部门         北京  

     上海销售经理       察看销售订单         部门         上海     

     广州销售经理       察看销售订单         部门         广州     

     -------------------------------------------------------------------

 

    上述定义中，销售总监只定义了功能权限，而没有定义数据权限，所以销售总监能够察看所有的销售订单；而其他几位销售经理分别定义了这一功能的数据权限，所以只能察看指定部门的销售订单。

 

     在实际应用中，往往会出现部门分组，组长能够察看本组所有人员处理的销售订单的情况，以及某些情况下，某些人只能察看本人的销售订单的情况，这些特殊情况在上述的说明中无法解决，需要在设计和实现中进行处理。

 

 

    北京销售代表 -- 只能察看北京销售部的本人的所有销售订单；  

     北京销售代表         察看销售订单           部门            北京     

                                                 个人                  

 

 

通用数据权限管理系统设计（三）--数据库设计

 

我们先来看看传统的基于角色的权限管理系统，如下图所示，最简单的基于角色的权限管理由系统功能、系统角色、系统用户、角色功能和用户角色五部分组成。

    图一：基于角色的数据库结构

为实现数据权限控制，在设计上对基于角色的权限管理进行扩充，如下图所示：

 

图二：通用数据权限管理系统数据库设计

对比两张图，我们可以看到，他们之间的主要变化为：

1、 增加系统资源信息和操作类型信息，系统资源为树形结构、如销售模块、销售订单等；操作类型记录可能的操作，如增加、删除、修改、查看、查询等，系统功能是资源与操作类型的组合，对资源的操作就是系统功能。

2、 增加数据对象类型和数据对象两张表，数据对象类型记录系统中需要控制的对象类型，如部门、库房、员工、客户、供应商等；数据对象记录各对象类型的对象实例，如北京销售部、上海销售部、张三、李四等等。（独立保存的好处后面会说到）

3、 增加系统资源与数据对象类型的关联表（多对多），本表为配置表，说明某种资源可能需要的控制点，如销售订单与部门类型的关联可能涉及到分部门分配权限；销售订单与客户的关联可能涉及到按客户分配权限等等。

4、 增加数据对象与角色权限的关联，这张表是真正最终实现数据权限管理的所在地。

 

通过这种设计，能够最小化地减少对原有权限系统的更改，并且可以很灵活地增加数据的控制点。在产品化软件的设计中使用，能够灵活满足客户的需要。

 

下一篇文章将讨论这种结构如何满足第二部分功能需求的问题，如果时间允许，将对程序的设计做进一步阐述。

 

本设计方法已应用于自行开发的通用供应链管理系统中，欢迎指正。