General Rights Management Design

A Introduction
Because some of the system's rights management functions are gradually improved, but there are some unsatisfactory places, always want to take a time to better think about the design of the Authority system.
Privilege system has always been an indispensable part of our application system, if each application system to re-design the system's permissions to meet the needs of different system users, will waste our valuable time, so it is very meaningful to spend time to design a relatively universal permission system.
Two Design goals
Design a flexible, universal, convenient rights management system.
In this system, we need to control all the resources of the system, so what are the resources in the system? We can simply summarize these resources as static resources (functional operations, data columns) and dynamic resources (data), also known as Object resources and data resources, which is the name of our system design and implementation.
The goal of the system is to control all the object resources and data resources of the application system, such as the function menu of the application system, the buttons of each interface, the columns of data display and various row level data to manipulate the permissions.
Three Related objects and their relationships
Probably cleared up the relevant concepts of the permission system, as follows:
1. Permissions
All permission information for the system. Permissions have a hierarchical relationship and are a tree-like structure. Let's look at an example
System Management
User Management
View User
New user
Modify User
Delete User
For each of the above permissions, there are two cases, one is just accessible, the other is authorized, for example, "View user" this permission, if the user is only granted "accessible", then he can not assign the permissions he has to other people.
2. User
Bolted 2nd page 2010-7-8
The specific operator of the application system, the user can own the rights information, can belong to 0~n roles, can be belonging to 0~n groups. His permission set is the one with permissions, the permissions that belong to each role, and the set of permissions that belong to each group. Its relationship to permissions, roles, and groups is n-to-N.
3. Roles
In order to classify and manage many users with similar permissions, the concept of roles is defined, such as system administrators, administrators, users, and visitors. A role has a hierarchical relationship that can form a tree view, and the permissions of the parent role are a synthesis of itself and the permissions of all its child roles. The user of the parent role, the group of the parent role, are similarly pushed.
4. Group
In order to better manage users, group groups of users, referred to as the user group. Groups also have a hierarchical relationship that can form a tree view. In the actual situation, we know that the group can also have its own role information, permission information. This reminds me of our QQ user group, a group can have multiple users, a user can also join multiple groups. Each group has its own permission information. For example, view a group share. QQ Group can also have their own role information, such as the General Group, senior group and so on.
For the four types of objects presented above, let's look at the relationship between them through graphs.

It can be seen that the relationship between the four is very complex, and the actual situation is more complicated than the figure, the authority, the role, the group has the subordinate relations, the Authority management is the application system in the more difficult problem, to design a general rights management system, the workload is really not small.
Bolted 3rd page 2010-7-8
Of course, for some projects, the permissions problem is not so complicated. Some only need to involve the rights and the user two types of objects, only need to assign permissions to the user.
In other cases, a role object, such as a role-based permission system, that only needs to be assigned permissions to the role and the user is part of the role, does not require that the user be assigned role information separately.
In the next article, we'll talk about database design for Rights management.
After clearing the object relationship, let's proceed with the design of the database. In database modeling, for N pairs
N relationships, it is generally necessary to add an association table to represent the relationship between the two associations. Preliminary estimate, the system to
Fewer than 10 tables are required: Permission table, user table, Role table, Group table, User Rights association table, user role off
Table, Role Permission Association table, Group Permissions Association table, Group Role Association table, User Group Association table. Of course, it may lead
Some of the related tables. Let's draw the tables in the PowerDesigner.
The tables and their relationships are as follows:
Bolted 4th page 2010-7-8

1. User tables
User table (TUser)
Field Name field type remarks
Record identification tu_id bigint PK, NOT NULL
Affiliated organization TO_ID bigint FK, NOT NULL
Login account login_name varchar (+) NOT NULL
Bolted 5th page 2010-7-8
User password Password varchar (+) NOT NULL
User name Vsername varchar (+) NOT NULL
Cell phone number mobile varchar (20)

e-mail Email varchar (64)

Creation time Gen_time datetime NOT NULL
Logon Time Login_time datetime

Last Login Time Last_login_time datetime

Number of logins count bigint not NULL
2. Character table
Role Table (Trole)
Field Name field type remarks
Role ID tr_id bigint PK, NOT NULL
Parent role ID parent_tr_id bigint NOT NULL
Role name Role_name varchar (+) NOT NULL
Creation time Gen_time datetime NOT NULL
Role Description Description varchar (200)

Bolted 6th page 2010-7-8
3. Permissions table
Permission table (tright)
Field Name field type remarks
Permission ID tr_id bigint PK, NOT NULL
Parent permission parent_tr_id bigint NOT NULL
Permission name Right_name varchar (+) NOT NULL
Permission Description Description varchar (200)

4. Group table
Group table (Tgroup)
Field Name field type remarks
Group ID tg_id bigint PK, NOT NULL
Group name Group_name varchar (+) NOT NULL
Parent group parent_tg_id bigint NOT NULL
Creation time Gen_time datetime NOT NULL
Group Description Description varchar (200)

5. Role Permissions Table
Role Permissions table (trolerightrelation)
Bolted 7th page 2010-7-8
Field Name field type remarks
Record identification trr_id bigint PK, NOT NULL
Role role_id bigint FK, NOT NULL
Permissions right_id bigint FK, NOT NULL
Permission type Right_type int NOT null (0: Accessible, 1: Available
Authorized
6. Group Permissions Table
Group Permissions table (tgrouprightrelation)
Field Name field type remarks
Record identification tgr_id bigint PK, NOT NULL
Group tg_id bigint FK, NOT NULL
Permissions tr_id bigint FK, NOT NULL
Permission type Right_type int NOT null (0: Accessible, 1: Available
Authorized
7. Group Roles Table
Group Roles table (tgrouprolerelation)
Field Name field type remarks
Bolted 8th page 2010-7-8
Record identification tgr_id bigint PK, NOT NULL
Group tg_id bigint FK, NOT NULL
Role tr_id bigint PK, NOT NULL
8. User Rights table
User Rights table (tuserrightrelation)
Field Name field type remarks
Record identification tur_id bigint PK, NOT NULL
User tu_id bigint FK, NOT NULL
Permissions tr_id bigint FK, NOT NULL
Permission type Right_type int NOT null (0: Accessible, 1: Available
Authorized
9. User Role Table
User Role Table (tuserrolerelation)
Field Name field type remarks
Record identification tur_id bigint PK, NOT NULL
User tu_id bigint FK, NOT NULL
Role tr_id bigint FK, NOT NULL
Bolted 9th page 2010-7-8
10. User Group table
User Group table (tusergrouprelation)
Field Name field type remarks
Record identification tug_id bigint PK, NOT NULL
User tu_id bigint FK, NOT NULL
Group tg_id bigint FK, NOT NULL
11. Organizational chart
Organizational chart (torganization)
Field Name field type remarks
Organization ID to_id bigint PK, NOT NULL
Parent group parent_to_id bigint NOT NULL
Organization Name Org_name varchar (+) NOT NULL
Creation time Gen_time datetime NOT NULL
Organization Description Description varchar (200)

12. Operation Log Table
Operation Log Table (TLOG)
Field Name field type remarks
Bolted 10th page 2010-7-8
Log ID log_id bigint PK, NOT NULL
Operation type Op_type int NOT null
Action contents content varchar ($) NOT NULL
Operator tu_id bigint FK, NOT NULL
Operation time Gen_time datetime NOT NULL

General Rights Management Design