Source: cnblogs.com/myindex/p/9116177.html
More common is our role-based access control, user roles and privileges by association. Simply put, a user has multiple roles, a role with more authority. In this way, it is configured to " user - role - permission " license model. In this model, between users and roles, and permissions between roles, often-many relationship. As shown below:
Based on this, you must first understand what role in the end is? We can understand it as a collection of a number of rights, the carrier is a privilege.
For example: a forum of "administrator", "moderator", they are all roles. But what can be done is not exactly the same, only moderator in the version management posts, users, etc., which are within the competence, if a user wants to grant these permissions, without direct grant user permissions , simply "moderator" this role can be given to the user.
But we also see the problem from the above, if the number of users is very large, you need to give each user one by one system of authorization (assigning roles), this is a very complicated matter, then you can add a user group, multiple users within each group of users, in addition to a single user authorization, the authorization may also be set to the user, so that, by a single authorization to multiple users can simultaneously grant the same permissions, then the user all the user's personal authority is the authority has the authority and that user's group and owned. User group, and user relationship below the three roles:
Usually in the application of the system of privileges which we showed it to access the menu (page-level), operational function modules (function level), the uploaded file deletion, or even a button on the page, the picture is visible, and so are all privileges category. Some rights design, the operation will function as a class, and the documents, menus, and other page elements as another class, this constitutes a "user - role - authority - resources" licensing model. And in doing modeling data table, can the functional operation and integrated management of resources, that is, are carried out directly associated with permissions on the table, this may be more convenient and easy scalability. As shown below:
这里特别需要注意以下权限表中有一列“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.操作日志表
（完）