范文一：通用角色权限管理系统设计通用角色权限管理系统设计

通用权限管理系统设计篇

一(引言

因为做过的一些系统的权限管理的功能虽然在逐步完善，但总有些不尽人意的地方，总想抽个时间来更好的思考一下权限系统的设计。

权限系统一直以来是我们应用系统不可缺少的一个部分，若每个应用系统都重新对系统的权限进行设计，以满足不同系统用户的需求，将会浪费我们不少宝贵时间，所以花时间来设计一个相对通用的权限系统是很有意义的。

二(设计目标

设计一个灵活、通用、方便的权限管理系统。

在这个系统中，我们需要对系统的所有资源进行权限控制，那么系统中的资源包括哪些呢,我们可以把这些资源简单概括为静态资源(功能操作、数据列)和动态资源(数据)，也分别称为对象资源和数据资源，后者是我们在系统设计与实现中的叫法。

系统的目标就是对应用系统的所有对象资源和数据资源进行权限控制，比如应用系统的功能菜单、各个界面的按钮、数据显示的列以及各种行级数据进行权限的操控。

三(相关对象及其关系

大概理清了一下权限系统的相关概念，如下所示:

1. 权限

系统的所有权限信息。权限具有上下级关系，是一个树状的结构。下面来看一个例子

系统管理

用户管理

查看用户

新增用户

修改用户

删除用户

对于上面的每个权限，又存在两种情况，一个是只是可访问，另一种是可授权，例如对于“查看用户”这个权限，如果用户只被授予“可访问”，那么他就不能将他所具有的这个权限分配给其他人。 2. 用户

应用系统的具体操作者，用户可以自己拥有权限信息，可以归属于0,n个角色，可属于0,n个组。他的权限集是自身具有的权限、所属的各角色具有的权限、所属的各组具有的权限的合集。它与权限、角色、组之间的关系都是n对n的关系。

3. 角色

为了对许多拥有相似权限的用户进行分类管理，定义了角色的概念，例如系统管理员、管理员、用户、访客等角色。角色具有上下级关系，可以形成树状视图，父级角色的权限是自身及它的所有子角色的权限的综合。父级角色的用户、父级角色的组同理可推。

4. 组

为了更好地管理用户，对用户进行分组归类，简称为用户分组。组也具有上下级关系，可以形成树状视图。在实际情况中，我们知道，组也可以具有自己的角色信息、权限信息。这让我想到我们的QQ用户群，一个群可以有多个用户，一个用户也可以加入多个群。每个群具有自己的权限信息。例如查看群共享。QQ群也可以具有自己的角色信息，例如普通群、高级群等。

针对上面提出的四种类型的对象，让我们通过图来看看他们之间的关系。

有上图中可以看出，这四者的关系很复杂，而实际的情况比这个图还要复杂，权限、角色、组都具有上下级关系，权限管理是应用系统中比较棘手的问题，要设计一个通用的权限管理系统，工作量也着实不小。

当然对于有些项目，权限问题并不是那么复杂。有的只需要牵涉到权限和用户两种类型的对象，只需要给用户分配权限即可。

在另一些情况中，引入了角色对象，例如基于角色的权限系统， 只需要给角色分配权限，用户都隶属于角色，不需要单独为用户分配角色信息。

在下一篇中，我们将讲述权限管理的数据库设计等内容。

欢迎各位拍砖或给出宝贵意见。

国庆前整的通用权限设计的数据库初步设计部分，现在贴上来。

理清了对象关系之后，让我们接着来进行数据库的设计。在数据库建模时，对于N对N的关系，一般需要加入一个关联表来表示关联的两者的关系。初步估计一下，本系统至少需要十张表，分别为:权限表、用户表、角色表、组表、用户权限关联表、用户角色关联表、角色权限关联表、组权限关联表、组角色关联

表、用户属组关联表。当然还可能引出一些相关的表。下面让我们在PowerDesigner中画出各表吧。

各表及其关系如下:

1. 用户表

字段名称 字段 类型 备注 记录标识 tu_id bigint pk, not null 所属组织 to_id bigint fk, not null 登录帐号 login_name varchar(64) not null 用户密码 password varchar(64) not null 用户姓名 vsername varchar(64) not null 手机号 mobile varchar(20) 电子邮箱 email varchar(64) 创建时间 gen_time datetime not null 登录时间 login_time datetime 上次登录时间 last_login_time datetime 登录次数 count bigint not null 2. 角色表

字段名称 字段 类型 备注 角色ID tr_id bigint pk, not null 父级角色ID parent_tr_id bigint not null 角色名称 role_name varchar(64) not null 创建时间 gen_time datetime not null 角色描述 description varchar(200) 3. 权限表

字段名称 字段 类型 备注 权限ID tr_id bigint pk, not null 父权限 parent_tr_id bigint not null 权限名称 right_name varchar(64) not null

权限描述 description varchar(200) 4. 组表

字段名称 字段 类型 备注 组ID tg_id bigint pk, not null 组名称 group_name varchar(64) not null 父组 parent_tg_id bigint not null 创建时间 gen_time datetime not null 组描述 description varchar(200) 5. 角色权限表

字段名称 字段 类型 备注 记录标识 trr_id bigint pk, not null 角色 Role_id bigint fk, not null 权限 right_id bigint fk, not null 权限类型 not null(0:可访问，1:可授right_type int

权) 6. 组权限表

字段名称 字段 类型 备注 记录标识 tgr_id bigint pk, not null 组 tg_id bigint fk, not null 权限 tr_id bigint fk, not null 权限类型 not null(0:可访问，1:可授right_type int

权)

7. 组角色表

字段名称 字段 类型 备注 记录标识 tgr_id bigint pk, not null 组 tg_id bigint fk, not null 角色 tr_id bigint pk, not null 8. 用户权限表

字段名称 字段 类型 备注 记录标识 tur_id bigint pk, not null 用户 tu_id bigint fk, not null 权限 tr_id bigint fk, not null 权限类型 not null(0:可访问，1:可授right_type int

权) 9. 用户角色表

字段名称 字段 类型 备注 记录标识 tur_id bigint pk, not null 用户 tu_id bigint fk, not null 角色 tr_id bigint fk, not null 10. 用户组表

字段名称 字段 类型 备注 记录标识 tug_id bigint pk, not null

用户 tu_id bigint fk, not null

组 tg_id bigint fk, not null

11. 组织表

字段名称 字段 类型 备注

组织id to_id bigint pk, not null

父组 parent_to_id bigint not null

组织名称 org_name varchar(64) not null

创建时间 gen_time datetime not null

组织描述 description varchar(200)

12. 操作日志表

字段名称 字段 类型 备注

日志ID log_id bigint pk, not null

操作类型 op_type int not null

操作内容 content varchar(200) not null

操作人 tu_id bigint fk, not null

操作时间 gen_time datetime not null

在前两篇文章中，不少朋友对我的设计提出了异议，认为过于复杂，当然在实际的各种系统的权限管理模块中，并不像这里设计得那么复杂，我以前所做的系统中，由只有用户和权限的，有只有用户、权限和角色的，还有一个系统用到了用户、权限、角色、组概念，这个系统是我在思考以前所做系统的权限管理部分中找到的一些共性而想到的一个设计方案，当然还会有不少设计不到位的地方，在设计开发过程中会慢慢改进，这个系统权当学习只用，各位朋友的好的建议我都会考虑到设计中，感谢各位朋友的支持。

今天抽时间整了一份概念设计出来，还有一些地方尚未考虑清楚，贴出1.0版，希望各位朋友提出宝贵

建议。

大家也可以点击此处《通用权限管理概要设计说明书》自行下载，这是1.0版本，有些地方可能还会进行部分修改，有兴趣的朋友请关注我的blog。

1. 引言

1.1 编写目的

本文档对通用权限管理系统的总体设计、接口设计、界面总体设计、数据结构设计、系统出错处理设计以及系统安全数据进行了说明。

1.2 背景

a、 软件系统的名称:通用权限管理系统;

b、 任务提出者、开发者:谢星星;

c、 在J2EE的web系统中需要使用权限管理的系统。

1.3 术语

本系统:通用权限管理系统;

SSH:英文全称是Secure Shell。

1.4 预期读者与阅读建议

预期读者 阅读重点 开发人员 总体设计、接口设计、数据结构设计、界面总体设计、系统出错处理设计 设计人员 总体设计、接口设计、数据结构设计、系统安全设计

1.5 参考资料

《通用权限管理系统需求规格说明书》

《通用权限管理系统数据库设计说明书》

2. 总体设计

2.1 设计目标

权限系统一直以来是我们应用系统不可缺少的一个部分，若每个应用系统都重新对系统的权限进行设计，以满足不同系统用户的需求，将会浪费我们不少宝贵时间，所以花时间来设计一个相对通用的权限系统是很有意义的。

本系统的设计目标是对应用系统的所有资源进行权限控制，比如应用系统的功能菜单、各个界面的按钮控件等进行权限的操控。

2.2 运行环境

操作系统:Windows系统操作系统和Linux系列操作系统。

2.3 网络结构

通用权限管理系统可采用Java Swing实现，可以在桌面应用和Web应用系统中进行调用。如果需要要适应所有开发语言，可以将其API发布到WEB Service上。暂时用Java Swing实现。 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

组1

[包含用户] [所属角色] [组权限] [总权限]

组11

组12 [修改]

组?

用户名 姓名 手机号 最近登录时间 登录次数

组2

阿蜜果 谢星星 13666666666 2007-10-8 66

组21

sterning xxx 13555555555 2007-10-8 10 组22

组? ??

当用户选择“修改”按钮时，弹出用户列表，操作人可以通过勾选或取消勾选来修改该组所包含的用

户。

4.1.2所属角色

组信息所选择组:组1

组1

[包含用户] [所属角色] [组权限] [总权限]

组11

[修改]

组12

角色ID 角色名称 角色描述 组?

组2 1 访客 --

组21

2 初级用户 --

组22

组?

当用户选择“修改”按钮时，弹出角色树形结构，操作人可以通过勾选或取消勾选来修改该组所属的

角色。

4.1.3组权限

组信息 所选择组:组1

组1

[包含用户] [所属角色] [组权限] [总权限]

组11

组12

组?

组2

组21

组22

组?

[保存] [取消]

4.1.4总权限

组信息 所选择组:组1

组1

[包含用户] [所属角色] [组权限] [总权限]

组11

组12

组?

组2

组21

组22

组?

[保存] [取消]

通过对已具有的权限取消勾选，或为某权限添加勾选，来修改组的权限信息，点击“保存”按钮保存

修改信息。

4.1.5组管理

在下图中，选中组1的时候，右键点击可弹出组的操作列表，包括添加、删除和修改按钮，从而完成

在该组下添加子组，删除该组以及修改该组的功能。

组信息 所选择组:组1

组1

[包含用户] [所属角色] [组权限] [总权限]

组11

[修改] 组12

用户名 姓名 手机号 最近登录时间 登录次数 组?

组2 阿蜜果 谢星星 13666666666 2007-10-8 66

组21

sterning xxx 13555555555 2007-10-8 10

组22

组? ??

4.2 角色权限管理

4.2.1包含用户

角色信息 所选择角色:角色1

角色1

[包含用户] [包含组] [角色权限]

角色11

[修改]

角色12

用户名 姓名 手机号 最近登录时间 登录次数 角色?

角色2 阿蜜果 谢星星 13666666666 2007-10-8 66

角色21

sterning xxx 13555555555 2007-10-8 10

角色22

?? 角色?

当用户选择“修改”按钮时，弹出用户列表，操作人可以通过勾选或取消勾选来修改该角色所包含的

用户。

4.2.2包含组

角色信息 所选择角色:角色1

角色1

[包含用户] [包含组] [角色权限]

角色11

[修改] 角色12

角色? 组ID 组名称 组描述

角色2

1 xxx1 --

角色21

2 xxx2 --

角色22

?? 角色?

当用户选择“修改”按钮时，弹出用户列表，操作人可以通过勾选或取消勾选来修改该角色所包含的

组。

4.2.3角色权限

角色信所选择角色:角色1

息

[包含用户] [包含组] [角色权限] 角色

1

角色11

角色12

角色?

角色

2

角色21

[保存] [取消]

角色22

角色?

通过对已具有的权限取消勾选，或为某权限添加勾选，来修改角色的权限信息，点击“保存”按钮保

存修改信息。

4.2.4管理角色

在下图中，选中组1的时候，右键点击可弹出组的操作列表，包括添加、删除和修改按钮，从而完成

在该组下添加子组，删除该组以及修改该组的功能。

角色信息 所选择角色:角色1

角色1

[包含用户] [包含组] [角色权限]

角色11

[修改]

角色12

用户名 姓名 手机号 最近登录时间 登录次数 角色?

角色2 阿蜜果 谢星星 13666666666 2007-10-8 66

角色21

sterning xxx 13555555555 2007-10-8 10

角色22

?? 角色?

4.3 用户权限管理

4.3.1所属角色

用户权限信息 所选择用户:阿蜜果

xx公司

[所属角色] [所属组] [用户权限] [总权限]

广州分公司

阿蜜果 [修改]

肖xx

角色ID 角色名称 角色描述

yy?

1 访客 --

北京分公司

2 初级用户 -- zz1

zz2 ?

zz3?

当用户选择“修改”按钮时，弹出角色树形结构，操作人可以通过勾选或取消勾选来修改该用户所属

的角色。

4.3.2所属组

用户信息 所选择用户:阿蜜果 xx公司

[所属角色] [所属组] [用户权限] [总权限]

广州分公司

[修改] 阿蜜果

组ID 组名称 组描述 肖xx

yy? 1 组1 --

北京分公司

2 组2 --

zz1

? zz2

zz3?

当用户选择“修改”按钮时，弹出组的树形结构，操作人可以通过勾选或取消勾选来修改该用户所属

的组。

4.3.3用户权限

用户信所选择用户:阿蜜果 息

[所属角色] [所属组] [用户权限] [总权限] xx公司

广州 分公司

阿蜜果

肖xx

yy?

北京

分公司

zz1 [保存] [取消]

zz2

zz3?

通过对已具有的权限取消勾选，或为某权限添加勾选，来修改用户的权限信息，点击“保存”按钮保

存修改信息。

4.3.4总权限

用户信所选择用户:阿蜜果

息

[所属角色] [所属组] [用户权限] [总权限] xx公司

广州

分公司

阿蜜果

肖xx

yy?

北京

分公司

zz1 [保存] [取消]

zz2

zz3?

通过对已具有的权限取消勾选，或为某权限添加勾选，来修改用户的权限信息，点击“保存”按钮保

存修改信息。

4.3.5用户管理

当选择了某用户时，点击右键，弹出菜单列表:修改、删除、取消，点击修改和删除按钮可以实现用

户的删除和修改功能。

选择某个组织，例如下表中的“广州分公司”，弹出菜单列表:添加子组织、删除组织、修改组织、

添加用户、取消，点击添加用户按钮可以实现用户的添加功能。

用户权限信息 所选择用户:阿蜜果

xx公司

[所属角色] [所属组] [用户权限] [总权限]

广州分公司

[修改]

阿蜜果

角色ID 角色名称 角色描述 肖xx

yy? 1 访客 --

北京分公司

2 初级用户 --

zz1

? zz2

zz3?

4.3.6组织管理

选择某个组织，例如下表中的“广州分公司”，弹出菜单列表:添加子组织、删除组织、修改组织、

添加用户、取消，点击添加子组织、删除组织、修改组织按钮可以实现组织的添加、删除和修改功能。

用户权限信息 所选择用户:阿蜜果

xx公司

[所属角色] [所属组] [用户权限] [总权限]

广州分公司

[修改] 阿蜜果

角色ID 角色名称 角色描述 肖xx

yy? 1 访客 --

北京分公司

2 初级用户 --

zz1

?

zz2

zz3?

4.4 操作日志管理

4.4.1查询操作日志

操作名称:|________| 操作人:|________|

操作时间从 |________| 到 |________| [查询] [重置] [删除]

编号 操作名称 操作内容 操作人 操作时间

1 xx1 -- Amigo 2007-10-8

2 xx2 -- xxyy 2007-10-8

?

输入上图表单中的查询信息后，点击“查询”按钮，可查询出符合条件的信息。

4.4.2删除操作日志

操作名称:|________| 操作人:|________|

操作时间从 |________| 到 |________| [查询] [重置] [删除]

编号 操作名称 操作内容 操作人 操作时间

1 xx1 -- Amigo 2007-10-8

2 xx2 -- xxyy 2007-10-8

?

输入上图表单中的查询信息后，点击“查询”按钮，可查询出符合条件的信息。而后点击“删除”按钮，可删除符合查询条件的操作日志。

5. 数据结构设计

数据库设计的模型请参见《通用权限管理系统_数据库模型.pdm》。表的说明请参见《通用权限管理系统数据库设计说明书》。

5.1 设计原则

5.1.1命名的规范

数据库中表、主键、外键、索引的命名都以统一的规则，采用大小写敏感的形式，各种对象命名长度不要超过30个字符，这样便于应用系统适应不同的数据库平台。

5.1.2数据的一致性和完整性

为了保证数据库的一致性和完整性，往往通过表间关联的方式来尽可能的降低数据的冗余。表间关联是一种强制性措施，建立后，对父表(Parent Table)和子表(Child Table)的插入、更新、删除操作均要占用系统的开销。如果数据冗余低，数据的完整性容易得到保证，但增加了表间连接查询的操作，为了提高系统的响应时间，合理的数据冗余也是必要的。使用规则(Rule)和约束(Check)来防止系统操作人员误输入造成数据的错误是设计人员的另一种常用手段，但是，不必要的规则和约束也会占用系统的不必要开销，需要注意的是，约束对数据的有效性验证要比规则快。所有这些，需要在设计阶段应根据系统操作的类型、频度加以均衡考虑。

5.2 数据库环境说明

数据库:MySql5.0

设计库建模工具:PowerDesigner12.0

5.3 数据库命名规则

表名以T开头，外键以FK开头，索引以INDEX开头。

5.4 逻辑结构

pdm文件的名称为:《通用权限管理系统_数据库模型》。

5.5 物理存储

通过数据库建模工具PowerDesigner12可以将pdm导出为文本文件，将数据库脚本放入文本文件中保存。

5.6 数据备份和恢复

数据库需定期备份(每天备份一次)，备份文件格式为backup_yyyyMMdd，数据库被破坏时，利用最新的备份文件进行恢复。

6. 系统出错处理设计

6.1 出错信息

错误分类 子项及其编码 错误名称 错误代码 备注 数据库错误 连接 连接超时 100001001

连接断开 100001002

数据库本身错误代码 数据库本身错100002+数据库错误代码

误代码

TCP连接错误 连接 连接超时 101001001

连接断开 101001002

其它TCP连接错误(sock101002+ socket错误代

et自身错误代码) 码

配置信息错误 未配置输入参数 102001

未配置输出参数 102002 组管理部分自定义错误 103001——103999 角色管理部分自定义错104001——104999 误

用户管理部分自定义错105001——105999 误

操作日志管理 106001——106999 6.2 补救措施

为了当某些故障发生时，对系统进行及时的补救，提供如下补救措施:

a(后备技术 定期对数据库信息进行备份(每天一次)，当数据库因某种原因被破坏时，以最新的

数据库脚本进行恢复;。

7. 系统安全设计

7.1 数据传输安全性设计

SSH可以通过将联机的封包加密的技术进行资料的传递; 使用SSH可以把传输的所有数据进行加密，即使有人截获到数据也无法得到有用的信息。同时数据经过压缩，大大地加快了传输的速度。通过SSH的使用，可以确保资料传输比较安全并且传输效率较高。

7.2 应用系统安全性设计

操作人的操作信息需要提供操作记录。对系统的异常信息需进行记录，已备以后查看。只有授权用户才能登录系统，对于某个操作，需要具有相应权限才能进行操作。

7.3 数据存储安全性设计

对于用户的密码等敏感信息采用MD5进行加密。

下面资料为赠送的地产广告语不需要的下载后可以编辑删除就可以，谢谢选择，

祝您工作顺利，生活愉快～

地产广告语

1、让世界向往的故乡

2、某沿河楼盘:生活，在水岸停泊 3、一江春水一种人生

4、某钱塘江边楼盘:面对潮流 经典依旧 5、海景房:站在家里，海是美景;站在海上，家是美景

6、以山水为卖点的楼盘:山水是真正的不动产 7、某城区的山腰上的楼盘:凌驾尊贵 俯瞰繁华 8、某地势较高的楼盘:高人，只住有高度的房子 9、某学区房:不要让孩子输在起跑线上 10、尾盘:最后，最珍贵

11、回家就是度假的生活

12、生命就该浪费在美好的事情上

我们造城——

2、我的工作就是享受生活——

3、 我家的客厅，就是我的生活名片—— 4、在自己的阳台 看上海的未来—— 5、公园不在我家里 我家住在公园里—— 6、这里的花园没有四季——

7、***，装饰城市的风景——

8、***，我把天空搬回家——

9、房在林中，人在树下——

10、生活，就是居住在别人的爱慕里—— 11、到〖星河湾〗看看好房子的标准—— 12、好生活在〖珠江〗——

13、爱家的男人住〖百合〗

城市岸泊: 城市的岸泊，生活的小镇 生活之美不缺少，在于发现

情趣不在于奢华，在于精彩

生活有了美感才值得思考……

玫瑰庄园: 山地生态，健康人生

卓越地段，超大社区

一种完整且完善的环境，像原生一样和谐 原生景象 自然天成

人本理念 精品建筑

知名物业 智能安防

诚信为本 实力铸造

比华利山庄:海岸生活——引领世界的生活方式 海岸生活——22公里的奢华

海岸生活——高尚人生的序曲

海岸生活——人与自然的融合

苹果二十二院街:人文 自然 现代

铺的蔓伸

荣和山水美地:让世界向往的故乡

香港时代: 时代精英 开拓未来

领衔建筑，彰显尊贵

绿地崴廉公寓:金桥 40万平方米德国音乐艺术生活 汇都国际: 昆明都心，城市引擎

财富之都 风情之都 梦幻之都 文化之都 商贸之都 西部首座巨型商业之城

颠峰商圈的原动力，缔造西部财富新领地 新江湾城: 绿色生态港 国际智慧城 新江湾城，一座承载上海新梦想的城区 上海城投，全心以赴

建设知识型，生态型花园城区

风和日丽: 入住准现楼，升值在望 湾区大户，空中花园

大格局下的西海岸

市中心: 市中心 少数人的专属

颠峰珍贵市中心的稀世名宅

正中心 城市颠峰领地

颠峰 勾勒稀世名宅

繁华 不落幕的居家风景

地利 皇者尽得先机

稀世经典180席

阳光国际公寓:阳光金桥来自纽约的生活蓝本 钟宅湾: 海峡西岸生态人居 休闲商务区 汇聚国际财富与人居梦想的绝版宝地 二十一世纪是城市的世纪，二十一世纪也是海洋的世纪

谁控制了海洋，谁就控制了一切

站在蓝色海岸的前沿，开启一个新的地产时代 东南门户 海湾之心

海峡西岸生态人居 休闲商务区

让所有财富的目光聚集钟宅湾，这里每一天都在创造历史

上海A座(科维大厦):创富人生的黄金眼 掘金上海～创富人生～

远东大厦: 花小公司的钱，做大公司的事 未来城: 无可挑战的优势 无可限量的空间

绿地集团: 居住问题的答疑者，舒适生活的提案人

茶马驿栈: 精明置业时机 享受附加值 财富最大化

雪山下的世外桃源 茶马古道上千年清泉之乡 金地格林春岸:城市精英的梦想家园 繁华与宁静共存，阔绰身份不显自露 建筑覆盖率仅20%，令视野更为广阔 占据最佳景观位置，用高度提炼生活 完美演绎自然精髓，谱写古城新篇章 创新房型推陈出新，阔气空间彰显不凡 365天的贴身护卫，阔度管理以您为尊 金地格林小城:心没有界限，身没有界限 春光永驻童话之城

我的家，我的天下

东渡国际: 梦想建筑，建筑梦想 齐鲁置业: 传承经典，创新生活 比天空更宽广的是人的思想

创新 远见 生活

嘉德 中央公园:一群绝不妥协的居住理想家 完成一座改变你对住宅想象的超越作品

极至的资源整合 丰富住家的生活内涵 苛求的建造细节 提升住家的生活品质 地段优势，就是永恒价值优势

设计优势，就是生活质量优势

景观优势，就是生命健康优势

管理优势，就是生活品味优势

空中华尔兹: 自然而来的气质，华尔兹的生活等级

享受，没有不可逾越的极限

所谓完美的习惯，是舒适空间的心情定格～ 临江花园: 经典生活品质

风景中的舞台

美林别墅: 源欧美经典 纯自然空间 住原味别墅 赏园林艺术

淡雅 怡景 温馨 自然

钱江时代: 核心时代，核心生活 核心位置 创意空间 优雅规划 人文景观 财富未来

城市精神，自然风景，渗透私人空间 泰达时尚广场: 是球场更是剧场 城市经济活力源

时尚天津 水舞中国

未来都会休闲之居

创意时尚 天天嘉年华

健康快乐新境界

商旅新天地 缔造好生意

城市运营战略联盟，参与协作，多方共赢 华龙碧水豪园: 浪漫一次，相守一生

东方莱茵: 品鉴品位 宜家宜人

建筑一道贵族色彩

品鉴一方美学空间

品位一份怡然自得

荡漾一股生命活力

坐拥一处旺地静宅

体会一种尊崇感受

常青花园(新康苑):新康苑 生活感受凌驾常规 大非凡生活领域 成功人士的生活礼遇 拥有与自己身份地位相等的花园社区 在属于自己的宴会餐厅里会宾邀朋

只与自己品味爱好相同的成功人士为邻 孩子的起步就与优越同步

酒店式物管礼遇

拥有[一屋两公园 前后是氧吧]的美极环境 水木清华: 住在你心里

福星惠誉(金色华府):金色华府，市府街 才智名门——释放生命的金色魅力

真正了解一个人，要看他的朋友，看他的对手。 真正了解一种生活，也当如此。

核心地段(区位是一面镜子，照见家的质素) 隐逸空间(环境是一面镜子，照见家的质素) 超大规模(点亮与过往不同的“大”生活) 成熟配套(周边一切是镜子，照见家的质素) 精品建筑(外揽天下，内宜室家)

均好户型(每天每秒都被释放到四壁之外) 大唐新都: 原创生活，非常空间

住宅不是炫耀的标签，生活是用来享受的。 人信.千年美丽: 森庭画意.千年美丽 宁静是一种内在的力量

生活是与自然的恋爱

在自然中体验自由的生存

建筑让人迷恋的核心是思想

华智.翡翠星空: 创意生活由此进

时代美博城: 繁华领地 时尚生活

浪漫无极限

阳光海岸: 美景与生活的邂逅

带着些许闲散情绪，安享私藏一片湖的幸福 梦幻湖畔 温柔横亘在回归前方 这是你的见.心的家 景江华庭: 静享都市繁华 新锐生活核心 海虹.景: 城市在变 世界观也要变

海虹.景 国际社区

一个改变你世界观的城市文化住宅

海虹.景 区位世界观

一块好地 不仅要放到空间中 更要放到时间中去评价

海虹.景 美景世界观

先成为园林鉴赏家才能鉴赏城市 海虹.景 享受世界观

放手生活是享受的开始

海虹.景 生活世界观

洞悉时尚潮流才能洞悉生活的变化 海虹.景 空间世界观

空间随意识而变 空间是流动变化的 碧水晴天: 生活就是……寻开心 驾奴.桥的前途 路的前程 城市的前景 守望.江的神奇 滩的神话 岸边的神韵 品尝.园的风景 家的风采 眼前的风情 沐浴.屋的明亮 窗的明净 心底的明朗 闽东电力集团.楚都地产:璀璨，用诚信打造 辉煌，用实力说话

领跑，用行动证明

昆明走廊: 昆明走廊，一场与众不同的城市诡计游戏，全情体验行走的变幻情趣.

2004.场景.商业地产

西南商圈.重获新生，王者复活 2004.剧情.昆明走廊

昆明走廊的实体不是一个建筑，而是一个场所。

2004.主角.城市FI客

概念商街，体验生活进行中

2004.精彩.正式开始

乐得家.金瀚家园: 水边的香格里拉 生活的真谛源于自然，

自然的奥意在于和谐，

和谐的精髓表达完美。

江畔语林: 距璀璨不远，离自然更近 在这里，学习过悠然人生

非凡礼遇，成就居者高人一等的气质 金地香蜜山: 山在这里，我在这里 城市山居生活再升级

白描香蜜山

山林生活的升级演绎

真正的健康住宅

长在山上的房子

城市中的山地建筑

坚持 简约的后现代美学

原生态私家山野公园

四季分明的山中岁月

健康、趣味、质朴、自然是最好的设计师 风、光、水、石、云五大庭院艺术 空间是用来收藏自然的

山中的有氧运动

网球也是一种生活方式

健康成为一种习惯

山是一件运动装备

上海五角世贸商城: 百舸争流，谁能竞风流 卓越来自您抢先一步～乘天时，顺势而起。 成功来自您抢占高位～据地利，如虎添翼 理想来自您精心创造～通人知，倾情打造。 维多利亚公寓: 城南三环之内/最后，最珍贵 精粹城南里的优裕生活

花园里的洋楼，演绎英伦贵派风格 国际与本土顶尖建筑团体

全球景观设计权威/美国易道，全景营造 让每扇窗，向着风景深呼吸

金色嘉苑: 水光山色中的幸福家园 有保证的幸福生活

上风上水，幸福生活版图

尽善尽美配套，演绎幸福生活

365天美景生活，幸福生活时时刻刻 特别的爱献给特别的你

找到都市的幸福时光

嘉德现代城: 豪华尊贵的盛会 名流云集的家园 景江苑: 开启全景生活 展现全新人生 恒海国际高尔夫别墅:在这里，掀开淀山湖，恒海计划历史一页

世纪金融大厦: 璀璨闪烁

冉冉升起 我不能视而不见

清怡花苑: 风生，水起，潮涌

观赏，无边境

天境.山因势而动

山青，塔长，钟鸣

艺境.艺因琢而精

心境.心因静而远

心静，致远，淡泊，明智

筑境.筑因妙而传

创造，无止境

上品.巨洋豪园: 陆家嘴，顶极地标，至上口味 上品 稀缺，升值，唯一

新海派主义建筑集群

无限阳光 双景生态 自然居停

舒适源于对居住尺度的把握

星星港湾: 星星港湾，看见非一般的梦想 星星港湾，大学城后花园

重组，文化浓郁之美

东部生活的坐标

星星港湾的星空下，微笑的你，发现新生活已经来临

居住，是气质的一种表达

BLOCK，围合式空间，标识居住者的领域感和归属感

核心区域，处处折射品质生活

生活美学，一次满足你的梦想

一个正在实现中的梦想

天寓: 抛开一切繁文缛节，一切约定俗成，还原自然，真实的居住理想。 设计改变生活

设计思想——简洁、自由、大气

建筑——凝固的音乐

景观——回归自然

生命的真谛

品质生活——上帝在细节中

室内空间

简 历 姓 名: 简历模板 http://

性 别: 男

出生日期: 1989年2月

年 龄: 37岁

户口所在地:上海

政治面貌: 党员

毕业生院校:

专 业:

地 址:

电 话:

E-mail:

___?教育背景?_______________________________________________________________

1983/08--1988/06 华东理工大学 生产过程自动化 学士

___?个人能力?_______________________________________________________________

这里展示自己有什么的特长及能力

___?专业课程?_______________________________________________________________

《课程名称(只写一些核心的)》:简短介绍

《课程名称》:简短介绍

___?培训经历?_______________________________________________________________

2002/06--2002/10 某培训机构 计算机系统和维护 上海市劳动局颁发的初级证书

1998/06--1998/08 某建筑工程学校 建筑电气及定额预算 上海建筑工程学校颁发

___?实习经历?_______________________________________________________________

2011年5月 —— 现在 某(上海)有限公司 XX职位

【公司简单描述】

属外资制造加工企业,职工1000人，年产值6000万美金以上。

主要产品有:五金制品、设备制造、零部件加工、绕管器

【工作职责】

【工作业绩】

___?语言能力?_______________________________________________________________

英 语:熟练

英语等级:大学英语考试四级

___?IT技能?_______________________________________________________________

Windows NT\/2000\/XP 36个月经验 水平:精通

LAN 36个月经验 水平:熟练

Office 84个月经验 水平:精通

___?自我评价?_______________________________________________________________

这里写自我评价的内容 可以访问 http://

___?获得的证书与奖项?_______________________________________________________

系里的一等奖学金 获得时间: 年 全系XXX人只有XX人取得。

内部讲师培训班》培训方案

为落实 “用‘教练式’企管模式打造学习型组织”的企业指导思想，提升企业内学习

型员工演讲能力，传播培训、主持理念和技巧，培养储备公司内部主持人、讲师人才，培训

部特开办“双虎内部讲师培训班”(第一期)。

本期培训班选用《30天精英演讲速成》作为自学教材，共计划十次面授课程，利用每

周四晚间19:00~20:00开展，每课九十分钟。

每次课程的主要流程包括以下环节:

1. 主持人开场互动练习

2. 学员根据规定主题展示口才(60分钟)

3. 每位5分钟综合展示时间，主题为上节课介绍内容。(包括:自我介绍，PPT宣讲，互

动等。)

4. 每位学员展示完后，进行学员互评。学员互评制:每位学员发一张评分表，按照评分表

根据不同项目进行打分，单项满分为10分，不足之处可用文字在空格内表示。单项项

目取平均分后进行项目汇总得出综合测评分，并邀请单项评分打分最高和最低的学员进

行点评。

5. 主持人介绍下节课学习内容(20分钟)

6. 提问时间(5分钟)

7. 根据学员得分排名情况进行下节课出场次序安排并宣布。

8. 结束。

备注:

项目 学员展示主题安排 课程内容安排 课时

演讲基础训练、演讲5项基本功训练、演讲必备互动训1. 9月15日 5分钟自选口才展示 练

5分钟自我介绍 2. 9月22日 演说家台风训练、讲师必备互动 (参照黄一鸣自我介绍)

3. 9月29日 30分钟情景路演 专业讲师素质、 4. 10月6日 暖场游戏 演讲稿设计 5. 10月13日 励志演讲 待定 6. 10月20日 导游 待定 7. 10月27日 会议主持 待定 8. 11月3日 主题培训 待定 9. 11月10日 待定 待定 10. 11月17日 待定 待定

学员互评表

评分者签名: (单项满分为10分，不足之处可用

文字在空格内表示。)

项目

形象气质 礼仪姿态 普通话 控场能力 互动交流 时间控制 演讲内容 得分汇总 学员编号

1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15.

范文二：基于角色的ORACLE用户权限管理设计

总第 242期 2009年第 12期

计算机与数字工程

Computer &D ig ital Eng ineer ing

V ol. 37N o. 12 89

基于角色的 ORACLE 用户权限管理设计 *

赵晓娟

(湖南城建职业技术学院信息工程系 湘 潭 411101)

摘 要 基于角色的用户权限管理是目前应用最广 泛的用 户管理 方法 , OR ACL E 10g 提供 的基于 角色用 户管理 系统 为系统的安全保障提供了基础。介绍了基于角色用 户管理 的原理 , 分 析了 ORA CL E 提供 的角色 和权限管 理机制 , 并 以一 个图书管理系统的数据库为例 , 进行了角色、 用户和权限的设计。测试结果表明 , 所设计的用户系统提供了用户访问系统的 最小权限 , 能够有效防止用户越权访问数据。

关键词 RBA C 用户权限管理 O RA CL E 数据访问安全

中图分类号 T P393

ORACL E U ser Role -based Rights M anagement D esign Z hao X iao juan

(I nf o rma tio n Eng ineer ing D epartm ent, H unan U r ban C onstr uct io n C olleg e , X iang tan 411101)

Abstract R o le -based user r ig hts manage ment is the mo st widely used me thod of user m anagem ent, OR A CL E 10g to pr o vide r o le -based use r m anagem ent system, t he system pro vides the basis f or secur ity. Intr oduce d the ro le -based user manag ement pr inciples, to pr o vide an ana lysis of the r o le of OR A CL E and the r ig hts m anagem ent mechanism, and a l-i br ar y ma na geme nt syste m dat abase as an exam ple, had a ro le in the desig n o f user s a nd pe rm issio ns. T est results show that user s o f the system designed to pr ov ide the user access to the sy stem o f least pr iv ilege, user s can ef fect ive ly pr eve nt unau -tho r ized access to da ta.

Key words R BAC, user r ig hts ma nageme nt, O RA CL E, data access secur it y

Class Nu mber T P393

1引言

ORACLE 数据库是一种应用于大型企业分布 式业务处理系统中的大型数据库系统。分布式数 据库是将一定数量的数据库服务器通过网络连接 起来 , 众多数据库服务器协同工作 , 为系统提供一 个统一的数据视图的大型网络系统。在网络环境 中 , 对数据的访问来自于网络中的任意位置和不同 的用户 , 为了保证众多的用户对数据库的访问 , 需 要严格控制每个用户的使用权限。传统基于用户 名的权限管理无法适应细化到表一级的要求 , 不仅 需要大量的空间来保存用户权限数据而且灵活性 差。 ORACLE 10g 采用基于角色的用户权限管理 系统 , 不仅提高了系统的安全性和灵活性 , 同时降 低了用户数据设计和管理的难度。以图书管理系 统的数据库为例 , 进行了用户权限设计 , 测试结果 表明 , 所设计的用户系统提供了用户访问系统的最 小权限 , 能够有效防止用户越权访问数据。

2基于角色的用户管理理论

基于角色的用户权限管理采用基于角色的访 问控制 (RBAC) 技术实现 , 它是在自主访问控制 [1]和强制访问控制 [2]的基础上发展而来 , 克服了自主 存取控制权限分离控制的缺点。将系统的权限赋 给不同的角色 , 用户不能直接得到权限 , 只有成为 角色的成员才能获得权限。

*收稿日期 :2009年 7月 29日 , 修回日期 :2009年 9月 3日 基金项目 :湖南省自然科学项目 (编号 :08D030; 07D018) 资助。 ::

90 赵晓娟 :基于角色的 O RA CL E 用户权限管理设计 第 37卷

角色用一般业务系统中的术语来说 , 就是业务 系统中的岗位、 职位或者分工。它和用户组最主要 的区别在于 :用户组是作为用户的一个集合来对待 的 , 并不涉及它的授权许可 ; 而角色则既是一个用 户的集合 , 又是一个授权许可的集合。角色是指具 有一定技能 , 可以执行某些工作的人员集合。通过 给成员赋予不 同的角色 , 对成员的多职 能进行表 达 , 提供约束成员不同权限范围变化的依据。角色 由系统管理员定义 , 角色成员的增减也只能由系统 管理员来执行 , 即只有系统管理员有权定义和分配 角色。用户与客体无直接联系 , 他只有通过角色才 享有所对应的权限 , 从而访问客体。因此用户不能 自主地将访问权限授给其他用户。

角色是对一类对象的一种描述 , 在数据库系统 中 , 一个角色可以对应一个或者多个用户。角色具 有特定的行为和特征 , 符合角色所有特征的用户即 属于该角色 , 因此 , 一个用户可以属于一个或者多 个角色 , 角色与用户之间是一种多对多的关系 , 如 图 1

所示。

图 1 角色与用户的对应关系

权限是用户具有的对数据库对象的访问能力 , 数据对象可以是表、 视图、 结构和存储过程等。权 限可以细分为很多种类 , 如 ORACLE 中的权限就 有几十种 , 如 CREAT E DAT ABASELINK 、 CRE -A TE VIEW 、 ADVISOR 等。因此用户的权限不仅 要具体的每个对象 , 而且要有详细的设置 , 这样就 能明确所有用户的操作能力。 RBA C 的基本模型 如图 2

所示。

图 2 基于角色控制 的基本模型

角色和权限的关联表示角色拥有的一组权限 的集合 , 一个角色可以具有多项权限 , 一项权限也 可以被赋予给多个不同的角色 , 它们之间也是多对 多的关系。基于角色访问控制的模型可描述为 :

[3]

p I P[u]only if (v r ) {rI R[u]and p I P[r]}R[u]表示用户 u 被分配的所有角色的集合 ; P [r]表示角色 r 被分配的权限的集合 ; P [u]表示用 户 u 拥有的权限的集合。

式中 u 表示用户 (User ) ; r 表示角色 (Role ) ; p 表示权限 (Privilege ) , 并假设 p I P [u]表示用户 u 具有某项权限 p 。

原则和最少权限原则 [4]。任务分离要求对于特定 的一个事务集合 , 没有一个人被允许来执行所有这 些事务。最常见的例子是 , 对于提起支付与授权支 付 , 不允许一个人同时处理这两项事务。最小权限 原则要求用户分配的权限不会多于完成某项工作 所必须的权限。确保最小权限要求辨别该用户的 工作 , 确定完成该项工作所需要的最小权限集合 , 并限制用户在这些权限而不是更大范围之内。

3 ORA CL E 的用户权限管理体系

系统权限、 对象 权限 以及 角色构 成了 ORA -CLE 数据库安全的基本 层次 [5], 他 们用来控制用 户对数据库的 访问和限 制用户所 执行的 SQL 语 句。 ORACLE 的权 限分为系统权限和实体权限 , 系统规定用户使用数据库的权限 , 实体权限是某种 权限用 户 对 其它 用 户 的 表或 视 图 的 存 取权 限。 ORACLE 权限以及角色定义如表 1所示。

表 1 ORA CL E 的权限和角色

权限或角色

描述

Sy stem pr ivilege An Oracle -defined privilege usually gr anted

only to and by administrators. System pr ivileges enable users to perform specific database operations.

O bject pr iv ileg e A privilege that controls access to a specific

object.

Ro le A gr oup o f priv ileg es or other r oles

在 访问 ORACLE 数据库时必须提供被授权 的用户账号和密码 , 可以通过管理员来创建一个账 号 , 并为其设置密码和其他属性。用户常见的属性 包括 :

#验证方法

#用户验证身份的密码 #访问的表空间 #表空间配额

所有的 ORACLE 数据库安装后 都包括 SYS 、 SYSTEM 、 SYSMAN 、 DBSNMP 这四个管理员帐户。

4 ORA CL E 权限管理

权限是用户对一项功能的执行权力。在 Ora -cle 中 , 根据系统管理方式不同 , 将权限分为系统权 限与实体权限两类。 4. 1 系统权限分类

系统权限是指是否被授权用户可以连接到数 据库上 , 在数据库中可以进行哪些系统操作。 OR -ACLE 的 系 统 权 限 主 要 有 DBA 、 RESOU RCE 、

第 37卷 (2009) 第 12期 计算机与数字工程 91

表 2ORA CL E 提供的管理账号清单

用户名 密码 描述

CT XSY S CT XSY S T he O racle T ext account

DBSN M P DBSNM P T he account used by t he M anag ement A gent co mpo nent of O racle Enterprise M anag -er to monito r and manag e the database

M DDA T A M DD AT A T he schema used by O racle Spatia l for stor ing G eo coder and r outer data

M DSY S M DSY S T he O racle Spatial and O racle inter M edia Lo cat or administr ator account

DM SY S DM SY S T he data mining account. DM SY S per for ms data mining operatio ns.

OL A PSY S M A N A GER T he account used to cr eate OL A P metadata st ruct ur es. T his account o wns the O L AP Cat alog (CW M L ite).

OR DPL U GI NS O RDPL U G INS T he O racle inter M edia user. P lugins supplied by O racle and third part y fo rmat plu -g ins ar e inst alled in this schema.

OR DSYS O RDSYS T he O racle inter M edia administ rato r acco unt

OU T L N O U T L N T he account that suppo rts plan st abilit y. Plan stability enables you t o mainta in the same executio n plans for the same SQ L statement s. O U T L N acts as a r ole to cen -tr ally manage metadata asso ciated w ith stor ed o utlines.

SI_INF ORM T N_ SCH EM A SI_INF OR M T N _

SCHEM A

T he account that stor es the info rmation v iews for the SQL /M M Still Imag e Standard

SYS CH AN G E_ON_

IN ST A L L

T he account used t o perfor m database administ ratio n t asks

SYSM A N CH AN G E_ON_ IN ST A L L T he account used to per for m O racle Ent erprise M anager database administration tasks. N ote that SY S and SYST EM can also perfo rm these tasks.

YST EM M A N A GER A nother account used to perfo rm dat abase administ ratio n tasks

DBA:拥有全部特权 , 是系统最高权 限 , 只有 DBA 才可以创建数据库结构。

RESOU RCE:拥有 Reso urce 权限的用户只可 以创建实体 , 不可以创建数据库结构。

CONNECT:拥有 Connect 权限的用户只可以 登录 Oracle, 不可以创建实体 , 不可以创建数据库 结构。

系统权限授权命令的使用语法 :

GRANT 权限名 TO 用户 |角色 |PU BLIC 其中 , PU BLIC 表示将权限赋给数据库中所有 的用户。

在进行用户权限管理时 , 普通用户授予 CON -NECT 、 RESOURCE 权限。 DBA 管 理 用 户授 予 CONNECT 、 RESOURCE 、 DBA 权限。

4. 2实体权限管理

实体权限是指用户对 具体的模式实体 (sche -m a) 所拥有的权限 , 实体权限主要包括 select, up -date, insert, alter, index, delete, all 等类型。 实体权限的授命令语法如下 :

GRANT 实体权限名 |ALL TO 用 户 |角色 | PUBLIC

其中 , ALL 表示实体的所有实体权限。 5图书管理系统的 RBA C 设计

以湖南城建职 业技 术学 院图 书 管理 系统 为 , 域中的用户操作人 员分 析出 角色 并为 角色分 配 初始权限 , 然 后 针 对具 体 岗 位设 置 创 建具 体 用 户账号 , 最后 根 据 该岗 位 的 职能 进 行 用户 权 限 的具体配制。

5. 1角色设计

根据图书管的行政编制和岗位行政职能 , 分析 出图书管理系统的角色包括馆长、 编目员、 采编员、 流通员四个角色。馆长能够操作整个数据库的对 象 , 并且具有创建和修改部门用户的权利。编目员 具有对目录表的修改权限。采编员具有对图书表 的修改权限。流通员具有存量表、 借出表和还书表 的修改权限 , 根据最小权利原则 , 流通员只能修改 这些表的数量字段内容。

5. 2用户设计

根据图书馆岗位设计的情况 , 最后确定馆长角 色包含用户数一个 , 编目用户 2个 , 采编用户 2个 , 流通用户 12个。

5. 3权限设计

用户属于某一个角色就具有了该角色所拥有 的所有权限 , 但是角色中的每个具体用户的权限还 是有一些差异 , 而这些差异就需要在具体用户的权 限上进行修改。 2个编目人员负责不同类型图书 的编目 , 所有编目员的权限就设置为他具体需要进 行编目的书所对应的表。 12个流通用户也是分别 在不同的借阅时管理不同类别的图书 , 因此也对他

92 赵晓娟 :基于角色的 O RA CL E 用户权限管理设计

第 37卷

6 结语

基于角色的存取控制这 一概念被 提出以来 , 便由于其自身的优点在理论模型和具体系统实现 两方面都引起 了人们很大的 兴趣 , 并 已经在 OR -ACLE 数据库系统中得到了应用。通过基于角色 用户权限管理 , 简化了用户管理难度 , 提供了系统 安全性和灵活性 , 可以让 不同级别的管 理人员和 操作人员能充分地、 有效地、 合理地访问数据库系 统。

参 考 文 献

[1]R avi Sandhu, P. Samar ati. A ccess Contr ol:Prin -ciples and P ractice [J]. IEEE Communicatio ns, 1994, 32

(9) :40~48

[2]朱虹 , 冯玉才 . DM 3强制 存取控制 设计与 实现 [J].华中理工大学学报 , 2000, 28(4) :26~29

[3]周俊 . 大型 信 息系 统用 户权 限 管理 的探 讨 与实 现 [J].计算应用研究 , 2004, (12) :143~144

[4]徐升华 , 陈思华 . 关系数 据库 系统中 基于 角色的 存 取控制 [J].计算机与现代化 , 2005, (4) :73~74

[5]Sushil Kumar, Antonio Romero, David Austin, et al. Oracle ?Database 2Day DBA 10g Release 2(10. 2) . Oracle

(上接第 49页 )

的增大 , 系统的吞吐量在中间一个阶段发生明显的 下降 , 继而缓慢下降 , 在最后阶段急剧下降 , 直至中 断通信 ; 图 6纵轴代表网络节点平均端到端时延数 值 , 单位为 :秒 (s) , 从图可以得到 , 随着降雨量的增 大 , 网络平均端到端时延在中间一个阶段发生明显 的上升 , 随后缓慢上升 , 直至通信中断为无穷大 ; 图 7纵轴代表网络 节点平 均抖动 率数值 , 单 位为秒 (s) , 从图可以得到 , 随着降雨量的增大 , 网络节点 平均抖动率在中间一个阶段发生明显的波动 , 随后 缓慢上升 ,

直至通信中断为无穷大。

综上所述 , Link -16数据链抗干扰能力比较好 , 天气因素对 Link -16数据链的网络性能影响较小 , 虽然在某些条件下 , 参数发生变化 , 但变化的幅度 并不大 , 能够保持较好的通信 , 在更加恶劣的环境

下就会引起通信中断。

4 结语

本文在结合 Link -16数据链的 特点与仿真软 件 QualN et 的优势的基础上 , 着重于使用 QualN et 网络仿真软件对 Link -16数据链网络进行了仿真 和性能分析 , 引入了评估 Link -16数据链网络性能 的性能指标 :网络节点吞吐量、 网络节点平均端到 端时延以及网络 节点平均 抖动率。根据 Link -16数据链的技术特性 , 使用 QualNet 对 Link -16数据 链工作过程进行了基本建模仿真 , 结合不同情况对 所得的性能指标详细对比分析 , 研究了天气情况对 Link -16数 据链 的 网络 性 能的 影 响。研 究 表明 :Link -16数据链的抗干扰能力比较好 , 能够在较为 恶劣的情况下维持通信。

参 考 文 献

[1]骆光明 , 杨斌 , 邱 致和 , 等 . 数据 链 ) 信息 系统连 接 武器系统的捷径 [M ]. 北京 :国防工业出版社 , 2008

[2]李卫 , 王杉 , 魏急波 . 基 于 O PN ET 的 L ink -16建 模 与仿真 [J].系统工程与电子技术 , 2006, 28(12)

[3]邢智 , 戴浩 . 基于 O PN ET 的 L ink -16数据链建模与 仿真 [J].军事运筹与系统工程 , 2005, 19(1)

[4]韩勇 , 陈强 , 王 建新 . 移 动 Ad -hoc 网 络仿 真工具 比 较 [J].通信技术 , 2008, 41(12)

[5]Q ualNet -4. 0-U ser p s -Guide. Scalable N etwo rk

T echno log ies, I nc. , 2007, 1

[6]孙戈 , 韩晓冰 , 张 衡伟 , 等 . 短 距离无 线通 信及组 网 技术 [M ]. 西安 :西安电子科技大学出版社 , 2008

[7]Q ualN et -4. 0-M o delL ibrar y -Wireless. Scalable Net -w o rk T echno log ies, Inc. , 2006, 11

[8]田 斌鹏 , 陈林 星 , 卢 建川 , 等 . 基于 Q ualN et 的战 术 ,

范文三：基于角色的ORACLE用户权限管理设计

3

基于角色的 O RA CL E 用户权限管理设计

赵晓娟

(湖南城建职业技术学院信息工程系 湘潭 411101)

摘 要 基于角色的用户权限管理是目前应用最广泛的用户管理方法 , O RA CL E 10g 提供的基于角色用户管理系统 为系统的安全保障提供了基础 。介绍了基于角色用户管理的原理 ,分析了 O RA CL E 提供的角色和权限管理机制 ,并以一 个图书管理系统的数据库为例 ,进行了角色 、用户和权限的设计 。测试结果表明 ,所设计的用户系统提供了用户访问系统的 最小权限 ,能够有效防止用户越权访问数据 。

关键词 RBA C 用户权限管理 O RA CL E 数据访问安全

中图分类号 T P393

O R A CL E U s e r R ol e2b as e d Ri g h ts M a n a ge m e n t D esi g n

Z h a o Xi a oj ua n

( )I nf o r m a t i o n En gi ne e r i ng D ep a r t me n t , H u n a n U r ba n C o ns t r uc t i o n C olle ge , Xi a n gt a n 411101

A b s t r a c t R ole2bas e d us e r ri g h ts m a na ge me n t is t h e m os t wi del y us e d me t h o d of us e r m a n a ge me n t , O R A CL E 10g t o p r o vi de r ole2bas e d us e r m a na ge me nt s ys t e m , t he s ys t e m p r o vi des t h e basis f o r s ec u ri t y . I nt r o duc e d t h e r ole2bas e d us e r m a n a ge me n t p ri ncip les , t o p r o vi de a n a n al ysis of t h e r ole of O R A CL E a n d t he ri g h ts m a na ge me n t me c h a nis m , a n d a li2 b r a r y ma n a ge me n t s ys t e m da t a bas e as a n e xa mp l e , h a d a r ole i n t he desi g n of use rs a n d p e r missi o ns . Tes t r es ul ts s h ow t h a t us e rs of t he s ys t e m desi g ne d t o p r ovi de t he us e r a cc ess t o t h e s ys t e m of le as t p ri vile ge , us e rs c a n ef f e c t i vel y p r e ve n t u n a u2 t h o riz e d a cc ess t o da t a .

Ke y w o r ds RB A C , us e r ri g h ts m a n a ge me nt , O R A CL E , da t a a cc ess se c ur i t y

Cl a s s N u m b e r T P393

系统 ,不仅提高了系统的安全性和灵活性 ,同时降 1 引言 低了用户数据设计和管理的难度 。以图书管理系

O RA CL E 数据库是一种应用于大型企业分布 统的数据库为例 ,进行了用户权限设计 , 测试结果 式业务处理系统中的大型数据库系统 。分布式数表明 ,所设计的用户系统提供了用户访问系统的最

小权限 ,能够有效防止用户越权访问数据 。 据库是将一定数量的数据库服务器通过网络连接

起来 ,众多数据库服务器协同工作 ,为系统提供一 2 基于角色的用户管理理论 个统一的数据视图的大型网络系统 。在网络环境

基于角色的用户权限管理采用基于角色的访 中 ,对数据的访问来自于网络中的任意位臵和不同 [ 1 ] ( ) 问控制 RB A C技术实现 ,它是在自主访问控制的用户 ,为了保证众多的用户对数据库的访问 ,需 [ 2 ] 和强制访问控制的基础上发展而来 ,克服了自主 要严格控制每个用户的使用权限 。传统基于用户 存取控制权限分离控制的缺点 。将系统的权限赋 名的权限管理无法适应细化到表一级的要求 ,不仅 给不同的角色 ,用户不能直接得到权限 , 只有成为 需要大量的空间来保存用户权限数据而且灵活性 角色的成员才能获得权限 。

差 。O RA CL E 10 g 采用基于角色的用户权限管理

3 收稿日期 :2009 年 7 月 29 日 ,修回日期 :2009 年 9 月 3 日

基金项目 :湖南省自然科学项目 (编号 :08D030 ;07D018) 资助 。

作者简介 :赵晓娟 ,女 ,工程师 ,研究方向 :人工智能和信息安全 。

90 赵晓娟 :基于角色的 O RACL E 用户权限管理设计第 37 卷

[ 4 ] 原则和最少权限原则。任务分离要求对于特定 角色用一般业务系统中的术语来说 ,就是业务

系统中的岗位 、职位或者分工 。它和用户组最主要 的一个事务集合 ,没有一个人被允许来执行所有这 的区别在于 :用户组是作为用户的一个集合来对待 些事务 。最常见的例子是 ,对于提起支付与授权支

的 ,并不涉及它的授权许可 ; 而角色则既是一个用 付 ,不允许一个人同时处理这两项事务 。最小权限 户的集合 ,又是一个授权许可的集合 。角色是指具 原则要求用户分配的权限不会多于完成某项工作 有一定技能 ,可以执行某些工作的人员集合 。通过 所必须的权限 。确保最小权限要求辨别该用户的 给成员赋 予不 同 的角 色 , 对成 员 的多 职能 进 行 表 工作 ,确定完成该项工作所需要的最小权限集合 , 达 ,提供约束成员不同权限范围变化的依据 。角色 并限制用户在这些权限而不是更大范围之内 。 由系统管理员定义 ,角色成员的增减也只能由系统 3 O RA CL E 的用户权限管理体系 管理员来执行 ,即只有系统管理员有权定义和分配

系统权 限 、对 象 权 限 以 及 角 色 构 成 了 O RA2 角色 。用户与客体无直接联系 ,他只有通过角色才

[ 5 ] 享有所对应的权限 ,从而访问客体 。因此用户不能 CL E 数据库 安全 的基 本 层次, 他 们用 来控 制用 自主地将访问权限授给其他用户 。 户对数据库 的 访 问 和 限 制 用 户 所 执 行 的 SQL 语

角色是对一类对象的一种描述 ,在数据库系统 句 。O RA CL E 的权限分为系统权限和实体权限 , 中 ,一个角色可以对应一个或者多个用户 。角色具 系统规定用户使用数据库的权限 ,实体权限是某种

权限 用 户 对 其 它 用 户 的 表 或 视 图 的 存 取 权 限 。 有特定的行为和特征 ,符合角色所有特征的用户即

O RA CL E 权限以及角色定义如表 1 所示 。 属于该角色 ,因此 ,一个用户可以属于一个或者多

表 1 O RA CL E 的权限和角色 个角色 ,角色与用户之间是一种多对多的关系 ,如

图 1 所示 。 权限或角色描述

2defined p rivilege usually granted An OracleSystem p rivilege

o nly to and by administ rato rs. System

p rivileges enable users to perfo rm specific

图 1 角色与用户的对应关系 database operations.

Object p rivilege A p rivilege t hat co nt rol s access to a specific 权限是用户具有的对数据库对象的访问能力 , o bject . 数据对象可以是表 、视图 、结构和存储过程等 。权 Role A gro up of p rivilege s o r o t he r role s 限可以细分为很多种类 ,如 O RA CL E 中的权限就 在访问 O RA CL E 数据库时必须提供被 授权 有几十种 , 如 CR EA T E DA TAB A S EL IN K、CR E2 的用户账号和密码 ,可以通过管理员来创建一个账 A T E V I EW 、ADV ISO R 等 。因此用户的权限不仅 号 ,并为其设臵密码和其他属性 。用户常见的属性 要具体的每个对象 ,而且要有详细的设臵 ,这样就 包括 :

能明确所有用户的操作能力 。RB A C 的基本模型 〃验证方法

如图 2 所示 。 〃用户验证身份的密码

〃访问的表空间

〃表空间配额 图 2 基于角色控制的基本模型

所有的 ORACL E 数据 库 安装 后都 包 括 S YS、 角色和权限的关联表示角色拥有的一组权限

S YS TEM 、S YSMAN 、DBSNMP 这四个管理员帐户 。 的集合 ,一个角色可以具有多项权限 ,一项权限也

可以被赋予给多个不同的角色 ,它们之间也是多对 4 O RA CL E 权限管理 [ 3 ]多的关系 。基于角色访问控制的模型可描述为 :

权限是用户对一项功能的执行权力 。在 O ra2 ( ) p ?P[ u ] o nly if v r{ r ?R[ u] and p ?P[ r]}

R [ u ]表示用户 u 被分配的所有角色的集合 ; P cle 中 ,根据系统管理方式不同 ,将权限分为系统权

限与实体权限两类 。 [ r ]表示角色 r 被分配的权限的集合 ; P[ u ]表示用

4 . 1 系统权限分类 户 u 拥有的权限的集合 。

式中 u 表示用户 ( U se r) ; r 表示角色 ( Role) ; p 系统权限是指是否被授权用户可以连接到数 表示权限 ( Privilege) , 并假设 p ?P[ u ]表示用户 u 据库上 ,在数据库中可以进行哪些系统操作 。O R2

A CL E 的 系 统 权 限 主 要 有 DB A 、R ESO U RC E 、 具有某项权限 p 。 基于角色的存取控制安全原则

CO N N EC T 三类 。 包括任务分离

() 91 计算机与数字工程第 37 卷 2009第 12 期

表 2 O RA CL E 提供的管理账号清单

用户名密码描述

C T XS YS C T XS YS The O racle Text acco unt

The acco unt used by t he Ma nagement A gent co mpo nent of O racle Enterp ri se Ma nag2 DB SN M P DB SN M P

er to mo nito r a nd ma nage t he databa se

The schema used by O racle Sp atial fo r sto ring Geoco der a nd ro ut er data MDDA TA MDDA TA

The O racle Sp atial a nd O racle inter Media Locato r admini st rato r acco unt MDS YS MDS YS

The data mining acco unt . DM S YS p erfo r ms dat a mi ning op eratio ns. DM S YS DM S YS

The acco unt used to creat e OL A P met adata st r uct ure s. Thi s acco unt o w ns t he OL A PS YS MA N A GER

( ) OL A P Catalo g CWML ite.

The O racle int er Media user . Pl ugins supplied by O racle a nd t hir d pa rt y fo r mat pl u2 O RD PL U GIN S O RD PL U GIN S

gins a re installed in t hi s schema .

The O racle int er Media admini st rato r acco unt O RDS YS O RDS YS

The acco unt t hat suppo rt s plan sta bilit y. Pla n sta bilit y ena ble s yo u to maint ai n t he OU TL N O U TL N

sa me executio n pla ns fo r t he sa me SQL statement s. O U TL N act s a s a role to cen2

t rally ma nage metadata a ssociated wit h sto red o utlines.

The acco unt t hat sto res t he info r matio n view s fo r t he SQL / MM Still Image Sta nda r d SI_ IN FO RM TN_ SI_ IN FO RM TN_

SC H EMA SC H EMA

S YS C HA N GE_ON_ The acco unt used to p erfo r m dat aba se admini st ratio n ta sks

IN S TALL

S YSMA N C HA N GE_ON_ The acco unt used to p erfo r m O racle Enterp ri se Ma nager dat aba se admini st ratio n

IN S TALL t a sk s. No te t hat S YS a nd S YS T EM ca n al so p erfo r m t hese ta sks. YS T EM MA N A GER A no t her acco unt used to p erfo r m dat aba se admini st ratio n ta sks

DB A : 拥有全部特权 , 是系统 最高 权限 , 只 有域中的用户操作 人 员 分 析 出 角 色 并 为 角 色 分 配 DB A 才可以创建数据库结构 。 初始权限 , 然 后 针 对 具 体 岗 位 设 臵 创 建 具 体 用

R ESO U RC E :拥有 Re so urce 权限的用户只可 户账号 ,最 后 根 据 该 岗 位 的 职 能 进 行 用 户 权 限

的具体配制 。 以创建实体 ,不可以创建数据库结构 。

5 . 1 角色设计 CO N N EC T :拥有 Co nnect 权限的用户只可以

登录 O racle ,不可以创建实体 ,不可以创建数据库 根据图书管的行政编制和岗位行政职能 ,分析 结构 。 出图书管理系统的角色包括馆长 、编目员 、采编员 、

系统权限授权命令的使用语法 : 流通员四个角色 。馆长能够操作整个数据库的对

GRA N T 权限名 TO 用户| 角色| PUBL IC 象 ,并且具有创建和修改部门用户的权利 。编目员

其中 , PUBL IC 表示将权限赋给数据库中所有 具有对目录表的修改权限 。采编员具有对图书表 的用户 。 的修改权限 。流通员具有存量表 、借出表和还书表

在进行用户权限管理时 ,普通用户授予 CON2 的修改权限 ,根据最小权利原则 ,流通员只能修改 N EC T 、R ESO U RC E 权 限 。DB A 管 理 用 户 授 予 这些表的数量字段内容 。

CON N EC T 、R ESO U RC E 、DB A 权限 。 5 . 2 用户设计

4 . 2 实体权限管理 根据图书馆岗位设计的情况 ,最后确定馆长角

实体权限是指用户对具体的模 式 实体 ( sche2 色包含用户数一个 ,编目用户 2 个 ,采编用户 2 个 , ma) 所拥有的权限 ,实体权限主要包括 select , up2 流通用户 12 个 。

5 . 3 权限设计 dat e , i n ser t , alt er , i nde x , delet e , all 等类型 。

用户属于某一个角色就具有了该角色所拥有 实体权限的授命令语法如下 :

GRA N T 实体权限名 | AL L TO 用 户 | 角 色 | 的所有权限 ,但是角色中的每个具体用户的权限还 PUBL IC 是有一些差异 ,而这些差异就需要在具体用户的权

其中 ,AL L 表示实体的所有实体权限 。 限上进行修改 。2 个编目人员负责不同类型图书

的编目 ,所有编目员的权限就设臵为他具体需要进 图书管理系统的 RB A C 设计5 行编目的书所对应的表 。12 个流通用户也是分别

在不同的借阅时管理不同类别的图书 ,因此也对他 以湖南城建 职 业 技 术 学 院 图 书 管 理 系 统 为

们的权限进行了进一步的细化 。 背景进 行 数 据 库 的 RB A C 设 计 , 首 先 以 工 作 领

92 赵晓娟 :基于角色的 O RACL E 用户权限管理设计第 37 卷

参 考 文 献 6 结语 [ 1 ] Ravi Sa ndhu , P. Sa marati . Acce ss Co nt rol : Prin2 ciple s a nd Practice [ J ] . IE E E Co mmunicatio ns , 1994 , 32 基于角色的存 取控 制 这 一 概 念 被 提 出 以 来 , () 9:40,48 便由于其自身的优点在理论模型和具体系统实现 [ 2 ]朱虹 ,冯玉才 . DM3 强制存取控制设计与实现 [ J ] . 两方面都引起 了 人们 很大 的 兴趣 , 并 已经 在 O R2 华中理工大学学报 ,2000 ,28 (4) :26,29

[ 3 ]周俊 . 大型信息系 统 用 户 权 限 管 理 的 探 讨 与 实 现 A CL E 数据库系统中得到了应用 。通过基于角色

[J ] . 计算应用研究 ,2004 , (12) :143,144 用户权限管理 ,简化了用户管理难度 ,提供了系统 [ 4 ]徐升华 ,陈思华 . 关系数据库系统中基于角色的存 安全性和灵活性 , 可 以让 不同 级 别的 管理 人 员和 () 取控制 [J ] . 计算机与现代化 ,2005 , 4:73,74 操作人员能充分地 、有效地 、合理地访问数据库系 [ 5 ] Sushil Kumar , Antonio Ro mero , David Austin , et al.

() 统 。 Oracle Database 2 Day DBA 10g Release 2 10. 2. Oracle ()下就会引起通信中断 。上接第 49 页

的增大 ,系统的吞吐量在中间一个阶段发生明显的 4 结语 下降 ,继而缓慢下降 ,在最后阶段急剧下降 ,直至中

本文在结合 L i nk216 数据链的 特点 与仿 真软 断通信 ;图 6 纵轴代表网络节点平均端到端时延数

件 Q ual Net 的优势的基础上 ,着重于使用 Q ual Net ( ) 值 ,单位为 :秒 s,从图可以得到 ,随着降雨量的增 网络仿真软件对 L i n k216 数据链网络进行了仿真 大 ,网络平均端到端时延在中间一个阶段发生明显 和性能分析 ,引入了评估 L i nk216 数据链网络性能 的上升 ,随后缓慢上升 ,直至通信中断为无穷大 ;图 的性能指标 :网络节点吞吐量 、网络节点平均端到 7 纵轴代 表 网 络 节 点 平 均 抖 动 率 数 值 , 单 位 为 秒 端时延以及 网 络 节 点 平 均 抖 动 率 。根 据 L i nk216

数据链的技术特性 ,使用 Q ual Net 对 L i nk216 数据 ( ) s,从图可以得到 ,随着降雨量的增大 ,网络节点

链工作过程进行了基本建模仿真 ,结合不同情况对 平均抖动率在中间一个阶段发生明显的波动 ,随后

所得的性能指标详细对比分析 ,研究了天气情况对 缓慢上升 ,直至通信中断为无穷大 。 L i n k216 数 据 链 的 网 络 性 能 的 影 响 。研 究 表 明 :

L i n k216 数据链的抗干扰能力比较好 ,能够在较为

恶劣的情况下维持通信 。

参 考 文 献

[ 1 ]骆光明 ,杨斌 ,邱致和 ,等 . 数据链 —信息系统连接

武器系统的捷径 [ M ] . 北京 :国防工业出版社 ,2008

[ 2 ]李卫 ,王杉 ,魏急波 . 基于 O PN E T 的 L ink216 建模

()与仿真 [J ] . 系统工程与电子技术 ,2006 ,28 12

[ 3 ]邢智 ,戴浩 . 基于 O PN E T 的 L ink216 数据链建模与

()仿真 [J ] . 军事运筹与系统工程 ,2005 ,19 1

[ 4 ]韩勇 ,陈强 ,王建新 . 移动 A d2hoc 网络仿真工具比

()较 [J ] . 通信技术 ,2008 ,41 12

[ 5 ] Q ualNet24 . 02U serπs2 Guide. Scala ble Net wo r k

Technolo gies , Inc. ,2007 ,1

[ 6 ]孙戈 ,韩晓冰 ,张衡伟 ,等 . 短距离无线通信及组网

技术 [ M ] . 西安 :西安电子科技大学出版社 ,2008 综上所述 ,L i nk216 数据链抗干扰能力比较好 ,

[ 7 ] Q ualNet24 . 02Mo delL ibrar y2Wireless. Scala ble Net2 天气因素对 L i nk216 数据链的网络性能影响较小 , wo r k Technolo gie s , Inc . ,2006 ,11 虽然在某些条件下 ,参数发生变化 ,但变化的幅度 [ 8 ] 田斌鹏 ,陈林星 ,卢建川 ,等 . 基于 Q ualNet 的战术 并不大 ,能够保持较好的通信 ,在更加恶劣的环境 ()数据链多链建模与仿真 [J ] . 电讯技术 ,2008 , 3

范文四：系统用户权限管理设计

系统用户权限管理设计

系统用户权限管理设计

需求陈述

不同职责的人员，对于系统操作的权限应该是不同的。优秀的业务系统，这是最基本的功能。

可以对“组”进行权限分配。对于一个大企业的业务系统来说，如果要求管理员为其下员工逐一分配系统操作权限的话，是件耗时且不够方便的事情。所以，系统中就提出了对“组”进行操作的概念，将权限一致的人员编入同一组，然后对该组进行权限分配。

权限管理系统应该是可扩展的。它应该可以加入到任何带有权限管理功能的系统中。就像是组件一样的可以被不断的重用，而不是每开发一套管理系统，就要针对权限管理部分进行重新开发。

满足业务系统中的功能权限。传统业务系统中，存在着两种权限管理，其一是功能权限的管理，而另外一种则是资源权限的管理，在不同系统之间，功能权限是可以重用的，而资源权限则不能。

设计

我们先来分析一下数据库结构:

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

范文五：角色权限表设计

用户 ·角色 ·权限 ·表

一.引言

因为做过的一些系统的权限管理的功能虽然在逐步完善,但总有些不尽人意的地方,总想抽个 时间来更好的思考一下权限系统的设计。

权限系统一直以来是我们应用系统不可缺少的一个部分,若每个应用系统都重新对系统的权限 进行设计,以满足不同系统用户的需求,将会浪费我们不少宝贵时间,所以花时间来设计一个相对通用的 权限系统是很有意义的。

二.设计目标

设计一个灵活、通用、方便的权限管理系统。

在这个系统中,我们需要对系统的所有资源进行权限控制,那么系统中的资源包括哪些呢?我们可 以把这些资源简单概括为静态资源(功能操作、数据列)和动态资源(数据),也分别称为对象资源和数 据资源,后者是我们在系统设计与实现中的叫法。

系统的目标就是对应用系统的所有对象资源和数据资源进行权限控制,比如应用系统的功能菜单、 各个界面的按钮、数据显示的列以及各种行级数据进行权限的操控。

三.相关对象及其关系

大概理清了一下权限系统的相关概念,如下所示:

1. 权限

系统的所有权限信息。权限具有上下级关系,是一个树状的结构。下面来看一个例子

系统管理

用户管理

查看用户

新增用户

修改用户

删除用户

对于上面的每个权限,又存在两种情况,一个是只是可访问,另一种是可授权,例如对于 “ 查看 用户 ” 这个权限,如果用户只被授予 “ 可访问 ” ,那么他就不能将他所具有的这个权限分配给其他人。

2. 用户

应用系统的具体操作者, 用户可以自己拥有权限信息, 可以归属于 0~n 个角色, 可属于 0~n 个组。 他的权限集是自身具有的权限、所属的各角色具有的权限、所属的各组具有的权限的合集。它与权限、角 色、组之间的关系都是 n 对 n 的关系。

3. 角色

为了对许多拥有相似权限的用户进行分类管理,定义了角色的概念,例如系统管理员、管理员、用 户、访客等角色。角色具有上下级关系,可以形成树状视图,父级角色的权限是自身及它的所有子角色的 权限的综合。父级角色的用户、父级角色的组同理可推。

4. 组

为了更好地管理用户,对用户进行分组归类,简称为用户分组。组也具有上下级关系,可以形成树 状视图。在实际情况中,我们知道,组也可以具有自己的角色信息、权限信息。这让我想到我们的 QQ 用 户群,一个群可以有多个用户,一个用户也可以加入多个群。每个群具有自己的权限信息。例如查看群共 享。 QQ 群也可以具有自己的角色信息,例如普通群、高级群等。

针对上面提出的四种类型的对象,让我们通过图来看看他们之间的关系。

有上图中可以看出,这四者的关系很复杂,而实际的情况比这个图还要复杂,权限、角色、组都 具有上下级关系,权限管理是应用系统中比较棘手的问题,要设计一个通用的权限管理系统,工作量也着 实不小。

当然对于有些项目,权限问题并不是那么复杂。有的只需要牵涉到权限和用户两种类型的对象,只 需要给用户分配权限即可。

在另一些情况中,引入了角色对象,例如基于角色的权限系统, 只需要给角色分配权限,用户都隶 属于角色,不需要单独为用户分配角色信息。

通用权限管理设计篇(二) —— 数据库设计

国庆前整的通用权限设计的数据库初步设计部分,现在贴上来。

理清了对象关系之后,让我们接着来进行数据库的设计。在数据库建模时,对于 N 对 N 的

关系, 一般需要加入一个关联表来表示关联的两者的关系。 初步估计一下, 本系统至少需要十张表, 分别为:权限表、用户表、角色表、组表、用户权限关联表、用

户角色关联表、角色权限关联表、组权限关联表、组角色关联表、用户属组关联表。当然还可能引 出一些相关的表。下面让我们在 PowerDesigner 中画出各表吧。

各表及其关系如下:

1. 用户表

2. 角色表

3. 权限表

4. 组表

5. 角色权限表

6. 组权限表

7. 组角色表

8. 用户权限表

9. 用户角色表

10. 用户组表

11. 组织表

12. 操作日志表

通用权限管理系统设计篇(三) —— 概要设计说明书

在前两篇文章中,不少朋友对我的设计提出了异议,认为过于复杂,当然在实际的各种系统的权限 管理模块中,并不像这里设计得那么复杂,我以前所做的系统中,

由只有用户和权限的,有只有用户、权限和角色的,还有一个系统用到了用户、权限、角色、组概 念,这个系统是我在思考以前所做系统的权限管理部分中找到的一

些共性而想到的一个设计方案, 当然还会有不少设计不到位的地方, 在设计开发过程中会慢慢改进, 这个系统权当学习只用,各位朋友的好的建议我都会考虑到设计

中,感谢各位朋友的支持。

今天抽时间整了一份概念设计出来,还有一些地方尚未考虑清楚,贴出 1.0版,希望各位朋友提 出宝贵建议。

大家也可以点击此处《通用权限管理概要设计说明书》自行下载,这是 1.0版本,有些地方可能 还会进行部分修改,有兴趣的朋友请关注我的 blog 。

1. 引言

1.1 编写目的

本文档对通用权限管理系统的总体设计、接口设计、界面总体设计、数据结构设计、系统出错处理 设计以及系统安全数据进行了说明。

1.2 背景

a 、 软件系统的名称:通用权限管理系统;

b 、 任务提出者、开发者:谢星星;

c 、 在 J2EE 的 web 系统中需要使用权限管理的系统。

1.3 术语

本系统:通用权限管理系统;

SSH :英文全称是 Secure Shell。

1.4 预期读者与阅读建议

1.5 参考资料

《通用权限管理系统需求规格说明书》

《通用权限管理系统数据库设计说明书》

2. 总体设计

2.1 设计目标

权限系统一直以来是我们应用系统不可缺少的一个部分,若每个应用系统都重新对系统的权限进行 设计,以满足不同系统用户的需求,将会浪费我们不少宝贵时间,所以花时间来设计一个相对通用的权限 系统是很有意义的。

本系统的设计目标是对应用系统的所有资源进行权限控制,比如应用系统的功能菜单、各个界面的 按钮控件等进行权限的操控。

2.2 运行环境

操作系统:Windows 系统操作系统和 Linux 系列操作系统。

2.3 网络结构

通用权限管理系统可采用 Java Swing实现,可以在桌面应用和 Web 应用系统中进行调用。如果需 要要适应所有开发语言,可以将其 API 发布到 WEB Service上。暂时用 Java Swing实现。

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. 界面总体设计

本节将阐述用户界面的实现,在此之前对页面元素做如下约定:

4.1 组权限管理

4.1.1包含用户

当用户选择 “ 修改 ” 按钮时, 弹出用户列表, 操作人可以通过勾选或取消勾选来修改该组所包含的用户。 4.1.2所属角色

当用户选择 “ 修改 ” 按钮时,弹出角色树形结构,操作人可以通过勾选或取消勾选来修改该组所属的角 色。

4.1.3组权限

4.1.4总权限

通过对已具有的权限取消勾选,或为某权限添加勾选,来修改组的权限信息,点击 “ 保存 ” 按钮保存修 改信息。

4.1.5组管理

在下图中,选中组 1的时候,右键点击可弹出组的操作列表,包括添加、删除和修改按钮,从 而完成在该组下添加子组,删除该组以及修改该组的功能。

4.2 角色权限管理

4.2.1包含用户

当用户选择 “ 修改 ” 按钮时,弹出用户列表,操作人可以通过勾选或取消勾选来修改该角色所包含的用 户。

4.2.2包含组

当用户选择 “ 修改 ” 按钮时, 弹出用户列表, 操作人可以通过勾选或取消勾选来修改该角色所包含的组。 4.2.3角色权限

通过对已具有的权限取消勾选,或为某权限添加勾选,来修改角色的权限信息,点击 “ 保存 ” 按钮保存 修改信息。

4.2.4管理角色

在下图中,选中组 1的时候,右键点击可弹出组的操作列表,包括添加、删除和修改按钮,从 而完成在该组下添加子组,删除该组以及修改该组的功能。

4.3 用户权限管理

4.3.1所属角色

当用户选择 “ 修改 ” 按钮时,弹出角色树形结构,操作人可以通过勾选或取消勾选来修改该用户所属的 角色。

4.3.2所属组

当用户选择 “ 修改 ” 按钮时,弹出组的树形结构,操作人可以通过勾选或取消勾选来修改该用户所属的 组。

4.3.3用户权限

通过对已具有的权限取消勾选,或为某权限添加勾选,来修改用户的权限信息,点击 “ 保存 ” 按钮保存 修改信息。

4.3.4总权限

通过对已具有的权限取消勾选,或为某权限添加勾选,来修改用户的权限信息,点击 “ 保存 ” 按钮保存 修改信息。

4.3.5用户管理

当选择了某用户时,点击右键,弹出菜单列表:修改、删除、取消,点击修改和删除按钮可以 实现用户的删除和修改功能。

选择某个组织, 例如下表中的 “ 广州分公司 ” , 弹出菜单列表:添加子组织、 删除组织、 修改组织、 添加用户、取消,点击添加用户按钮可以实现用户的添加功能。

4.3.6组织管理

选择某个组织, 例如下表中的 “ 广州分公司 ” , 弹出菜单列表:添加子组织、 删除组织、 修改组织、 添加用户、取消,点击添加子组织、删除组织、修改组织按钮可以实现组织的添加、删除和修改功能。

4.4 操作日志管理

4.4.1查询操作日志

输入上图表单中的查询信息后,点击 “ 查询 ” 按钮,可查询出符合条件的信息。

4.4.2删除操作日志

输入上图表单中的查询信息后,点击 “ 查询 ” 按钮,可查询出符合条件的信息。而后点击 “ 删除 ” 按钮, 可删除符合查询条件的操作日志。

5. 数据结构设计

数据库设计的模型请参见《通用权限管理系统 _数据库模型 .pdm 》。表的说明请参见《通用权限管理 系统数据库设计说明书》。

5.1 设计原则

5.1.1命名的规范

数据库中表、主键、外键、索引的命名都以统一的规则,采用大小写敏感的形式,各种对象命名长 度不要超过 30个字符,这样便于应用系统适应不同的数据库平台。

5.1.2数据的一致性和完整性

为了保证数据库的一致性和完整性,往往通过表间关联的方式来尽可能的降低数据的冗余。表间关 联是一种强制性措施,建立后,对父表(Parent Table)和子表 (Child Table)的插入、更新、删除操作均要 占用系统的开销。如果数据冗余低,数据的完整性容易得到保证,但增加了表间连接查询的操作,为了提 高系统的响应时间,合理的数据冗余也是必要的。使用规则(Rule )和约束(Check )来防止系统操作人 员误输入造成数据的错误是设计人员的另一种常用手段,但是,不必要的规则和约束也会占用系统的不必 要开销,需要注意的是,约束对数据的有效性验证要比规则快。所有这些,需要在设计阶段应根据系统操 作的类型、频度加以均衡考虑。

5.2 数据库环境说明

数据库:MySql5.0

设计库建模工具:PowerDesigner12.0

5.3 数据库命名规则

表名以 T 开头,外键以 FK 开头,索引以 INDEX 开头。

5.4 逻辑结构

pdm 文件的名称为:《通用权限管理系统 _数据库模型》。

5.5 物理存储

通过数据库建模工具 PowerDesigner12可以将 pdm 导出为文本文件, 将数据库脚本放入文本文件中 保存。

5.6 数据备份和恢复

数据库需定期备份(每天备份一次),备份文件格式为 backup_yyyyMMdd,数据库被破坏时,利用 最新的备份文件进行恢复。

6. 系统出错处理设计

6.1 出错信息

6.2 补救措施

为了当某些故障发生时,对系统进行及时的补救,提供如下补救措施:

a .后备技术 定期对数据库信息进行备份(每天一次),当数据库因某种原因被破坏时,以最新的 数据库脚本进行恢复;。

7. 系统安全设计

7.1 数据传输安全性设计

SSH 可以通过将联机的封包加密的技术进行资料的传递 ; 使用 SSH 可以把传输的所有数据进行加密, 即使有人截获到数据也无法得到有用的信息。 同时数据经过压缩, 大大地加快了传输的速度。 通过 SSH 的 使用,可以确保资料传输比较安全并且传输效率较高。

7.2 应用系统安全性设计

操作人的操作信息需要提供操作记录。对系统的异常信息需进行记录,已备以后查看。只有授权用 户才能登录系统,对于某个操作,需要具有相应权限才能进行操作。

7.3 数据存储安全性设计

对于用户的密码等敏感信息采用 MD5进行加密。

转载请注明出处范文大全网 » 通用角色权限管理系统设计通用