共计 1696 个字符，预计需要花费 5 分钟才能阅读完成。
作者：不哼不哈
cnblogs.com/myindex/p/9116177.html
咱们比拟常见的就是基于角色的访问控制，用户通过角色与权限进行关联。简略地说，一个用户领有多个角色，一个角色领有多个权限。
这样，就结构成“用户 - 角色 - 权限”的受权模型。在这种模型中，用户与角色之间、角色与权限之间，通常都是多对多的关系。如下图：
基于这个，得先理解角色到底是什么？咱们能够了解它为肯定数量的权限的汇合，是一个权限的载体。
例如：一个论坛的“管理员”、“版主”，它们都是角色。然而所能做的事件是不齐全一样的，版主只能治理版内的贴子，用户等，而这些都是属于权限，如果想要给某个用户授予这些权限，不必间接将权限授予用户，只需将“版主”这个角色赋予该用户即可。
然而通过下面咱们也发现问题了，如果用户的数量十分大的时候，就须要给零碎的每一个用户逐个受权(调配角色)，这是件十分繁琐的事件，这时就能够减少一个用户组，每个用户组内有多个用户，除了给单个用户受权外，还能够给用户组受权。
这样一来，通过一次受权，就能够同时给多个用户授予雷同的权限，而这时用户的所有权限就是用户集体领有的权限与该用户所在组所领有的权限之和。用户组、用户与角色三者的关联关系如下图：
通常在利用零碎外面的权限咱们把它体现为菜单的拜访(页面级)、功能模块的操作(性能级)、文件上传的删改，甚至页面上某个按钮、图片是否可见等等都属于权限的领域。
有些权限设计，会把性能操作作为一类，而把文件、菜单、页面元素等作为另一类，这样形成“用户 - 角色 - 权限 - 资源”的受权模型。
而 在做数据表建模时，可把性能操作和资源对立治理，也就是都间接与权限表进行关联，这样可能更具便捷性和易扩展性。如下图：
这里特地须要留神以下权限表中有一列“PowerType(权限类型)”，咱们依据它的取值来辨别是哪一类权限，能够把它了解为一个枚举，如“MENU”示意菜单的拜访权限、“OPERATION”示意功能模块的操作权限、“FILE”示意文件的批改权限、“ELEMENT”示意页面元素的可见性管制等。
这样设计的益处有两个：
一、不须要辨别哪些是权限操作，哪些是资源，（实际上，有时候也不好辨别，如菜单，把它了解为资源呢还是功能模块权限呢？）；
二、不便扩大，当零碎要对新的货色进行权限管制时，我只须要建设一个新的关联表“权限 XX 关联表”，并确定这类权限的权限类型字符串即可。
须要留神的是，权限表与权限菜单关联表、权限菜单关联表与菜单表都是一对一的关系。（文件、页面权限点、性能操作等同理）。也就是每增加一个菜单，就得同时往这三个表中各插入一条记录。
这样，能够不须要权限菜单关联表，让权限表与菜单表间接关联，此时，须在权限表中新增一列用来保留菜单的 ID，权限表通过“权限类型”和这个 ID 来辨别是种类型下的哪条记录。最初扩大进去的模型残缺设计如下图：
留神下面我额定减少了一个操作日志表；
随着零碎的日益宏大，为了方便管理，如果有须要可引入角色组对角色进行分类管理，跟用户组不同，角色组不参加受权。
例如：当遇到有多个子公司，每个子公司下有多个部门，这是咱们就能够把部门了解为角色，子公司了解为角色组，角色组不参于权限调配。
另外，为不便下面各主表本身的治理与查找，可采纳树型构造，如菜单树、性能树等，当然这些可不须要参于权限调配。
数据字典：
1. 用户表：
2. 角色表：
3. 用户与角色关联表
4. 用户组表
5. 用户组与用户信息关联表
6. 用户组与角色关联表
7．菜单表
8. 页面元素表
9. 文件表
10. 权限表
11. 权限与菜单关联表
12. 权限与页面元素关联表
13. 权限与文件关联表
14. 性能操作表
15. 权限与性能操作关联表
16. 角色与权限关联表
17. 操作日志表
近期热文举荐：
1.600+ 道 Java 面试题及答案整顿(2021 最新版)
2. 终于靠开源我的项目弄到 IntelliJ IDEA 激活码了，真香！
3. 阿里 Mock 工具正式开源，干掉市面上所有 Mock 工具！
4.Spring Cloud 2020.0.0 正式公布，全新颠覆性版本！
5.《Java 开发手册（嵩山版）》最新公布，速速下载！
感觉不错，别忘了顺手点赞 + 转发哦！
