CN113722343A - 一种多级中心环境下数据状态一致性管控方法 - Google Patents

Abstract

本发明提出了一种多级中心环境下数据状态一致性管控方法，将分布式信息管理系统构建成多级数据管理中心；对所述管理中心数据设置唯一管理标识ID，所述ID包括版本号和修改次数，所述版本号与多级管理中心对应，版本级数对应所述管理中心级数；所述多级数据管理中心通过所述管理表示ID进行数据接收、变更和发送。该方法通用性强，可复用到多中心环境下各中心的数据状态存管应用中，灵活适配各级中心的对数据收发、本地数据处理的状态管控需求。不仅可适用于因网络隔离导致的分布式数据管理环境，同样也可适用于集中数据存储但强调分权限管理的环境。

Description

一种多级中心环境下数据状态一致性管控方法

技术领域

本发明涉及一种数据版本状态一致性管控方法，特别涉及一种多级中心环境下数据状态一致性管控方法。

背景技术

业务流程是由工作分工而产生概念，是指由不同的人为共同目标有序完成的一系列活动，活动之间存在先后顺序或者条件限定，且活动内容、方式、责任等也有明确的界定，以便活动可在不同人之间进行转手交接。在信息管理领域，可以狭义的理解为与客户价值满足相联系的一系列过程节点及执行方式有序组成的工作过程。

在信息管理领域，业务流程管理经常使用工作流(workflow)引擎技术进行支撑。工作流是对业务流程的抽象，而工作流引擎是实现驱动工作流的一套实现工具，它可以方便的定义业务流程中的角色、分工，并根据条件的不同决定信息传递路由，内容等级等。一般工作流引擎需要定义work(单个活动)、task(交互任务)、user(参与者)等表单，并通过设定的流程驱动数据流转、回退、重试等操作。

工作流引擎可以通过抽象和格式化流程，实现业务可视化编排，易维护易拓展，但引入工作流本身会增加工程难度，而且各节点必须能够同时访问到工作流引擎定义的表单才能正确驱动业务流程，当业务管理系统相互隔离、无法直接互访数据时，采用工作流引擎来支持如多级编审这样的长链条业务流程管理会十分困难。

在数据管理过程中，经常希望把操作之前的数据保留下来，能够看到操作前后的数据变化，一般采用保留历史数据并使用数据版本管理来实现。最常见的版本管理方案就是在保留历史数据的表上增加一个版本号字段，可以是时间、也可以是数字，版本号只增不减，最大的版本号就对应最新的业务数据。

当业务管理过程中使用同一个数据库(含分布式数据库)时，可以很方便的进行全局的数据版本管控，每个用户在处理数据时都可以通过数据库获得最新业务数据及其历史版本，当用户改动数据时，不会修改原有版本的数据，而是新增数据并赋予新的版本号，新增数据和历史数据通过数据记录的唯一标识来表明他们是同一条数据记录的不同状态。

但当业务管理过程中，受网络条件限制、或者安全保密限制，业务数据有可能存储在不同的数据库(不直接联通)由不同单位/用户分别维护，通过数据投递/数据摆渡等方式进行数据交互时，对数据版本的一致性维护就变得困难，且其复杂性将会随业务关系的复杂化和管理要求的精细化不断提升。

为体现管理的权威性、严肃性、综合性，在业务数据多级编报审核管理流程中，具有数据统一规范、操作全程留痕的内在技术要求。但在一些特定场景下，比如网络条件不具备时，参与编审流程的各用户、各节点实际形成多中心并存、数据异步维护的局面，给多层级多节点间数据一致性保持带来了极大不便。

在多中心并存条件下的业务数据管理过程中，业务数据按一定流程在各中心数据库之间流转，并不断被修改、审核调整和删除，一方面希望能在软件系统中尽量留存和交互更多更细的数据变更记录，这就意味着存储更多业务数据版本导致数据管理规模增大，另一方面又希望在大量记录历史业务数据版本状态的情况下保证对业务数据表的访问性能和节点间数据交互的性能，而这些性能都是随着数据规模增大而下降的。在无联网多中心分布条件下，单中心性能受限和多中心之间数据投递性能受限。

发明内容

如何提供一种通用化、可扩展、轻量级的数据状态管控方法，以满足多中心条件下数据协同管理过程中数据状态一致和可追溯要求，并平衡管理精细程度和数据处理性能，是本发明要解决的核心技术问题。本发明提供了一种多级中心环境下数据状态一致性管控方法，其包括以下步骤：

将分布式信息管理系统构建成多级数据管理中心；

对所述管理中心数据设置唯一管理标识ID，所述ID包括版本号和修改次数，所述版本号与多级管理中心对应，版本级数对应所述管理中心级数；

所述多级数据管理中心通过所述管理表示ID进行数据接收、变更和发送。

进一步，所述级数据管理中心中，高级别数据管理中心可以由至少1个低一级别数据管理中心组合构成；

属于相同高级数据管理中心的同级别数据管理中心能进行数据交互，属于不同高级别数据管理中心的同级别数据管理中心不能进行直接数据交互。

进一步，在所述数据管理中心内部进行数据变更时，所述版本号不变，变更所述修改次数；

向其他数据管理中心发送数据时，将所述数据版本号变更为较高级别数据管理中心版本号。

进一步，数据变更或流转时，还需记录数据ID、变更前版本号、变更人、变更人所属单位、变更时间、变更原因。

进一步，所述方法还包括设置多层级数据表，所述多层级数据表包括最新信息管理表、数据收发历史版本表、操作记录表、同版本变更信息表，具体为：

所述最新信息管理表存储本地最新数据的状态，其主键为所述数据管理标识ID，还具体存储所述数据版本号和修改次数、变更数据人员信息、变更数据时间；

所述数据收发历史版本数据表，存储本数据管理中心与外界同级别数据管理中心进行数据交互时的数据状态，该表与本数据管理中心级别相对应，具体存储所述数据管理ID、对应本中心级别的版本号、收发时间、数据来源、数据目的。

所述操作记录表用于记录本数据管理中心内部的所有数据变更操作，该表保留所述最新信息管理表中的历史记录以及每次变化的前后状态。

所述同版本变更信息表记录本数据管理中心内部对同一版本同一ID的数据总体变更情况。

进一步，所述数据管理中心接收其他中心发送数据时，将所述数据加上收发时间、数据来源存入对应本中心级别的历史版本表；

将接收的数据记录的对应本数据管理中心级别的版本号+1，修改次数清零，然后存入所述最新信息管理表。

进一步，所述数据管理中心本地数据变更时，变更后数据保存到所述最新信息管理表，有同管理ID的数据则覆盖原数据，新增数据版本号从初始状态开始记起，删、改数据版本号不变，修改次数+1，同时将变更前后数据状态存入所述操作记录表。

进一步，所述数据管理中心发送数据给其他数据管理中心，从所述最新信息管理表中按发送要求选取部分或者全部数据，发送给其他数据管理中心，同时还可将所述同版本变更信息表记录的所述发送数据对应的变更信息发送给其他数据管理中心。

通过本发明提供的方法，多用户进行协同业务数据管理场景下，对数据状态进行一致性管控的方法，以实现对全系统中数据状态的精细化管理，并可限制多中心间业务数据交互量、保证对业务数据的访问性能，使各中心节点都能最终获得按权限可以掌握的数据状态副本，并保证多数据副本的最终数据一致性。

附图说明

图1多中心环境结构模型

图2多中心环境结构图

具体实施方式

下面将结合附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

一般情况下，多用户参与的数据管理信息系统将数据存储在集中的数据中心，有利于对数据状态的一致性管控。但当网络条件不具备，或者系统有特殊的分级分权限管理要求时，可以设置多个数据中心，各自维护本地的业务数据，各中心之间收网络或者权限划分的限制不能进行直接的数据共享和整体复制，仅进行必要的业务数据交互以实现对数据的协同管理维护。

同一条数据记录，在业务管理过程中将被不同的用户创建、修改、删除，即该数据记录的状态是不断变化的。在信息管理系统中，常用版本号来标记数据的状态，不同版本号的同一条数据记录是该数据记录的不同状态。因此数据版本是说明数据状态的重要标志。此外，数据创建/修改/删除的时间信息、数据创建/修改/删除的操作者信息，以及对数据变更原因的说明信息(如审核意见等)，都是用于对数据状态进行解释说明的信息，这些信息和版本号一起可以比较全面的说明数据状态以及状态变化原因。

在本专利申请中，面对较为复杂的多中心环境，可采用多级数据版本管理机制，版本号可以采用011.045.234的多级形态，第一个数字段表示一个大单位对数据的修改次数(1级版本号)，第二个三位数字段表示大单位内部某个部门在1级版本数据状态下对数据的修改次数(2级版本号)，以下依次类推。这样可以精细的记录在一个大系统内数据状态的变化情况。

一般在单一数据库内，数据一致性(Consistency)是指在事务开始之前和结束之后，数据完整性不被破坏。

在分布式系统中数据一致性，是指对每个客户端而言，每一次的读操作，返回的一定是最新的写操作的结果。在分布式系统中往往存在数据的多个副本，此时数据一致性主要关注各副本在一定时间窗口内实现对某次数据状态更新操作的同步，时间窗口的长短将标志系统可达到数据一致性的强弱。

在本专利申请中，多中心环境下，存在类似分布式系统的多个数据副本存储在不同中心节点上，各节点上数据副本并非通过底层分布式数据库内部同步机制进行统一管控，而是通过业务数据传递产生的多个数据副本，因此对数据一致性的管控需要更加细致的设计才能达成。

这是常见于各类信息管理系统中的一组相对的概念。业务数据是在系统工作过程中，随着业务工作的开展，不断添加的和业务工作相关的数据；而基础数据是系统的数据字典，在系统初始化的时候，就存在于系统数据库中，为业务数据内容的一致性和标准化提供统一结构性支持，是业务顺利开展和系统高效运行的基础。

在本申请中，提到的数据状态主要指业务数据的状态，基础数据其实也存在版本变更(状态变化)但变化频度较低且一般会统一维护和发布，故不专门考虑基础数据的状态一致性问题。

当业务数据存在多个版本时，要准确找到某个数据记录的某个版本是，要通过数据记录的标识码和数据记录的版本号两个条件进行精确检索。如果把多版本的业务数据都存储在一个数据表中，则这个数据表的规模会随着数据版本的变化而增大，对该表的检索性能将受限于快速增长的规模。

实际用户使用业务数据时，最常用的是最新状态(最新版本)，因此，为提高常用功能(对最新版本业务数据进行修改、删除)的性能，可以将业务数据表分成多个层级，一个表专门用于存储最新状态的业务数据，另一个表用于存储各个历史版本的业务数据。如果版本号也分成多个级别控制，如1级版本+2级版本，那么存储历史版本的数据表还可以进一步拆分成多层级数据表，第1级历史版本表存储各个1级版本下的最新数据状态、第2级历史版本表存储各个2级版本下的最新数据状态……

本发明采用的技术方案是对业务数据进行多级版本控制和配套的多级数据表管理，构建一套通用化、可扩展、轻量级的数据状态管控方法，以适应多中心环境下的数据状态一致性管控特点，在控制多中心之间的数据交互量的前提下保证数据完整性，并平衡数据访问性能和版本记录精细程度。

当网络条件不具备，或者信息管理系统有特殊的分级分权限管理要求时，可以设置多个数据中心，各自维护本地的业务数据，各中心之间收网络或者权限划分的限制不能进行直接的数据共享和整体复制，仅进行必要的业务数据交互以实现对数据的协同管理维护。多中心环境的结构模型如图1所示。

图1中给出了多个数据中心，A、B、C、D，他们之间存在数据交互关系，以带箭头的线表示。各中心内部可以进一步划分成更小的中心，各中心之间也存在数据流转关系，以带箭头的虚线表示。以此类推，各个小中心内部也可进一步划分成更小的中心。对中心与数据的关系，以及中心之间的关系，进行如下抽象和规约：

(1)多中心分级结构

多中心可以按管理级别，分为1级中心、2级中心、3级中心……，其中高级别中心可以由多个下一级别中心组合构成。

考虑到网络隔离或者分级分权限管理要求，各同级中心之间不能直接访问对方的数据库，只能通过预先设定的数据交互接口获取对方的部分数据。

(2)中心之间的交互限定

跨1级中心的2级中心之间原则上不应存在直接交互关系，而必须通过各自上级的1级中心进行交互。如2级中心A.2不能和2级中心C.3直接交互，而必须通过上级中心A和C进行间接交互。

高级别中心和内部的下一级中心必然存在交互关系，为简化模型，可认为高级别中心与其内部的某个下一级别中心等价。例如1级中心A等价于2级中心A.1，作为1级中心A它与其他1级中心B、C、D存在交互关系，作为2级中心A.1它与其他2级中心A.2和A.3存在交互关系。

在同一个高级别中心内部的低级别中心，可以交互数据，考虑到高级别中心实际等价于某个低级别中心，则该低级别中心必然和其他低级别中心都存在交互关系以获得整个高级别中心所应掌握的数据状态。

(3)各中心对业务数据的管理权限

各中心可以独立维护所掌握的业务数据，进行新增、修改、删除操作。

各中心能够掌握的业务数据，一部分来自本中心新增，一部分来自接收其他中心传递过来的数据。

(4)中心间数据交互遵从业务流关系

各中心之间的交互如果是随机发生没有规律，则所有同属上一级中心的同级中心之间全连通(两两节点之间均存在双向交互链路)；如果各中心之间的交互遵循一定规则，即系统整体的业务流程，则同级中心之间非全连通，流转过程可以更简化。

数据版本管控的目标是尽量留存更多更细的数据状态和变更记录，这就意味着存储更多数据版本下的数据信息(数据镜像)以及对数据版本的说明信息。

为了实现对数据版本的精细化管理和全程留痕，对业务数据的存储结构进行如下设定：

(1)业务数据的全局唯一标识

每一条业务数据自创建起，将被赋予一个标识ID，在该业务数据内容变更、业务数据信息流转过程中ID永远保持不变。在技术上可以使用GUID、雪花算法等保证该ID在系统全局中的唯一性。

(2)适应多中心环境的多级数据版本设置

多中心环境下，业务数据在多中心之间流转，由各中心进行变更操作，为便于记录数据变更情况，本方案采用多级版本号+修改次数的多级数据版本机制，其中各个中心在本地进行一般性数据维护(增删改)时，不会导致版本号的变化，只利用修改次数字段记录数据的状态变化，只有当各中心需要向外部其他中心提报数据时，才会形成正式版本给其他中心，也就是说版本号只记录数据交互的数据状态。

与多中心环境结构模型中的多级中心相对应，版本号也设置为多级版本号，版本号级数和中心级数一致。例如对应图1中的两层结构，版本号格式为两级XXX.YYY，其中XXX为1级版本号是多位数的数字，YYY为二级版本号也是多位数字，ZZZ是3级版本号也是多位数数字。

当1级中心之间进行业务数据流转时，将改动1级版本号(一般为+1)，并将2级及以下版本号清0，在1级中心内部各2级中心之间进行数据流转时，将改动2级版本号，并将3级及以下版本号清零。

(3)全面记录业务数据的变更信息

除了保存业务数据的各个状态版本，还需记录业务数据每次变更的相关信息，包括变更的数据ID、变更前版本号、变更人、变更人所属单位、变更时间、变更原因等。

通过上一节的多级数据版本管理设计，每个中心可保存接收的数据版本、本地操作形成的大量数据版本，以及各个数据版本的变更信息。这种精细化管理方式将带来较大的数据量，且随系统运行不断积累，数据规模逐渐增大。

为了便于管理多版本数据，并针对实际数据访问场景的性能优化需要，设计多层级数据表结构如下：

(1)最新信息管理表

实际应用中，业务数据的(本中心)最新版本是被访问频度最高的数据版本，经常需要对其进行数据查询、数据更新、数据插入操作。

因此设置业务数据最新信息管理表，它只存本地最新数据的状态。除了业务数据的字段外，该表中还应增加数据ID这一标识字段，版本号和修改次数这样的版本记录字段，以及创建/修改/删除人及所属单位、创建/修改/删除时间等用于记录变更信息的字段。

只需要保存业务数据的最新状态，主键设置为业务数据的全局唯一标识ID。

(2)对应本中心级别的数据收发历史版本数据表

当本中心与外界同级别中心进行数据交互时，需设置数据收发历史版本表，存储所有交互数据以便于数据比对和状态追溯，

根据多级数据版本设置，当本中心与外界同级别中心进行数据交互时，会导致与本中心级别对应的数据版本级别的变更。因此数据收发历史版本表需要与本中心级别相对应。从应用角度，考虑到可接收来自不同中心的相同ID的数据，可重复接收来自同一中心的数据，以及可重复发送数据到同一中心，因此需保存交互数据的来源、目的和历次状态，因此历史版本表(相对最新信息管理表)需增加“收发时间”字段用于记录和区分历次交互数据的状态，需增加“数据来源”字段以记录数据来自于哪个中心，需增加“数据目的”字段以记录数据发往哪个中心。

该表的主键是“计划ID+对应本中心级别的版本号+收发时间+数据来源+数据目的”。例如本中心是2级中心，那就需要一个用于记录交互数据的2级历史版本数据表，主键是“数据ID+2级版本号+收发时间+数据来源+数据目的”，即“数据ID+XXX.YYY+收发时间+数据来源+数据目的”，可记录每一次数据收发的数据状态。

特殊情况下，高级别中心等价于下级中心时(例如1级中心A等价于2级中心A.1)，该中心同时需要与多个级别的同级中心进行交互，则需要维护多个数据收发历史版本数据表，分别对应其所在的多个级别。

(3)记录本中心内部每次数据变更的操作记录表

为全面记录本中心内部的所有数据变更操作，可设置操作记录表，无主键，可存储同版本同ID的业务数据，通过修改次数来区分同计划ID同版本号计划项目数据的不同状态。

该表保留所有的最新信息管理表中的历史记录以及每次变化的前后状态，可全面追溯业务数据、复盘数据变更和流转的细节。

该表数据量较大，但只需支持新增追加数据和低频地查询操作，不会有修改和删除操作，可设计成利于查询和追加新增的数据存储形式，如分布式文件存储，以保证查询和新增的效率。

(4)记录本中心内部对同一版本同一ID的数据总体变更情况的同版本变更信息表

当中心之间交互数据时，其他中心不会关心本中心内部的操作记录，但会关心数据在本中心总体的变更情况，即数据在进入本中心到离开本中心(在同一个版本号下)前后的变更信息，包括数据ID、变更人、数据变更前版本、变更人所属单位、变更时间、变更原因、变更前后数据内容对比等，这个总体变更情况可以由本中心记录的一系列操作记录合并计算而得到，也可以由自动记录前后变化+用户人工录入信息而成。

在多中心环境下，基于“多级版本号+修改次数”的数据版本设计和多层数据表结构设计，对数据流转和变更的控制机制进行规约，以保证所有数据流转和变更情况均被准确、全面的记录，同时使得每个中心均可掌握权限范围内的所有数据版本并保证其在全系统中的一致性。

以单个中心为例，其需要管理的数据流转和变更操作包括：接收其他中心传递来的业务数据、在本地对业务数据进行变更、发送业务数据给其他中心三类，分别说明各类操作的数据版本控制机制如下：

(1)接收其他中心传递来的业务数据

将接收的业务数据原样加上收发时间、数据来源(发送中心)存入对应本中心级别的历史版本表，用于记录接收数据状态。历史版本表的主键是“数据ID+版本号(截止到本中心级别)+收发时间”，因此，当重复接收同一版本同ID的业务数据时，因为收发时间不同，将保存一条新的数据记录。

将接收的数据记录的对应本中心级别的版本号+1，修改次数清零，然后存入最新信息管理表。最新信息管理表的主键是“数据ID”，因此，如果有数据ID相同的情况，最新信息管理表中新接收数据将覆盖原数据记录，原数据记录和新数据记录将存入操作记录表。

除了接收业务数据，还可根据需要接收业务数据的变更信息，对本中心而言，仅关心业务数据在之前流转过的各个中心里的总变化情况，即业务数据从创建之后流转过的各个中心对数据的总体变更信息，信息内容见“多层数据表结构设计”中的“(4)记录本中心内部对同一版本同一ID的数据总体变更情况的同版本变更信息表”

(2)在本地对业务数据进行变更

接收其他中心传递来的业务数据后，最新信息管理表里就是接收并修改版本状态后的本地最新数据。本中心可以对最新信息管理表中的业务数据进行增、删、改等创建/变更操作。具体为：

新增数据：新增数据保存到最新信息管理表，版本号从初始状态开始记起。并将操作前后数据状态记录到操作记录表中，操作之前数据状态为空，操作之后数据状态为新增数据内容。

修改数据：修改后数据保存到最新信息管理表覆盖原数据(ID相同)，版本号不变，修改次数+1；同时将修改前后的数据转存到操作记录表。

删除数据：为保证对多中心环境下数据的全程跟踪和追溯，不能物理删除数据，而应该以删除标志位来逻辑删除数据，即将被删除数据记录的删除标志位置为1表示该数据记录被逻辑删除，否则该数据记录未被逻辑删除。这样，删除操作本质上和修改操作是类似的，删除后数据记录除了将删除标志位置为1之外，同样也保存到最新信息管理表覆盖原数据(ID相同)，版本号不变，修改次数+1；同时将删除前后的数据转存到操作记录表。

(3)发送业务数据给其他中心

从最新信息管理表中按一定条件选取部分或者全部数据，发送给其他中心。同时还应将发送业务数据对应的变更信息(从创建之后流转过的各个中心对数据的变更信息)发送给其他中心。

将发送的数据原样加上收发时间、数据目的(接收中心)存储到历史版本管理表中，以保存发送的数据状态。

下面以某计划管理系统编审流程为例，说明本发明方法的应用方式和作用，如图2所示。

1、多中心环境结构构建

计划管理系统覆盖三级单位，每级单位中有一个综合部门和多个业务部门，下级单位编制计划经审核后上报给上级单位，每个单位中的综合口接收下级单位上报的计划数据，然后拆分给多个业务部门进行审核，业务部门审核完成后将数据回报给综合部门，综合部门汇总各业务部门审核后计划数据经审核后上报上级单位。由于各级单位之间存在物理或者权限的隔离，需要各单位/部门单独部署数据中心管理所辖数据。

从图2可以看到，各个大单位可视为1级中心，包括中心A1、B1、B2、C1、C2、C3等。各1级中心内部可划分为多个2级中心对应单位内的部门(单位/部门单独部署数据中心管理所辖数据)，如1级中心A1内部包括2级中心A1.0、A1.1、……A1.N。其中A1.0为综合部门，由于1级中心的收发都统一通过2级中心里的综合部门来完成，则1级中心和其下的综合部门2级中心可视为等价的，即1级中心X和2级中心X.0等价。

采用多中心环境建模之后，对整个编审过程的业务流程进行分析，可看到每个1级中心都将执行如下工作步骤：

(1)综合部门(2级中心，等价于本1级中心)接收下级单位(某1级中心)上报数据。

(2)综合部门(2级中心，等价于本1级中心)拆分数据并发送给本1级中心内的业务部门(其他2级中心)。

(3)业务部门(2级中心)接收综合部门(2级中心，等价于本1级中心)拆分过来的数据。

(4)业务部门(2级中心)对数据进行审核，也可创建新的数据。

(5)业务部门(2级中心)上报(编审后)数据给综合部门(2级中心，等价于本1级中心)。

(6)综合部门(2级中心，等价于本1级中心)接收业务部门(2级中心)上报的数据。

(7)综合部门(2级中心，等价于本1级中心)对数据进行审核，也可创建新的数据。

(8)综合部门(2级中心，等价于本1级中心)上报(编审后)数据给上级单位(某1级中心)。

2、数据状态控制字段设计

为了实现对计划项目数据在编审全过程的精细化管理和全程留痕，对计划项目数据设计如下数据状态控制字段：

(1)计划项目数据的全局唯一标识

每一条计划项目数据自创建起，将被赋予一个标识ID，在该计划项目数据内容变更、业务数据信息流转过程中ID永远保持不变，可以使用32位随机GUID作为计划项目数据的标识ID，在全系统中不会重复。

(2)多级数据版本设置

多中心环境分成1级中心和2级中心，采用两级版本号+修改次数的多级数据版本机制。

版本号设计为三位数字，其中第1位数字表示1级版本号，第2-3位数字表示2级版本号。

当计划项目数据在1级中心之间进行流转时，1级版本号+1，2级版本号清0，因为1级中心之间的流转次数较少，因此，1位数字可以支持9次流转，可满足业务流程需求。

当计划项目数据在2级中心(必须属于同一个1级中心)之间流转时，2级版本号+1，1级版本号不变。2位数字可以支持99次流转，可满足业务流程需求。

各中心在本地进行一般性数据维护(增删改)时，不会导致版本号的变化，只利用修改次数字段记录数据的状态变化。

(3)全面记录计划项目数据的变更信息

除了保存计划项目数据的各个状态版本，还需记录计划项目数据每次变更的相关信息，包括变更人、变更人所属单位、变更时间、变更原因等。

在计划项目数据记录中加上创建/修改/删除人及所属单位、创建/修改/删除时间等字段记录变更信息；

采用专门的审核意见表来记录计划项目数据审核的相关信息，包括审核人、审核部门、审核对应的计划项目版本、审核意见、审核后数据相对数据在本中心初始状态(创建或者接收)的变化情况等。

3、多层数据表结构设计

根据前述分析，围绕对计划项目数据多版本管理，在各个中心处构建多层数据表结构：

(1)最新信息管理表(ZXXXGL)：

该表只存储本中心维护的计划项目数据信息的最新状态，主键是项目ID。最新状态的计划项目数据被访问的频度最高，因此单独成表以控制数据规模，从而保证数据存取和查询性能。

(2)数据收发历史版本管理表(LSBBGL)：

该表存储来自其他中心的计划项目数据，或者本中心发往其他中心的计划项目数据，以便于进行数据对比和追溯。主键是“计划项目ID+与中心级别相适应的版本号+数据收发时间”。如果本中心是1级中心，则与中心级别相适应的版本号就是1级版本号，即版本号字段中3位数字的第1位；如果本中心是2级中心，则与中心级别相适应的版本号就是1级版本号+2级版本号，即版本号字段中3位数字全部。

(3)操作记录表(CZJL)：

全面记录本中心内部的所有数据变更操作，确保对计划项目数据的所有操作留痕。该表不设置主键，可存储同版本同ID的业务数据，通过修改次数来区分同ID同版本号数据的不同状态。

(4)审核意见表(SHYJ)：

记录本中心对计划项目的总体变更情况，即数据在进入本中心(或创建自本中心)到离开本中心(在同一个版本号下)前后的变更信息。包括审核计划项目ID、计划项目版本号(审核前)、审核人、变更人所属单位、审核时间、审核意见、审核前后内容对比等，其中审核前内容固定为该计划项目数据接收状态(计划项目接收自其他中心)或者创建状态(计划项目创建自本中心)。

4、数据流转和变更过程控制

设计相应的数据流转和变更过程控制如下：

(1)综合部门(2级中心，等价于本1级中心)接收下级单位(某1级中心)上报数据。

将接收的计划项目数据原样加上收发时间、数据来源(发送中心)存入对应1级中心的数据收发历史版本表。

将接收的数据记录的1级版本号(版本号3位数字的第1位)+1，修改次数清零，然后存入最新信息管理表。如果有数据ID相同的情况，新接收数据将覆盖原数据记录，原数据记录和新数据记录将存入操作记录表。

除了计划项目数据之外，还接收对应所接收计划项目的审核意见信息，存入审核意见表。

(2)综合部门(2级中心，等价于本1级中心)拆分数据并发送给本1级中心内的业务部门(其他2级中心)。

从最新信息管理表中按一定条件选取部分或者全部计划项目数据，发送给其他2级中心。同时还应将发送计划项目数据对应的审核意见信息(来自审核意见表)发送给其他2级中心。

将发送的数据原样加上收发时间、数据目的(接收中心)存储到对应2级中心的数据收发历史版本管理表中，以保存发送的数据状态。

(3)业务部门(2级中心)接收综合部门(2级中心，等价于本1级中心)拆分过来的数据。

数据状态管控逻辑与(1)比较接近。

区别在于本地中心是2级中心，因此，本地数据收发历史版本表是对应2级中心的，主键有区别；接收的计划项目转存入最新信息管理表时，是将接收的数据记录的2级版本号(版本号3位数字的第2-3位)+1。

(4)业务部门(2级中心)对数据进行审核，也可创建新的数据。

新增数据保存到最新信息管理表，版本号从初始状态开始记起。并将操作前后数据状态记录到操作记录表。新增数据同时存储到数据收发历史版本表，“数据来源”字段填入本2级中心标识。

对最新信息管理表中的计划项目数据进行审核，审核(修改或删除)后数据保存到最新信息管理表覆盖原数据(ID相同)，版本号不变，修改次数+1；同时将审核(修改或删除)前后的数据转存到操作记录表。

审核时自动记录审核意见表，存入审核计划项目ID、计划项目版本号(审核前)、审核人、变更人所属单位、审核时间、审核意见、审核前后内容对比等字段，审核前计划项目状态为该计划项目在历史版本表中的最近一次接收状态。

(5)业务部门(2级中心)上报(编审后)数据给综合部门(2级中心，等价于本1级中心)。

数据状态管控逻辑与(2)类似，不再赘述。

(6)综合部门(2级中心，等价于本1级中心)接收业务部门(2级中心)上报的数据。

数据状态管控逻辑与(3)类似，不再赘述。

(7)综合部门(2级中心，等价于本1级中心)对数据进行审核，也可创建新的数据。

数据状态管控逻辑与(4)类似，不再赘述。

(8)综合部门(2级中心，等价于本1级中心)上报(编审后)数据给上级单位(某1级中心)

数据状态管控逻辑与(2)比较接近。

区别在于本地中心是1级中心，因此，本地数据收发历史版本表是对应1级中心的，主键有区别。

5、数据冲突发现和消解

因为C2将数据同时上报给B1和B2，然后B1和B2又将数据上报A1，则A1收到数据中，有来自C1创建但由B1和B2分别审核过的计划项目数据，此时B1和B2对C1创建数据的审核(变更)可能不同，需要A1识别这种差异，并进行处理以消解数据冲突。

从“7.4数据流转过程设计”中的“(1)综合部门(2级中心，等价于本1级中心)接收下级单位(某1级中心)上报数据”可以看到：A1接收来自B1和B2的数据时，会在数据收发历史版本表中保存数据接收状态，当发现有来自不同中心但数据ID相同的数据记录时，意味着同一条数据记录被不同中心审核过，可用此种逻辑进行数据冲突发现。

当发现数据冲突后，可找到产生冲突的两个数据接收状态对应的审核意见信息，观察B1和B2对同一计划项目的审核意见的差异，供A1进行下一步审核参考，当A1完成该计划项目审核后，该计划项目最新版本状态是唯一的。由于在业务流程中，计划项目的终审权一定仅属于一个中心，因此，最终完成业务流程之后，计划项目的最终版本状态一定是唯一的，而在审核过程中出现的同版本号的不同状态可结合数据来源中心或数据持有中心加以区分。

尽管已经示出和描述了本发明的实施例，对于本领域的普通技术人员而言，可以理解在不脱离本发明的原理和精神的情况下可以对这些实施例进行多种变化、修改、替换和变型，本发明的范围由所附权利要求及其等同物限定。

Claims (8)

1.一种多级中心环境下数据状态一致性管控方法，其特征在于包括以下步骤：

将分布式信息管理系统构建成多级数据管理中心；

对所述管理中心数据设置唯一管理标识ID，所述ID包括版本号和修改次数，所述版本号与多级管理中心对应，版本级数对应所述管理中心级数；

所述多级数据管理中心通过所述管理表示ID进行数据接收、变更和发送。

2.根据权利要求1所述一种多级中心环境下数据状态一致性管控方法，其特征在于：

所述级数据管理中心中，高级别数据管理中心可以由至少1个低一级别数据管理中心组合构成；

属于相同高级数据管理中心的同级别数据管理中心能进行数据交互，属于不同高级别数据管理中心的同级别数据管理中心不能进行直接数据交互。

3.根据权利要求2所述一种多级中心环境下数据状态一致性管控方法，其特征在于：

在所述数据管理中心内部进行数据变更时，所述版本号不变，变更所述修改次数；

向其他数据管理中心发送数据时，将所述数据版本号变更为较高级别数据管理中心版本号。

4.根据权利要求3所述一种多级中心环境下数据状态一致性管控方法，其特征在于：

数据变更或流转时，还需记录数据ID、变更前版本号、变更人、变更人所属单位、变更时间、变更原因。

5.根据权利要求4所述一种多级中心环境下数据状态一致性管控方法，其特征在于：

所述方法还包括设置多层级数据表，所述多层级数据表包括最新信息管理表、数据收发历史版本表、操作记录表、同版本变更信息表，具体为：

所述最新信息管理表存储本地最新数据的状态，其主键为所述数据管理标识ID，还具体存储所述数据版本号和修改次数、变更数据人员信息、变更数据时间；

所述数据收发历史版本数据表，存储本数据管理中心与外界同级别数据管理中心进行数据交互时的数据状态，该表与本数据管理中心级别相对应，具体存储所述数据管理ID、对应本中心级别的版本号、收发时间、数据来源、数据目的。

所述操作记录表用于记录本数据管理中心内部的所有数据变更操作，该表保留所述最新信息管理表中的历史记录以及每次变化的前后状态。

所述同版本变更信息表记录本数据管理中心内部对同一版本同一ID的数据总体变更情况。

6.根据权利1-5所述任一一种多级中心环境下数据状态一致性管控方法，其特征在于：

所述数据管理中心接收其他中心发送数据时，将所述数据加上收发时间、数据来源存入对应本中心级别的历史版本表；

将接收的数据记录的对应本数据管理中心级别的版本号+1，修改次数清零，然后存入所述最新信息管理表。

7.根据权利1-5所述任一一种多级中心环境下数据状态一致性管控方法，其特征在于：

所述数据管理中心本地数据变更时，变更后数据保存到所述最新信息管理表，有同管理ID的数据则覆盖原数据，新增数据版本号从初始状态开始记起，删、改数据版本号不变，修改次数+1，同时将变更前后数据状态存入所述操作记录表。

8.根据权利1-5所述任一一种多级中心环境下数据状态一致性管控方法，其特征在于：

所述数据管理中心发送数据给其他数据管理中心，从所述最新信息管理表中按发送要求选取部分或者全部数据，发送给其他数据管理中心，同时还可将所述同版本变更信息表记录的所述发送数据对应的变更信息发送给其他数据管理中心。

Images