结合RBAC模型讲解权限管理系统需求及表结构建立

在本号以前的文章中，已经为你们介绍了不少关于Spring Security的使用方法，也介绍了RBAC的基于角色权限控制模型。可是不少朋友虽然已经理解了RBAC控制模型，可是仍有不少的问题阻碍他们进一步开发。好比：

• RBAC模型的表结构该如何建立？
• 具体到某个页面，某个按钮权限是如何控制的？
• 为了配合登陆验证表，用户表中应该包含哪些核心字段？
• 这些字段与登陆验证或权限分配的需求有什么关系？

那么本文就但愿将这些问题，与你们进行一下分享。

1、回顾RBAC权限模型

• 用户与角色之间是多对多的关系，一个用户有多个角色，一个角色包含多个用户
• 角色与权限之间是多对多关系，一个角色有多种权限，一个权限能够属于多个角色

上图中：

• User是用户表，存储用户基本信息
• Role是角色表，存储角色相关信息
• Menu(菜单)是权限表，存储系统包含哪些菜单及其属性
• UserRole是用户和角色的关系表
• RoleMenu是角色和权限的关系表

本文讲解只将权限控制到菜单的访问级别，即控制页面的访问权限。若是想控制到页面中按钮级别的访问，能够参考Menu与RoleMenu的模式一样的实现方式。或者干脆在menu表里面加上一个字段区别该条记录是菜单项仍是按钮。

为了有理有据，咱们参考一个比较优秀的开源项目：若依后台管理系统。

2、组织部门管理

2.1.需求分析

之因此先将部门管理提出来说一下，是由于部门管理没有在咱们上面的RBAC权限模型中进行提现。可是部门这样一个实体仍然是，后端管理系统的一个重要组成部分。一般有以下的需求：

• 部门要能体现出上下级的结构（如上图中的红框）。在关系型数据库中。这就须要使用到部门id及上级部门id，来组合成一个树形结构。这个知识是SQL学习中必备的知识，若是您还不知道，请自行学习。
• 若是组织与用户之间是一对多的关系，就在用户表中加上一个org_id标识用户所属的组织。原则是：实体关系在多的那一边维护。好比：是让老师记住本身的学生容易，仍是让学生记住本身的老师更容易？
• 若是组织与用户是多对多关系，这种状况现实需求也有可能存在。好比：某人在某单位既是生产部长，又是技术部长。因此他及归属于技术部。也归属于生产部。对于这种状况有两种解决方案，把该人员放到公司级别，而不是放到部门级别。另一种就是从数据库结构上建立User与Org组织之间的多对多关系。
• 组织信息包含一些基本信息，如组织名称、组织状态、展示排序、建立时间
• 另外，要有基本的组织的增删改查功能

2.2 组织部门表的CreateSQL

如下SQL以MySQL为例:

CREATE TABLE `sys_org` (
    `id` INT(11) NOT NULL AUTO_INCREMENT,
    `org_pid` INT(11) NOT NULL COMMENT '上级组织编码',
    `org_pids` VARCHAR(64) NOT NULL COMMENT '全部的父节点id',
    `is_leaf` TINYINT(4) NOT NULL COMMENT '0:不是叶子节点，1:是叶子节点',
    `org_name` VARCHAR(32) NOT NULL COMMENT '组织名',
    `address` VARCHAR(64) NULL DEFAULT NULL COMMENT '地址',
    `phone` VARCHAR(13) NULL DEFAULT NULL COMMENT '电话',
    `email` VARCHAR(32) NULL DEFAULT NULL COMMENT '邮件',
    `sort` TINYINT(4) NULL DEFAULT NULL COMMENT '排序',
    `level` TINYINT(4) NOT NULL COMMENT '组织层级',
    `status` TINYINT(4) NOT NULL COMMENT '0:启用,1:禁用',
    PRIMARY KEY (`id`)
)
COMMENT='系统组织结构表'
COLLATE='utf8_general_ci'
ENGINE=InnoDB
;

注意：mysql没有oracle中的start with connect by的树形数据汇总SQL。因此一般须要为了方便管理组织之间的上下级树形关系，须要加上一些特殊字段，如：org_pids：该组织全部上级组织id逗号分隔，即包括上级的上级；is_leaf是不是叶子结点；level组织所属的层级(1,2,3)。

3、菜单权限管理

3.1 需求分析

• 由上图能够看出，菜单仍然是树形结构，因此数据库表必须有id与menu_pid字段
• 必要字段：菜单跳转的url、是否启用、菜单排序、菜单的icon矢量图标等
• 最重要的是菜单要有一个权限标志，具备惟一性。一般可使用菜单跳转的url路径做为权限标志。此标志做为权限管理框架识别用户是否具备某个页面查看权限的重要标志
• 须要具有菜单的增删改查基本功能
• 若是但愿将菜单权限和按钮超连接相关权限放到同一个表里面，能够新增一个字段。用户标志该权限记录是菜单访问权限仍是按钮访问权限。

3.2 菜单权限表的CreateSQL

CREATE TABLE `sys_menu` (
    `id` INT(11) NOT NULL AUTO_INCREMENT,
    `menu_pid` INT(11) NOT NULL COMMENT '父菜单ID',
    `menu_pids` VARCHAR(64) NOT NULL COMMENT '当前菜单全部父菜单',
    `is_leaf` TINYINT(4) NOT NULL COMMENT '0:不是叶子节点，1:是叶子节点',
    `name` VARCHAR(16) NOT NULL COMMENT '菜单名称',
    `url` VARCHAR(64) NOT NULL COMMENT '跳转URL',
    `icon` VARCHAR(45) NULL DEFAULT NULL,
    `icon_color` VARCHAR(16) NULL DEFAULT NULL,
    `sort` TINYINT(4) NULL DEFAULT NULL COMMENT '排序',
    `level` TINYINT(4) NOT NULL COMMENT '菜单层级',
    `status` TINYINT(4) NOT NULL COMMENT '0:启用,1:禁用',
    PRIMARY KEY (`id`)
)
COMMENT='系统菜单表'
COLLATE='utf8_general_ci'
ENGINE=InnoDB
;

4、角色管理

上图为角色修改及分配权限的页面

4.1.需求分析

• 角色自己的管理须要注意的点很是少，就是简单的增删改查。重点在于角色分配该如何作。
• 角色表包含角色id，角色名称，备注、排序顺序这些基本信息就足够了
• 为角色分配权限：以角色为基础勾选菜单权限或者操做权限，而后先删除sys_role_menu表内该角色的全部记录，在将新勾选的权限数据逐条插入sys_role_menu表。
• sys_role_menu的结构很简单，记录role_id与menu_id，一个角色拥有某一个权限就是一条记录。
• 角色要有一个全局惟一的标识，由于角色自己也是一种权限。能够经过判断角色来判断某用户的操做是否合法。
• 一般的需求：不会在角色管理界面为角色添加用户，而是在用户管理界面为用户分配角色。

4.2.角色表与角色菜单权限关联表的的CreateSQL

CREATE TABLE `sys_role` (
    `id` INT(11) NOT NULL AUTO_INCREMENT,
    `role_id` VARCHAR(16) NOT NULL COMMENT '角色ID',
    `role_name` VARCHAR(16) NOT NULL COMMENT '角色名',
    `role_flag` VARCHAR(64) NULL DEFAULT NULL COMMENT '角色标识',
    `sort` INT(11) NULL DEFAULT NULL COMMENT '排序',
    PRIMARY KEY (`id`)
)
COMMENT='系统角色表'
COLLATE='utf8_general_ci'
ENGINE=InnoDB
;

CREATE TABLE `sys_role_menu` (
    `id` INT(11) NOT NULL AUTO_INCREMENT,
    `role_id` VARCHAR(16) NOT NULL COMMENT '角色ID',
    `menu_id` INT(11) NOT NULL COMMENT '菜单ID',
    PRIMARY KEY (`id`)
)
COMMENT='角色菜单多对多关联表'
COLLATE='utf8_general_ci'
ENGINE=InnoDB
;

5、用户管理

5.1.需求分析

• 上图中点击左侧的组织菜单树结点，要能显示出该组织下的全部人员（系统用户）。在组织与用户是一对多的关系中，须要在用户表加上org_id字段，用于查询某个组织下的全部用户。
• 用户表中要保存用户的用户名、加密后的密码。页面提供密码修改或重置的功能。
• 角色分配:实际上为用户分配角色，与为角色分配权限的设计原则是同样的。因此能够参考。
• 实现用户基本信息的增删改查功能

5.2.sys_user 用户信息表及用户角色关系表的CreateSQL

CREATE TABLE `sys_user` (
        `id` INT(11) NOT NULL AUTO_INCREMENT,
        `org_id` INT(11) NOT NULL,
        `username` VARCHAR(64) NULL DEFAULT NULL COMMENT '用户名',
        `password` VARCHAR(64) NULL DEFAULT NULL COMMENT '密码',
        `enabled` INT(11) NULL DEFAULT '1' COMMENT '用户帐户是否可用',
        `locked` INT(11) NULL DEFAULT '0' COMMENT '用户帐户是否被锁定',
        `lockrelease_time` TIMESTAMP NULL  '用户帐户锁定到期时间',
        `expired_time` TIMESTAMP NULL  '用户帐户过时时间',
        `create_time` TIMESTAMP NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '用户帐户建立时间',
    PRIMARY KEY (`id`)
)
COMMENT='用户信息表'
ENGINE=InnoDB
;

CREATE TABLE `sys_user_role` (
    `id` INT(11) NOT NULL AUTO_INCREMENT,
    `role_id` VARCHAR(16) NULL DEFAULT NULL,
    `user_id` VARCHAR(18) NULL DEFAULT NULL,
    PRIMARY KEY (`id`)
)
COLLATE='utf8_general_ci'
ENGINE=InnoDB
;

在用户的信息表中，体现了一些隐藏的需求。如：屡次登陆锁定与锁定到期时间的关系。帐号有效期的设定规则等。

固然用户表中，根据业务的不一样还可能加更多的信息，好比：用户头像等等。可是一般在比较大型的业务系统开发中，业务模块中使用的用户表和在权限管理模块使用的用户表一般不是一个，而是根据某些惟一字段弱关联，分开存放。这样作的好处在于：常常发生变化的业务需求，不会去影响不常常变化的权限模型。

期待您的关注

• 向您推荐博主的系列文档：《手摸手教您学习SpringBoot系列-16章97节》
• 本文转载注明出处（必须带链接，不能只转文字）：字母哥博客。