Custom data modeling for document forwarding process

It is impossible to develop a more complicated enterprise multiuser management Information System (MIS) without involving the transfer and approval of data files among multiple users in the system. Because the enterprise's demand always changes with the time lapse, plus each enterprise internal office flow is different, a set of general better management Information system should allow system administrator to define the process of document forwarding.

Although the author does not have the opportunity in the developed MIS to implement the document forwarding process customization function, but, early in 2002 has thought deeply about this aspect design. At that time for some reason can not open their own design ideas, now on the market has a lot of mis products to provide such functions, the author has left, so it is time to put my design ideas sorted out, and you share.

First, let's analyze the needs and set goals.

1 under normal circumstances, the enterprise's official documents forwarding, approval is to be transferred by department or position, that is, to hillock not people. For example: a part of a process requires the financial controller for approval, the future financial controller substitution, the process should not be affected. Also, a link in the process may be approved by any one of the departments, or all of the department's personnel will be required to approve it.

2 in the process of transfer, approval of documents generally divided into documents and forms 2 kinds of formats. File format documents should support batch processing, that is, you can forward multiple files at a time, approval can only return one of the unqualified documents, other documents can be transferred to the next link to continue processing. Documents in form format should allow users to define form formats and determine the table entries in the form. In the same vein, the form should support batching.

3 The process of handling official documents should be able to allow users to define their own. This way, once the new processing action is added, there is no need to modify the underlying data modeling of the MIS system. Of course, to implement the new processing action, it is necessary to write the code at the business logic layer, but the workload is much less than the modification of the underlying data model.

4 The number of links per process is not necessarily the same, should allow users to set the number of links, specify the flow of documents in each link in the sending department and accept departments, processing mode, the longest waiting time.

5 When the documents to be processed, the system should be in the waiting time periodically to the next link in the process of the users (people) issued a notice to remind the user (we) timely processing, until the document has been processed. If the maximum wait time is exceeded, the document has not been processed by the user, and the process fails. Enterprise management may require that information be recorded for reference in future business process reengineering (BPR).

6 Some enterprises for special reasons, in a process requirements for the implementation of trans-link processing. For example, the process has 6 steps, the implementation of the second link when required to skip the middle of the three links, directly to the last link waiting for processing. In fact, in this case, it is not necessarily a technical level to achieve its flexibility, which is, after all, a minority. Users only need to define a new process, the above process of the first 1,2,6 step replication to join in, 2 processes between the process name to distinguish between. An excellent system architect should make full use of existing tools and do not set up development on its own.

The above requirements for flexibility, higher levels of abstraction, so in the performance layer and business logic layer of development, the initial investment more, but after the development of the estimate does not need to modify the underlying database, you can meet the future changes in the official document flow needs. If such flexibility is not required, certain assumptions can be simplified in terms of actual projects. The following requirements are followed for use cases analysis and data modeling.

1 due to the process of the sender and receiver is not to the people, we should first draw the entire enterprise setup, determine the rights and responsibilities of each department. There may be a number of sub departments within the larger department, each with a different position in the department responsible for handling the corresponding transaction. So, you can create a tree-relational datasheet to hold the enterprise structure, and then use a combination of permission lists and user groups to preserve the functions of each position in each department. The idea of this piece of design before I released the "Simple discussion of database design techniques (upper), (next)", I directly below the approximate data table structure:

Departmental table (department_table)

Description of name type constraint condition

dp_id int no duplicate category ID, primary key

Dp_name varchar (50) is not allowed to be an empty type name, duplicate is not allowed

Dp_father int is not allowed to identify the parent class of this class, if the top node is set to a unique value

The Dp_layer varchar (6) is limited to 3 layers, the initial value is 000000 categories of first-order traversal, mainly to reduce the number of database retrieval

function table (function_table)

Description of name type constraint condition

f_id int without duplicate function identification, PRIMARY key

F_name varchar (20) does not allow empty feature names, duplicates are not allowed

F_desc varchar (50) allows for empty function description