Realization of user Rights Management in business system--design article

　　b/S system is more important than C/S, c/s system because of a special client, so access to the user's permission detection can be achieved through the client or through the client + server detection, and b/s, the browser is every computer has, if not to establish a complete permission detection, Then an "illegal user" is likely to be able to easily access all the functions in the B/s system through the browser. Therefore, b/s business system needs to have one or more permission system to implement access rights detection, so that authorized users can legitimately use the authorized functions, and for those unauthorized "illegal users" will be completely "shut them out." Let us see together how to design to meet the majority of B/s system in the user function of the rights control system.

Demand statement

• people with different responsibilities should have different permissions for the system operation. Excellent business system, this is the most basic function.

• You can assign permissions to groups . For a business system of a large enterprise, it is a time-consuming and inconvenient thing to ask the administrator to assign the system operation permission to the employee. Therefore, the concept of "group" is put forward in the system, the people with the same permissions are programmed into the same group, and then the rights are assigned to the group.

• The Rights management system should be extensible. It should be able to participate in any system with rights management capabilities. Just as components can be reused, not every development of a management system, it is necessary to re-develop the Rights Management Section.

• satisfies functional permissions in the business system. in traditional business system, there are two kinds of rights management, one is the management of the function authority, while the other is the management of resource rights, and the function permission can be reused between different systems, and the resource permission cannot.

About Design

　　With Noahweb's action programming concept, in the design phase, the system designer does not need to consider the design of the program structure, but begins with the program flow and the database structure. In order to realize the requirement, the design of database is very important, whether it is the concept of "group" operation or the reusability of the whole set of Rights management system, it is the design of database.

Let's start by analyzing the database structure:

　　First, the Action table (hereinafter referred to as the "permission Table"), the Gorupmanager table (hereinafter referred to as the "Management Group Table"), and the Master table (hereinafter referred to as the "People Table"), are three entity tables, They record in turn the "permissions" information, "management Group" information and "people" information. Such as:

　　The relationships between the three tables are many-to-many, and one permission may belong to more than one administrative group, and multiple permissions may also be included in an administrative group. Similarly, a person may belong to multiple administrative groups at the same time, and an administrative group may contain multiple people at the same time. Such as:

　　Since there are many-to-many relationships between these three tables, the interaction between them is best done using two additional tables. The two tables are mapped to the "Actiongroup" table (hereinafter referred to as the "Permissions Mapping Table") and the "Mastergroup" table (hereinafter referred to as the "People Mapping Table"), which maps the interaction between the permission table and the Management Group table. The latter maps the interaction between the people table and the Management Group table. Such as:

　　In addition, a table is required to control the permissions column in the left-hand menu when the system is running, that is, the "Permissions column table", such as:

　　Based on the above analysis, we conduct database structure design, such as:

Click here to view the design of the data table field of the Rights management system

　　In order to be able to perform good analysis, we split the database structure diagram, the function of the three entities table is already very clear, now let's look at the two mapping table role.

A permissions mapping table such as:

　　First, let's look at the field associations between the permission mapping table and the Management Group table and the permission table .

　　Look at the red circle in the picture, first look at the Gorupid field Associated, the association in the actual database performance such as:

　　, the GroupID of "super Administrator" in the Management Group table is 1, so the permissions GroupID 1 in the permission map table are the permissions that "Super Administrator" has.

　　Use the GroupID Field Association to find out what permissions a management group can perform. However, the details of these permissions are queried by the Action Field Association.

　　The action field is associated with the behavior in the database such as:

　　This association is the only way to query the details of those permissions in the permission mapping table . Together, we know what permissions a management group can perform, and what the details of those permissions are.

　　Perhaps you would ask, why not use the ActionId field associated with it? Because:

• The ID field in the permission table may change after several database operations.
• The Permissions mapping table only records the permissions that an administrative group can perform.
• Once the ID in the permission table changes, the records in the permission map table are changed.
• The permissions that an administrative group can perform are bound to make an error, which is very much not desirable.

　　Consider the above situation, so you should use the action field to correlate because:

• In the permissions table , the ID may change, and the action field is not likely to change under any circumstances.
• The action field that is recorded in the Permission mapping table will not change.
• The permissions that an administrative group can perform will not go wrong.

Two person mapping table such as:

　　Let's look at the field associations between the people mapping table and the Management Group table and the people table , such as:

　　Look at the red Circle section of the picture, first look at the GroupID Field Association, the association in the database performance such as:

　　, "Super admins" group GroupID is 1, we look at the people mapping table , admin belongs to the Super Admins group, and administrator belongs to the Super Admins group, but also belongs to the Administrators group.

　　This association is used to find out who the people in a management group are. As with the above, the details of the person are queried by the ID field (the MasterID field in the People Mapping table ).

　　The ID field (the MasterID field in the People Mapping Table ) is represented in the form of a database such as:

　　A person may belong to more than one administrative group at a time, and administrator belongs to two administrative groups at the same time. So, there will be two records about administrator in the people mapping table .

　　This association is the only way to query the details of the people in the management group. Together, you can know who the people in a management group are, and the details of this person.

　　Combining the permissions table and the Permission mapping table mentioned above, the "group" operation in the requirement is implemented, such as:

　　In fact, the Management Group table only records basic information about the group, such as name, group ID, and so on. Details about the people in a group, and the permissions that the group can perform, are documented in the people tables and permissions tables . Two mapping tables really record what people are in a group and what permissions they can perform. Through the convergence of the two mapping tables, the interaction between the three entity tables is realized, which completes the "group" operation mentioned in the requirements.

　　Let's look at the interaction between the Permissions column table and the permission table . The fields between the two tables are associated as follows:

　　Two tables are associated with the Actioncolumnid field, which behaves in a database such as:

　　, through this association, we can see very clearly which of the permissions in the permission table belongs to which column.

　　Now that the database structure is clear, the ability to assign permissions and the "group" operations have been implemented. Let's examine the reusability of the Rights management system mentioned in the requirements.

　　Why can a system built with this database design be reused?

• the three decisive elements in the system are recorded in three entity tables. "Permissions", "groups" and "people". And these three elements can be arbitrarily added, not affected by each other. Regardless of the type of business system, these three decisive elements will not change, meaning that the structure will not change, but only the data.
• the relationship between three elements is recorded in two mapping tables. But these relationships are completely man-made and need to change, just manipulate the records in the database without altering the structure.
• The columns displayed in the system's use are recorded in the Permissions column table . Whether you want to add columns, modify columns, or reduce columns, it's just a record of operations.

　　In summary, this design database, the system is completely reusable, and can withstand the "change" test.

Summarize:

　　The focus of this system is that the three entity tables firmly capture the core components of the system, and the two mapping tables perfectly map the interactions between the three entity tables. The difficulty lies in understanding the work of the mapping table, which records relationships and implements the concept of "group" operations. The overall system design is based on the different MIS systems can be "reused" to meet the functional rights of different systems set.

Appendix:

field design of data table for Rights management system

　　Let's take a look at the database table design of the Rights management system, which is divided into six tables, such as:

Action table:

　　The action table records all the actions in the system, as well as the action-related descriptions.

Actioncolumn table:

　　Actioncolumn table records the action of the column, the system runs, the left menu bar provides a few different functions, each piece is a column, each add a column, the table records will be added one, the corresponding, the left menu bar will also add a column.

Actiongroup table:

　　The Actiongroup table records the group in which the action is located.

Groupmanager table:

　　The Groupmanager table records information about the management group, and each additional management group adds a record.

Mastergroup table:

　　The Mastergroup table records the administrative group in which the administrator is located, because one administrator may belong to more than one group at a time, so there may be multiple records for an administrator in the table.

Master table:

　　The master table records information for all administrators, and each time an administrator is added, the table adds a record.

Realization of user Rights Management in business system--design article