当前位置:文档之家› 用户权限管理模块分析与设计(有图析)

用户权限管理模块分析与设计(有图析)

用户权限管理模块分析与设计(有图析)
用户权限管理模块分析与设计(有图析)

用户权限管理模块分析与设计

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

系统权限管理设计方案(优选.)

OA系统权限管理设计方案 l 不同职责的人员,对于系统操作的权限应该是不同的。优秀的业务系统,这是最基本的功能。 l 可以对“组”进行权限分配。对于一个大企业的业务系统来说,如果要求管理员为其下员工逐一分配系统操作权限的话,是件耗时且不够方便的事情。所以,系统中就提出了对“组”进行操作的概念,将权限一致的人员编入同一组,然后对该组进行权限分配。 l 权限管理系统应该是可扩展的。它应该可以加入到任何带有权限管理功能的系统中。就像是组件一样的可以被不断的重用,而不是每开发一套管理系统,就要针对权限管理部分进行重新开发。 l 满足业务系统中的功能权限。传统业务系统中,存在着两种权限管理,其一是功能权限的管理,而另外一种则是资源权限的管理,在不同系统之间,功能权限是可以重用的,而资源权限则不能。 针对OA系统的特点,权限说明: 权限 在系统中,权限通过模块+动作来产生,模块就是整个系统中的一个子模块,可能对应一个菜单,动作也就是整个模块中(在B/S系统中也就是一个页面的所有操作,比如“浏览、添加、修改、删除”等)。将模块与之组合可以产生此模块下的所有权限。 权限组 为了更方便的权限的管理,另将一个模块下的所有权限组合一起,组成一个“权限组”,也就是一个模块管理权限,包括所有基本权限操作。比如一个权限组(用户管理),包括用户的浏览、添加、删除、修改、审核等操作权限,一个权限组也是一个权限。

角色 权限的集合,角色与角色之间属于平级关系,可以将基本权限或权限组添加到一个角色中,用于方便权限的分配。 用户组 将某一类型的人、具有相同特征人组合一起的集合体。通过对组授予权限(角色),快速使一类人具有相同的权限,来简化对用户授予权限的繁琐性、耗时性。用户组的划分,可以按职位、项目或其它来实现。用户可以属于某一个组或多个组。 通过给某个人赋予权限,有4种方式(参考飞思办公系统) A. 通过职位 a) 在职位中,职位成员的权限继承当前所在职位的权限,对于下级职位拥有的权限不可继承。 b) 实例中:如前台这个职位,对于考勤查询有权限,则可以通过对前台这个职位设置考勤查询的浏览权,使他们有使用这个对象的权限,然后再设置个,考勤查询权(当然也可以不设置,默认能进此模块的就能查询),则所有前台人员都拥有考勤查询的权利。 B. 通过项目 a) 在项目中,项目成员的权限来自于所在项目的权限,他们同样不能继承下级项目的权限,而对于项目组长,他对项目有全权,对下级项目也一样。 b) 实例中:在项目中,项目成员可以对项目中上传文档,查看本项目的文档,可以通过对项目设置一个对于本项目的浏览权来实现进口,这样每个成员能访问这个项目了,再加上项目文档的上传权和查看文档权即可。

统一用户及权限管理系统概要设计说明书范文

统一用户及权限管理系统概要设计说 明书

统一用户及权限管理系统 概要设计说明书 执笔人:K1273-5班涂瑞 1.引言 1.1编写目的 在推进和发展电子政务建设的进程中,需要经过统一规划和设计,开发建设一套统一的授权管理和用户统一的身份管理及单点认证支撑平台。利用此支撑平台能够实现用户一次登录、网内通用,避免多次登录到多个应用的情况。另外,能够对区域内各信息应用系统的权限分配和权限变更进行有效的统一化管理,实现多层次统一授权,审计各种权限的使用情况,防止信息共享后的权限滥用,规范今后的应用系统的建设。 本文档旨在依据此构想为开发人员提出一个设计理念,解决在电子政务整合中遇到的一些问题。 1.2项目背景 随着信息化建设的推进,各区县的信息化水平正在不断提升。截至当前,在各区县的信息化环境中已经建设了众多的应用系统并投入日常的办公使用,这些应用系统已经成为电子政务的重要组成部分。 各区县的信息体系中的现存应用系统是由不同的开发商在不同的时期采用不同的技术建设的,如:邮件系统、政府内

部办公系统、公文管理系统、呼叫系统、GIS系统等。这些应用系统中,大多数都有自成一体的用户管理、授权及认证系统,同一用户在进入不同的应用系统时都需要使用属于该系统的不同账号去访问不同的应用系统,这种操作方式不但为用户的使用带来许多不便,更重要的是降低了电子政务体系的可管理性和安全性。 与此同时,各区县正在不断建设新的应用系统,以进一步提高信息化的程度和电子政务的水平。这些新建的应用系统也存在用户认证、管理和授权的问题。 1.3定义 1.3.1 专门术语 数据字典:对数据的数据项、数据结构、数据流、数据存储、处理逻辑、外部实体等进行定义和描述,其目的是对数据流程图中的各个元素做出详细的说明。 数据流图:从数据传递和加工角度,以图形方式来表示系统的逻辑功能、数据在系统内部的逻辑流向和逻辑变换过程,是结构化系统分析方法的主要表示工具及用于表示软件模型的一种图示方法。 性能需求:系统必须满足的定时约束或容量约束。 功能需求:系统必须为任务提出者提供的服务。 接口需求:应用系统与她的环境通信的格式。 约束:在设计或实现应用系统时应遵守的限制条件,这些

JAVA用户角色权限数据库设计

实现业务系统中的用户权限管理 B/S系统中的权限比C/S中的更显的重要,C/S系统因为具有特殊的客户端,所以访问用户的权限检测可以通过客户端实现或通过客户端+服务器检测实现,而B/S中,浏览器是每一台计算机都已具备的,如果不建立一个完整的权限检测,那么一个“非法用户”很可能就能通过浏览器轻易访问到B/S系统中的所有功能。因此B/S业务系统都需要有一个或多个权限系统来实现访问权限检测,让经过授权的用户可以正常合法的使用已授权功能,而对那些未经授权的“非法用户”将会将他们彻底的“拒之门外”。下面就让我们一起了解一下如何设计可以满足大部分B/S系统中对用户功能权限控制的权限系统。 需求陈述 ?不同职责的人员,对于系统操作的权限应该是不同的。优秀的业务系统,这是最基本的功能。 ?可以对“组”进行权限分配。对于一个大企业的业务系统来说,如果要求管理员为其下员工逐一分配系统操作权限的话,是件耗时且不够方便的事情。所以,系统中就提出了对“组”进行操作的概念,将权限一致的人员编入同一组,然后对该组进行权限分配。 ?权限管理系统应该是可扩展的。它应该可以加入到任何带有权限管理功能的系统中。 就像是组件一样的可以被不断的重用,而不是每开发一套管理系统,就要针对权限管理部分进行重新开发。 ?满足业务系统中的功能权限。传统业务系统中,存在着两种权限管理,其一是功能权限的管理,而另外一种则是资源权限的管理,在不同系统之间,功能权限是可以重用的,而资源权限则不能。 关于设计 借助NoahWeb的动作编程理念,在设计阶段,系统设计人员无须考虑程序结构的设计,而是从程序流程以及数据库结构开始入手。为了实现需求,数据库的设计可谓及其重要,无论是“组”操作的概念,还是整套权限管理系统的重用性,都在于数据库的设计。 我们先来分析一下数据库结构: 首先,action表(以下简称为“权限表”),gorupmanager表(以下简称为“管理组表”),以及master表(以下简称为“人员表”),是三张实体表,它们依次记录着“权限”的信息,“管理组”的信息和“人员”的信息。如下图:

最经典用户权限管理模块设计

实现业务系统中的用户权限管理--设计篇 B/S系统中的权限比C/S中的更显的重要,C/S系统因为具有特殊的客户端,所以访问用户的权限检测可以通过客户端实现或通过客户端+服务器检测实现,而B/S中,浏览器是每一台计算机都已具备的,如果不建立一个完整的权限检测,那么一个“非法用户”很可能就能通过浏览器轻易访问到B/S系统中的所有功能。因此B/S业务系统都需要有一个或多个权限系统来实现访问权限检测,让经过授权的用户可以正常合法的使用已授权功能,而对那些未经授权的“非法用户”将会将他们彻底的“拒之门外”。下面就让我们一起了解一下如何设计可以满足大部分B/S系统中对用户功能权限控制的权限系统。 需求陈述 ?不同职责的人员,对于系统操作的权限应该是不同的。优秀的业务系统,这是最基本的功能。 ?可以对“组”进行权限分配。对于一个大企业的业务系统来说,如果要求管理员为其下员工逐一分配系统操作权限的话,是件耗时且不够方便 的事情。所以,系统中就提出了对“组”进行操作的概念,将权限一致 的人员编入同一组,然后对该组进行权限分配。 ?权限管理系统应该是可扩展的。它应该可以加入到任何带有权限管理功能的系统中。就像是组件一样的可以被不断的重用,而不是每开发一套 管理系统,就要针对权限管理部分进行重新开发。 ?满足业务系统中的功能权限。传统业务系统中,存在着两种权限管理,其一是功能权限的管理,而另外一种则是资源权限的管理,在不同系统 之间,功能权限是可以重用的,而资源权限则不能。 关于设计 借助NoahWeb的动作编程理念,在设计阶段,系统设计人员无须考虑程序结构的设计,而是从程序流程以及数据库结构开始入手。为了实现需求,数据库的设计可谓及其重要,无论是“组”操作的概念,还是整套权限管理系统的重用性,都在于数据库的设计。 我们先来分析一下数据库结构: 首先,action表(以下简称为“权限表”),gorupmanager表(以下简称为“管理组表”),以及master表(以下简称为“人员表”),是三张实体表,它们依次记录着“权限”的信息,“管理组”的信息和“人员”的信息。如下图:

系统分析和设计方法(复习纲要)

系统分析和设计方法(复习纲要) 目录 系统分析和设计方法 (1) 第一部分 (2) 第1章系统分析和设计方法的环境 (2) 一.基本概念 (2) 二.重点内容 (2) 第2章信息系统构件 (3) 一.基本概念 (3) 二.重点内容 (3) 第3章信息系统开发 (4) 一.基本概念 (4) 二.重点内容 (4) 第4章项目管理 (6) 一.基本概念 (6) 二.重点内容 (6) 第二部分 (6) 第5章系统分析 (6) 一.基本概念 (6) 二.重点内容 (7) 第6章需求获取的调查研究技术 (8) 一.基本概念 (8) 二.重点内容 (8) 第7章使用用例建模系统需求 (8) 一、基本概念 (8) 二、重点内容 (9) 第8章数据建模和分析 (9) 一.基本概念 (9) 二.重点内容 (10) 第9章过程建模 (10) 一.基本概念 (10) 二.重点内容 (11) 第10章使用UML进行面向对象分析和建模 (12) 一.基本概念 (12) 二.重点内容 (12) 第11章可行性妇女系和系统方案建议 (13) 一.基本概念 (13) 二.重点内容 (13) 第三部分系统设计方法 (14)

第一部分 第1章系统分析和设计方法的环境 一.基本概念 1.信息系统: 信息系统是人、数据、过程和信息技术之间相互作用,收集、处理、存储和提供支持企业运作的信息的集合体。 2. 二.重点内容 1. 七类信息系统应用: 事务处理系统、管理信息系统、决策信息系统、主管信息系统、专家系统、通信和协作系统、办公自动化系统 2.系统关联人员(参与者) 1)系统所有者: 2)系统用户: 内部系统用户(如技术人员、服务人员、中间经理、高层经历) 外部系统用户(顾客、供应商、合作伙伴) 3)系统设计人员(如网络架构师、数据库管理员、web架构师) 4)系统构造人员(应用程序员、系统程序员) 5)系统分析员 6)外部服务提供者 7)项目经理 3.系统分析员的角色 系统分析员既懂业务又懂技术,他们首先研究业务问题和机遇,然后把业务和信息需求转换为对基于计算机的信息系统的规格说明,而这个信息系统则由包括程序员在内的技术专家来实现。 4.系统分析员所需的技能 有效的信息技术知识 一半商业知识 通用的解决问题的技能 良好的与人沟通的能力。 良好的处理人际关系的能力。 灵活性和适应能力

用户管理模块设计

用户管理模块设计 用户管理模块提供对用户信息的管理,包括用户注册、用户登录、用户权限管理、用户信息修改以及用户等级修改。 1、用户注册 根据用户表,设计相应的注册页面,注册页面包括用户名、密码、邮箱、部门、电话等信息,当用户进行注册时,填写这些信息,用户名是不能与已注册的用户名相同,填写完成后,提交注册请求,后台相应的Action会响应该动作,首先获取到页面发来的参数,然后将这些参数通过Session 对象写入到数据库中,最后向用户提示注册成功与否。 2、用户登录 用户注册之后,就可以通过账户和密码登陆至平台。当用户提交登陆请求,后台相应的Action 会响应该动作,首先获取到页面发来的用户名和密码,然后通过Query对象查询该用户是否存在且密码正确,最后将根据结果给用户发送跳转页面,如果用户存在且密码正确,则可进入平台主页面,否则,提示登陆错误信息。 3、用户权限管理 用户权限管理将用户分为普通用户和管理员,他们具有不同的权限,他们各自的权限如表1所示。此平台首次使用时,会内置一个超级管理员,有修改用户等级的权限。 表1 不同用户权限授权

定义一个权限拦截器,它的功能是用来检验用户类型,对每一个需要管理权限的操作均进行拦截,同时检验用户类型,判断该用户类型是否可执行该操作,即可达到权限管理的作用。如果某操作在当前用户等级对应的操作范围内,则可正常访问,否则跳转到提示页面,提示用户权限不足。 4、用户信息修改 用户管理模块提供用户修改自己信息的功能。当进入信息修改界面,首先会获取Session中当前用户信息,供用户在当前信息基础上进行信息修改。当用户填写完修改信息,并发送修改请求后,后台将响应用户的请求,首先得到所有用户修改参数,然后将修改的信息设置到该对象中,最后更新数据库,将更新结果发送给用户。 青山埋白骨,绿水吊忠魂。

设计分析与表达的基本概念及意义

设计分析与表达的基本概念及意义 (约法三章——1.不点名,不迟到2可插话3关手机略) (教学方式——讲一半做一半。a课程缘起——起源于我带自己研究生设计时时候对一些设计问题的看法,在研究设计的时候一个一个题目的做有缺陷,我们需要去问这个设计是怎么展开的,怎样才能使我们的设计在交流的时候变得很方便,我的心得可以变成别人的心得,怎样使自己的设计变得理性同时又保留体验性的成分,所以我们很多研究生在一起就做做了很多案例分析,后来我们发现这个经验是可以推广出来的,这样逐渐产生了这门课程。b作业成果及学分认定略) 1.解题 设计分析与表达,英文名叫Design Analysis and Expression。名称中并没有建筑这涉及到(我本人)对设计的看法,设计是分析的直接对象,建筑是对设计的限定;要使分析过程和成果便于交流和自我检验,就需要清晰的表达,这样的表达是有技术性的。 2.要求 课程的最低要求:学会鉴别和画出好的分析图。什么是好的、专业的分析图?好是指清晰的表达设计的想法,而不是指多漂亮。(评审项目分析图的两种模式:越看越糊涂的失败型和越看越清晰的成功型略)课程要求:“设计分析,是一种学习研究并且能够呈现设计概念的专业技术,特别是进入现代时期以后,设计的分析以及对分析的表达已经成为现代设计,包括建筑设计相关研究和教学工作中的重要环节。”通过这门课程的学习,应该要了解和掌握建筑设计当中基本的分析理论和表达方法。分析理论,是指方法理论,就是如何去做分析;表达方法是指思维活动如何呈现出来,通过表达方法理解一个设计主导概念、逻辑结构和设计过程,并呈现一个设计中的最关键的特征。由此建立起一个连续互动的过程——从分析开始,通过分析学习设计的源泉和方法,相互交流,交流的成果重新启动一个新的分析过程,分析和交流首尾相连。从分析到设计到交流连续互动,这是思维方法和研究方法,更是操作方法,通过操作、思维、研究和实践来提高设计能力,而不在培养“分析家”。因此,分析是学习设计的方法之一,尽管不是唯一的,比如可以通过理论学习来提高思维能力、价值观、判断能力和评论的能力,通过技术课来学习设计的常识和知识,设计课在实践层面上直接训练设计的过程。 3.大纲 1.设计分析与表达的基本概念和意义

一个用户权限管理模块的设计思路

一个用户权限管理模块的设计思路: 1. 权限资源(功能资源) 系统的所有权限信息。权限具有上下级关系,是一个树状的结构。如下: 系统管理 单位管理 查看单位 添加单位 修改单位 删除单位 部门管理 查看部门 添加部门 修改单位 删除单位 对于每个权限,又存在两种情况:1可访问;2可授权,部分表中采用拥有类型做判断(0可访问,1即可访问也可授权) 2. 用户 系统的具体操作者,用户可以自己拥有权限信息,可以归属于0~n个角色,可属于0~n 个组。他的权限集是自身具有的权限+所属的各角色具有的权限+所属的各组具有的权限的合集。它与权限、角色、组之间的关系都是n对n的关系。 3. 角色 为了对拥有相似权限的用户进行分类管理,因此定义角色,例如:超级管理员,一般管理员、一般用户等角色。在这里同时也让角色具有上下级关系,形成树状视图,父级角色的权限是自身及它的所有子角色的权限的综合。 4. 组 为了更好地管理用户,对用户进行分组归类,简称为用户分组。组也具有上下级关系,可以形成树状视图。在实际应用中,我们知道,组也可以具有自己的角色信息、权限信息。 就好比是javaeye中的圈子,一个圈子可以拥有多个会员,同时一个会员也可以加入多个圈子,对于不同的圈子又有不同的权限信息。(组的解释:例如一个公司中,不同的部门即可划分不同的组来进行权限的分配) 针对以上描述,结构关系如下: 整个模块分为组权限管理、角色权限管理、用户权限管理。 其中组权限管理:组权限 = 所属角色的权限合集 + 组自身的权限。

角色权限管理:角色权限 = 角色自身权限。 用户权限管理:用户权限 = 所属角色权限合集 + 所属组权限合集 + 用户自身权限。 注意:因为组和角色都具有上下级关系,所以下级的组或角色的权限只能在自己的直属上级的权限中选择,下级的组或者角色的总的权限都不能大于直属上级的总权限。 欢迎大家拍砖,给点建议。

用户管理模块详细设计

用户管理模块概述: 该模块主要实现管理员对用户信息的添加及修改,查看用户信息列表,对新增用户进行密码初始化。用户本身有修改密码及修改本人信息的权限。 用户管理模块技术分析: 本模块中主要运用查看、添加和删除。其中注意的是对密码的初始化以及密码修改后的加密。针对密码初始化,由系统管理员在添加新增用户时设置初始化密码,一般初始化密码统一。新入公司的员工在首次登录系统时需要对初始密码进行修改,修改后的密码具有保密性,在前台与后台数据库均是不可见的。因此采用MD5加密算法,用于加密用户名密码,验证登录身份。MD5即Message-Digest Algorithm 5,用于确保信息传输完整一致。是计算机广泛使用的杂凑算法之一,主流编程语言普遍已有MD5实现。将数据运算为另一固定长度值,是杂凑算法的基础原理,MD5的作用是让大容量信息在用数字签名软件签署私人秘钥前被"压缩"成一种保密的格式(就是把一个任意长度的字节串变换成一定长的十六进制数字串)。 用户管理模块实现过程: 系统管理员登录系统后点击用户管理模块,选择添加用户,跳转至userAdd.jsp,进行添加用户的信息,并对密码进行初始化,然后保存即可更新数据库。如果某员工升职,则要对其工资以及职务更改。点击修改用户信息跳转至userEdit.jsp,输入某项信息保存即可更新数据库。应部门领导要求打印所有员工信息列表,点击查看员工信息跳转至userList.jsp,即可查看员工信息,员工信息记录以每10个记录为一页,可以进行翻页处理。 新员工首次登录公司系统需要进行改密,此密码需要加密。后台管理员不可见。当用户忘记密码时可以选择通过手机发送验证码来重置密码,并重新登录。员工也拥有对员工本人信息修改的权限。点击修改信息即可完成页面的跳转。 1、开发模型:首先开发用来封装一条表记录的JavaBean即user类。然后开发用来封装针对该表记录实现增删改查的工具JavaBean,即DAO类userDao完成对数据库的操作。 2、开发静态视图,分别为userAdd.jsp,userEdit.jsp,userList.jsp,EditPassword.jsp. 3、开发控制器servlet ,使静态页面转化为动态页面。

用户权限管理系统需求分析

软件需求分析报告目录 1.引言 1.1 项目简介 本文档对通用用户权限管理系统的总体设计、接口设计、界面总体设计、数据结构设计、系统出错处理设计以及系统安全数据进行了说明。 1.2 编写说明 1.3参考资料 《通用权限管理系统需求规格说明书》 《通用权限管理系统数据库设计说明书》

2.目标 2.1概述 权限系统一直以来是我们应用系统不可缺少的一个部分,若每个应用系统都重新对系统的权限进行设计,以满足不同系统用户的需求,将会浪费我们不少宝贵时间,所以花时间来设计一个相对通用的权限系统是很有意义的。 本系统的设计目标是对应用系统的所有资源进行权限控制,比如应用系统的功能菜单、各个界面的按钮控件等进行权限的操控。2.2系统目标 系统的目标包括如下三点: (1)对应用系统的所有资源进行权限控制,比如应用系统的功能菜单、各个界面的按钮控件等进行权限的操控; (2)完善用户、角色、组织、资源、操作的管理功能,其中的组织管理模块只提供组织视图,不参与权限的控制管理。 (3)开发人员开发新的系统功能,通过资源和角色模块进行操作管理。使用系统管理员身份登陆,直接将访问路径作对角色资源授权给操作,实现资源访问控制管理。 2.2.1 总目标 本系统提供一个调用简单、可复用性高、满足一般需求的权限管理模块,并为需要对权限管理的系统节省开发本。 2.2.2 性能目标 1、要求下载和安装速度快,响应时间快。

2、要求系统可适用于不同操作平台。 3、要求系统的可维护性和实用性强。 4、要求系统有一定的检错能力。 5、要求系统支持多用户同时操作,但管理者与用户不能同时操作。 2.2.3 功能目标 本系统的设计目标是对应用系统的所有资源进行权限控制,比如应用系统的功能菜单、各个界面的按钮控件等进行权限的操控。 2.3 目标说明 3.结构 3.1系统需求结构 系统采用B/S架构模式,基于 BNFW开发,服务封装了对后台数据操纵的细节,并提供安全调用接口. WEB 应用程序通过接口访问系统服务,执行用户操作并返回结果。系统采用SQL SERVER数据库和tomcat web应用服务器开发,部署在 Linux和windows服务器下运行。 3.2 需求结构的说明 用户权限管理系统概貌如图所示:

系统用户及权限管理制度

航开发系统用户账号及权限管理制度 第一章总则 第一条 航开发系统用户的管理包括系统用户ID的命名;用户ID的主数据的建立;用户ID的增加、修改;用户ID的终止;用户密码的修改;用户ID的锁定和解锁;临时用户的管理;应急用户的管理;用户ID的安全管理等。 第二章管理要求 第二条 航开发系统管理员(以下简称系统管理员)在系统中不得任意增加、修改、删除用户ID,必须根据《系统用户账号申请及权限审批表》和相关领导签字审批才能进行相应操作,并将相关文档存档。 第三条 用户ID的持有人特别是共享的用户ID必须保证用户ID和用户密码的保密和安全,不得对外泄漏,防止非此用户ID的所有者登录系统。 第四条 用户管理员要定期检查系统内用户使用情况,防止非法授权用户恶意登录系统,保证系统的安全。 第五条 用户ID持有人要对其在系统内的行为负责,各部门领导要对本部门用户的行为负责。

第六条 用户ID的命名由系统管理员执行,用户ID命名应遵循用户ID的命名规则,不得随意命名。 第七条 用户ID主数据库的建立应保证准确、完整和统一,在用户ID发生改变时,用户管理员应及时保证主数据库的更新,并做好用户ID变更的归档工作。 第八条 对用户申请表等相关文档各申请部门的用户管理员必须存档,不得遗失。 第九条 公司NC-ERP系统中各部门必须明确一名运维管理人员负责本部门用户管理、权限管理及基础数据维护等相关工作。 第三章增加、修改用户ID的管理第十条 公司NC-ERP系统中增加、修改用户ID应符合下列情况之一: 1、因工作需要新增或修改用户ID; 2、用户ID持有人改变; 3、用户ID封存、冻结、解冻; 4、单位或部门合并、分离、撤消; 5、岗位重新设置; 6、其他需要增加或修改公司NC-ERP系统中用户ID的情况。 第十一条

建筑方案设计方法与设计中设计原则及要点分析

建筑方案设计方法与设计中设计原则及要点分析 发表时间:2018-06-16T15:32:11.500Z 来源:《建筑学研究前沿》2018年第2期作者:王斌宇 [导读] 建筑方案设计是建筑设计最初的阶段,同时也是最重要的阶段。 广东诚实建设工程设计有限公司 520000 摘要:生活水平的改善与公众审美能力的提升对建筑质量、外观和功能提出了众多的要求,因此提高建筑方案设计水平就格外的迫切,下面简单的分析建筑方案设计中设计的原则与设计的一些要点。提出重视建筑方案的设计才能提高建筑设计的整体的水平,保障建筑整体的施工效果。 关键词:建筑方案设计原则要点方法形式 前言:建筑方案设计是建筑设计最初的阶段,同时也是最重要的阶段。如方案设计不够合理,就会影响后续的设计以及施工图的设计,即使及时的进行补救工作,其效果也有所影响。所以相关建筑企业需要对建筑方案设计引起重视,以此提高我国建筑行业的整体水平。 1.建筑方案设计简述 建筑方案设计属于生活设计范围,常指结合建筑拟建地环境的条件,对其空间环境进行针对性构建,同时也是利用图式思维处理设计矛盾的过程。它对设计人员的立体化思维和空间想象力要求甚高,与一般性方案设计比较,设计人员虽不可能掌握所有类型的建筑设计,但若能掌握科学的设计思维和合理的方法,以及对建筑功能的分析与生活沉淀,依旧可设计出优秀的建筑方案。建筑方案设计通常是环境-群体-单体-细节这一递进式规律。包括任务书阅读、方案设计、绘图、检查四个环节,即要求从任务书中明确场地条件、设计目标与内容,然后经地、图对照分析形成空间环境概念,同时结合平面信息、面积表及设计要求了解建筑功能并进行分区等。由此可见建筑方案设计内容复杂,难度大,故选用恰当设计方法十分关键。 2.建筑方案设计原则 2.1 建筑工程整体风格的体现:随着社会经济的不断发展,现阶段建筑功能已不单单是生活及工作,更多的是对个性的追求。仅从城市建筑整体上来说,建筑性质及功能有很多相似的地方,不过其内涵及意义还是有较大的不同。针对设计单位方案来说,建筑方案设计中核心的内容就是整理或分析建筑当中的潜在信息,要抓住重点,让设计人员的精神以及底蕴都能在建筑设计中很好的体现出来,使设计人员对其的需求能得到有效的满足,同时也表现出建筑文化的相关层次,这就是建筑灵魂的所在。 2.2 建筑专业人员主导性作用需发挥:在优化建筑方案设计的时候,经常会有一些优化不成功或持续恶化的现象出现,而造成这种现象出现的原因较多,其最主要的原因就是因为有非专业因素干预其中而导致的。比如一些建设单位太过热情参与到方案设计中,并提出一些主观的意愿,这在一定程度上会使建筑设计师的思维受到影响。从另一方面来看,有些中标的设计单位在建筑任务完成过程中会存在一种被动工作的状态,仅根据业主单位的要求进行修改,在建立工作积极性上严重的缺乏。因此在优化建筑设计方案时,不仅需多方面的参与及探讨,还要对工作的专业性引起重视。 3.建筑方案设计的基本要点 3.1 分析图底关系:开始任何一项建筑方案的设计所需要考虑的内容都很多。在考虑相关设计问题的时候,可将其中的矛盾方面进行有效的简化。比如在分析图底关系的时候,可将需要设计的建筑房间当作是一个设计的要素,并将室外人群聚集的所有活动区域都当成是设计要素,只有这样才能让各个分区促进具体分析的设计要素,并且还要解决这个设计阶段当中存在的设计矛盾。不过我们还需意识到在分析具体建筑方位中的图底关系时,还需与出入口方位以及外部环境条件有效结合,并进行有目的性的分析。设计人员只有通过这种分析才能将图的形状及位置确定好。 3.2 设计建筑总平面:通过设计建筑总平面图,首先需要确定一些内容。比如室外场地与出入口的关系需确定,通过分析车、人及建筑物三者当中关系,以此对建筑物的主次人口范围予以确定。其具体人流的方向及部位是建筑设计中最先要确定的内容,这在一定程度上对建筑总平面的布局成败有直接的影响。其分析依据主要从设计计划书中的地形图以及道路状况获取的;不仅如此,所判断出来的选择是否与本身合适,这是城市环境及建筑物的关系中最为直接的关系;而其中是否做到合理的协调,则与建筑物的出入口定位有较为直接的关系,这也与建筑物在内部功能布局中的合理性有较大关联性。 3.3 设计建筑物功能区:设计人员在进行建筑方案设计时,需将建筑物当中的使用、管理等功能区与场地的出人口依次对应,或可归纳及划分建筑物,比如可以将其分成安静区或者是活动区等功能区,依次有效简化设计矛盾。而针对一些建筑功能较为复杂的建筑物,如先划分全部功能房间的话,就会导致我们进入到自己设置的迷魂阵中,因我们无法在最快时间内将几十个甚至上百的房间中的联系弄清楚,仅从表面来孤立分析个别房间,会使我们无法把握好整体方案。因此建筑物中所应用的功能分析方法需从划分功能开始进行分区。 3.4 设计房间布局:设计工作人员在设计建筑物各个功能分区时,首先必须要对彼此之间位置的关系予以确定,并先竖向划分功能分区,再对其进行水平的划分。而在所有功能分区房间中,将哪些设嚣于上层,哪些设置在下层,这都是设计工作者在进行平面功能分区时所需要现行决策好的;不过这在一定程度上也代表竖向功能分区存在一定优先权,必须要在竖向功能分区已经设计好的情况下,才可配置水平的功能分区;这两者当中有一定的互动关系,而在相互调整的关系之下,才能慢慢确定好功能分区的所有布局。不仅如此竖向功能分区必须要遵循好结构设计。 3.5 建筑细部的设计:设计人员首先应适当调整个别房间当中的比例及尺寸,并有效完善平面设计;同时还需严格检查建筑的疏散宽度、采光通风以及无障碍设计等,要对设置的合理性进行分析,以此使总平面设计得以不断完善。比如以某住宅户内的设计为例,首先要确定窗户以及房间门的设置是否合理,其主要是对家具摆放、通风、采光等有无影响;针对卫生间以及厨房等布置,要对相关器具的摆放以及尺度规格的合理性进行考虑,并且要确定是否使用方便,而燃气管道及上下水管位置是否合理,其通风的效果是否好,能不能保证房问的隐私性;此外还应对室内外空调位置的合理性进行关注,所有水管安置的位置合理与否。不仅如此还应重点对结构柱网或墙体布置的合理性进行检查,看是否需要增减一些柱子或墙,而防火分区面积与相关规定是否相符,以此对防火分区数量予以确定,并对其数量进行

权限管理模块设计

权限管理模块设计说明书 摘要 权限管理分为两个部分,操作权限管理和资源权限管理。针对我们的系统,分别进行说明。 一、操作权限管理即为允许用户使用那些功能,进行哪些操作。有两个地方需要处理, 1、对用户隐藏没有授权的功能。如“LOG管理”功能没有对用户A授权,则用户A是看不见“LOG 管理”这个功能菜单的。 2、在功能所在的页面进行权限验证,防止没有授权的用户通过输入URL进入功能所在页面。 如“LOG管理”功能没有对用户A授权,则用户A是即使是手动输入“LOG管理”功能所在的页面,他也无法使用这个功能。 在实现方式上可以通过”角色”和”功能”来实现,一个”角色”对应多个”功能”,”用户”与”角色”是多对多的关系。当用户登录时通过 (用户->角色->功能)查询出该用户可以使用的功能列表并显示,无权使用的功能将被隐藏。并且在功能所在页面进行权限验证,避免没有权限的用户通过特殊方法进入页面。 二、资源权限管理的意思是限制用户对资源的访问和操作。 1、省级的用户可以查看和操作全省的数据。但不能查看和操作外省的数据。 2、市级的用户可以查看和操作全市的数据,但不能查看和操作该市以外的数据。 3、全国级的用户可以查看和操作全国的数据。

目录 1概述 (3) 1.1目的 (3) 2模块结构描述 (3) 3模块功能描述 (3) 3.1权限管理 (3) 3.1.1功能菜单管理 (3) 3.1.2用户管理 (4) 3.1.3角色管理 (4) 3.2操作权限验证 (4) 3.2.1登录验证 (5) 3.2.2页面载入验证 (5) 3.2.3页面操作权限验证 (5) 3.3资源权限验证 (6) 4数据库设计ER图 (6)

权限模块说明

角色权限模块说明 一、何为权限 通常登录一个系统在页面左边部分能看到相关操作菜单,鼠标点击相应菜单会进入相关操作页面,页面里面展示当前登录用户能查看的相关数据及对数据可进行的操作按钮;通过以上描述,我们可以用相对专业点的术语描述:当前登录用户有该菜单功能的操作权限,并且该用户只能查看自己拥有权限查看的数据,数据的操作按钮也可能不是全部操作按钮,比如可以新增但是不可以删除,而管理员登录后进入该页面这可以看到删除按钮并且可以进行删除操作等;以上文字描述了菜单权限,数据权限,按钮权限等三种权限概念; 二、何为角色 如果管理员为系统每个用户各自选择可以操作的权限,这样不仅效率低下而且用户体验相当不好,每新建一个用户就要为该用户单独选择可操作的权限,即使该用户的权限和之前的用户是一模一样的可还是要重新选择,有没有好的解决方案呢?我们可以将权限相似的用户所拥有的权限进行分组,将用户加入该分组,那么用户就拥有该分组里面的权限,分组名称就是角色,这样只要我们为用户分配相应的角色该用户就一次性的获得了多个可操作的权限。 三、权限分配 通常角色拥有的权限及用户所属的角色会根据需求进行变化,比如部门重组或者人员调离,该部门人员的职责不同了,那么其拥有的权限和所属角色也会发生相应的变化,通常管理员会根据实际情况新增或取消某个角色拥有的权限或者新建新的角色亦或者删除过期的角色等,这些操作我们称之为权限分配。 四、新系统权限管理说明 新系统后台权限分为三种即菜单权限,数据权限,按钮权限。新系统默认有个超级管理员角色(superadmin)及该角色下用户名为superadmin的用户,该角色默认拥有系统全部资源的操作权限(新功能开发时由开发人员进行配置),并且在权限分配时只有该角色里面的用户才能看到所有权限并对其进行分配,其他任何角色里面的用户都不能对其进行修改和重新分配权限,该角色仅限公司内部开发人员,维护人员及测试人员使用,其中菜单管理,系统配置管理,定时器配置管理,系统词典管理,demo功能原型等功能为该角色独有的权限(业务逻辑上如此规定,如超级管理员将这些权限分配给其他角色则其他角色里面的用户也是可以对其进行操作的)。 超级系统管理员可以创建其他的角色,创建角色时分配该角色拥有的权限,如果将权限分配权限也分配给新角色,那么新角色在创建其他新角色并对其进行权限分配时只能看到自

设计分析与方法心得

设计分析与方法学习报告 现如今设计师除了需要满足人们目前的愿望,还必须为人们提供他们并不知道自己是否想要的产品,或者从未想过他们能够拥有的产品。因此必须不断地探讨理论付诸实践的可能性与限制,在理论建构与实际运用之间建立互动,研究探讨不同学科间持续不断的交流合作可能产生的问题。新产品计划来自许多概念,从新的概念、市场需求、发展新的技术去增加产品的利润。从设计开始到成品的制造过程中,利用计算机辅助设计程序或虚拟方法设计分析产品的结构、产品的性能、产品的装配,可以有效的减少材料的浪费,优化产品的质量,能更深入理解产品制造的成本和性能的关系。产品设计过程中最重要的是各部件的组合,并将这些部件形成一个组合体,然后根据不同的工作需要,利用一些分析工具,计算出产品在不同环境中的反应。在一件产品的周期内和设计组合体的程序中,有效和周详的考虑是可以有很大的潜在能力,从而增加生产力更可减少实质的生产成本。设计师在设计一个产品的时候,首先会考虑产品的必须功能,其次考虑减少生产部件程序的范围,很少有考虑到组合工序中发生的问题,但这些问题一旦发生,往往很浪费时间和金钱。因此在选择不同设计的程序上,组合各工件的容易度必须在设计产品过程中考虑到。所以一些分析工具被用在优化设计组合体的过程中,来模拟产品生产或使用中遇到的问题,通过分析计算来寻找解决方法。 产品通常使用的分析方法如材料力学、理论力学和弹性力学等,只能计算形状较规则的产品,计算得到的准确度很低,为了提高准确度,通常会加入安全系数,使产品不会因为误差而导致结构性问题,缺点会造成产品的结构复杂化,增加产品的重量,浪费材料。因此在设计产品时,为了提高产品的效率、精度、性能和降低制造成本,产品的设计分析是不可缺少的重要步骤。 对于产品的造型设计来说,存在着功能结构与装饰的二元关系。一般来说,功能是决定产品能否存在、被使用的的必要物理条件,一件产品的功能结构是该产品的物理部分,如果改动或删减功能结构,产品的功能便会改变或失效。而装饰是人天然的本性,从石器时代开始便是如此,所以装饰是产品结构以外的造型,改动或删减一般来说不会影响功能,只会影响其艺术价值。产品上装饰的多少,会随着时代转变而增减,在工业革命时代,装饰过多会变成“矫饰”;没有装饰又会缺少现在时代所追求的“个性化”。一些设计师提出,从把产品的造型建立

系统分析与设计方法(原书第7版)

系统分析与设计(原书第7版)配套练习 目录 CHAPTER 1 (2) CHAPTER 2 (4) CHAPTER 3 (6) CHAPTER 4 (9) CHAPTER 5 (11) CHAPTER 6 (14) CHAPTER 7 (16) CHAPTER 8 (19) CHAPTER 9 (21) CHAPTER 10 (23) CHAPTER 11 (26)

CHAPTER 1 1. Management information systems (MIS) A) create and share documents that support day-today office activities B) process business transactions (e.g., time cards, payments, orders, etc.) C) capture and reproduce the knowledge of an expert problem solver D) use the transaction data to produce information needed by managers to run the business E) none of the above 2. The term used to describe those people whose jobs involve sponsoring and funding the project to develop, operate, and maintain the information system is A) information worker B) internal system user C) systems owner D) external system user E) systems builder 3. The person who ensures that systems are developed on time, within budget, and with acceptable quality is a A) systems designer B) project manager C) systems owner D) external system user E) systems builder 4. Which one of the following is not a business driver for an information system? A) business process redesign B) knowledge asset management C) proliferation of networks and the Internet D) security and privacy E) collaboration and partnership 5. A task of developing a technical blueprint and specifications for a solution that fulfills the business requirements is undertaken in the following phase of the system development process A) system initiation B) system implementation C) system analysis D) system design E) feasibility analysis 6. If a university sets up a web-based information system that faculty could access to record student grades and to advise students, that would be an example of a/an A) CRM B) intranet C) ERP D) extranet E) none of the above 7. Which of the following is not a technology driver for an information system? A) enterprise applications B) object technologies

用户权限管理设计方案

盛年不重来,一日难再晨。及时宜自勉,岁月不待人。 用户权限管理设计方案 用户认证管理设计方案 1 设计思路 为了设计一套具有较强可扩展性的用户认证管理,需要建立用户、角色和权限等数据库表,并且建立之间的关系,具体实现如下。 1.1 用户 用户仅仅是纯粹的用户,用来记录用户相关信息,如用户名、密码等,权限是被分离出去了的。用户(User)要拥有对某种资源的权限,必须通过角色(Role)去关联。 用户通常具有以下属性: ?编号,在系统中唯一。 ?名称,在系统中唯一。 ?用户口令。 ?注释,描述用户或角色的信息。 1.2 角色 角色是使用权限的基本单位,拥有一定数量的权限,通过角色赋予用户权限,通常具有以下属性: ?编号,在系统中唯一。 ?名称,在系统中唯一。 ?注释,描述角色信息 1.3 权限 权限指用户根据角色获得对程序某些功能的操作,例如对文件的读、写、修改和删除功能,通常具有以下属性: ?编号,在系统中唯一。 ?名称,在系统中唯一。 ?注释,描述权限信息 1.4 用户与角色的关系 一个用户(User)可以隶属于多个角色(Role),一个角色组也可拥有多个用户,用户角色就是用来描述他们之间隶属关系的对象。用户(User)通过角色

(Role)关联所拥有对某种资源的权限,例如 ●用户(User): UserID UserName UserPwd 1 张三xxxxxx 2 李四xxxxxx …… ●角色(Role): RoleID RoleName RoleNote 01 系统管理员监控系统维护管理员 02 监控人员在线监控人员 03 调度人员调度工作人员 04 一般工作人员工作人员 …… ●用户角色(User_Role): UserRoleID UserID RoleID UserRoleNote 1 1 01 用户“张三”被分配到角色“系 统管理员” 2 2 02 用户“李四”被分配到角色“监 控人员” 3 2 03 用户“李四”被分配到角色“调 度人员” …… 从该关系表可以看出,用户所拥有的特定资源可以通过用户角色来关联。 1.5 权限与角色的关系 一个角色(Role)可以拥有多个权限(Permission),同样一个权限可分配给多个角色。例如: ●角色(Role): RoleID RoleName RoleNote 01 系统管理员监控系统维护管理员 02 监控人员在线监控人员 03 调度人员调度工作人员 04 一般工作人员工作人员 …… ●权限(Permission): PermissionID PermissionName PermissionNote 0001 增加监控允许增加监控对象 0002 修改监控允许修改监控对象 0003 删除监控允许删除监控对象 0004 察看监控信息允许察看监控对象 …… ●角色权限(Role_Permission): RolePermissionID RoleID PermissionID RolePermissionNote

相关主题
文本预览
相关文档 最新文档