用户表角色权限表的设计说明

.用户角色权限表的设计一引言 因为做过的一些系统的权限管理的功能虽然在逐步完善,但总有些不尽人意的地方,总想抽个时间来更好的思考一下权限系统的设计。 权限系统一直以来是我们应用系统不可缺少的一个部分,若每个应用系统都重新对系统的权限进行设计,以满足不同系统用户的需求,将会浪费我们不少宝贵时间,所以花时间来设计一个相对通用的权限系统是很有意义的。二设计目标 设计一个灵活、通用、方便的权限管理系统。 在这个系统中,我们需要对系统的所有资源进行权限控制,那么系统中的资源包括哪些呢？我们可以把这些资源简单概括为静态资源功能操作、数据列和动态资源数据,也分别称为对象资源和数据资源,后者是我们在系统设计与实现中的叫法。系统的目标就是对应用系统的所有对象资源和数据资源进行权限控制,比如应用系统的功能菜单、各个界面的按钮、数据显示的列以及各种行级数据进行权限的操控。三相关对象及其关系 大概理清了一下权限系统的相关概念,如下所示：1. 权限系统的所有权限信息。权限具有上下级关系,是一个树状的结构。下面来看一个例子系统管理 用户管理 查看用户 新增用户 修改用户 删除用户 对于上面的每个权限,又存在两种情况,一个是只是可访问,另一种是可授权,例如对于查看用户这个权限,如果用户只被授予可访问,那么他就不能将他所具有的这个权限分配给其他人。2. 用户应用系统的具体操作者,用户可以自己拥有权限信息,可以归属于0n个角色,可属于0n个组。他的权限集是自身具有的权限、所属的各角色具有的权限、所属的各组具有的权限的合集。它与权限、角色、组之间的关系都是n对n的关系。3. 角色为了对许多拥有相似权限的用户进行分类管理,定义了角色的概念,例如系统管理员、管理员、用户、访客等角色。角色具有上下级关系,可以形成树状视图,父级角色的权限是自身及它的所有子角色的权限的综合。父级角色的用户、父级角色的组同理可推。4. 组为了更好地管理用户,对用户进行分组归类,简称为用户分组。组也具有上下级关系,可以形成树状视图。在实际情况中,我们知道,组也可以具有自己的角色信息、权限信息。这让我想到我们的QQ用户群,一个群可以有多个用户,一个用户也可以加入多个群。每个群具有自己的权限信息。例如查看群共享。也可以具有自己的角色信息,例如普通群、高级群等。针对上面提出的四种类型的对象,让我们通过图来看看他们之间的关系。有上图中可以看出,这四者的关系很复杂,而实际的情况比这个图还要复杂,权限、角色、组都具有上下级关系,权限管理是应用系统中比较棘手的问题,要设计一个通用的权限管理系统,工作量也着实不小。当然对于有些项目,权限问题并不是那么复杂。有的只需要牵涉到权限和用户两种类型的对象,只需要给用户分配权限即可。在另一些情况中,引入了角色对象,例如基于角色的权限系统, 只需要给角色分配权限,用户都隶属于角色,不需要单独为用户分配角色信息。通用权限管理设计篇二数据库设计 国庆前整的通用权限设计的数据库初步设计部分,现在贴上来。理清了对象关系之后,让我们接着来进行数据库的设计。在数据库建模时,对于N对N的关系,一般需要加入一个关联表来表示关联的两者的关系。初步估计一下,本系统至少需要十张表,分别为：权限表、用户表、角色表、组表、用户权限关联表、用户角色关联表、角色权限关联表、组权限关联表、组角色关联表、用户属组关联表。当然还可能引出一些相关的表。下面让我们在PowerDesigner中画出各表吧。 各表及其关系如下：1. 用户表用户表TUser字段名称字段类型备注记录标识tu_idbigintpk, not null所属组织to_idbigintfk, not null登录帐号login_namevarcharnot null用户密码passwordvarcharnot null用户姓名vsernamevarcharnot null手机号mobilevarchar电子邮箱emailvarchar创建时间gen_timedatetimenot null登录时间login_timedatetime上次登录时间last_login_timedatetime登录次数countbigintnot null2. 角色表角色表TRole字段名称字段类型备注角色IDtr_idbigintpk, not null父级角色IDparent_tr_idbigintnot null角色名称role_namevarcharnot null创建时间gen_timedatetimenot null角色描述descriptionvarchar3. 权限表权限表TRight字段名称字段类型备注权限IDtr_idbigintpk, not null父权限parent_tr_idbigintnot null权限名称right_namevarcharnot null权限描述descriptionvarchar4. 组表组表TGroup字段名称字段类型备注组IDtg_idbigintpk, not null组名称group_namevarcharnot null父组parent_tg_idbigintnot null创建时间gen_timedatetimenot null组描述descriptionvarchar5. 角色权限表角色权限表TRoleRightRelation字段名称字段类型备注记录标识trr_idbigintpk, not null角色Role_idbigintfk, not null权限right_idbigintfk, not null权限类型right_typeintnot null0:可访问,1:可授权6. 组权限表组权限表TGroupRightRelation字段名称字段类型备注记录标识tgr_idbigintpk, not null组tg_idbigintfk, not null权限tr_idbigintfk, not null权限类型right_typeintnot null0:可访问,1:可授权7. 组角色表组角色表TGroupRoleRelation字段名称字段类型备注记录标识tgr_idbigintpk, not null组tg_idbigintfk, not null角色tr_idbigintpk, not null8. 用户权限表用户权限表TUserRightRelation字段名称字段类型备注记录标识tur_idbigintpk, not null用户tu_idbigintfk, not null权限tr_idbigintfk, not null权限类型right_typeintnot null0:可访问,1:可授权9. 用户角色表用户角色表TUserRoleRelation字段名称字段类型备注记录标识tur_idbigintpk, not null用户tu_idbigintfk, not null角色tr_idbigintfk, not null10. 用户组表用户组表TUserGroupRelation字段名称字段类型备注记录标识tug_idbigintpk, not null用户tu_idbigintfk, not null组tg_idbigintfk, not null11. 组织表组织表TOrganization字段名称字段类型备注组织idto_idbigintpk, not null父组parent_to_idbigintnot null组织名称org_namevarcharnot null创建时间gen_timedatetimenot null组织描述descriptionvarchar12. 操作日志表操作日志表TLog字段名称字段类型备注日志IDlog_idbigintpk, not null操作类型op_typeintnot null操作内容contentvarcharnot null操作人tu_idbigintfk, not null操作时间gen_timedatetimenot 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. 用户应用系统的具体操作者,用户可以自己拥有权限信息,可以归属于0n个角色,可属于0n个组。他的权限集是自身具有的权限、所属的各角色具有的权限、所属的各组具有的权限的合集。它与权限、角色、组之间的关系都是n对n的关系。3. 角色为了对许多拥有相似权限的用户进行分类管理,定义了角色的概念,例如系统管理员、管理员、用户、访客等角色。角色具有上下级关系,可以形成树状视图,父级角色的权限是自身及它的所有子角色的权限的综合。父级角色的用户、父级角色的组同理可推。4. 组为了更好地管理用户,对用户进行分组归类,简称为用户分组。组也具有上下级关系,可以形成树状视图。在实际情况中,我们知道,组也可以具有自己的角色信息、权限信息。这让我想到我们的QQ用户群,一个群可以有多个用户,一个用户也可以加入多个群。每个群具有自己的权限信息。例如查看群共享。也可以具有自己的角色信息,例如普通群、高级群等。针对如上提出的四种对象,我们可以整理得出它们之间的关系图,如下所示：总体设计思路是将系统分为组权限管理、角色权限管理、用户权限管理、组织管理和操作日志管理五部分。其中组权限管理包括包含用户、所属角色、组权限资源和组总权限资源四部分,某个组的权限信息可用公式表示：组权限 = 所属角色的权限合集 + 组自身的权限。角色权限管理包括包含用户、包含组和角色权限三部分,某个角色的权限的计算公式为：角色权限 = 角色自身权限。用户权限管理包括所属角色、所属组、用户权限、用户总权限资源和组织管理五部分。某个用户总的权限信息存在如下计算公式：用户权限 = 所属角色权限合集 + 所属组权限合集 + 用户自身权限。组织管理即对用户所属的组织进行管理,组织以树形结构展示,组织管理具有组织的增、删、改、查功能。操作日志管理用于管理本系统的操作日志。注意：因为组和角色都具有上下级关系,所以下级的组或角色的权限只能在自己的直属上级的权限中选择,下级的组或者角色的总的权限都不能大于直属上级的总权限。2.5 模块结构设计本系统的具有的功能模块结构如下图所示：2.6 尚未解决的问题无。3. 接口设计暂略3.1 用户接口暂略3.2 外部接口暂略3.3 内部接口暂略4. 界面总体设计本节将阐述用户界面的实现,在此之前对页面元素做如下约定：序号页面元素约定1按钮未选中时：按钮名称选中时：按钮名称2单选框 选项3复选框 选项4下拉框选项, 5文本框|_|6TextArea|7页签未选中时：选项名称选中时：选项名称8未选中链接链接文字9选中链接链接文字10说明信息说明信息4.1 组权限管理4.1.1包含用户组信息 组1 组11 组12 组 组2 组21 组22 组所选择组：组1 包含用户 所属角色 组权限 总权限修改用户名 姓名 手机号 最近登录时间登录次数当用户选择修改按钮时,弹出用户列表,操作人可以通过勾选或取消勾选来修改该组所包含的用户。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 包含用户 所属角色 组权限 总权限修改用户名 姓名 手机号 最近登录时间登录次数4.2 角色权限管理4.2.1包含用户角色信息 角色1 角色11 角色12 角色 角色2 角色21 角色22 角色所选择角色：角色1 包含用户 包含组 角色权限修改用户名 姓名 手机号 最近登录时间登录次数当用户选择修改按钮时,弹出用户列表,操作人可以通过勾选或取消勾选来修改该角色所包含的用户。4.2.2包含组角色信息 角色1 角色11 角色12 角色 角色2 角色21 角色22 角色所选择角色：角色1 包含用户 包含组 角色权限修改组ID 组名称 组描述1xxx1-2 xxx2 -当用户选择修改按钮时,弹出用户列表,操作人可以通过勾选或取消勾选来修改该角色所包含的组。4.2.3角色权限角色信息 角色1 角色11 角色12 角色 角色2 角色21 角色22 角色所选择角色：角色1 包含用户 包含组 角色权限保存 取消通过对已具有的权限取消勾选,或为某权限添加勾选,来修改角色的权限信息,点击保存按钮保存修改信息。4.2.4管理角色 在下图中,选中组1的时候,右键点击可弹出组的操作列表,包括添加、删除和修改按钮,从而完成在该组下添加子组,删除该组以及修改该组的功能。角色信息 角色1 角色11 角色12 角色 角色2 角色21 角色22 角色所选择角色：角色1 包含用户 包含组 角色权限修改用户名 姓名 手机号 最近登录时间登录次数4.3 用户权限管理4.3.1所属角色用户权限信息xx公司 XX分公司 阿蜜果 肖xx yy 北京分公司 zz1 zz2 zz3所选择用户：阿蜜果所属角色 所属组 用户权限 总权限修改角色ID 角色名称 角色描述1 访客 - 2 初级用户 -当用户选择修改按钮时,弹出角色树形结构,操作人可以通过勾选或取消勾选来修改该用户所属的角色。4.3.2所属组用户信息xx公司 XX分公司 阿蜜果 肖xx yy 北京分公司 zz1 zz2 zz3所选择用户：阿蜜果所属角色 所属组 用户权限 总权限修改组ID 组名称 组描述1 组1 - 2 组2 -当用户选择修改按钮时,弹出组的树形结构,操作人可以通过勾选或取消勾选来修改该用户所属的组。4.3.3用户权限用户信息xx公司 XX分公司 阿蜜果 肖xx yy 北京分公司 zz1 zz2 zz3所选择用户：阿蜜果所属角色 所属组 用户权限 总权限保存 取消通过对已具有的权限取消勾选,或为某权限添加勾选,来修改用户的权限信息,点击保存按钮保存修改信息。4.3.4总权限用户信息xx公司 XX分公司 阿蜜果 肖xx yy 北京分公司 zz1 zz2 zz3所选择用户：阿蜜果所属角色 所属组 用户权限 总权限保存 取消通过对已具有的权限取消勾选,或为某权限添加勾选,来修改用户的权限信息,点击保存按钮保存修改信息。4.3.5用户管理 当选择了某用户时,点击右键,弹出菜单列表：修改、删除、取消,点击修改和删除按钮可以实现用户的删除和修改功能。 选择某个组织,例如下表中的XX分公司,弹出菜单列表：添加子组织、删除组织、修改组织、添加用户、取消,点击添加用户按钮可以实现用户的添加功能。用户权限信息xx公司 XX分公司 阿蜜果 肖xx yy 北京分公司 zz1 zz2 zz3所选择用户：阿蜜果所属角色 所属组 用户权限 总权限修改角色ID 角色名称 角色描述1 访客 - 2 初级用户 -4.3.6组织管理 选择某个组织,例如下表中的XX分公司,弹出菜单列表：添加子组织、删除组织、修改组织、添加用户、取消,点击添加子组织、删除组织、修改组织按钮可以实现组织的添加、删除和修改功能。用户权限信息xx公司 XX分公司 阿蜜果 肖xx yy 北京分公司 zz1 zz2 zz3所选择用户：阿蜜果所属角色 所属组 用户权限 总权限修改角色ID 角色名称 角色描述1 访客 - 2 初级用户 -4.4 操作日志管理4.4.1查询操作日志操作名称：|_| 操作人：|_|操作时间从|_| 到 |_|查询 重置 删除编号 操作名称 操作内容 操作人 操作时间1 xx1 - Amigo 2007-10-82 xx2 - xxyy 2007-10-8输入上图表单中的查询信息后,点击查询按钮,可查询出符合条件的信息。4.4.2删除操作日志操作名称：|_|操作人：|_|操作时间从|_| 到 |_|查询 重置 删除编号 操作名称 操作内容 操作人 操作时间1 xx1 - Amigo 2007-10-82 xx2 - xxyy 2007-10-8输入上图表单中的查询信息后,点击查询按钮,可查询出符合条件的信息。而后点击删除按钮,可删除符合查询条件的操作日志。5. 数据结构设计数据库设计的模型请参见通用权限管理系统_数据库模型.pdm。表的说明请参见通用权限管理系统数据库设计说明书。5.1 设计原则5.1.1命名的规范数据库中表、主键、外键、索引的命名都以统一的规则,采用大小写敏感的形式,各种对象命名长度不要超过30个字符,这样便于应用系统适应不同的数据库平台。5.1.2数据的一致性和完整性为了保证数据库的一致性和完整性,往往通过表间关联的方式来尽可能的降低数据的冗余。表间关联是一种强制性措施,建立后,对父表Parent Table和子表的插入、更新、删除操作均要占用系统的开销。如果数据冗余低,数据的完整性容易得到保证,但增加了表间连接查询的操作,为了提高系统的响应时间,合理的数据冗余也是必要的。使用规则Rule和约束Check来防止系统操作人员误输入造成数据的错误是设计人员的另一种常用手段,但是,不必要的规则和约束也会占用系统的不必要开销,需要注意的是,约束对数据的有效性验证要比规则快。所有这些,需要在设计阶段应根据系统操作的类型、频度加以均衡考虑。5.2 数据库环境说明数据库：MySql5.0设计库建模工具：PowerDesigner12.05.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连接错误101002+ socket错误代码配置信息错误未配置输入参数102001未配置输出参数102002组管理部分自定义错误103001103999角色管理部分自定义错误104001104999用户管理部分自定义错误105001105999操作日志管理1060011069996.2 补救措施为了当某些故障发生时,对系统进行及时的补救,提供如下补救措施：a后备技术 定期对数据库信息进行备份每天一次,当数据库因某种原因被破坏时,以最新的数据库脚本进行恢复；。7. 系统安全设计7.1 数据传输安全性设计SSH可以通过将联机的封包加密的技术进行资料的传递; 使用SSH可以把传输的所有数据进行加密,即使有人截获到数据也无法得到有用的信息。同时数据经过压缩,大大地加快了传输的速度。通过SSH的使用,可以确保资料传输比较安全并且传输效率较高。7.2 应用系统安全性设计操作人的操作信息需要提供操作记录。对系统的异常信息需进行记录,已备以后查看。只有授权用户才能登录系统,对于某个操作,需要具有相应权限才能进行操作。7.3 数据存储安全性设计 对于用户的密码等敏感信息采用MD5进行加密。.