关于用户权限的数据库设计_第1页
关于用户权限的数据库设计_第2页
关于用户权限的数据库设计_第3页
关于用户权限的数据库设计_第4页
关于用户权限的数据库设计_第5页
已阅读5页,还剩2页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

1、1 设计思路 为了设计一套具有较强可扩展性的用户认证管理,需要建立用户、角色和权限等数据库表,并且建立之间的关系,具体实现如下。 1.1 用户 用户仅仅是纯粹的用户,用来记录用户相关信息,如用户名、密码等,权限是被分离出去了的。用户(User)要拥有对某种资源的权限,必须通过角色(Role)去关联。 用户通常具有以下属性:         编号,在系统中唯一。  ü    &#

2、160;    名称,在系统中唯一。  ü         用户口令。 ü         注释,描述用户或角色的信息。 1.2 角色 角色是使用权限的基本单位,拥有一定数量的权限,通过角色赋予用户权限,通常具有以下属性: ü    

3、60;    编号,在系统中唯一。 ü         名称,在系统中唯一。 ü         注释,描述角色信息 1.3 权限        权限指用户根据角色获得对程序某些功能的操作,例如对文件的读、写、修改和删除功能,通常具有以下属

4、性: ü         编号,在系统中唯一。 ü         名称,在系统中唯一。 ü         注释,描述权限信息 1.4 用户与角色的关系 一个用户(User)可以隶属于多个角色(Role),一个角色组也可拥有多个用户,用户

5、角色就是用来描述他们之间隶属关系的对象。用户(User)通过角色(Role)关联所拥有对某种资源的权限,例如 l         用户(User): UserID      UserName      UserPwd 1           

6、0;       张三                 xxxxxx 2                   李四    

7、;             xxxxxx       l         角色(Role): RoleID           RoleName    

8、;       RoleNote  01                  系统管理员       监控系统维护管理员        02     &

9、#160;            监控人员           在线监控人员        03                 

10、 调度人员           调度工作人员        04                  一般工作人员    工作人员      

11、  从该关系表可以看出,用户所拥有的特定资源可以通过用户角色来关联。 1.5 权限与角色的关系 一个角色(Role)可以拥有多个权限(Permission),同样一个权限可分配给多个角色。例如: l         角色(Role): RoleID           RoleName    

12、60;      RoleNote  01            系统管理员       监控系统维护管理员        02           

13、       监控人员          在线监控人员        03                  调度人员    &#

14、160;     调度工作人员        04                  一般工作人员   工作人员         l   &

15、#160;     权限(Permission): PermissionID      PermissionName       PermissionNote 0001                   &#

16、160;    增加监控                 允许增加监控对象 0002                        修改监控

17、                 允许修改监控对象 0003                        删除监控     &#

18、160;           允许删除监控对象 0004                        察看监控信息       允许察看监控对象  

19、l         角色权限(Role_Permission): RolePermissionID   RoleID PermissionID RolePermissionNote 1                     &#

20、160;       01            0001        角色“系统管理员”具有权限“增加监控” 2                 

21、            01            0002        角色“系统管理员”具有权限“修改监控” 3            

22、0;                01            0003        角色“系统管理员”具有权限“删除监控” 4        &#

23、160;                    01            0004        角色“系统管理员”具有权限“察看监控” 5    

24、                         02            0001        角色“监控人员”具有权限“增加监控” 

25、6                             02            0004        

26、;角色“监控人员”具有权限“察看监控”         由以上例子中的角色权限关系可以看出,角色权限可以建立角色和权限之间的对应关系。1.6 建立用户权限 用户权限系统的核心由以下三部分构成:创造权限、分配权限和使用权限。 第一步由Creator创造权限(Permission),Creator在设计和实现系统时会划分。利用存储过程CreatePermissionInfo(PermissionName,PermissionNote)创建权限信息,指定系统模块具有哪些权限。

27、60;第二步由系统管理员(Administrator)创建用户和角色,并且指定用户角色(UserRole)和角色权限(RolePermission)的关联关系。 1)        具有创建用户、修改用户和删除用户的功能: Administrator l         存储过程CreateUserInfo(UserName,UserPwd)创建用户信息;l   &#

28、160;     存储过程ModifyUserInfo(UserName,UserPwd)修改用户信息; l         存储过程DeleteUserInfo(UserID)删除用户信息; 2)        具有创建角色和删除角色的功能: Administrator l     &#

29、160;   存储过程CreateRoleInfo(RoleName,RoleNote)创建角色信息;l         存储过程DeleteRoleInfo(RoleID)删除角色信息; 3)Administrator具有建立用户和角色、角色和权限的关联关系功能: l    存储过程GrantUserRole(UserID,RoleID,UserRoleNote)建立用户和角色的关联关系; l 

30、        存储过程DeleteUserRole(UserRoleID)删除用户和角色的关联关系; l         存储过程GrantRolePermission(RoleID,PermissionID,RolePermissionNote)建立角色和权限的关联关系; l         存储过程DeleteR

31、olePermission(RolePermissionID)删除角色和权限的关联关系; 第三步用户(User)使用Administrator分配给的权限去使用各个系统模块。利用存储过程GetUserRole(UserID, UserRoleID output),GetRolePermission(RoleID,Role- -PermissinID output)获得用户对模块的使用权限。1.7 用户认证实现 当用户通过验证后,由系统自动生成一个128位的TicketID保存到用户数据库表中,建立存储过程Login(User

32、ID,UserPwd, TicketID output)进行用户认证,认证通过得到一个TicketID,否则TicketID为null。其流程图如下: 图1 Login流程图 得到TicketID后,客户端在调用服务端方法时传递TicketID,通过存储过程JudgeTicketPermission(TicketID,PermissionID)判断TicketID对应的用户所具有的权限,并根据其权限进行方法调用。 当用户退出系统时,建立存储过程Logout(UserID)来退出系统。当用户异常退出系统时,根据最后的登陆时间(LastS

33、ignTime)确定用户的TickeID,建立存储过程ExceptionLogout(UserID,LastSignTime)处理用户的异常退出。 图2 Logout流程图 WebService可以采用SoapHeader中写入TicketID来使得TicketID从客户端传递给服务端。.Net Remoting可以采用CallContext类来实现TicketID从客户端传递给服务端。2 数据库设计 2.1 数据库表 图3 数据库关系图 2.2 数据库表说明 2.2.1&#

34、160;用户表(Static_User) Static_User  Static_User字段名   详细解释   类型    备注  UserID   路线编号   varchar(20)   PK  UserName   用户名称    varchar(20)     UserPwd   用户密码  &#

35、160;varchar(20)    LastSignTime  最后登陆时间   datatime    SignState   用户登陆状态标记   int  TickeID   验证票记录编号   varchar(128)        2.2.2 角色表(Static_Role)&

36、#160;Static_Role Static_User字段名   详细解释   类型   备注  RoleID   角色编号   varchar(20)   PK  RoleName   角色名称   varchar(20)     RoleNote   角色信息描述   varchar(20) 

37、       2.2.3 用户角色表(Static_User_Role) Static_User_Role Static_User字段名   详细解释   类型   备注  UserRoleID   用户角色编号   varchar(20)  PK  UserID   用户编号   varchar(

38、20)   FK  RoleID   角色编号    varchar(20)   FK  UserRoleNote   用户角色信息描述  varchar(20)      2.2.4 权限表(Static_Permission) Static_Permission Static_User字段名   详细解释 

39、0; 类型   备注  PermissionID  编号   varchar(20)   PK PermissionName  权限名称   varchar(20)    PermissionNote  全息信息描述  varchar(20)        2.2.5 角色权限表(Stat

40、ic_Role_Permission) Static_Role_Permission Static_User字段名   详细解释   类型   备注   RolePermissionID    角色权限编号    varchar(20)   PK  RoleID   角色编号    varchar(20)   FK  Permi

41、ssionID   权限编号   varchar(20)   FK  RolePermissionNote   角色权限信息描述  varchar(20)        用“位”来存储、修改用户权限的方法以前我用记录方式,如A用户有3个模块权限,则A有三条记录    看到别人的程序里有这种方法,感觉不错,给大家看看有没有优点可取。  &#

42、160; 用户权限用一个int字段表示,可以放32位,    如果有第1,3,4模块的权限则,值为1 4 8=13    _  _userId_userQx_  A? |? 13  _|_    增加权限具体实现    如增加第四个模块的权限,4的二进制值8  update qxUser 

43、set userQx = userQx|8 where userId='A'    删除第四个模块的权限    update qxUser set userQx = userQx&8 where userId='A'    如果删除第四个模块,则不加条件就可以了  update qxUse

44、r set userQx = userQx&8   以上在SqlServer2000企业版通过。    欢迎大家讨论,有更好的方法大家共享呀    在Java 里    34&2 !=0就行了。   通过二,三两步的理解,相信这篇文章就不会生涩了! 首先上文权限设计拙见(1)中只是想记录下自己权限设计上的一点看法,以及将自己日常最常

45、用的权限解决方案记录下来以供日后回顾,没想到有朋友关注此类的设计,那就只能先把代码拿出来献丑了,抛砖引玉,大家共同探讨学习接着上文来说,上文所讨论的权限设计是一条思路,但既然是web应用,少不了数据库的支持,本文我们来讨论一下数据库的设计。(以下想法及思路仅仅代表本人拙见)说到权限的数据库设计,必先理清权限中几种实体及其关系,此部分想必有过设计权限经验的同仁都知道怎么设计了,网上摆渡一下也是一裤衩子一裤衩子的,我们就在最平凡直观的数据库关系的基础上来建立权限。下面是我的几个表(所有的表都带有一个pk_id,作为表的自动生成的唯一主键): 用户表(T_UserInfo): &

46、#160;1/*=*/  2/* Table: T_UserInfo                                         

47、   */  3/*=*/  4create table T_UserInfo   5( 6   pk_id  NUMBER   not null,  7  name  VARCHAR2(20), 8  sex  BOOLEAN, 9  a

48、ge    int, 10    emp_num    NUMBER, 11    polity     int, 12    unit               &#

49、160; VARCHAR2(50), 13    department           VARCHAR2(20), 14    specialty            int, 15    positio

50、n             VARCHAR2(10), 16    offtel               VARCHAR2(20), 17    famtel     

51、;          VARCHAR2(20), 18    post_state           VARCHAR2(10), 19    remark           &

52、#160;   VARCHAR2(100), 20    constraint PK_T_USERINFO primary key (pk_id) 21); 实战经验:用户表就不多说了,都是一些常用字段,年龄、电话、职位等,建议大家建立一个通用一些,字段多一些的一个用户表,便于以后扩展,以后如果有特殊需求,不用扩这个基本表,可以通过主外键关系来新建一个表,用于扩充字段   角色表(T_RoleInfo):  

53、;1/*=*/  2/* Table: T_RoleInfo                                         

54、0;  */ 3/*=*/ 4create table T_RoleInfo   5( 6    pk_id                number            &#

55、160;            not null,  7    role_name            VARCHAR2(20),  8    role_desc     

56、60;      VARCHAR2(100),  9    parent_role_id       NUMBER, 10    constraint PK_T_ROLEINFO primary key (pk_id) 11); 角色表中需要说明的就一个parent_role_id父角色id,此字段

57、用来扩展角色的继承关系。   资源表(T_ResourceInfo):  1/*=*/ 2/* Table: T_ResourceInfo                                

58、;        */  3/*=*/ 4create table T_ResourceInfo   5( 6    pk_id                NUMBER     

59、;                    not null,  7    module_name          VARCHAR2(20),  8    module_

60、code          VARCHAR2(10),  9    module_desc          VARCHAR2(100), 10    privilege_name       VARCHAR2(10),

61、 11    privilege_code       CHAR, 12    privilege_desc       VARCHAR2(100), 13    constraint PK_T_RESOURCEINFO primary key (pk_id) 

62、;14); 这个表需要说明的就比较多了,首先该表用来记录资源与资源权限,我这边所谓的资源就是实体,就是数据库表,角色需要对应到资源,有些角色对该资源有权限,有些角色则对该资源无权限,角色可对此资源操作的权限也不同。说白了,就是不同的角色对不同的数据库表的操作权限不同。因此我们这里的资源就是数据库表。   module_name:资源名;module_code:资源代码(存放数据库表名); privilege_name:权限名;privilege_code:权限代码(代表权限的code,也就是我们上文所说的权值)   

63、;例如角色a对数据库表T_UserInfo有添加与删除的权限则该表应该按照如下配置:  module_name:人员信息; module_code:T_UserInfo privilege_name:添加与删除 privilege_code:6   这里我们假设的是2的0次方为添加权限,2的1次方为添加权限,2的2次方为删除权限,2的3次方为更新权限,则拥有添加与删除权限就应该为2的1次方+2 的2次方=6,其实2的几次方代表什么含义我们可以另外开个数据库表来配置(或者xml文件)此处我们忽略这些步骤。当

64、然如果你的权限较多,譬如你还希望 a这个角色对人员信息表有上传得权限,我们可以将将上传权限定义为2的4次方,16,16的16进制数为10,记录在数据库里的形式应该为0x10如果a 角色拥有添加、删除、更新、上传权限,则a的权值应该为2的1次方+2的2次方+2的3次方+2的4次方=30,用16进制来表示就应该为0x1E,记录 16进制数据,你不用担心位数不够。 剩余的就是几张关系表了:人员角色关系表(T_R_User_Role):  1/*=*/  2/* Table: T_R_user_role                     

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论