关于权限的数据库设计

不管是在网站开发还是MIS系统开发中，涉及到多用户的软件系统都会遇到这个问题，如何比较优雅的解决这个问题也一直是大家经常探讨的热门话题，本文试着谈论一下自己的观点，希望和大家共同切磋。

方法一： 
 
用户表： 
T_UserInfo 
   id 
   name 
 
对象表: 
T_Object 
   id 
   name 
 
权限表 
T_Access 
   accessid 
   userid（外键，来自用户表） 
   objectid（外键，来自对象表） 
   access(用代码记录用户的权限组合： 
       1000  浏览 
       1100  浏览、添加 
       1110  浏览、添加、编辑 
       1111  浏览、添加、编辑、删除 
       等) 
 
方法二： 
 
用户表： 
T_UserInfo 
   id 
   name 
 
对象表: 
T_Object 
   id 
   name 
   access1(代表浏览，保存用户的id号，用逗号分隔) 
   access2(代表浏览、添加) 
   access3(代表浏览、添加、编辑) 
   access4(代表浏览、添加、编辑、删除) 
 
孰优孰劣？ 
--------------------------------------------------------------- 
 
我們用的是第一種 
WINDOWS系統用的也是第一種 
 
 
--------------------------------------------------------------- 
 
方法2不可取，用户增加的时候非常麻烦，而且access1--access4的长度很难确定。  

下面我要说的是MIS系统权限管理的数据库设计及实现，当然，这些思路也可以推广开来应用，比如说在BBS中用来管理不同级别的用户权限。

权限设计通常包括数据库设计、应用程序接口(API)设计、程序实现三个部分。

这三个部分相互依存，密不可分，要实现完善的权限管理体系，必须考虑到每一个环节可行性与复杂程度甚至执行效率。

我们将权限分类，首先是针对数据存取的权限，通常有录入、浏览、修改、删除四种，其次是功能，它可以包括例如统计等所有非直接数据存取操作，另外，我们还可能对一些关键数据表某些字段的存取进行限制。除此，我想不出还有另外种类的权限类别。

完善的权限设计应该具有充分的可扩展性，也就是说，系统增加了新的其它功能不应该对整个权限管理体系带来较大的变化，要达到这个目的，首先是数据库设计合理，其次是应用程序接口规范。

我们先讨论数据库设计。通常我们使用关系数据库，这里不讨论基于Lotus产品的权限管理。

权限表及相关内容大体可以用六个表来描述，如下：
1 角色（即用户组）表：包括三个字段，ID，角色名，对该角色的描述；
2 用户表：包括三个或以上字段，ID，用户名，对该用户的描述，其它（如地址、电话等信息）；
3 角色-用户对应表：该表记录用户与角色之间的对应关系，一个用户可以隶属于多个角色，一个角色组也可拥有多个用户。包括三个字段，ID，角色ID，用户ID；
4 限制内容列表：该表记录所有需要加以权限区分限制的数据表、功能和字段等内容及其描述，包括三个字段，ID，名称，描述；
5 权限列表：该表记录所有要加以控制的权限，如录入、修改、删除、执行等，也包括三个字段，ID，名称，描述；
6 权限-角色-用户对应表：一般情况下，我们对角色/用户所拥有的权限做如下规定，角色拥有明令允许的权限，其它一律禁止，用户继承所属角色的全部权限，在 此范围内的权限除明令禁止外全部允许，范围外权限除明令允许外全部禁止。该表的设计是权限管理的重点，设计的思路也很多，可以说各有千秋，不能生搬硬套说 某种方法好。对此，我的看法是就个人情况，找自己觉得合适能解决问题的用。

先说第一种也是最容易理解的方法，设计五个字段：ID，限制内容ID，权限ID，角色/用户类型（布尔型字段，用来描述一条记录记录的是角色权限还是用户权限），角色/用户ID，权限类型（布尔型字段，用来描述一条记录表示允许还是禁止）

好了，有这六个表，根据表六，我们就可以知道某个角色/用户到底拥有/禁止某种权限。

或 者说，这么设计已经足够了，我们完全实现了所需要的功能：可以对角色和用户分别进行权限定制，也具有相当的可扩展性，比如说增加了新功能，我们只需要添加 一条或者几条记录就可以，同时应用程序接口也无须改动，具有相当的可行性。但是，在程序实现的过程中，我们发现，使用这种方法并不是十分科学，例如浏览某 个用户所拥有的权限时，需要对数据库进行多次（甚至是递归）查询，极不方便。于是我们需要想其它的办法。使用过Unix系统的人们都知道，Unix文件系 统将对文件的操作权限分为三种：读、写和执行，分别用1、2、4三个代码标识，对用户同时具有读写权限的文件被记录为3，即1+2。我们也可以用类似的办 法来解决这个问题。初步的想法是修改权限列表，加入一个字段：标识码，例如，我们可以将录入权限标识为1，浏览权限标识为2，修改权限标识为4，删除权限 标识为8，执行权限标识为16，这样，我们通过权限累加的办法就可以轻易的将原本要分为几条记录描述的权限放在一起了，例如，假定某用户ID为1，库存表 对应的限制内容ID为2，同时规定角色类型为0、用户类型为1，我们就可以将该用户具有录入、浏览、修改、删除库存表的权限描述为：2,15,1,1。

确实很简单，不是吗？甚至还有更过激的办法，将限制内容列表也加上一列，定义好标识码，这样，我们甚至可以用简单的一条记录描述某个用户具 有的对全部内容所具有的全部权限了。当然，这样做的前提是限制内容数量比较小，不然，呵呵，2的n次方递增起来可是数量惊人，不容易解析的。

从 表面上看，上述方法足以达到实现功能、简化数据库设计及实现的复杂度这个目的，但这样做有个弊端，我们所涉及的权限列表不是相互独立而是互相依赖的，比如 说修改权限，其实是包含浏览权限的，例如，我们可能只是简单的设置用户对库存表存取的权限值为录入+修改+删除（1+4+8=13),但事实上，该用户具 有(1+2+4+8=15）的权限，也就是说，在这种方案中，13=15。于是当我们调用API询问某用户是否具有浏览权限时，就必须判断该用户是否具有 对该数据表的修改权限，因此，如果不能在程序中固化权限之间的包含关系，就不能利用应用程序接口简单的做出判断。但这与我们的目的“充分的可扩展性”矛 盾。

这个问题如何解决？我想到了另外一种设置标识码的方法，那就是利用素数。我们不妨将录入、浏览、修改、删除、执行的基本标志码定为 2,3,5,7,11，当遇到权限互相包含的时候，我们将它的标识码设定为两个（或多个）基本标志码的乘积，例如，可以将“修改”功能的标志码定为3*5 =15，然后将所有的权限相乘，就得到了我们需要的最终权限标识值。这样，我们在询问用户是否具有某项权限的时候，只需要将最终的值分解成质因子，例如， 我们可以定义一个用户具有录入+修改+删除库存表的权限为 2*15*7=2*3*5*7，即表示，该用户具有了对库存表录入+浏览+修改+删除权限。

当然，对权限列表我们使用上述方法的前提是权限列表记录条数不会太多并且关系不是十分复杂，否则，光是解析权限代码就要机器忽悠半宿：）

我 希望以上的分析是正确且有效的（事实上，我也用这些的方法在不止一套系统中实现），但无论如何，我觉得如此实现权限管理，只是考虑了数据库设计和应用程序 接口两部分内容，对于实现，还是显得很费劲。因此，我恳请有过类似设计、实现经验的同志们提出建设性的意见和修改建议。

Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=1536110

　　在设计篇中，我们已经为大家阐述了有关权限管理系统的数据库设计，在本篇中，我们将重点放在其实现代码部分。为了让你能够更直接更有效的看到全部动作的代码，我们使用“动作分解列表”的方式来陈述每个动作以及相关资源。

实现权限管理功能的动作

系统动作

详解模组：

　　1.setup(数据库初始化、权限设置模组)

　　当布署好一个新的系统后，我们可以通过执行一个动作setup来安装数据库和一些初始值，通过执行这个动作系统可以正常运行。因为执行setup这个动作时会调用到一个名称为setup的模组，这个模组的作用是初始化系统所用到的数据库，并且在系统中设置动作的权限，否则数据库和有权限的动作就没办法执行。下面我们来看一下setup模组的代码，点击这里查看代码。这里我们把代码拆分开看一下，由于setup模组里有好多类似的代码，所以这里我们只找出不同功能的代码做一下介绍：

　　第一段：数据库安装

　　在模组中首先调用了一个datebase_SQL_setup这个数据库操作集，这个数据库操作集用来为系统中的数据库表（根据情况删除或新建）做初始化。

　　第二段：添加权限信息

　　代码中调用了action_I_newone这个数据库操作集，在这个操作集中加入权限的名称和它的其它信息。

　　第三段：添加一个管理员

　　这部分代码中调用了master_I_newone数据库操作集在数据库中添加了一个管理员的信息，这个信息是可以不写在这里的，可以直接在数据库中添加，但是为了减少不必要的麻烦所以直接在这里添入了一个默认的管理员。

　　第四段：添加管理员组

　　通过调用groupmanager_I_newmaster这个数据库操作集新建了一个管理员组，并加入了详细的管理员组信息，可以把新用户加入到此管理员组。

　　第五段：添加新的工具分栏

　　通过调用actioncolumn_I_newone数据库操作集在工具栏里加入一个工具栏分栏选项。

　　第六段：指定管理组

　　通过调用mastergroup_I_newone数据库操作集把admin这个用户加入到第一个管理组里，使该用户成为第一个管理组的成员。

　　最后一段：指定管理组拥有的权限

　　这段代码首先调用了action_S_all数据库操作集并使用Loop语句列出所有的动作，然后调用actiongroup_I_newone这个数据库操作集，把所有的动作都加入到第一个管理组里，使第一个管理组拥有所有权限。

　　这里之所以把数据库的安装和权限的设置都放在模组里面，是为了使用户使用更加方便，不需要再去重新手动建库，以减不在数据库这方面的错误，使系统更加简单流畅。如果其它系统也需要权限这方面的管理，可以把模组稍做修改就可以直接拿来用，这样也体现出代码的重用性。

　　2.checkuserpurview（检验当前用户能否执行该动作的模组）

　　在权限管理系统中，模组checkuserpurview得到了反复使用，该模组担负着检测用户权限的任务，在所有需要进行访问权限控制的动作的开始部分都调用了该模组，所以理解该模组的代码也有一定难度。下面，我们来看一看该模组的代码。

　　我们将整段代码拆分一下，首先看第一段，如下图：

　　判断_SESSION.myloginid的值是否为空，如果为空，在当前页面中执行nosession这个动作。我们在用户登陆的动作中login会为登陆的用户使用myloginid的SESSION变量记录下该用户的ID，因此如果用户是正常登陆并在SESSION有效期内的话，则_SESSION.myloginid的值是不可能为空的。通过此部分代码检测用户是否已经登陆成功并获得合法的访问身份。

　　然后看下面的代码，如下图：

　　调 用数据库操作集mastergroup_S_bymasterid，使用逻辑层的Loop，使用当前执行的action以及查询返回的groupid作为 条件，调用数据库操作集actiongroup_S_byactionandgroupid进行循环查询，如果查询返回值大于0（零），将局部变量 purview的值设置为1。

　　这 段代码的重点在于使用的Loop进行循环，由于actiongroup表中记录着用户所处的管理组能够执行的权限，并且一个用户可能同时会属于多个组，因 此我们需要去检验用户属于的多个组中是否有对该动作执行的权限，因此，我们使用当前需要执行的动作action以及用户所处的管理组groupid循环查 询，当前用户所属于的组中只要有一个组具有执行该动作的执行权限，则该用户就可以执行该动作。

　　最后一部分代码如下图：

　　再次使用判断，如果purview的值不为1的话，则在当前页面执行nopurview动作。

　　由于之前的代码中，如果用户拥有执行动作的权限的话，会将局部变量purview的值设置为1，所以这里如果该变量值不为1，就说明了此用户没有执行动作的权限，故执行nopurview动作。

总结

　　从设计到实现，权限管理系统的教程到这里就全部结束了。在设计阶段，最重要也是最难理解的是那两张映射表的作用，理解了两张映射表，基本上也就理解了整套数据库的设计。而实现阶段，比较难理解的就是上面说到的模组checkuserpurview了。理解该模组，需要联合数据库设计，actiongroup表中记录着用户组可以执行的权限，使用action字段和groupid字段进行查询，返回的数大于1，说明了用户所在的组拥有执行该动作的权限。

附录

MYSQL版本权限管理系统源码下载

MSSQL版本权限管理系统源码下载

　　B/S 系统中的权限比C/S中的更显的重要，C/S系统因为具有特殊的客户端，所以访问用户的权限检测可以通过客户端实现或通过客户端+服务器检测实现，而 B/S中，浏览器是每一台计算机都已具备的，如果不建立一个完整的权限检测，那么一个“非法用户”很可能就能通过浏览器轻易访问到B/S系统中的所有功 能。因此B/S业务系统都需要有一个或多个权限系统来实现访问权限检测，让经过授权的用户可以正常合法的使用已授权功能，而对那些未经授权的“非法用户” 将会将他们彻底的“拒之门外”。下面就让我们一起了解一下如何设计可以满足大部分B/S系统中对用户功能权限控制的权限系统。

需求陈述

• 不同职责的人员，对于系统操作的权限应该是不同的。优秀的业务系统，这是最基本的功能。
• 可以对“组”进行权限分配。对于一个大企业的业务系统来说，如果要求管理员为其下员工逐一分配系统操作权限的话，是件耗时且不够方便的事情。所以，系统中就提出了对“组”进行操作的概念，将权限一致的人员编入同一组，然后对该组进行权限分配。
• 权限管理系统应该是可扩展的。它应该可以加入到任何带有权限管理功能的系统中。就像是组件一样的可以被不断的重用，而不是每开发一套管理系统，就要针对权限管理部分进行重新开发。
• 满足业务系统中的功能权限。传统业务系统中，存在着两种权限管理，其一是功能权限的管理，而另外一种则是资源权限的管理，在不同系统之间，功能权限是可以重用的，而资源权限则不能。

关于设计

　　借助NoahWeb的动作编程理念，在设计阶段，系统设计人员无须考虑程序结构的设计，而是从程序流程以及数据库结构开始入手。为了实现需求，数据库的设计可谓及其重要，无论是“组”操作的概念，还是整套权限管理系统的重用性，都在于数据库的设计。

我们先来分析一下数据库结构：

　　首先，action表（以下简称为“权限表”），gorupmanager表（以下简称为“管理组表”），以及master表（以下简称为“人员表”），是三张实体表，它们依次记录着“权限”的信息，“管理组”的信息和“人员”的信息。如下图：

　　这三个表之间的关系是多对多的，一个权限可能同时属于多个管理组，一个管理组中也可能同时包含多个权限。同样的道理，一个人员可能同时属于多个管理组，而一个管理组中也可能同时包含多个人员。如下图：

　　由于这三张表之间存在着多对多的关系，那么它们之间的交互，最好使用另外两张表来完成。而这两张表起着映射的作用，分别是“actiongroup”表（以下简称“权限映射表”）和“mastergroup”表（以下简称“人员映射表”），前者映射了权限表与管理组表之间的交互。后者映射了人员表与管理组表之间的交互。如下图：

　　另外，还需要一张表来控制系统运行时左侧菜单中的权限分栏，也就是“权限分栏表”，如下图：

　　根据上面的分析，我们进行数据库结构设计，如下图：

　　点击这里查看权限管理系统数据表字段设计

　　为了能够进行良好的分析，我们将数据库结构图拆分开来，三张实体表的作用已经很清晰，现在我们来看一下两张映射表的作用。

一 权限映射表 如下图：

　　首先，我们来了解一下权限映射表与管理组表以及权限表之间的字段关联。

　　看图中的红圈，先看gorupid字段相关联，这种关联方式在实际数据库中的表现如下图：

　　如图中所示，管理组表中“超级管理员”的groupid为1，那么权限映射表中groupid为1的权限也就是“超级管理员”所拥有的权限。

　　使用groupid字段关联，是为了查到一个管理组能够执行的权限有哪些。但这些权限的详细信息却是action字段关联所查询到的。

　　action字段相关联在数据库中的表现如下图：

　　通过这种关联，才查询到权限映射表之中那些权限的详细信息。综合起来，我们就知道了一个管理组可以执行的权限有哪些，以及这些权限的详细信息是什么。

　　或许你会问，为什么不使用actionid字段相关联呢？因为：

• 权限表中的id字段在经过多次的数据库操作之后可能会发生更改。
• 权限映射表中仅仅记录着一个管理组可以执行的权限。
• 一旦权限表中的id更改，那么权限映射表中的记录也就更改了。
• 一个管理组可以执行的权限势必将出错，这是非常不希望的。

　　考虑到上面的情况，所以应该使用action字段相关联，因为：

• 在权限表中，id可能发生变化，而action字段却是在任何情况下也不可能发生变化的。
• 权限映射表中记录的action字段也就不会变。
• 一个管理组可以执行的权限就不会出错了。

二 人员映射表 如下图：

　　我们来了解一下人员映射表与管理组表以及人员表之间的字段关联，如下图：

　　看图中的红圈部分，先看groupid字段关联，这种关联方式在数据库中的表现如下图：

　　如图，“超级管理员”组的groupid为1，我们再看人员映射表，admin属于超级管理员组，而administrator属于超级管理员组，同时也属于管理员组。

　　使用这种关联方式，是为了查到一个管理组中的人员有谁。和上面一样，人员的详细信息是靠id字段（人员映射表中是masterid字段）关联查询到的。

　　id字段（人员映射表中是masterid字段）关联表现在数据库中的形式如下图：

　　一个人员可能同时属于多个“管理组”，如图中，administrator就同时属于两个“管理组”。所以，在人员映射表中关于administrator的记录就会是两条。

　　这种关联方式才查询到管理组中人员的详细信息有哪些。综合起来，才可以知道一个管理组中的人员有谁，以及这个人员的详细信息。

　　再结合上面谈到的权限表和权限映射表，就实现了需求中的“组”操作，如下图：

　　其实，管理组表中仅仅记录着组的基本信息，如名称，组id等等。至于一个组中人员的详细信息，以及该组能够执行的权限的详细信息，都记录在人员表和权限表中。两张映射表才真正记录着一个组有哪些人员，能够执行哪些权限。通过两张映射表的衔接，三张实体表之间的交互才得以实现，从而完成了需求中提到的“组”操作。

　　我们再来看一下权限分栏表与权限表之间的交互。这两张表之间的字段关联如下图：

　　两张表使用了actioncolumnid字段相关联，这种关联方式在数据库中的表现如下图：

　　如图所示，通过这种关联方式，我们可以非常清晰的看到权限表中的权限属于哪个分栏。

　　现在，数据库结构已经很清晰了，分配权限的功能以及“组”操作都已经实现。下面我们再来分析一下需求中提到的关于权限管理系统的重用性问题。

　　为什么使用这种数据库设计方式搭建起来的系统可以重用呢？

• 三张实体表中记录着系统中的三个决定性元素。“权限”，“组”和“人”。而这三种元素可以任意添加，彼此之间不受影响。无论是那种类型的业务系统，这三个决定性元素是不会变的，也就意味着结构上不会变，而变的仅仅是数据。
• 两张映射表中记录着三个元素之间的关系。但这些关系完全是人为创建的，需要变化的时候，只是对数据库中的记录进行操作，无需改动结构。
• 权限分栏表中记录着系统使用时显示的分栏。无论是要添加分栏，修改分栏还是减少分栏，也只不过是操作记录而已。

　　综上所述，这样设计数据库，系统是完全可以重用的，并且经受得住“变更”考验的。

总结：

　　此套系统的重点在于，三张实体表牢牢地抓住了系统的核心成分，而两张映射表完美地映射出三张实体表之间的交互。其难点在于，理解映射表的工作，它记录着关系，并且实现了“组”操作的概念。而系统总体的设计是本着可以在不同的MIS系统中“重用”来满足不同系统的功能权限设置。

附录：

　　下面我们来看看权限管理系统的数据库表设计，共分为六张表，如下图：

action表：

　　action表中记录着系统中所有的动作，以及动作相关描述。

actioncolumn表：

　　actioncolumn表中记录着动作的分栏，系统运行时，左侧菜单栏提供了几块不同的功能，每一块就是一个分栏，每添加一个分栏，该表中的记录就会增加一条,相对应的，左侧菜单栏中也会新增机一个栏。

actiongroup表：

　　actiongroup表记录着动作所在的组。

groupmanager表：

　　groupmanager表记录着管理组的相关信息，每添加一个管理组，这里的记录就会增加一条。

mastergroup表：

　　mastergroup表记录着管理员所在的管理组，由于一名管理员可能同同时属于多个组，所以该表中关于某一名管理员的记录可能有多条。

master表：

　　master表记录着所有管理员的信息，每添加一个管理员，该表就会增加一条记录。