实现业务系统中的用户权限管理--设计篇

Posted 2020-09-12 llguanli

       B/S系统中的权限比C/S中的更显的重要，C/S系统由于具有特殊的client，所以訪问用户的权限检測能够通过client实现或通过client+server检測实现，而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表记录着全部管理员的信息。每加入一个管理员，该表就会添加一条记录。