A Method for Controlling Data State Consistency in a Multi-Level Centralized Environment

Abstract

The present invention proposes a method for controlling data status consistency in a multi-level central environment, which constructs a distributed information management system into a multi-level data management center; sets a unique management identifier ID for the data of the management center, and the ID includes a version number and a modification count. The version number corresponds to the multi-level management center, and the number of version levels corresponds to the number of levels of the management center; the multi-level data management center receives, changes, and sends data through the management representation ID. This method has strong versatility and can be reused in the data status storage applications of each center in a multi-center environment, and flexibly adapts to the status control requirements of each level of center for data receiving and sending and local data processing. It can not only be applied to a distributed data management environment caused by network isolation, but also be applied to an environment with centralized data storage but emphasizing hierarchical management of permissions.

Description

Technical Field

[0001] The present invention relates to a method for controlling the consistency of data version states, and particularly to a method for controlling the consistency of data states in a multi-level central environment. Background Art

[0002] A business process is a concept generated by work division, which refers to a series of activities orderly completed by different people for a common goal. There is a sequence or conditional limitation between activities, and the content, method, responsibility, etc. of the activities are also clearly defined so that the activities can be transferred and handed over between different people. In the field of information management, it can be narrowly understood as a work process orderly composed of a series of process nodes and execution methods associated with customer value satisfaction.

[0003] In the field of information management, business process management often uses workflow engine technology for support. A workflow is an abstraction of a business process, and a workflow engine is a set of implementation tools to drive the workflow. It can conveniently define the roles and divisions in the business process and determine the information transfer routing, content level, etc. according to different conditions. Generally, a workflow engine needs to define forms such as work (a single activity), task (an interactive task), user (a participant), etc., and drive operations such as data flow, rollback, and retry through the set process.

[0004] The workflow engine can achieve visual business orchestration through abstracting and formatting the process, which is easy to maintain and expand. However, introducing the workflow itself will increase the engineering difficulty, and each node must be able to access the forms defined by the workflow engine simultaneously to correctly drive the business process. When business management systems are isolated from each other and cannot directly access data, it will be very difficult to use the workflow engine to support long-chain business process management such as multi-level review and approval.

[0005] During the data management process, it is often desired to retain the data before the operation and be able to see the data changes before and after the operation. Generally, it is achieved by retaining historical data and using data version management. The most common version management solution is to add a version number field to the table that retains historical data. The version number can be time or a number, and it only increases and does not decrease. The largest version number corresponds to the latest business data.

[0006] When using the same database (including distributed databases) during the business management process, it is very convenient to perform global data version control. Each user can obtain the latest business data and its historical versions through the database when processing data. When a user modifies the data, the original version of the data will not be modified, but new data will be added and given a new version number. The new data and historical data are indicated as different states of the same data record through the unique identifier of the data record.

[0007] However, during the business management process, due to network condition limitations or security and confidentiality restrictions, business data may be stored in different databases (not directly connected) and maintained separately by different units / users. When data interaction is carried out through data delivery / data ferry and other methods, it becomes difficult to maintain the consistency of data versions, and its complexity will continuously increase with the complexity of business relationships and the refinement of management requirements.

[0008] To reflect the authority, solemnity, and comprehensiveness of management, there are inherent technical requirements for unified data specifications and full-process operation traceability in the multi-level reporting and review management process of business data. However, in some specific scenarios, such as when network conditions are unavailable, each user and each node participating in the review process actually form a situation of coexistence of multiple centers and asynchronous data maintenance, which brings great inconvenience to maintaining data consistency among multiple levels and multiple nodes.

[0009] In the process of business data management under the condition of coexistence of multiple centers, business data flows between the central databases of each center according to a certain process, and is continuously modified, reviewed, adjusted, and deleted. On the one hand, it is hoped that as many and as detailed data change records as possible can be retained and interacted in the software system, which means storing more business data versions and increasing the scale of data management. On the other hand, it is hoped that the access performance of business data tables and the data interaction performance between nodes can be ensured under the condition of a large number of historical business data version states, and these performances all decline as the data scale increases. Under the condition of non-networked multi-center distribution, the performance of a single center is limited and the data delivery performance between multiple centers is limited. Summary of the Invention

[0010] How to provide a generalized, extensible, and lightweight data status control method to meet the requirements of data status consistency and traceability in the process of data collaborative management under multi-center conditions, and balance the degree of management refinement and data processing performance is the core technical problem to be solved by the present invention. The present invention provides a method for controlling data status consistency in a multi-level center environment, which includes the following steps:

[0011] Construct a distributed information management system into a multi-level data management center;

[0012] Set a unique management identifier ID for the data of the management center, where the ID includes a version number and a modification count. The version number corresponds to the multi-level management center, and the number of version levels corresponds to the number of levels of the management center;

[0013] The multi-level data management center receives, changes, and sends data through the management representation ID.

[0014] Further, in the multi-level data management center, a high-level data management center can be composed of at least one low-level data management center combined;

[0015] Peer data management centers belonging to the same high-level data management center can perform data interaction, while peer data management centers belonging to different high-level data management centers cannot perform direct data interaction.

[0016] Furthermore, when data is changed within the data management center, the version number remains unchanged while the modification count is changed.

[0017] When sending data to other data management centers, the data version number is changed to the version number of the higher-level data management center.

[0018] Furthermore, when data is changed or transferred, it is also necessary to record the data ID, the version number before the change, the person making the change, the unit to which the person making the change belongs, the change time, and the reason for the change.

[0019] Furthermore, the method also includes setting up multi-level data tables, which include the latest information management table, the data receiving and sending historical version table, the operation record table, and the same-version change information table. Specifically:

[0020] The latest information management table stores the status of the local latest data, with its primary key being the data management identification ID. It also specifically stores the data version number and the modification count, the information of the person changing the data, and the data change time.

[0021] The data receiving and sending historical version data table stores the data status when this data management center performs data interaction with peer data management centers outside. This table corresponds to the level of this data management center and specifically stores the data management ID, the version number corresponding to the level of this center, the receiving and sending time, the data source, and the data destination.

[0022] The operation record table is used to record all data change operations within this data management center. This table retains the historical records in the latest information management table and the states before and after each change.

[0023] The same-version change information table records the overall change situation of data with the same version and the same ID within this data management center.

[0024] Furthermore, when the data management center receives data sent by other centers, the data is added with the receiving and sending time and the data source and then stored in the historical version table corresponding to the level of this center.

[0025] The version number corresponding to the level of this data management center recorded in the received data is incremented by 1, the modification count is cleared, and then it is stored in the latest information management table.

[0026] Further, when the local data of the data management center changes, the changed data is saved to the latest information management table. If there is data with the same management ID, the original data is overwritten. The new data version number starts from the initial state. The version numbers of deleted and modified data remain unchanged, and the modification times are incremented by 1. At the same time, the data status before and after the change is stored in the operation record table.

[0027] Further, when the data management center sends data to other data management centers, part or all of the data is selected from the latest information management table according to the sending requirements and sent to other data management centers. At the same time, the change information corresponding to the sent data recorded in the same version change information table can also be sent to other data management centers.

[0028] Through the method provided by the present invention, in the scenario of collaborative business data management by multiple users, a method for consistent control of data status is provided to achieve refined management of data status in the entire system, limit the amount of business data interaction between multiple centers, ensure the access performance of business data, enable each center node to finally obtain a data status copy that can be mastered according to permissions, and ensure the final data consistency of multiple data copies. Brief Description of the Drawings

[0029] Figure 1 Multi-center environment structure model

[0030] Figure 2 Multi-center environment structure diagram Detailed Embodiments

[0031] Next, the technical solutions in the embodiments of the present invention will be clearly and completely described in conjunction with the drawings. Obviously, the described embodiments are only a part of the embodiments of the present invention, rather than all the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative efforts belong to the protection scope of the present invention.

[0032] Generally, a data management information system participated by multiple users stores data in a centralized data center, which is beneficial to the consistent control of data status. However, when the network conditions are not available, or the system has special hierarchical and permission management requirements, multiple data centers can be set up to each maintain local business data. Due to network or permission division restrictions, direct data sharing and overall replication cannot be carried out between the centers, and only necessary business data interactions are carried out to achieve collaborative management and maintenance of data.

[0033] For the same data record, it will be created, modified, and deleted by different users during the business management process, that is, the status of this data record is constantly changing. In an information management system, version numbers are commonly used to mark the status of data. The same data record with different version numbers represents different statuses of this data record. Therefore, the data version is an important indicator to illustrate the data status. In addition, the time information of data creation / modification / deletion, the operator information of data creation / modification / deletion, and the information explaining the reason for data change (such as review opinions, etc.) are all information used to explain the data status. Together with the version number, these information can comprehensively illustrate the data status and the reason for status change.

[0034] In this patent application, in the face of a relatively complex multi-center environment, a multi-level data version management mechanism can be adopted. The version number can adopt a multi-level form of 011.045.234. The first digit field represents the number of times a large unit modifies the data (1st-level version number), the second three-digit field represents the number of times a certain department within the large unit modifies the data in the data status of the 1st-level version (2nd-level version number), and so on. In this way, the change situation of the data status within a large system can be finely recorded.

[0035] Generally, within a single database, data consistency (Consistency) means that the data integrity is not damaged before and after the start and end of a transaction.

[0036] In a distributed system, data consistency means that for each client, every read operation must return the result of the latest write operation. In a distributed system, there are often multiple copies of data. At this time, data consistency mainly focuses on the synchronization of each copy to a certain data status update operation within a certain time window. The length of the time window will mark the strength of the data consistency that the system can achieve.

[0037] In this patent application, in a multi-center environment, there are multiple data copies similar to a distributed system stored on different central nodes. The data copies on each node are not uniformly controlled through the internal synchronization mechanism of the underlying distributed database, but are multiple data copies generated through business data transfer. Therefore, more detailed design is required to achieve the control of data consistency.

[0038] This is a set of relative concepts commonly found in various information management systems. Business data is the data related to business work that is continuously added during the operation of the system as the business work progresses; while basic data is the data dictionary of the system, which exists in the system database during system initialization and provides unified structural support for the consistency and standardization of business data content, and is the basis for the smooth progress of business and the efficient operation of the system.

[0039] In this application, the data status mentioned mainly refers to the status of business data. Although there are actually version changes (status changes) in basic data, the change frequency is relatively low and it is generally maintained and released uniformly. Therefore, the status consistency of basic data is not specifically considered.

[0040] When there are multiple versions of business data, to accurately find a specific version of a data record, precise retrieval needs to be carried out based on two conditions: the identification code of the data record and the version number of the data record. If all multi-version business data is stored in a single data table, the scale of this data table will increase as the data version changes, and the retrieval performance of this table will be limited by the rapidly growing scale.

[0041] When actual users use business data, the most commonly used is the latest status (latest version). Therefore, to improve the performance of common functions (modifying and deleting the latest version of business data), the business data table can be divided into multiple levels. One table is specifically used to store the business data in the latest status, and another table is used to store the business data of each historical version. If the version number is also divided into multiple levels of control, such as level 1 version + level 2 version, then the data table for storing historical versions can be further split into multi-level data tables. The level 1 historical version table stores the latest data status under each level 1 version, and the level 2 historical version table stores the latest data status under each level 2 version...

[0042] The technical solution adopted by the present invention is to perform multi-level version control on business data and supporting multi-level data table management, and construct a set of general, extensible, and lightweight data status control methods to adapt to the characteristics of data status consistency control in a multi-center environment, ensure data integrity while controlling the amount of data interaction between multiple centers, and balance data access performance and the level of detail of version records.

[0043] When the network conditions are not available, or when the information management system has special hierarchical and permission management requirements, multiple data centers can be set up to each maintain local business data. Due to network or permission division restrictions, direct data sharing and overall replication cannot be carried out between centers, and only necessary business data interactions are carried out to achieve collaborative management and maintenance of data. The structural model of the multi-center environment is as Figure 1 shown.

[0044] Figure 1 In the figure, multiple data centers, A, B, C, and D, are given, and there are data interaction relationships between them, represented by arrowed lines. Each center can be further divided into smaller centers internally, and there are also data flow relationships between centers, represented by dotted arrowed lines. By analogy, each small center can also be further divided into smaller centers internally. The relationship between the centers and the data, as well as the relationship between the centers, is abstracted and specified as follows:

[0045] (1) Multi - center hierarchical structure

[0046] The multi - centers can be divided into level - 1 centers, level - 2 centers, level - 3 centers... according to the management level. Among them, a higher - level center can be composed of multiple lower - level centers combined.

[0047] Considering the requirements of network isolation or hierarchical and permission - based management, the databases of each peer - level center cannot directly access each other, and only part of the data of the other party can be obtained through a pre - set data interaction interface.

[0048] (2) Interaction limitations between centers

[0049] In principle, there should be no direct interaction relationship between level - 2 centers across level - 1 centers, and they must interact through their respective superior level - 1 centers. For example, level - 2 center A.2 cannot directly interact with level - 2 center C.3, but must interact indirectly through superior centers A and C.

[0050] There must be an interaction relationship between a higher - level center and its internal lower - level center. To simplify the model, it can be considered that a higher - level center is equivalent to a certain lower - level center within it. For example, level - 1 center A is equivalent to level - 2 center A.1. As level - 1 center A, it has interaction relationships with other level - 1 centers B, C, and D. As level - 2 center A.1, it has interaction relationships with other level - 2 centers A.2 and A.3.

[0051] Low - level centers within the same higher - level center can exchange data. Considering that the higher - level center is actually equivalent to a certain lower - level center, then this lower - level center must have interaction relationships with all other lower - level centers to obtain the data status that the entire higher - level center should master.

[0052] (3) Management permissions of each center for business data

[0053] Each center can independently maintain the business data it holds and perform operations such as addition, modification, and deletion.

[0054] The business data that each center can master comes partly from new data added by this center and partly from data transmitted from other centers.

[0055] (4) Data interaction between centers follows the business flow relationship

[0056] If the interaction between each center occurs randomly without rules, then all peer - level centers belonging to the same superior center are fully connected (there is a two - way interaction link between every two nodes); if the interaction between each center follows certain rules, that is, the overall business process of the system, then the peer - level centers are not fully connected, and the transfer process can be more simplified.

[0057] The goal of data version control is to retain as many and as detailed data states and change records as possible, which means storing data information (data mirror images) under more data versions and explanatory information about data versions.

[0058] To achieve refined management of data versions and full traceability, the storage structure of business data is set as follows:

[0059] (1) Global unique identifier for business data

[0060] Since the creation of each piece of business data, it will be assigned an identification ID, which will remain unchanged during the content change of the business data and the information flow of the business data. Technically, GUID, Snowflake algorithm, etc. can be used to ensure the uniqueness of this ID in the system globally.

[0061] (2) Multi-level data version setting adapted to multi-center environment

[0062] In a multi-center environment, business data flows between multiple centers and change operations are carried out by each center. To facilitate recording data change situations, this solution adopts a multi-level data version mechanism of multi-level version number + modification times. When each center performs general data maintenance (insertion, deletion, modification) locally, it will not cause a change in the version number, and only the modification times field is used to record the state change of the data. Only when each center needs to submit data to other external centers, a formal version will be formed for other centers. That is to say, the version number only records the data state of data interaction.

[0063] Corresponding to the multi-level centers in the multi-center environment structure model, the version number is also set as a multi-level version number, and the number of version number levels is the same as the number of center levels. For example, corresponding to Figure 1 the two-layer structure, the version number format is two-level XXX.YYY, where XXX is the first-level version number which is a multi-digit number, YYY is the second-level version number which is also a multi-digit number, and ZZZ is the third-level version number which is also a multi-digit number.

[0064] When business data flows between first-level centers, the first-level version number will be changed (usually +1), and the second-level and lower version numbers will be cleared to 0. When data flows between second-level centers within a first-level center, the second-level version number will be changed, and the third-level and lower version numbers will be cleared to 0.

[0065] (3) Comprehensively record change information of business data

[0066] In addition to saving each state version of business data, it is also necessary to record relevant information about each change of business data, including the data ID of the change, the version number before the change, the changer, the unit to which the changer belongs, the change time, the reason for the change, etc.

[0067] Through the multi-level data version management design in the previous section, each center can save the received data versions, a large number of data versions formed by local operations, and the change information of each data version. This refined management method will bring a large amount of data, which accumulates continuously with the operation of the system, and the data scale gradually increases.

[0068] To facilitate the management of multi-version data and meet the performance optimization requirements for actual data access scenarios, a multi-level data table structure is designed as follows:

[0069] (1) Latest Information Management Table

[0070] In practical applications, the latest version of business data (in this center) is the data version with the highest access frequency, and data query, data update, and data insertion operations are often required for it.

[0071] Therefore, a latest information management table for business data is set up, which only stores the status of the latest local data. In addition to the fields of business data, this table should also add an identification field of data ID, version record fields such as version number and modification times, and fields for recording change information such as the creator / modifier / deleter and their affiliated units, and the creation / modification / deletion times.

[0072] Only the latest status of business data needs to be saved, and the primary key is set as the globally unique identifier ID of business data.

[0073] (2) Data Sending and Receiving Historical Version Data Table at the Level of This Center

[0074] When this center conducts data interaction with external centers at the same level, a data sending and receiving historical version table needs to be set up to store all interaction data for data comparison and status traceability.

[0075] According to the multi-level data version setting, when this center conducts data interaction with external centers at the same level, it will cause changes in the data version level corresponding to the level of this center. Therefore, the data sending and receiving historical version table needs to correspond to the level of this center. From the application perspective, considering that data with the same ID from different centers can be received, data from the same center can be received repeatedly, and data can be sent repeatedly to the same center, the source, destination, and previous status of interaction data need to be saved. Therefore, the historical version table (relative to the latest information management table) needs to add a "sending and receiving time" field to record and distinguish the status of previous interaction data, a "data source" field to record which center the data comes from, and a "data destination" field to record which center the data is sent to.

[0076] The primary key of this table is "Plan ID + Version number corresponding to this center level + Sending and receiving time + Data source + Data destination". For example, if this center is a level-2 center, a level-2 historical version data table for recording interaction data is required. The primary key is "Data ID + Level-2 version number + Sending and receiving time + Data source + Data destination", that is, "Data ID + XXX.YYY + Sending and receiving time + Data source + Data destination", which can record the data status of each data sending and receiving.

[0077] In special cases, when a higher-level center is equivalent to a lower-level center (for example, Level-1 center A is equivalent to Level-2 center A.1), and this center needs to interact with peer centers at multiple levels simultaneously, multiple data sending and receiving historical version data tables need to be maintained, corresponding to the multiple levels it belongs to respectively.

[0078] (3) An operation record table for recording each data change within this center

[0079] To comprehensively record all data change operations within this center, an operation record table can be set up. It has no primary key and can store business data with the same version and ID. The different states of data items with the same plan ID and version number are distinguished by the number of modifications.

[0080] This table retains the historical records in all the latest information management tables and the pre- and post-change states of each change, enabling comprehensive traceability of business data and review of the details of data changes and transfers.

[0081] Although the amount of data in this table is large, it only needs to support adding and appending data and low-frequency query operations, without modification and deletion operations. It can be designed into a data storage form conducive to querying and appending new data, such as distributed file storage, to ensure the efficiency of querying and adding.

[0082] (4) A same-version change information table for recording the overall change situation of data with the same version and ID within this center

[0083] When data is exchanged between centers, other centers do not care about the operation records within this center, but they do care about the overall change situation of the data within this center, that is, the change information before and after the data enters and leaves this center (under the same version number), including data ID, changer, version before data change, unit to which the changer belongs, change time, reason for change, comparison of data content before and after change, etc. This overall change situation can be obtained by merging and calculating a series of operation records recorded by this center, or by automatically recording pre- and post-changes + manual entry of information by users.

[0084] In a multi - center environment, based on the data version design of "multi - level version number + modification times" and the multi - layer data table structure design, the control mechanism for data flow and change is specified to ensure that all data flow and change situations are accurately and comprehensively recorded. At the same time, each center can master all data versions within its authority and ensure their consistency throughout the system.

[0085] Taking a single center as an example, the data flow and change operations it needs to manage include: receiving business data transferred from other centers, making changes to the business data locally, and sending business data to other centers. The data version control mechanisms for each type of operation are described as follows:

[0086] (1) Receiving business data transferred from other centers

[0087] The received business data is stored in the historical version table at the corresponding center level as it is, along with the receiving and sending time and the data source (sending center) to record the received data status. The primary key of the historical version table is "data ID + version number (up to the center level) + receiving and sending time". Therefore, when receiving the same version of business data with the same ID repeatedly, a new data record will be saved due to different receiving and sending times.

[0088] Increment the version number at the corresponding center level of the received data record by 1, clear the modification times, and then store it in the latest information management table. The primary key of the latest information management table is "data ID". Therefore, if there is a situation where the data IDs are the same, the newly received data in the latest information management table will overwrite the original data record, and the original data record and the new data record will be stored in the operation record table.

[0089] In addition to receiving business data, it is also possible to receive change information of business data as needed. For this center, it only cares about the total change situation of the business data in each center it has passed through before, that is, the overall change information of the data by each center that the business data has passed through since its creation. The information content can be found in the "Same - version change information table for recording the overall change situation of the same version and the same ID data within this center" in the "Multi - layer data table structure design".

[0090] (2) Making changes to business data locally

[0091] After receiving business data transferred from other centers, the latest information management table contains the local latest data after receiving and modifying the version status. This center can perform create / change operations such as addition, deletion, and modification on the business data in the latest information management table. Specifically:

[0092] New data: The new data is saved to the latest information management table, and the version number starts from the initial state. The data status before and after the operation is recorded in the operation record table. The data status before the operation is empty, and the data status after the operation is the content of the new data.

[0093] Modified data: The modified data is saved to the latest information management table to overwrite the original data (with the same ID), the version number remains unchanged, and the modification times +1; at the same time, the data before and after the modification is transferred to the operation record table.

[0094] Deleted data: To ensure the full tracking and traceability of data in a multi-center environment, data cannot be physically deleted, but should be logically deleted with a deletion flag. That is, the deletion flag of the data record to be deleted is set to 1 to indicate that the data record is logically deleted, otherwise the data record is not logically deleted. In this way, the deletion operation is essentially similar to the modification operation. After deletion, in addition to setting the deletion flag of the data record to 1, the data record is also saved to the latest information management table to overwrite the original data (with the same ID), the version number remains unchanged, and the modification times +1; at the same time, the data before and after the deletion is transferred to the operation record table.

[0095] (3) Send business data to other centers

[0096] Select some or all of the data from the latest information management table according to certain conditions and send it to other centers. At the same time, the change information corresponding to the sent business data (the change information of the data by each center after creation) should also be sent to other centers.

[0097] The sent data is stored in the historical version management table as it is, plus the sending and receiving time and the data destination (receiving center) to save the status of the sent data.

[0098] The following takes the review process of a certain plan management system as an example to illustrate the application method and role of the method of the present invention, as Figure 2 shown.

[0099] 1. Construction of multi-center environment structure

[0100] The plan management system covers three-level units. Each level of unit has a comprehensive department and multiple business departments. The plans prepared by the lower-level units are reported to the higher-level units after being reviewed. The comprehensive department in each unit receives the plan data reported by the lower-level units, and then splits it to multiple business departments for review. After the business departments complete the review, they report the data back to the comprehensive department. The comprehensive department summarizes the plan data reviewed by each business department and reports it to the higher-level unit after review. Due to the physical or permission isolation between levels of units, each unit / department needs to deploy a data center separately to manage the data under its jurisdiction.

[0101] From Figure 2It can be seen that each large unit can be regarded as a level-1 center, including Center A1, B1, B2, C1, C2, C3, etc. Each level-1 center can be divided into multiple department-level centers corresponding to departments within the unit (data centers are deployed separately for units / departments to manage the data under their jurisdiction). For example, within level-1 center A1, there are level-2 centers A1.0, A1.1, …… A1.N. Among them, A1.0 is the comprehensive department. Since the receiving and sending of the level-1 center are all completed through the comprehensive department in the level-2 center, the level-1 center and the comprehensive department-level center under it can be regarded as equivalent, that is, level-1 center X and level-2 center X.0 are equivalent.

[0102] After adopting the multi-center environment modeling and analyzing the business processes of the entire editing and review process, it can be seen that each level-1 center will perform the following working steps:

[0103] (1) The comprehensive department (level-2 center, equivalent to this level-1 center) receives the data reported by the subordinate unit (a certain level-1 center).

[0104] (2) The comprehensive department (level-2 center, equivalent to this level-1 center) splits the data and sends it to the business departments (other level-2 centers) within this level-1 center.

[0105] (3) The business department (level-2 center) receives the data split by the comprehensive department (level-2 center, equivalent to this level-1 center).

[0106] (4) The business department (level-2 center) reviews the data and can also create new data.

[0107] (5) The business department (level-2 center) reports the (edited and reviewed) data to the comprehensive department (level-2 center, equivalent to this level-1 center).

[0108] (6) The comprehensive department (level-2 center, equivalent to this level-1 center) receives the data reported by the business department (level-2 center).

[0109] (7) The comprehensive department (level-2 center, equivalent to this level-1 center) reviews the data and can also create new data.

[0110] (8) The comprehensive department (level-2 center, equivalent to this level-1 center) reports the (edited and reviewed) data to the superior unit (a certain level-1 center).

[0111] 2. Design of Data Status Control Fields

[0112] In order to achieve refined management and full-process traceability of planned project data throughout the editing and review process, the following data status control fields are designed for planned project data:

[0113] (1) Global Unique Identifier of Planned Project Data

[0114] Since the creation of each planned project data, it will be assigned an identification ID, which will remain unchanged during the process of content change of the planned project data and the transfer of business data information. A 32-bit random GUID can be used as the identification ID of the planned project data, which will not be repeated throughout the system.

[0115] (2) Multi-level data version setting

[0116] The multi-center environment is divided into level 1 centers and level 2 centers, adopting a multi-level data version mechanism of two-level version numbers + modification times.

[0117] The version number is designed as a three-digit number, where the first digit represents the level 1 version number, and the second and third digits represent the level 2 version number.

[0118] When the planned project data is transferred between level 1 centers, the level 1 version number is incremented by 1, and the level 2 version number is cleared to 0. Since the number of transfers between level 1 centers is relatively small, one digit can support 9 transfers, which can meet the requirements of the business process.

[0119] When the planned project data is transferred between level 2 centers (which must belong to the same level 1 center), the level 2 version number is incremented by 1, and the level 1 version number remains unchanged. Two digits can support 99 transfers, which can meet the requirements of the business process.

[0120] When each center performs general data maintenance (addition, deletion, modification) locally, it will not cause changes to the version number, and only the modification times field is used to record the status changes of the data.

[0121] (3) Comprehensively record the change information of the planned project data

[0122] In addition to saving each status version of the planned project data, it is also necessary to record the relevant information of each change of the planned project data, including the changer, the unit to which the changer belongs, the change time, the reason for the change, etc.

[0123] Add fields such as the creator / modifier / deleter and the affiliated unit, and the creation / modification / deletion time to the planned project data record to record the change information;

[0124] Use a special audit opinion form to record the relevant information of the planned project data audit, including the auditor, the audit department, the planned project version corresponding to the audit, the audit opinion, the change situation of the data after the audit compared with the initial state (creation or reception) of the data in this center, etc.

[0125] 3. Multi-layer data table structure design

[0126] According to the foregoing analysis, a multi-layer data table structure is constructed at each center around the multi-version management of the planned project data:

[0127] (1) Latest Information Management Table (ZXXXGL):

[0128] This table only stores the latest status of the planned project data maintained by this center. The primary key is the project ID. The planned project data in the latest status is accessed most frequently, so it is formed into a separate table to control the data scale, thus ensuring the performance of data access and query.

[0129] (2) Data Sending and Receiving Historical Version Management Table (LSBBGL):

[0130] This table stores the planned project data from other centers or the planned project data sent from this center to other centers for data comparison and traceability. The primary key is "planned project ID + version number adapted to the center level + data sending and receiving time". If this center is a level-1 center, the version number adapted to the center level is the level-1 version number, that is, the first digit of the 3-digit number in the version number field; if this center is a level-2 center, the version number adapted to the center level is the level-1 version number + level-2 version number, that is, all 3 digits in the version number field.

[0131] (3) Operation Record Table (CZJL):

[0132] Comprehensively record all data change operations within this center to ensure that all operations on the planned project data are recorded. This table does not set a primary key and can store business data with the same version and ID, and distinguishes different states of data with the same ID and version number by the number of modifications.

[0133] (4) Audit Opinion Table (SHYJ):

[0134] Record the overall change situation of the planned project by this center, that is, the change information of the data before and after entering (or being created by) this center and leaving this center (under the same version number). It includes the audit planned project ID, planned project version number (before audit), auditor, unit to which the changer belongs, audit time, audit opinion, comparison of content before and after audit, etc. Among them, the content before audit is fixed as the received status of the planned project data (the planned project is received from other centers) or the created status (the planned project is created by this center).

[0135] 4. Control of Data Flow and Change Process

[0136] Design the corresponding data flow and change process control as follows:

[0137] (1) The comprehensive department (level-2 center, equivalent to this level-1 center) receives the data reported by the subordinate unit (a certain level-1 center).

[0138] Deposit the received planned project data as it is, plus the sending and receiving time and data source (sending center), into the data sending and receiving historical version table of the corresponding level-1 center.

[0139] Increment the first digit of the 1-level version number of the received data record (the first digit of the three-digit version number) by 1, clear the modification count, and then store it in the latest information management table. If there are cases where the data IDs are the same, the newly received data will overwrite the original data record, and the original data record and the new data record will be stored in the operation record table.

[0140] In addition to the planned project data, receive the review opinion information corresponding to the received planned project and store it in the review opinion table.

[0141] (2) The comprehensive department (2nd-level center, equivalent to this 1st-level center) splits the data and sends it to the business departments (other 2nd-level centers) within this 1st-level center.

[0142] Select some or all of the planned project data from the latest information management table according to certain conditions and send it to other 2nd-level centers. At the same time, the review opinion information corresponding to the sent planned project data (from the review opinion table) should also be sent to other 2nd-level centers.

[0143] Store the sent data as it is, along with the sending and receiving time and the data destination (receiving center), in the data sending and receiving history version management table of the corresponding 2nd-level center to save the status of the sent data.

[0144] (3) The business department (2nd-level center) receives the data split by the comprehensive department (2nd-level center, equivalent to this 1st-level center).

[0145] The data status control logic is relatively close to that in (1).

[0146] The difference is that the local center is a 2nd-level center. Therefore, the local data sending and receiving history version table corresponds to the 2nd-level center, and the primary key is different; when the received planned project is transferred and stored in the latest information management table, increment the 2-level version number of the received data record (the second and third digits of the three-digit version number) by 1.

[0147] (4) The business department (2nd-level center) reviews the data and can also create new data.

[0148] The newly added data is saved to the latest information management table, and the version number starts from the initial state. Record the data status before and after the operation in the operation record table. The newly added data is also stored in the data sending and receiving history version table, and the "data source" field is filled with the identifier of this 2nd-level center.

[0149] Review the planned project data in the latest information management table. After the review (modification or deletion), the data is saved to the latest information management table to overwrite the original data (with the same ID), the version number remains unchanged, and the modification count is incremented by 1; at the same time, transfer the data before and after the review (modification or deletion) to the operation record table.

[0150] Automatically record the review opinion form during review, and store fields such as the review plan project ID, the version number of the planned project (before review), the reviewer, the unit to which the changer belongs, the review time, the review opinion, and the comparison of the content before and after review. The status of the planned project before review is the most recent received status of the planned project in the historical version table.

[0151] (5) The business department (level 2 center) reports (after compilation and review) data to the comprehensive department (level 2 center, equivalent to this level 1 center).

[0152] The data status control logic is similar to that in (2) and will not be elaborated further.

[0153] (6) The comprehensive department (level 2 center, equivalent to this level 1 center) receives the data reported by the business department (level 2 center).

[0154] The data status control logic is similar to that in (3) and will not be elaborated further.

[0155] (7) The comprehensive department (level 2 center, equivalent to this level 1 center) reviews the data and can also create new data.

[0156] The data status control logic is similar to that in (4) and will not be elaborated further.

[0157] (8) The comprehensive department (level 2 center, equivalent to this level 1 center) reports (after compilation and review) data to the superior unit (a certain level 1 center)

[0158] The data status control logic is relatively close to that in (2).

[0159] The difference is that the local center is a level 1 center. Therefore, the local data receiving and sending historical version table corresponds to the level 1 center, and the primary keys are different.

[0160] 5. Discovery and Resolution of Data Conflicts

[0161] Because C2 reports data to B1 and B2 simultaneously, and then B1 and B2 report the data to A1. Among the data received by A1, there is planned project data created by C1 but reviewed (changed) separately by B1 and B2. At this time, the reviews (changes) of the data created by C1 by B1 and B2 may be different. A1 needs to identify this difference and process it to resolve the data conflict.

[0162] As can be seen from "(1) The comprehensive department (level 2 center, equivalent to this level 1 center) receives the data reported by the subordinate unit (a certain level 1 center)" in "7.4 Data Flow Process Design": When A1 receives data from B1 and B2, it will save the data reception status in the data receiving and sending historical version table. When it is found that there are data records with the same data ID from different centers, it means that the same data record has been reviewed by different centers. This kind of logic can be used to discover data conflicts.

[0163] After detecting a data conflict, the review opinion information corresponding to the two data reception statuses that caused the conflict can be found, and the differences in the review opinions of B1 and B2 on the same project plan can be observed for reference by A1 in the next review. After A1 completes the review of the project plan, the latest version status of the project plan is unique. Since in the business process, the final approval right of the project plan must belong to only one center, after the business process is finally completed, the final version status of the project plan must be unique, and the different statuses with the same version number during the review process can be distinguished by combining the data source center or the data holding center.

[0164] Although the embodiments of the present invention have been shown and described, those of ordinary skill in the art can understand that various changes, modifications, substitutions, and variations can be made to these embodiments without departing from the principles and spirit of the present invention. The scope of the present invention is defined by the appended claims and their equivalents.

Claims

1. A method for controlling data state consistency in a multi-level central environment, characterized in that It includes the following steps: Build the distributed information management system into a multi-level data management center; Set a unique management identifier ID for the data of the management center. The ID includes a version number and a modification count. The version number corresponds to the multi-level management center, and the number of version levels corresponds to the number of levels of the management center; The multi-level data management center receives, changes, and sends data through the management identifier ID. There are restrictions on network or permission division between the multi-level data management centers, and direct data sharing and overall replication cannot be performed. Only necessary business data interactions are carried out to achieve collaborative management and maintenance of data; In the multi-level data management center, the high-level data management center is composed of at least one low-level data management center combined; The same-level data management centers belonging to the same high-level data management center can perform data interaction, and the same-level data management centers belonging to different high-level data management centers cannot perform direct data interaction.

2. The method for controlling data state consistency in a multi-level center environment according to claim 1, wherein: When data is changed within the data management center, the version number remains unchanged, and the modification count is changed; When sending data to other data management centers, change the data version number to the version number of the higher-level data management center.

3. The method for controlling data state consistency in a multi-level center environment according to claim 2, wherein: When data is changed or transferred, it is also necessary to record the data ID, the version number before the change, the person who changed the data, the unit to which the person who changed the data belongs, the change time, and the reason for the change.

4. The method for controlling data state consistency in a multi-level center environment according to claim 3, wherein: The method further includes setting multi-level data tables, and the multi-level data tables include the latest information management table, the data receiving and sending historical version data table, the operation record table, and the same-version change information table. Specifically: The latest information management table stores the status of the local latest data. Its primary key is the data management identifier ID, and it also specifically stores the data version number and the modification count, the information of the person who changed the data, and the change data time; The data receiving and sending historical version data table stores the data status when the data management center interacts with the same-level data management centers outside. It corresponds to the level of the data management center, and specifically stores the data management ID, the version number corresponding to the level of this center, the receiving and sending time, the data source, and the data destination; The operation record table is used to record all data change operations within the data management center, and retains the historical records in the latest information management table and the front and back states of each change; The same-version change information table records the overall change situation of the data with the same version and the same ID within the data management center.

5. The method for controlling data state consistency in a multi-level center environment according to claim 4, wherein: When the data management center receives data sent by other centers, add the receiving and sending time and the data source to the data and store it in the data receiving and sending historical version data table corresponding to the level of this center; Increment the version number corresponding to the received data record at the level of this data management center by 1, clear the modification count, and then store it in the latest information management table.

6. The method for controlling data status consistency in a multi-level center environment according to claim 5, wherein: When the local data of the data management center changes, the changed data is saved to the latest information management table. If there is data with the same management ID, the original data is overwritten. The version number of the newly added data starts from the initial state, and the version numbers of the deleted and modified data remain unchanged, while the modification count is incremented by 1. At the same time, the data status before and after the change is stored in the operation record table.

7. The method for controlling data status consistency in a multi-level center environment according to claim 6, wherein: When the data management center sends data to other data management centers, part or all of the data is selected from the latest information management table according to the sending requirements and sent to other data management centers. At the same time, the change information corresponding to the sent data recorded in the same version change information table can also be sent to other data management centers.

Images