Document Forwarding process Custom Data Modeling

Recently, I saw an article in my blog "converting the Document Forwarding process custom data modeling. I am going to raise this topic for discussion and discussion, with the main purpose of improving. My general requirements are as follows:

Developing a complex enterprise multi-user management information system (MIS) does not involve the development of functions such as data file transfer and approval among multiple users in the system. As the requirements of enterprises always change over time, and the office processes set in each enterprise are different, A general management information system should allow the system administrator to define the Document Forwarding process.

Objectives:

• Generally, documents in an enterprise are forwarded and approved by a department or position. For example, if a process needs to be approved by the financial director at a specific stage, the process should not be affected if the financial director changes to another person in the future. In addition, any person in a department may be able to approve the application at a stage in the process, or all personnel in the Department may need to approve the application together.
• In the process, the approved documents are generally divided into two formats: files and forms. Documents in the file format should support batch processing, that is, multiple files can be forwarded at a time. Only one unqualified file can be returned during approval, other files can be transferred to the next step for further processing. The document in the form format should allow you to define the form format and determine the table items in the form. Similarly, the form should support batch processing.
• You can customize the process to process documents. In this way, once a new processing action is added in the future, you do not need to modify the underlying data modeling of the MIS system. Of course, to implement new processing actions, you still need to write the corresponding code at the business logic layer. However, compared with modifying the underlying data modeling, the workload is much less.
• The number of links in each process is not necessarily the same. Users should be allowed to set the number of links and specify the sending Department and receiving department for each link in the document flow. The processing mode is the longest waiting time.
• After the documents to be processed are issued, the system should regularly send notifications to the users in the next step of the process during the waiting time to remind the users to process the documents in a timely manner, until the document has been processed. If the maximum waiting time is exceeded and the document has not been processed by the user, the process fails to be processed. The enterprise management may require relevant information to be recorded for reference in future business process reengineering.
• Some enterprises require cross-link processing in a specific process for special reasons. For example, there are six steps in the process. When the second step is executed, you can skip the three steps and directly go to the last step for processing. In fact, in this case, it is not necessary to implement its flexibility at the technical level. Such a special case is, after all, a minority. You only need to define a new process and copy steps 1, 2, and 6 of the above process. The two processes can be distinguished by the process name. A good system architecture designer should make full use of the existing tools and do not develop anything on its own.

Analysis:

1) Since the sender and receiver of each node in the process are not the same person, the authority setting of the entire enterprise should be taken into account to determine the rights and responsibilities of each department. There may be several sub-departments in each major department, and each sub-department has a different position, responsible for handling the corresponding affairs.

* The department settings are based on the positions of relevant personnel of each department.
* Set specific post permissions for the user group.
* A specific department may have permissions on the positions of several user groups.

The data model is as follows:

Notes:
In the figure, it may be suggested that the user group Department table and user group table should be merged into a table. My consideration is that you do not need to consider specific details when setting the user group Department table. You also do not need to consider which department you belong to when setting the user group function. Because a user group can belong to only one department or several departments, in other words, a department can have permissions in one user group or multiple user groups.

2) Approval documents are generally divided into two formats: files and forms. Abstract documents. Extract the common attributes of Two formats of documents to create a document table.

A. File Format

Document Table (Document_table)
Description of name type constraints
Doc_id int no duplicate Document ID, primary key
Doc_name varchar (50) cannot be empty document names
Doc_type char (1) cannot be empty document type

The doc_type field is used to identify the document format. Currently, there are only two formats. "1" indicates the file format, and "2" indicates the Form format. It is estimated that there will not be too many new document formats in the future, so this field only needs one character. Documents in the file format are usually fixed in the file. We can use a binary field to directly Save the content of the entire file. An official document in the file format needs to be created to save the relevant information. Its Approximate data table is as follows:

File Table (File_table)
Description of name type constraints
File_id int no duplicate file ID, primary key
File_name varchar (50) cannot be empty file names
File_value binary cannot be empty file content
......

B. For documents in the form format, you must define the form format and determine the table items in the form. There are two methods to achieve this:

① Every time a user creates a new format form, a new table is created, and the table items entered by the user are treated as fields of the table. The advantage of this method is that the form query speed is fast and convenient, and the development of the business logic layer is small. The disadvantage is that it is not flexible. If the enterprise uses more forms of different formats (> 20), the structure of the entire database is chaotic, and most forms have the same fields, this also increases data redundancy.

Data Modeling in this way is as follows:
Table Summary table (Sheet_table)
Description of name type constraints
Sheet_id int no duplicate form ID, primary key
Sheet_name varchar (50) cannot be empty form name
Table_name varchar (20) cannot be empty table sub-table names, such as Sub_table1/Sub_table2

Table subtable 1 (Sub_table1)
Description of name type constraints
Sub_id int no repeated table sub-Table ID, primary key
Option1 varchar does not allow empty form table entry 1
Option2 varchar does not allow empty form table entry 2
Option3 varchar does not allow empty form table entry 3
......

Table subtable 2 (Sub_table2)
Description of name type constraints
Sub_id int no repeated table sub-Table ID, primary key
Option1 varchar does not allow empty form table entry 1
Option2 varchar does not allow empty form table entry 2
Option3 varchar does not allow empty form table entry 3
......

......

② Abstract the form and regard the form as a set composed of several form table items. The advantage of this method is that it is quite flexible. When you create a new lattice form, you only need to select the expected table items from the existing table items, and the entire database structure is clear without data redundancy. The disadvantage is that the development is complicated, the workload is much higher than above, and the form query speed is slow. Data Modeling in this way is as follows:

Table Summary table (Sheet_table)
Description of name type constraints
Sheet_id int no duplicate form ID, primary key
Sheet_name varchar (50) cannot be empty form name

Table item table (Option_table)
Description of name type constraints
Op_id int no repeated form table item identifier, primary key
Op_name varchar (50) does not allow empty form table item names
Op_length int cannot be empty.
Op_unit varchar (10) allows empty table item units

Form information table (Sheetinfo_table)
Description of name type constraints
Info_id int no duplicate form information identifier, primary key
The sheet_id int cannot be empty. It is associated with Sheet_table.sheet_id.
Op_id int cannot be an empty form table item identifier, which is associated with Option_table.op_id
Info_value varchar () cannot be empty form information value

For the above two cases, I personally think the second one should be more appropriate.

Continuing ....