用户表角色权限表的设计.docx
《用户表角色权限表的设计.docx》由会员分享，可在线阅读，更多相关《用户表角色权限表的设计.docx（25页珍藏版）》请在冰点文库上搜索。
用户表角色权限表的设计
用户·角色·权限·表的设计
一．引言
因为做过的一些系统的权限管理的功能虽然在逐步完善，但总有些不尽人意的地方，总想抽个时间来更好的思考一下权限系统的设计。
权限系统一直以来是我们应用系统不可缺少的一个局部，假设每个应用系统都重新对系统的权限进展设计，以满足不同系统用户的需求，将会浪费我们不少珍贵时间，所以花时间来设计一个相对通用的权限系统是很有意义的。
二．设计目标
设计一个灵活、通用、方便的权限管理系统。
在这个系统中，我们需要对系统的所有资源进展权限控制，那么系统中的资源包括哪些呢？
我们可以把这些资源简单概括为静态资源〔功能操作、数据列〕和动态资源〔数据〕，也分别称为对象资源和数据资源，后者是我们在系统设计与实现中的叫法。
系统的目标就是对应用系统的所有对象资源和数据资源进展权限控制，比方应用系统的功能菜单、各个界面的按钮、数据显示的列以及各种行级数据进展权限的操控。
三．相关对象及其关系
大概理清了一下权限系统的相关概念，如下所示：
1. 权限
系统的所有权限信息。
权限具有上下级关系，是一个树状的构造。
下面来看一个例子
系统管理
用户管理
查看用户
新增用户
修改用户
删除用户
对于上面的每个权限，又存在两种情况，一个是只是可访问，另一种是可授权，例如对于“查看用户〞这个权限，如果用户只被授予“可访问〞，那么他就不能将他所具有的这个权限分配给其他人。
2. 用户
应用系统的具体操作者，用户可以自己拥有权限信息，可以归属于0～n个角色，可属于0～n个组。
他的权限集是自身具有的权限、所属的各角色具有的权限、所属的各组具有的权限的合集。
它与权限、角色、组之间的关系都是n对n的关系。
3. 角色
为了对许多拥有相似权限的用户进展分类管理，定义了角色的概念，例如系统管理员、管理员、用户、访客等角色。
角色具有上下级关系，可以形成树状视图，父级角色的权限是自身及它的所有子角色的权限的综合。
父级角色的用户、父级角色的组同理可推。
4. 组
为了更好地管理用户，对用户进展分组归类，简称为用户分组。
组也具有上下级关系，可以形成树状视图。
在实际情况中，我们知道，组也可以具有自己的角色信息、权限信息。
这让我想到我们的QQ用户群，一个群可以有多个用户，一个用户也可以参加多个群。
每个群具有自己的权限信息。
例如查看群共享。
QQ群也可以具有自己的角色信息，例如普通群、高级群等。
针对上面提出的四种类型的对象，让我们通过图来看看他们之间的关系。
有上图中可以看出，这四者的关系很复杂，而实际的情况比这个图还要复杂，权限、角色、组都具有上下级关系，权限管理是应用系统中比拟棘手的问题，要设计一个通用的权限管理系统，工作量也着实不小。
当然对于有些工程，权限问题并不是那么复杂。
有的只需要牵涉到权限和用户两种类型的对象，只需要给用户分配权限即可。
在另一些情况中，引入了角色对象，例如基于角色的权限系统，只需要给角色分配权限，用户都隶属于角色，不需要单独为用户分配角色信息。
通用权限管理设计篇〔二〕——数据库设计
国庆前整的通用权限设计的数据库初步设计局部，现在贴上来。
理清了对象关系之后，让我们接着来进展数据库的设计。
在数据库建模时，对于N对N的
关系，一般需要参加一个关联表来表示关联的两者的关系。
初步估计一下，本系统至少需要十表，分别为：
权限表、用户表、角色表、组表、用户权限关联表、用
户角色关联表、角色权限关联表、组权限关联表、组角色关联表、用户属组关联表。
当然还可能引出一些相关的表。
下面让我们在PowerDesigner中画出各表吧。
各表及其关系如下：
1. 用户表
用户表〔TUser〕
字段名称
字段
类型
备注
记录标识
tu_id
bigint
pk,notnull
所属组织
to_id
bigint
fk,notnull
登录
login_name
varchar（64）
notnull
用户密码
password
varchar（64）
notnull
用户
vsername
varchar（64）
notnull
手机号
mobile
varchar（20）
电子
email
varchar（64）
创立时间
gen_time
datetime
notnull
登录时间
login_time
datetime
上次登录时间
last_login_time
datetime
登录次数
count
bigint
notnull
2. 角色表
角色表〔TRole〕
字段名称
字段
类型
备注
角色ID
tr_id
bigint
pk,notnull
父级角色ID
parent_tr_id
bigint
notnull
角色名称
role_name
varchar（64）
notnull
创立时间
gen_time
datetime
notnull
角色描述
description
varchar（200）
3. 权限表
权限表〔TRight〕
字段名称
字段
类型
备注
权限ID
tr_id
bigint
pk,notnull
父权限
parent_tr_id
bigint
notnull
权限名称
right_name
varchar（64）
notnull
权限描述
description
varchar（200）
4. 组表
组表〔TGroup〕
字段名称
字段
类型
备注
组ID
tg_id
bigint
pk,notnull
组名称
group_name
varchar（64）
notnull
父组
parent_tg_id
bigint
notnull
创立时间
gen_time
datetime
notnull
组描述
description
varchar（200）
5. 角色权限表
角色权限表〔TRoleRightRelation〕
字段名称
字段
类型
备注
记录标识
trr_id
bigint
pk,notnull
角色
Role_id
bigint
fk,notnull
权限
right_id
bigint
fk,notnull
权限类型
right_type
int
notnull〔0:
可访问，1:
可授权〕
6. 组权限表
组权限表〔TGroupRightRelation〕
字段名称
字段
类型
备注
记录标识
tgr_id
bigint
pk,notnull
组
tg_id
bigint
fk,notnull
权限
tr_id
bigint
fk,notnull
权限类型
right_type
int
notnull〔0:
可访问，1:
可授权〕
7. 组角色表
组角色表〔TGroupRoleRelation〕
字段名称
字段
类型
备注
记录标识
tgr_id
bigint
pk,notnull
组
tg_id
bigint
fk,notnull
角色
tr_id
bigint
pk,notnull
8. 用户权限表
用户权限表〔TUserRightRelation〕
字段名称
字段
类型
备注
记录标识
tur_id
bigint
pk,notnull
用户
tu_id
bigint
fk,notnull
权限
tr_id
bigint
fk,notnull
权限类型
right_type
int
notnull〔0:
可访问，1:
可授权〕
9. 用户角色表
用户角色表〔TUserRoleRelation〕
字段名称
字段
类型
备注
记录标识
tur_id
bigint
pk,notnull
用户
tu_id
bigint
fk,notnull
角色
tr_id
bigint
fk,notnull
10. 用户组表
用户组表〔TUserGroupRelation〕
字段名称
字段
类型
备注
记录标识
tug_id
bigint
pk,notnull
用户
tu_id
bigint
fk,notnull
组
tg_id
bigint
fk,notnull
11. 组织表
组织表〔TOrganization〕
字段名称
字段
类型
备注
组织id
to_id
bigint
pk,notnull
父组
parent_to_id
bigint
notnull
组织名称
org_name
varchar（64）
notnull
创立时间
gen_time
datetime
notnull
组织描述
description
varchar（200）
12. 操作日志表
操作日志表〔TLog〕
字段名称
字段
类型
备注
日志ID
log_id
bigint
pk,notnull
操作类型
op_type
int
notnull
操作容
content
varchar（200）
notnull
操作人
tu_id
bigint
fk,notnull
操作时间
gen_time
datetime
notnull
通用权限管理系统设计篇〔三〕——概要设计说明书
在前两篇文章中，不少朋友对我的设计提出了异议，认为过于复杂，当然在实际的各种系统的权限管理模块中，并不像这里设计得那么复杂，我以前所做的系统中，
由只有用户和权限的，有只有用户、权限和角色的，还有一个系统用到了用户、权限、角色、组概念，这个系统是我在思考以前所做系统的权限管理局部中找到的一
些共性而想到的一个设计方案，当然还会有不少设计不到位的地方，在设计开发过程中会慢慢改良，这个系统权当学习只用，各位朋友的好的建议我都会考虑到设计
中，感各位朋友的支持。
今天抽时间整了一份概念设计出来，还有一些地方尚未考虑清楚，贴出1.0版，希望各位朋友提出珍贵建议。
大家也可以点击此处?
通用权限管理概要设计说明书?
自行下载，这是1.0版本，有些地方可能还会进展局部修改，有兴趣的朋友请关注我的blog。
1. 引言
1.1编写目的
本文档对通用权限管理系统的总体设计、接口设计、界面总体设计、数据构造设计、系统出错处理设计以及系统平安数据进展了说明。
1.2背景
a、 软件系统的名称：
通用权限管理系统；
b、 任务提出者、开发者：
星星；
c、 在J2EE的web系统中需要使用权限管理的系统。
1.3术语
本系统：
通用权限管理系统；
SSH：
英文全称是SecureShell。
1.4预期读者与阅读建议
预期读者
阅读重点
开发人员
总体设计、接口设计、数据构造设计、界面总体设计、系统出错处理设计
设计人员
总体设计、接口设计、数据构造设计、系统平安设计
1.5参考资料
?
通用权限管理系统需求规格说明书?
?
通用权限管理系统数据库设计说明书?
2. 总体设计
2.1设计目标
权限系统一直以来是我们应用系统不可缺少的一个局部，假设每个应用系统都重新对系统的权限进展设计，以满足不同系统用户的需求，将会浪费我们不少珍贵时间，所以花时间来设计一个相对通用的权限系统是很有意义的。
本系统的设计目标是对应用系统的所有资源进展权限控制，比方应用系统的功能菜单、各个界面的按钮控件等进展权限的操控。
2.2运行环境
操作系统：
Windows系统操作系统和Linux系列操作系统。
2.3网络构造
通用权限管理系统可采用JavaSwing实现，可以在桌面应用和Web应用系统中进展调用。
如果需要要适应所有开发语言，可以将其API发布到WEBService上。
暂时用JavaSwing实现。
2.4总体设计思路和处理流程
在说明总体设计思路前，我们先说明本系统的相关概念：
1.权限资源
系统的所有权限信息。
权限具有上下级关系，是一个树状的构造。
下面来看一个例子
系统管理
用户管理
查看用户
新增用户
修改用户
删除用户
对于上面的每个权限，又存在两种情况，一个是只是可访问，另一种是可授权，例如对于“查看用户〞这个权限，如果用户只被授予“可访问〞，那么他就不能将他所具有的这个权限分配给其他人。
2.用户
应用系统的具体操作者，用户可以自己拥有权限信息，可以归属于0～n个角色，可属于0～n个组。
他的权限集是自身具有的权限、所属的各角色具有的权限、所属的各组具有的权限的合集。
它与权限、角色、组之间的关系都是n对n的关系。
3.角色
为了对许多拥有相似权限的用户进展分类管理，定义了角色的概念，例如系统管理员、管理员、用户、访客等角色。
角色具有上下级关系，可以形成树状视图，父级角色的权限是自身及它的所有子角色的权限的综合。
父级角色的用户、父级角色的组同理可推。
4.组
为
了更好地管理用户，对用户进展分组归类，简称为用户分组。
组也具有上下级关系，可以形成树状视图。
在实际情况中，我们知道，组也可以具有自己的角色信息、
权限信息。
这让我想到我们的QQ用户群，一个群可以有多个用户，一个用户也可以参加多个群。
每个群具有自己的权限信息。
例如查看群共享。
QQ群也可以具有
自己的角色信息，例如普通群、高级群等。
针对如上提出的四种对象，我们可以整理得出它们之间的关系图，如下所示：
总体设计思路是将系统分为组权限管理、角色权限管理、用户权限管理、组织管理和操作日志管理五局部。
其中组权限管理包括包含用户、所属角色、组权限资源和组总权限资源四局部，某个组的权限信息可用公式表示：
组权限=所属角色的权限合集+组自身的权限。
角色权限管理包括包含用户、包含组和角色权限三局部，某个角色的权限的计算公式为：
角色权限=角色自身权限。
用户权限管理包括所属角色、所属组、用户权限、用户总权限资源和组织管理五局部。
某个用户总的权限信息存在如下计算公式：
用户权限=所属角色权限合集+所属组权限合集+用户自身权限。
组织管理即对用户所属的组织进展管理，组织以树形构造展示，组织管理具有组织的增、删、改、查功能。
操作日志管理用于管理本系统的操作日志。
注意：
因为组和角色都具有上下级关系，所以下级的组或角色的权限只能在自己的直属上级的权限中选择，下级的组或者角色的总的权限都不能大于直属上级的总权限。
2.5模块构造设计
本系统的具有的功能模块构造如下列图所示：
2.6尚未解决的问题
无。
3. 接口设计〔暂略〕
3.1用户接口〔暂略〕
3.2外部接口〔暂略〕
3.3部接口〔暂略〕
4. 界面总体设计
本节将阐述用户界面的实现，在此之前对页面元素做如下约定：
序号
页面元素
约定
1
按钮
未选中时：
[按钮名称]
选中时：
[按钮名称]
2
单项选择框
○选项
3
复选框
□选项
4
下拉框
[选项,…,]▽
5
文本框
|________|
6
TextArea
|…………|
7
页签
未选中时：
选项名称
选中时：
选项名称
8
未选中
文字
9
选中
文字
10
说明信息
说明信息
4.1组权限管理
4.1.1包含用户
组信息
组1
组11
组12
组…
组2
组21
组22
组…
所选择组：
组1
[包含用户][所属角色][组权限][总权限]
[修改]
用户名 手机号 最近登录时间 登录次数
阿蜜果 星星 2007-10-8 66
sterningxxx 2007-10-8 10
……
当用户选择“修改〞按钮时，弹出用户列表，操作人可以通过勾选或取消勾选来修改该组所包含的用户。
4.1.2所属角色
组信息
组1
组11
组12
组…
组2
组21
组22
组…
所选择组：
组1
[包含用户][所属角色][组权限][总权限]
[修改]
角色ID 角色名称 角色描述
1 访客 --
2 初级用户 --
当用户选择“修改〞按钮时，弹出角色树形构造，操作人可以通过勾选或取消勾选来修改该组所属的角色。
4.1.3组权限
组信息
组1
组11
组12
组…
组2
组21
组22
组…
所选择组：
组1
[包含用户][所属角色][组权限][总权限]
[保存][取消]
4.1.4总权限
组信息
组1
组11
组12
组…
组2
组21
组22
组…
所选择组：
组1
[包含用户][所属角色][组权限][总权限]
[保存][取消]
通过对已具有的权限取消勾选，或为某权限添加勾选，来修改组的权限信息，点击“保存〞按钮保存修改信息。
4.1.5组管理
在下列图中，选中组1的时候，右键点击可弹出组的操作列表，包括添加、删除和修改按钮，从而完成在该组下添加子组，删除该组以及修改该组的功能。
组信息
组1
组11
组12
组…
组2
组21
组22
组…
所选择组：
组1
[包含用户][所属角色][组权限][总权限]
[修改]
用户名 手机号 最近登录时间 登录次数
阿蜜果 星星 2007-10-8 66
sterningxxx 2007-10-8 10
……
4.2角色权限管理
4.2.1包含用户
角色信息
角色1
角色11
角色12
角色…
角色2
角色21
角色22
角色…
所选择角色：
角色1
[包含用户][包含组][角色权限]
[修改]
用户名 手机号 最近登录时间 登录次数
阿蜜果 星星 2007-10-8 66
sterningxxx 2007-10-8 10
……
当用户选择“修改〞按钮时，弹出用户列表，操作人可以通过勾选或取消勾选来修改该角色所包含的用户。
4.2.2包含组
角色信息
角色1
角色11
角色12
角色…
角色2
角色21
角色22
角色…
所选择角色：
角色1
[包含用户][包含组][角色权限]
[修改]
组ID 组名称 组描述
1 xxx1 --
2 xxx2 --
……
当用户选择“修改〞按钮时，弹出用户列表，操作人可以通过勾选或取消勾选来修改该角色所包含的组。
4.2.3角色权限
角色信息
角色1
角色11
角色12
角色…
角色2
角色21
角色22
角色…
所选择角色：
角色1
[包含用户][包含组][角色权限]
[保存][取消]
通过对已具有的权限取消勾选，或为某权限添加勾选，来修改角色的权限信息，点击“保存〞按钮保存修改信息。
4.2.4管理角色
在下列图中，选中组1的时候，右键点击可弹出组的操作列表，包括添加、删除和修改按钮，从而完成在该组下添加子组，删除该组以及修改该组的功能。
角色信息
角色1
角色11
角色12
角色…
角色2
角色21
角色22
角色…
所选择角色：
角色1
[包含用户][包含组][角色权限]
[修改]
用户名 手机号 最近登录时间 登录次数
阿蜜果 星星 2007-10-8 66
sterningxxx 2007-10-8 10
……
4.3用户权限管理
4.3.1所属角色
用户权限信息
xx公司
分公司
阿蜜果
肖xx
yy…
分公司
zz1
zz2
zz3…
所选择用户：
阿蜜果
[所属角色][所属组][用户权限][总权限]
[修改]
角色ID 角色名称 角色描述
1 访客 --
2 初级用户 --
…
当用户选择“修改〞按钮时，弹出角色树形构造，操作人可以通过勾选或取消勾选来修改该用户所属的角色。
4.3.2所属组
用户信息
xx公司
分公司
阿蜜果
肖xx
yy…
分公司
zz1
zz2
zz3…
所选择用户：
阿蜜果
[所属角色][所属组][用户权限][总权限]
[修改]
组ID 组名称 组描述
1 组1 --
2 组2 --
…
当用户选择“修改〞按钮时，弹出组的树形构造，操作人可以通过勾选或取消勾选来修改该用户所属的组。
4.3.3用户权限
用户信息
xx公司
分公司
阿蜜果
肖xx
yy…
分公司
升级会员 