java用户角色权限设计

实现业务系统中的用户权限管理

　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表记录着全部管理员的信息，每添加一个管理员，该表就会增长一条记录。