CN102591666A - 一种分级结构的元数据版本管理方法 - Google Patents

Abstract

本发明公开了一种分级结构的元数据版本管理方法，涉及ERP系统领域。该方法通过为元数据信息添加分级结构的版本描述，通过这种分级版本信息分别描述同一份元数据信息的不同在不同开发层次上的修改，并对同一份元数据的不同层级版本进行管理。包括设定开发层次、开发或修改元数据、发布元数据、部署元数据、加载元数据等步骤。与现有技术相比，本发明的分级结构的元数据版本管理方法能够有效控制对于同一份元数据信息的多方修改带来的冲突，具有很好的推广应用价值。

Description

一种分级结构的元数据版本管理方法

 

技术领域

本发明涉及ERP系统领域，具体地说是一种可实现元数据在多方开发场景下的版本冲突控制的分级结构的元数据版本管理方法。

背景技术

在ERP系统中，为了满足不同类型企业的管理需求，适应特定企业在发展过程中不断的变化，ERP系统必须具备良好的灵活性，使得ERP系统可配置、可修改、可扩展。

为了满足ERP系统的灵活性要求，在软件实现中一般采用MDD（模型驱动开发）的设计思路，总结提炼软件开发过程中的经验和模式，形成各类抽象结构，并通过图形化的开发工具进行设计，可快速生成可编译执行的程序源代码，或者生成特定的描述文档，在程序的运行时通过特定的解释器程序解释执行。

在本发明中，将ERP系统中用于描述特定类型技术抽象的定义，称为元数据。例如：对于数据库中数据结构的技术抽象，即可定义为一类描述数据结构的元数据，它用于描述数据表的表名称、字段集合、约束集合等等。

通过MDD的技术实现，ERP系统在企业客户具体实施过程中，通过MDD开发工具开发新的元数据或调整已有元数据，可快速的进行配置或定制开发，满足客户的个性化需求及需求变更。

作为一个较成熟的ERP软件提供商，ERP系统中共性的功能特征会积累下来，形成可复用的功能组成部分，并以此为基础形成ERP软件产品，ERP软件产品以同一个版本同时应用到多个不同的客户项目中去。这种产品化的积累，可提高ERP软件的研发效率和软件质量。在基于MDD开发的ERP系统中，这种可复用的功能组成部分，主要以元数据的方式来描述。

但是，对于一个可复用的功能部分，在产品维护过程及特定客户项目实施过程中，都会进行修改，这就会导致同一份元数据描述被施加了不同的修改，从而产生冲突，如果ERP产品升级，覆盖了特定客户项目上已经做了修改的元数据，将会产生错误。

随着ERP系统规模和复杂性的不断提高，会导致ERP系统的开发、实施的分工细化和分层，如：通用产品开发、行业化开发、区域化开发、项目定制开发等等，这些不同的分工产生的开发层次，都有可能对特定的元数据信息进行修改，从而把这种冲突从两方变为多方之间的冲突。另外，在云计算环境下，基于PaaS平台的SaaS应用模式的ERP系统，也存在同类问题。

发明内容

本发明的技术任务是针对上述现有技术的不足，提供一种分级结构的元数据版本管理方法。该方法通过为元数据信息添加分级结构的版本描述，通过这种分级版本信息分别描述同一份元数据信息的不同在不同开发层次上的修改，并对同一份元数据的不同层级版本进行管理，用以控制对于同一份元数据信息的多方修改带来的冲突。

本发明的技术任务是按以下方式实现的：一种分级结构的元数据版本管理方法，其特征在于：包括以下步骤：

A.   设定开发层次

包括定义元数据的开发层次，所述开发层次用于描述中ERP系统分工细化的结构；

包括定义一种元数据版本结构，所述元数据版本结构用于描述一个元数据的分级结构版本信息；

B.   开发或修改元数据；

C.   发布元数据

将元数据发布为系统部署环境可更新的软件打包形式，用于后续的元数据部署；

D.   部署元数据

在目标系统环境中更新步骤C发布的元数据；

E.    加载元数据

所述加载元数据的过程，是指根据元数据的标识和开发层级关系，获取到元数据内容的过程，

步骤B至步骤D可以进行多次迭代。

在步骤A，为了实现对于元数据的版本管理，首先需要定义元数据的开发层次，所述开发层次用于描述中ERP系统分工细化的结构，开发层次包含的内容：

（1）    开发层次标识，开发层次的唯一标识；

（2）    开发层次名称，用于语义化的表达开发层次的含义；

（3）    开发层次的分类，包含三类：产品层次、行业/区域化层次、客户定制层次，用于分类描述当前开发层次在ERP系统分工细化中的层次分类；

（4）    开发层次描述；

（5）    父级开发层次，用以指定开发层次之间的层级关系。

开发层次的定义，由ERP系统软件开发商统一管理和发布，主要目的是开发层次的冲突管理及规范性，

任何一个ERP系统的部署环境中，都必须设定当前部署环境的开发层次，如果需要修改相应的元数据，则必须具有开发层次的授权，如果不具备相应的授权，则系统阻止对于指定开发层次的元数据修改操作。

开发层次授权在系统中用于控制对于特定开发层次元数据的开发的操作权限，采用与特定硬件标识设备绑定的加密算法产生的字符串。

基于开发层次定义，定义一种元数据版本结构，所述元数据版本结构包含一个或多个带有父子层级关系的开发层次节点，每个开发层次节点用于描述一个元数据的特定开发层次版本控制信息，每个节点包含如下内容：

（1）    元数据标识，用于指定相应的元数据；

（2）    开发层次标识，用于指定元数据的当前的开发层次标识；

（3）    父层次标识，用于指定元数据当前修改所基于的开发层次的标识；

（4）    层次版本号，用于指定当前元数据，在当前开发层次下，其版本的变更记录；

（5）    层次控制信息，提供相关的控制标志。包含的控制标志如下：

a)       是否封闭，用于指定后续开发层次是否可以基于当前开发层次进行修改，如果是否封闭为“真”，则不允许修改；

b)      可修改的层次分类，用于指定当前开发层次的元数据，在哪类开发层次可被再次修改；

c)       是否允许替换，用于指定后续开发层次是否可以将当前开发层次元数据的引用替换为其他开发层次元数据；

d)      升级策略，用于指定当父开发层次及以上层次的变更在更新到当前开发层次时，元数据信息的合并策略，包括：自动合并、覆盖、人工合并、不合并；

e)       可替代的版本范围，用于指定当前版本可替代的开发层次及层次版本的范围，它在元数据加载时使用。

在步骤B，开发或修改元数据时，受到如下限制：

（1）    如果不具备当前开发层次的授权，则不允许对相应的元数据进行修改；

（2）    修改指定开发层次的元数据，系统的控制遵守相应的开发层次节点的“层次控制信息”中包含的控制标志设定；

在步骤B，修改元数据时，需要选择基于的该元数据的父开发层次，并且自动复制父开发层次元数据的元数据内容信息和开发层次节点信息；

在步骤B，修改的元数据被保存时，系统将自动保存元数据修改前内容为历史版本。

在步骤C，元数据发布时，需要发布元数据的开发层级节点信息及元数据内容信息。

步骤D，在部署元数据时，首先要更新元数据发布信息中包含的元数据开发层级节点信息及元数据内容信息；

步骤D，在部署元数据时，如果发现更新的元数据在目标部署环境中已经被修改，产生版本冲突，则根据目标部署环境中指定元数据的开发层次节点的升级策略，做相应的处理：

（1）    如果升级策略为自动合并，则通过特定元数据的合并处理程序，对版本冲突的元数据进行合并，合并后的元数据信息覆盖当前开发层次的元数据内容信息，

对于特定元数据的合并处理程序，它是针对每种元数据定制开发的，其功能是合并产生冲突的两份元数据内容； 

（2）    如果升级策略为覆盖，则直接使用发布的元数据信息覆盖当前开发层次的元数据内容信息；

（3）    如果升级策略为人工合并，则部署不会对当前开发层次的元数据产生影响，但系统中会识别为冲突，并在冲突解决之前阻止对于产生冲突的元数据的访问，直到冲突被处理；

（4）    如果升级策略为不升级，则部署不会对当前开发层次的元数据产生影响，而且系统也不会识别为冲突；

步骤D，在元数据升级完成时，自动更新当前开发层次节点的层次版本号为新版本；

步骤D，一旦产生对元数据当前开发层级节点的元数据内容的覆盖，系统会中覆盖之前自动备份将要被覆盖的元数据信息，产生历史版本。

步骤E中，元数据的加载支持两种加载策略：最新版本、指定版本，

其中，最新版本策略，是指根据指定元数据，根据其开发层级节点关系，叶子节点（没有下级节点）对应的元数据内容信息；指定版本策略，则根据指定的元数据开发层次标识及层次版本号来加载，如果仅指定了开发层次标识，则加载该开发层次标识中的按照层次版本号的当前版本；

步骤E中，按照指定版本策略加载时，需要检查指定的版本是否存在替换版本（根据开发层次节点的“层次控制信息”中的“可替代的版本范围”），如果存在，则加载其替代版本；

步骤E中，在加载元数据时，如果没有指定加载策略，系统默认加载最新版本策略加载元数据；

步骤E中，如果元数据的加载中，指定了加载策略，则按照加载策略进行加载。

本发明的分级结构的元数据版本管理方法与现有技术相比具有以下突出的有益效果：

在ERP产品中，随着ERP系统开发、实施的分工细化和分层，会产生多方开发的场景，如：通用产品开发、行业化开发、区域化开发、项目定制开发等等，这些不同的分工产生的开发层次，都有可能对特定的元数据信息进行修改，从而产生修改的冲突，本发明通过设定开发层次结构及开发层次的冲突处理策略，将不同的开发层次进行划分、隔离及基于对比的冲突合并，从而能有效的管理和解决这种冲突。

附图说明

附图1是本发明分级结构的元数据版本管理方法中元数据开发层次结构示意图；

附图2是本发明分级结构的元数据版本管理方法中元数据分级结构版本控制的主要实体关系示意图。

具体实施方式

参照说明书附图以具体实施例对本发明的分级结构的元数据版本管理方法作以下详细地说明。

实施例：

本实施例划分为三个阶段，分别是产品开发层次的开发、行业开发层次的开发、客户定制开发层次的开发。在介绍三个阶段之后，将描述当冲突发生后，本发明所提出的方法如何管理此冲突。

首先开发层次定义示例如下：

开发层次标识	开发层次名称	开发层次分类	开发层次描述
				ERP	ERP产品	产品	××ERP
ERP-01	汽车制造行业	行业/区域化	用于汽车制造业
				ERP-01-0001	甲客户项目	客户定制	用于甲客户的定制开发

以企业采购业务为例，ERP系统中提供了“维护采购订单”功能，该功能包含但不限于“单据编号规则”、“数据结构”两种元数据。

（一）产品开发层次

在“ERP”开发层次，“维护采购订单”功能在产品层面预定义了“采购订单单据编号规则”和“采购订单数据结构”两个元数据。其中编号规则定义为按照年月的4位流水号，示意为“2011-09-0001”，其数据结构包括采购订单表头及分录两张数据表。简单示意如下：

采购订单表头

名称	数据类型	必填	PK	注释
					内码	Varchar(36)	√	√
单据编号	Varchar(64)	√
					其他业务字段

采购订单分录（表体）

名称	数据类型	必填	PK	注释
					内码	Varchar(36)	√	√
采购订单内码	Varchar(36)	√
					采购物料内码	Varchar(36)	√
其他业务字段

元数据中存储示意如下：

元数据标识	元数据名称	元数据类型
			CodeRule_01	采购订单单据编号	单据编号规则
DataStru_01	采购订单数据结构	数据结构

元数据开发层次节点存储示意如下：

（二）行业开发层次

由于汽车制造行业的行业需求，行业化产品中的采购订单，在采购订单表头增加了“型号”字段，并且订单编号中包含了型号编号，示例为“BORA2011-09-0001”。

在行业开发层次，元数据开发层次节点存储示意如下：

 

名称	数据类型	必填	PK	注释
					内码	Varchar(36)	√	√
单据编号	Varchar(64)	√
					型号	Varchar(36)	√
其他业务字段

（三）客户定制开发层次

在“甲客户项目”实施初期，完全基于“ERP-01”开发层次定义，没有做任何定制。则在元数据开发层次节点存储中，并没有“ERP-01-0001”开发层次的任何数据。当元数据在加载时，按照默认的最新版本策略加载，查找到元数据的叶子节点，即“ERP-01”开发层次的元数据，并加载使用。

冲突控制

为了展示在不同开发层次的变更下，同一个元数据的冲突控制，以“ERP-01”和“ERP-01-0001”两个开发层次之间的冲突来举例。

（1）    客户化定制。在“ERP-01-0001”的“甲客户项目”开发层次，用户根据自身需求，将“CodeRule_01”编号规则，修改为型号+年+五位流水的方式，举例为“BORA2011-00001”；在“DataStru_01”数据结构的主表中添加了“代办人”字段。

名称	数据类型	必填	PK	注释
					内码	Varchar(36)	√	√
单据编号	Varchar(64)	√
					型号	Varchar(36)	√
代办人	Varchar(36)
					其他业务字段

开发层次节点具体的设置内容如下。

 （2）    行业开发层次的修改及发布。在“ERP-01”行业开发层次，由于项目经验的积累，需要调整行业版本的功能预制。其中，对于“CodeRule_01”编号规则，修改为型号+年月+3位流水的方式，举例为“BORA2011-09-001”；在“DataStru_01”数据结构的主表中添加了“采购主管”字段。

名称	数据类型	必填	PK	注释
					内码	Varchar(36)	√	√
单据编号	Varchar(64)	√
					型号	Varchar(36)	√
采购主管	Varchar(36)
					其他业务字段

以上修改在修改完毕后，将元数据相关信息发布，供“ERP-01”的下级开发层次升级。

（3）    客户定制开发层次的部署。当进行以上第3步发布内容的部署时，需要部署上述的两个元数据，部署过程如下：

a)       首先更新“ERP-01”开发层次节点及对应的元数据内容信息；

b)      “CodeRule_01”编号规则部署。依据“CodeRule_01”在“ERP-01-0001”开发层次节点中的版本控制信息中的升级策略：不升级。则部署过程将不会对现有的编号规则产生任何影响，在“ERP-01-0001”开发层次，仍然将使用原有的编号规则；

c)       “DataStru_01”数据结构部署。依据“DataStru_01”在“ERP-01-0001”开发层次节点中的版本控制信息中的升级策略：自动合并。系统将调用数据结构合并程序，对两个开发层次的元数据进行合并，并且会自动更新数据库中的数据结构。

部署后的数据结构如下。

名称	数据类型	必填	PK	注释
					内码	Varchar(36)	√	√
单据编号	Varchar(64)	√
					型号	Varchar(36)	√
采购主管	Varchar(36)
					代办人	Varchar(36)
其他业务字段

部署后的开发层次节点具体的设置内容如下。

Claims (9)

1.一种分级结构的元数据版本管理方法，其特征在于包括以下步骤：

设定开发层次

包括定义元数据的开发层次，所述开发层次用于描述中ERP系统分工细化的结构；

包括定义一种元数据版本结构，所述元数据版本结构用于描述一个元数据的分级结构版本信息；

开发或修改元数据；

发布元数据

将元数据发布为系统部署环境可更新的软件打包形式，用于后续的元数据部署；

部署元数据

在目标系统环境中更新步骤C发布的元数据；

加载元数据

所述加载元数据的过程，是指根据元数据的标识和开发层级关系，获取到元数据内容的过程，

步骤B至步骤D可以进行多次迭代。

2.根据权利要求1所述的分级结构的元数据版本管理方法，其特征在于：在步骤A，为了实现对于元数据的版本管理，首先需要定义元数据的开发层次，所述开发层次用于描述中ERP系统分工细化的结构，开发层次包含的内容：

开发层次标识，开发层次的唯一标识；

开发层次名称，用于语义化的表达开发层次的含义；

开发层次的分类，包含三类：产品层次、行业/区域化层次、客户定制层次，用于分类描述当前开发层次在ERP系统分工细化中的层次分类；

开发层次描述；

父级开发层次，用以指定开发层次之间的层级关系。

3.根据权利要求2所述的分级结构的元数据版本管理方法，其特征在于：开发层次的定义，由ERP系统软件开发商统一管理和发布，主要目的是开发层次的冲突管理及规范性，

任何一个ERP系统的部署环境中，都必须设定当前部署环境的开发层次，如果需要修改相应的元数据，则必须具有开发层次的授权，如果不具备相应的授权，则系统阻止对于指定开发层次的元数据修改操作。

4.根据权利要求3所述的分级结构的元数据版本管理方法，其特征在于：开发层次授权在系统中用于控制对于特定开发层次元数据的开发的操作权限，采用与特定硬件标识设备绑定的加密算法产生的字符串。

5.根据权利要求1所述的分级结构的元数据版本管理方法，其特征在于：基于开发层次定义，定义一种元数据版本结构，所述元数据版本结构包含一个或多个带有父子层级关系的开发层次节点，每个开发层次节点用于描述一个元数据的特定开发层次版本控制信息，每个节点包含如下内容：

元数据标识，用于指定相应的元数据；

开发层次标识，用于指定元数据的当前的开发层次标识；

父层次标识，用于指定元数据当前修改所基于的开发层次的标识；

层次版本号，用于指定当前元数据，在当前开发层次下，其版本的变更记录；

层次控制信息，提供相关的控制标志，包含的控制标志如下：

是否封闭，用于指定后续开发层次是否可以基于当前开发层次进行修改，如果是否封闭为“真”，则不允许修改；

可修改的层次分类，用于指定当前开发层次的元数据，在哪类开发层次可被再次修改；

是否允许替换，用于指定后续开发层次是否可以将当前开发层次元数据的引用替换为其他开发层次元数据；

升级策略，用于指定当父开发层次及以上层次的变更在更新到当前开发层次时，元数据信息的合并策略，包括：自动合并、覆盖、人工合并、不合并；

可替代的版本范围，用于指定当前版本可替代的开发层次及层次版本的范围，它在元数据加载时使用。

6.根据权利要求1所述的分级结构的元数据版本管理方法，其特征在于：在步骤B，开发或修改元数据时，受到如下限制：

如果不具备当前开发层次的授权，则不允许对相应的元数据进行修改；

修改指定开发层次的元数据，系统的控制遵守相应的开发层次节点的“层次控制信息”中包含的控制标志设定；

在步骤B，修改元数据时，需要选择基于的该元数据的父开发层次，并且自动复制父开发层次元数据的元数据内容信息和开发层次节点信息；

在步骤B，修改的元数据被保存时，系统将自动保存元数据修改前内容为历史版本。

7.根据权利要求1所述的分级结构的元数据版本管理方法，其特征在于：在步骤C，元数据发布时，需要发布元数据的开发层级节点信息及元数据内容信息。

8.根据权利要求1所述的分级结构的元数据版本管理方法，其特征在于：

步骤D，在部署元数据时，首先要更新元数据发布信息中包含的元数据开发层级节点信息及元数据内容信息；

步骤D，在部署元数据时，如果发现更新的元数据在目标部署环境中已经被修改，产生版本冲突，则根据目标部署环境中指定元数据的开发层次节点的升级策略，做相应的处理：

如果升级策略为自动合并，则通过特定元数据的合并处理程序，对版本冲突的元数据进行合并，合并后的元数据信息覆盖当前开发层次的元数据内容信息，

对于特定元数据的合并处理程序，它是针对每种元数据定制开发的，其功能是合并产生冲突的两份元数据内容； 

如果升级策略为覆盖，则直接使用发布的元数据信息覆盖当前开发层次的元数据内容信息；

如果升级策略为人工合并，则部署不会对当前开发层次的元数据产生影响，但系统中会识别为冲突，并在冲突解决之前阻止对于产生冲突的元数据的访问，直到冲突被处理；

如果升级策略为不升级，则部署不会对当前开发层次的元数据产生影响，而且系统也不会识别为冲突；

步骤D，在元数据升级完成时，自动更新当前开发层次节点的层次版本号为新版本；

步骤D，一旦产生对元数据当前开发层级节点的元数据内容的覆盖，系统会中覆盖之前自动备份将要被覆盖的元数据信息，产生历史版本。

9.根据权利要求1所述的分级结构的元数据版本管理方法，其特征在于：步骤E中，元数据的加载支持两种加载策略：最新版本、指定版本，

其中，最新版本策略，是指根据指定元数据，根据其开发层级节点关系，叶子节点对应的元数据内容信息；指定版本策略，则根据指定的元数据开发层次标识及层次版本号来加载，如果仅指定了开发层次标识，则加载该开发层次标识中的按照层次版本号的当前版本；

步骤E中，按照指定版本策略加载时，需要检查指定的版本是否存在替换版本，如果存在，则加载其替代版本；

步骤E中，在加载元数据时，如果没有指定加载策略，系统默认加载最新版本策略加载元数据；

步骤E中，如果元数据的加载中，指定了加载策略，则按照加载策略进行加载。

Images