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

转自:http://www.blogjava.net/amigoxie/archive/2007/10/06/150646.html

 

理清了对象关系之后,让我们接着来进行数据库的设计。在数据库建模时,对于 N N的 关系,一般需要加入一个关联表来表示关联的两者的关系。初步估计一下,本系统至少需要十张表,分别为:权限表、用户表、角色表、组表、用户权限关联表、用 户角色关联表、角色权限关联表、组权限关联表、组角色关联表、用户属组关联表。当然还可能引出一些相关的表。下面让我们在 PowerDesigner中画出各表吧。

       各表及其关系如下:

      

1.       用户表

用户表( TUser

字段名称

字段

类型

备注

记录标识

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.       角色表

角色表( TRole

字段名称

字段

类型

备注

角色 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.       权限表

权限表( TRight

字段名称

字段

类型

备注

权限 ID

tr_id

bigint

pk, not null

父权限

parent_tr_id

bigint

not null

权限名称

right_name

varchar(64)

not null

权限描述

description

varchar(200)

4.       组表

组表( TGroup

字段名称

字段

类型

备注

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.       角色权限表

角色权限表( TRoleRightRelation

字段名称

字段

类型

备注

记录标识

trr_id

bigint

pk, not null

角色

Role_id

bigint

fk, not null

权限

right_id

bigint

fk, not null

权限类型

right_type

int

not null 0:可访问, 1:可授权)

6.       组权限表

组权限表( TGroupRightRelation

字段名称

字段

类型

备注

记录标识

tgr_id

bigint

pk, not null

tg_id

bigint

fk, not null

权限

tr_id

bigint

fk, not null

权限类型

right_type

int

not null 0:可访问, 1:可授权)

7.       组角色表

组角色表( TGroupRoleRelation

字段名称

字段

类型

备注

记录标识

tgr_id

bigint

pk, not null

tg_id

bigint

fk, not null

角色

tr_id

bigint

pk, not null

8.       用户权限表

用户权限表( TUserRightRelation

字段名称

字段

类型

备注

记录标识

tur_id

bigint

pk, not null

用户

tu_id

bigint

fk, not null

权限

tr_id

bigint

fk, not null

权限类型

right_type

int

not null 0:可访问, 1:可授权)

9.       用户角色表

用户角色表( TUserRoleRelation

字段名称

字段

类型

备注

记录标识

tur_id

bigint

pk, not null

用户

tu_id

bigint

fk, not null

角色

tr_id

bigint

fk, not null

10.   用户组表

用户组表( TUserGroupRelation

字段名称

字段

类型

备注

记录标识

tug_id

bigint

pk, not null

用户

tu_id

bigint

fk, not null

tg_id

bigint

fk, not null

11.   组织表

组织表( TOrganization

字段名称

字段

类型

备注

组织 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.   操作日志表

操作日志表( TLog

字段名称

字段

类型

备注

日志 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

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
1、 抽象——总体思路。 先看这个ER图。 很简单,就是说明一下人员和资源的关系,一个人可以使用多个资源,一个资源可以被多个人使用,就是多对多的关系了。 不知道这个是不是可以叫做“抽象”。这个就是在金字塔的顶端来看权限了,站在顶端来看,就这么一点,估计没有那种情况可以逃出这个描述吧。 资源:这里指的资源是广义上的资源,包括很多的东东,模块、数据,菜单、节点、按钮、控件,表、字段、存储过程,页面、窗口、表单、图表、报表,什么都可以算作是一种资源。您也可以把您遇到的一些情况都来算作是一种资源。关于资源先说这些,下面还有详细的说明。 2、 加入权限 第一个图也太简单了,我们把他详细一下,把人员分成两个表——人员基本信息和登录信息,在加入“权限”。就是下面这个表了。 人员分成两个表可以应对很多的情况,比如一个人可以有多个登录帐号,人员基本信息还可以和其他的表相关联,登录方面的需求有什么变化的话,只需要修改登录信息表就可以了,不会影响人员基本信息表,不会让其越来越臃肿。 以前对于“权限”是很模糊的,似有似无的感觉,现在看来他其实就是一个多对多的关联表,呵呵。当然您可以说我的这个看法不对,呵呵,我只是说一下我的感觉。 3、 加入角色 第二个图,是把帐号的资源直接联系起来,这个有一个不方便的地方,比如有五个业务员他们的功能都是一样的,但是我们却需要做五遍一样的操作才能给这五个业务员设置好权限,而当业务员可以做的事情有变化的时候,我就又需要做五次相同的操作,这个就很麻烦了,所以引用了“角色”。 我们可以建立一个业务员角色,设置业务员角色可以做的事情,然后把五个业务员和业务员角色关联起来。这样就方便了,业务员可以做得事情有变化的时候,我只需要修改业务员角色可以做得事情就可以了。 您可能会问,客户的人少,每个人做得事情都不一样,这个怎么办呀? 这也好办呀,一个一个角色就可以了。虽然对于这种情况多用了一个角色,有点绕远的感觉,但是总体来说是可以接受的。角色初期设置一下就可以了,角色和人员“绑定”之后,修改角色可以做什么事情,和修改人员可以做什么事情,操作步骤都是一样的。 您可能又问了,客户是一个很大的公司,设置了n个角色之后,客户提出了一个需求:张三这个人比较特殊,他可以做XX事情,但是有没有对应的角色,也不想再多设置一个角色了,需要直接给张三设置可以做这件事情就可以了。 这个又要怎么处理呢?是不是要修改表结构了呢?我是不想改的,还是用角色绑定的方法来处理,增加一个“张三专用角色”,这个角色是“隐藏”的,不和其他的角色一样的管理,需要通过对“张三”来管理。这个好像说不太清楚,先这样吧,呵呵。 4、 表关联图 我觉得ER图就是ER图,不能代替表关系图,所以我就又做了一个表关系图。 【图四】 左面从上往下看,人员、登录帐号、角色、资源,右面是两个多对多的关联表。这个看起来就比较清晰了吧。 这个设计还可以吧,资源保罗万象什么都可以往里放,您可以展开您的联想,帮想到的东东都放进去就可以了。 这个图从设计的角度来说应该是挺简洁的,五六个表就搞定了。而且也可以适合很大的范围,因为那个资源的定义实在是太广泛了,到了无所不包的程度了。但是这个设计真的好吗?或者是实用吗? .......

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值