软件设计后台 *** 作用户权限管理的方案

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

我做过类似有权限管理的系统，表分3个：

第一个表是权限表（tb_pope)，都有什么权限，以你的系统要求，分3个权限：管理所有学生，管理系学生，本学生。

表列名可以是：ID,popeName,里面有3条记录。

1，管理所有学生

2，管理系学生

3，本学生

第二个表是用户表(tb_user)：ID,userName,age,等等

第三个表就是用户权限表(tb_userpope)：ID,userID,PopeID

登录时先检查是否有该用户名，然后读取其权限值，根据权限 *** 作数据库显示或隐藏 *** 作的部分。

大致就这样了。

数据库设计的过程(六个阶段)1需求分析阶段准确了解与分析用户需求（包括数据与处理）是整个设计过程的基础，是最困难、最耗费时间的一步2概念结构设计阶段是整个数据库设计的关键通过对用户需求进行综合、归纳与抽象，形成一个独立于具体DBMS的概念模型3逻辑结构设计阶段将概念结构转换为某个DBMS所支持的数据模型对其进行优化4数据库物理设计阶段为逻辑数据模型选取一个最适合应用环境的物理结构（包括存储结构和存取方法）5数据库实施阶段运用DBMS提供的数据语言、工具及宿主语言，根据逻辑设计和物理设计的结果建立数据库，编制与调试应用程序，组织数据入库，并进行试运行6数据库运行和维护阶段数据库应用系统经过试运行后即可投入正式运行。数据库,容纳数据的仓库，数据库系统,数据库、数据库管理系统、硬件、 *** 作人员的合在一起的总称数据库管理系统,用来管理数据及数据库的系统。数据库系统开发工具，以数据库管理系统为核心，用高级语言开发一套给傻瓜用户使用的数据库应用系统的软件。数据库系统包含数据库管理系统、数据库及数据库开发工具所开发的软件（数据库应用系统数据库管理系统(database management system)是一种 *** 纵和管理数据库的大型软件，是用于建立、使用和维护数据库，简称dbms。它对数据库进行统一的管理和控制，以保证数据库的安全性和完整性。用户通过dbms访问数据库中的数据，数据库管理员也通过dbms进行数据库的维护工作。它提供多种功能，可使多个应用程序和用户用不同的方法在同时或不同时刻去建立，修改和询问数据库。它使用户能方便地定义和 *** 纵数据，维护数据的安全性和完整性，以及进行多用户下的并发控制和恢复数据库。

采用自增长主要是性能

早期的数据库系统，经常采用某种编号，比如身份z号码，公司编号等等作为数据库表的

然而，很快，大家就发现其中的不利之处

比如早期的医院管理系统，用身份z号码作为病人表的

然而，第一，不是每个人都有身份z；第二，对于国外来的病人，不同国家的病人的证件号码并不见得没有重复

因此，用身份z号码作为病人表的是一个非常糟糕的设计

考虑到没有医生或者护士会刻意去记这些号码，使用自增长是更好的设计

公司编号采用某种特定的编码方法，这也是早期的数据库系统常见的做法

它的缺点也显而易见：很容易出现像千年虫的软件问题，因为当初设计数据库表的时候设计的位数太短，导致系统使用几年后不能满足要求，只有修改程序才能继续使用

问题在于，任何人设计系统的时候，在预计某某编号多少位可以够用的时候，都存在预计不准的风险

而采用自增长则不存在这种问题

同样的道理，没有人可以去记这些号码

使用自增长另外一个原因是性能问题

略有编程常识的人都知道，数字大小比较比字符串大小比较要快得多

使用自增长可以大大地提高数据查找速度

2

避免用复合主键(compound)这主要还是因为性能问题

数据检索是要用到大量的值比较，只比较一个字段比比较多个字段快很多

使用单个从编程的角度也很有好处，sql语句中where条件可以写更少的代码，这意味着出错的机会大大减少

3

双主键双主键是指数据库表有两个字段，这两个字段独立成为主键，但又同时存在

数据库系统的双主键最早用在用户管理模块

最早的来源可能是参照 *** 作系统的用户管理模块

*** 作系统的用户管理有两个独立的主键： *** 作系统自己自动生成的随机ID(Linux,windows的SID),loginid

这两个ID都必须是唯一的，不同的是，删除用户test然后增加一个用户test,SID不同，loginid相同

采用双主键主要目的是为了防止删除后增加同样的loginid造成的混乱

比如销售经理hellen本机共享文件给总经理peter,一年后总经理离开公司，进来一个普通员工peter，两个peter用同样的loginid,如果只用loginid作 *** 作系统的用户管理主键，则存在漏洞：普通员工peter可以访问原来只有总经理才能看的文件

*** 作系统自己自动生成的随机ID一般情况下面用户是看不到的

双主键现在已经广泛用在各种数据库系统中，不限于用户管理系统

4

以固定的数据库、表应付变化的客户需求这主要基于以下几个因素的考虑：4

1大型EPR系统的正常使用、维护需要软件厂商及其众多的合作伙伴共同给客户提供技术服务，包括大量的二次开发

如果用户在软件正常使用过程中需要增加新的表或者数据库，将给软件厂商及其众多的合作伙伴带来难题

4

2软件升级的需要

没有一个软件能够让客户使用几十上百年不用升级的

软件升级往往涉及数据库表结构的改变

软件厂商会做额外的程序将早期版本软件的数据库数据升级到新的版本，但是对于用户使用过程中生成的表进行处理就比较为难

4

3软件开发的需要

使用固定的数据库库表从开发、二次开发来说，更加容易

对于用户使用过程中生成的表，每次查找数据时都要先查表名，再找数据，比较麻烦

举例来说，早期的用友财务软件用Aess作数据库，每年建立一个新的数据库

很快，用户和用友公司都发现，跨年度数据分析很难做

因此这是一个不好的设计

在ERP中，很少有不同的年度数据单独分开

一般来说，所有年份的数据都在同一个表中

对于跨国公司甚至整个集团公司都用同一个ERP系统的时候，所有公司的数据都在一起

这样的好处是数据分析比较容易做

现在大多数数据库系统都能做到在常数时间内返回一定量的数据

比如，Oracle数据库中，根据在100万条数据中取10条数据，与在1亿条数据中取10条数据，时间相差并不多

5

避免一次取数据库大量数据，取大量数据一定要用分页

这基本上是现在很多数据库系统设计的基本守则

ERP系统中超过100万条数据的表很多，对于很多表中的任何一个，一次取所有的会导致数据库服务器长时间处于停滞状态，并且影响其它在线用户的系统响应速度

一般来说，日常 *** 作，在分页显示的情况下面，每次取得数据在1-100之间，系统响应速度足够快，客户端基本没有特别长的停顿

这是比较理想的设计

这也是大型数据库系统往往用ODBC,ADO等等通用的数据库联接组件而不用特定的速度较快的专用数据库联接组件的原因

因为系统瓶颈在于数据库(Database)方面(数据量大)，而不在于客户端(客户端每次只取少量数据)

在B/S数据库系统中，分页非常普遍

早期的数据库系统经常有客户端程序中一次性取大量数据做缓冲

现在已经不是特别需要了，主要原因有：5

1数据库本身的缓冲技术大大提高

大部分数据库都会自动将常用的数据自动放在内存中缓冲，以提高性能

5

2数据库联接组件的缓冲技术也在提高

包括ADO在内的一些数据库联接组件都会自动对数据结果集(resultset)进行缓冲，并且效果不错

比较新颖的数据库联接组件，比如Hibernate也加入了一些数据结果集缓冲功能

当然，也有一些数据库联接组件没有对数据结果集进行缓冲，比如JDBCDriver，不过几年之内情况应该有所改观

也有些不太成功的数据缓冲，比如EJB中的实体Bean，性能就不尽如人意，实体Bean数据也是放在内存中，可能是因为占用内存过多的缘故

相对来说，今天的程序员写客户端数据缓冲，能够超过以上两个缓冲效果的，已经比较难了

以上就是关于软件设计后台 *** 作用户权限管理的方案全部的内容，包括:软件设计后台 *** 作用户权限管理的方案、在数据库中如何设计权限表(给数据库用户创建表的权限)、数据库设计过程包括几个主要阶段哪些阶段独立于数据库管理系统哪些阶段依赖于数据库管理系统等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！