数据库管理员用户角色组权限设计

一.引言

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

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

二.设计目标

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

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

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

三.相关对象及其关系

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

1.       权限

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

系统管理

        用户管理

               查看用户

                新增用户

                     修改用户

                     删除用户

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

2.       用户

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

3.       角色

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

4.       组

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

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

用户·角色·权限·表 - 寒惜祉 - 諾愛→請深愛不愛→請滾開

 

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

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

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

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

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

理清了对象关系之后,让我们接着来进行数据库的设计。在数据库建模时,对于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


----------------------------------------------------------------------------------------------------------------------------------------------

以下为本博主一次简单的项目中管理员权限数据库设计:


  • 1
    点赞
  • 19
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
功能简介: 1.根据题目的描述,既然这个系统有教师和学生的管理,那这个系统不仅是毕业设计管理系统,而是有教师和学生的信息查询维护的教务管理系统的一部分。 本系统是一个专门用于毕业设计管理的系统,每个准备毕业设计的学生和每个指导老师都拥有一个账号。该系统的账号可能是从教务管理系统导入进来的。 2.鉴于审批需要,该系统共有四种角色,分别为教师、学生、系主任、管理员。不同的用户登录到这个系统中要有不同的界面,不同的功能。 3.学生界面内有“选题”功能,在选择题目并经导师和系主任批准后,将开题并可以在“上传进度”中实时查看自己的进度,随时补充最新进展。 4.系统管理员具有增删用户和决定用户权限的功能,但系统管理员不能涉及选题与审核环节,要修改选题与审核等环节的内容,需要管理员为自己创建具有系主任权限的教师账号。 5.没有系主任权限的教师只能指导学生和开题,不能进入系主任审批界面。而具有系主任权限的教师可以进入系主任审批界面,也可以指导学生和开题。(值得一提的是,系主任可以审批自己指导的学生进行的毕业设计。) 逻辑结构设计:(加粗表示主键) 用户表(统一ID,密码,用户类别) 学生表(统一ID,姓名,性别,专业,班级,电话,邮箱,备注) 教师表(统一ID,姓名,性别,职称,方向,电话,邮箱,是否系主任) 题目表(题目编号,题目名称,题目专业,命题导师,内容简介) 选题表(题目编号,学生ID,教师ID,毕设进程) 开发所用技术与环境: 架构:native 语言:C++ 数据库:sqlite 3.31.1 使用的库:EasyX_20200520(beta) 开发系统:Windows 10.0 Build 18362 开发工具:Visual Studio 2017 Community 支持的系统:Windows 7/10 AnyCPU(指能跑Windows的) 需要说明的内容: 需要说明,本次管理系统对学生的毕设进程进行了简化 分为0,1,2,3,4,5共计6个阶段 其中,系主任开题审批只针对0阶段 教师的审核(中期检查和导师意见)仅针对1,2阶段 系主任的审批(系主任审批和毕业答辩)仅针对3,4阶段 第5阶段为顺利毕业。 安全性考虑: 在登陆过程中对于是否为管理员采用的是预先与储存好的匹配而不是直接进行查询语句,避免了在用户登录过程中被SQL注入的风险,如admin'#这样的常见SQL注入点被避免。 而诸如''or 1=1#或username' AND 1=1—hack这样的注入方式,或者更为恶劣的username;DROP TABLE user—hack的攻击,采用对请求的字符串预处理的形式,过滤其中可提供多语句执行的;和=两个常见字符,在尽可能减少对用户自由性损失的同时,防范SQL注入的攻击。 非常遗憾因为时间关系,密码没能采用加盐后HASH,然后将HASH后数据进行比对的较为安全的方式进行处理,而是直接将明文送入查询。

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

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

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值