数据关系n:n到1:1优化

案例背景：
目前较为常见的用户权限鉴权模型：基于角色的访问控制RBAC（Role-Based Access Control）
RBAC介绍：
涉及程序的权限管理时，大家往往想到角色这一概念。角色是代表一系列可执行的操作或责任的实体，用于限定你在软件系统中能做什么、不能做什么。用户帐号往往与角色相关联，因此，一个用户在软件系统中能做什么取决于与之关联的各个角色。
例如，一个用户以关联了”管理员”角色的帐号登录系统，那这个用户就可以做项目管理员能做的所有事情哦，管理员可以做啥，整个用户就可以得到所有的权限。
RBAC隐式角色：
直接通过角色来验证用户有没有操作权限，如下代码示例：

if (user.hasRole("role1") ) {
   
    //show the button
} else {
   
    //don't show the button
}

如上某个接口或者功能只给role1使用，如果没有这个权限则其他处理方式。假如需求发生变更，role2 角色也可以使用，那么就需要调整代码。

if (user.hasRole("role1")|| user.hasRole("role2") ) {
   
    //show the button
} else {
   
    //don't show the button
}

程序扩展性很差，相当于代码写死，未来调整需求，成本加大，且容易出现遗漏测试的风险。
RBAC新解：Resource-Based Access Control
在程序中通过权限控制谁能访问某个资源，角色聚合一组权限集合；这样假设哪个角色不能访问某个资源，只需要从角色代表的权限集合中移除即可；无须修改多处代码；即粒度是以资源/实例为单位的；粒度较细。只要把明确的资源定义下面，这样就是一个资源操作的集合，把资源给某个角色就好，这样这个角色就拥有了访问的权限。

if (user.isPermitted("permit:view:a")) {
   
    //show the button
} else {
   
    //don't show the button
}

如果用户被明确的知道控制访问的是什么接口或者功能，把资源权限挂靠到角色下面，如果该角