数据库权限表设计

‘壹’ 一个角色对应多个用户，一个用户又有多个权限怎么设计数据库

前端的登陆界面，除了用户名、密码之外，添加一个下拉框选择公司名称
使用两个表的联合查询
sql
=
"select
a.position
from
user
a,corp
b
where
a.corpid
=
b.corpid
and
a.username
=
and
a.password
=
and
b.corpname
=
";
把输入的用户名、密码、公司名称这三个数据代入到三个号中。

‘贰’ java权限系统数据库的设计，三张表的那种

数据库和程序都很重要。 数据库方面设计权限这一块设计三张表，（用户表、角色表、权限表）， 权限表关联用户表和角色表的外键，这个就两个一对多的关系代替了，多对多的关系。 在hibernate中配置的时候要配置用户表和角色表的多对多关系。

‘叁’ java 权限管理系统中数据权限的设计与使用

建立一个角色资源表，表中各种资源设置不同的类型，比如菜单类型为0，数据权限类型为1等等，表中也可以规定能访问的数据规则，取得表中数据规则放到sql语句。

‘肆’ 2、用户权限管理，数据库表设计

网上资料说权限设计 = 功能权限 + 数据权限，我认为还是很有道理的。之前项目中只涉及到功能权限，没有数据权限，原因是最开始设计时，数据已经绑定在特定的用户下了，而且涉及到的表数量很少，不需要单独考虑数据权限的问题。

权限管理，最细致的权限管理有 用户，用户组，角色，权限，功能。根据不同的需求适当选择，如 用户量过大，每个人都授权和麻烦，就引入用户组，对用户组赋予权限。功能上也根据业务不同做适当的扩展。由于如用户权限之前存在多对多关系，需要引入中间表。
本系统设计如下：

数据量很小，功能也不复杂，所以只有用户，角色，权限（功能）及产生的中间表。
表中的数据都是提前填的，用户登陆，查ermroleuser表，获取角色，查ermrolefunction表，获取功能，再查ermfunction表，返回该用户的功能的中文，在页面上展示。

功能权限详细设计请参考，本项目也是受此启发：
http://blog.csdn.net/painsonline/article/details/7183613/

需求：给一个原来没有权限的数据配置系统加上登录，权限功能，不同角色查同一张表返回结果不同。
思路：所谓数据权限，关注点在于实体属性值、条件、允许值，用户登录后，查询该用户的查询条件，根据条件获取数据即可。详细表结构设计可以参考： https://zhuanlan.hu.com/p/31339794

具体介绍一下每个字段含义：
（1）主键 id；
（2）acl_id 映射权限点表主键，代表每行记录是针对哪个权限点的；
（3）status 代表当前这条配置是否有效，方便临时激活与禁用；
（4）param 代表需要校验的参数名，允许一个请求有多个参数参与数据校验；如果参数复杂，比如包含对象，定义的参数可能为a.b.c 这种多级的形式，建议不要太复杂
（5）operation 代表数据拦截的规则，使用数字代表是等于、大于、小于、大于等于、小于等于、包含、介于之间等，可以根据自己需要增加或减少支持的拦截规则
（6）value1 和 value2 用来和param、operation组成一个关系表达式，比如：1<=a<2
next_param_op 字段根据需要使用，如果一个权限点支持多条数据规则时，连接两个规则之间的操作，|| 还是 &&
（7）seq 字段用于某个权限点包含多条数据权限规则时的顺序

假设有这么一条数据，那么他的含义是：id为1（acl_id）的权限点，配置了一条有效（status=1）的数据规则，规则是：传入参数id（param）的值要大于（operation）10（value1）

这种设计很细致了，当然我的项目没有那么复杂，所以最终没有采用这个。
http://www.cnblogs.com/jeffwoot/archive/2008/12/23/1359591.html 讲述了数据权限设计的演化过程。
本系统跟权限相关的表结构如下：

‘伍’ 软件设计后台操作用户权限管理的方案

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

‘陆’ 怎么设计用户权限管理系统数据库要用到哪几张表每张表有哪些字段

什么样的权限？菜单权限？
一般用户表，角色表，模块表（或者菜单啊反正是你要权限的东西），然后角色和模块的表
这是最简单的结构，用户关联角色，角色关联模块，用角色去控制权限，增删改查什么的模块表呢，就是你要控制的东西，比菜单，根据登录人的角色，看有哪些模块，然后显示这些模块其他的模块隐藏。
如果需要复杂的东西，中间可以加别的东西，具体看你需求了
至于字段，用户和角色就没什么可说的，无法就是名字啊什么的
模块表也简单，比如模块名称，ID，父子模块id（如果有父子模块的话），具体字段还是要看需求。

‘柒’ 怎么设计用户权限管理系统数据库

一般用户表，角色表，模块表（或者菜单啊反正是你要权限的东西），然后角色和模块的表
这是最简单的结构，用户关联角色，角色关联模块，用角色去控制权限，增删改查什么的模块表呢，就是你要控制的东西，比菜单，根据登录人的角色，看有哪些模块，然后显示这些模块其他的模块隐藏。
如果需要复杂的东西，中间可以加别的东西，具体看你需求了。