[发明专利]元数据升级方法和系统

说明书

技术领域

本发明涉及企业资源管理系统，尤其涉及元数据升级方法和系统。

背景技术

ERP(Enterprise Resource Planning，简称ERP)系统的研发中涉及到了各种概念，下面进行简单说明：

元数据：是描述数据的数据，用于实现抽象的持久层和界面表现层，是抽象数据的描述性数据。在通常的管理信息系统中，元数据包含实体元数据、服务(接口)元数据、UI(User Interface，简称UI)元数据等。

元元数据：元数据的数据模型。

元数据包：按组件或应用组织为单位的数据包，该数据包包含元元数据、元数据、资源以及格式描述。升级数据包包含基准数据包和增量数据包。

资源元数据：描述系统中各种名称、字典、描述性信息以及其他非结构化数据的元数据，用以解决多语种、客户化等问题。

组件：一种软件模型管理的粒度，根据功能和数据模型间的耦合性、研发组织的便利性等因素在系统应用架构设计期间进行划分。

随着企业规模的扩大以及ERP系统的逐渐发展，系统的功能越来越复杂，数据越来越庞大，用户的需求也存在着多样性和不确定性。ERP系统的研发需要快速的响应用户的需求。元数据升级能够在快速软件开发中，起到关键性作用。

在通常的软件建模工具中，模型的发布往往是生成静态的脚本或者数据文件，有如下缺点

1.模型只能发布到新系统中，无法或很难保留现有数据和配置信息；

2.实体数据模型只能生成建库的脚本，开发人员需要人工编写升级脚本或升级程序；

3.用户环境的个性化信息，比如用户数据、授权信息、多语信息以及各种定制的UI数据都很难在版本升级时得到继承。

此外，开发和设计人员针对模型的修改有如下若干种：

1.增加实体或字段，修改属性类型；

2.UI模型对界面显示信息或者相关数据的增加、删除和修改；

3.修改物理模型的字段属性、默认值、索引等等；

4.实体信息改为多语种。

还有很多对模型的修改场景，在此不一一列举。

比较常见的设计工具在实现上述模型修改时一般情况下是比较简单的，但是模型改完之后有一系列问题难以处理：

1.单元测试环境和集成测试环境的验证环境的升级，而该验证环境往往有比较复杂的数据作为案例。

2.验证通过后进行用户环境的升级，补丁通过验证环境的验证后，进行用户环境的升级，而用户的数据更加复杂，并且各个用户的版本不一致，导致升级的困难。

这样，如果研发人员每次修改模型都要自己编写升级程序的话，会引起如下问题：

1.升级程序的编写降低了开发效率，同时提高了对开发人员的要求；

2.升级程序处理多版本时比较困难；

3.在大的团队开发中，很难对升级程序或脚本进行管理；

显然这样的研发过程很难保证高质量和高效率。

因此，需要一种元数据升级方法和系统，可以使用统一工具进行快速安全的升级，能够保留用户的个性化信息，提高研发人员的工作效率。

发明内容

有鉴于此，本发明所要解决的技术问题在于，提供一种元数据升级方法和系统，可以使用统一工具进行快速安全的升级，能够保留用户的个性化信息，提高研发人员的工作效率。

本发明提供了一种元数据升级方法，包括：步骤102，循环比较新的元数据与原有的元数据之间的差异；步骤104，根据所述差异实现所述原有的元数据的升级。不需要重新构造元数据的模型，通过比较差异的方法来修改原有的元数据，既能保留用户的个性化信息，又能保证元数据的快速升级。

在上述技术方案中，优选地，在所述步骤104中，根据所述差异判断需要修改的所述元数据是否为业务主键，在判断结果为是所述业务主键的情况下，删除所述元数据所在的表的所有触发器，对所述元数据进行修改。这样，删除了所述表的触发器之后，可以对元数据进行增加、删除和更改。

在上述技术方案中，优选地，在所述步骤104中，在对所述元数据进行修改后，判断需要修改的所述元数据是否存在索引和约束，在判断结果为是的情况下，则删除所述索引和所述约束，对所述元数据的所述表的结构进行修改。除了删除触发器之后，还要删除元数据的索引和约束，这样才能继续修改元数据的表结构。

在上述技术方案中，优选地，修改完所述元数据的所述表的结构之后，重新建立所述索引和所述约束。在有必要的情况下，重新建立元数据的索引和约束关系。