[发明专利]基于跟踪的数据库模式演进方法及系统

说明书

技术领域

本发明涉及对数据库的演进，具体来说，涉及一种基于跟踪的数 据库模式演进方法及系统。

背景技术

在现今的商业服务应用领域中，随着用户需求的不断变化，商业 服务的逻辑以及其数据库模式(schema)也相应地进行演进。例如， SaaS(服务式软件)系统可以通过一种系统设计来服务于不同的终端 用户。在服务式软件系统中，随着用户数量以及用户类型的增加，对 于解决方案的灵活性和个性化的需求越来越重要。例如，可能由于功 能性设计和/或非功能性设计的原因，需要对商业服务的逻辑以及数据 库模式进行改变。一般来说，在商业服务的整个寿命周期期间，商业 服务系统需要不断演进。

在商业服务系统的演进过程中，数据库模式的演进和商业逻辑的 演进应当同步。另外，对于发生演进之后的商业服务系统而言，原商 业服务系统中的数据可能仍然是重要，因此，需要根据数据库模式的 改变来正确地移植数据。

然而，在现有技术中，商业逻辑改变和数据库模式演进是在没有 集成工具支持的情况下被分开处理的。因此，在现有技术中，商业服 务系统的演进耗时、复杂且容易出错，并且，在商业逻辑的模型设计 和数据库模式演进的结果之间容易产生差异。

例如，图1示意性地说明了现有技术中可能产生的问题。

现今，通常采用模型驱动的代码产生技术来为商业逻辑产生代码。 其中，首先由设计人员设计用于商业服务的设计模型，然后，开发人 员基于设计模型产生代码并由此创建符合设计的商业逻辑。

如图1所示，当需求发生改变时，设计人员利用设计模型修改工 具101对设计模型进行修改，并将修改后的新设计模型分别提供给开 发人员和数据库管理员。

一方面，开发人员将新设计模型导入模型驱动工具111。模型驱 动工具111对设计模型进行解析。接着，代码生成器112根据解析结 果产生代码。商业逻辑编译器113利用产生的代码创建相应的商业逻 辑。

另一方面，在与创建所述商业逻辑完全不同的环境中，数据库管 理员(DBA)利用数据库重构装置121对新设计模型进行操作，以产 生重构点(Refactor Point)文件。然后，利用重构点文件，模式演进 脚本(script)生成装置122可以生成模式演进脚本，以及数据移植脚 本生成工具123可以生成数据移植脚本。接着，利用测试数据库124 对模式演进脚本和数据移植脚本进行测试。

在现有技术中，数据库管理员需要手动地分析新设计模型来产生 重构点文件，因此，所产生的脚本和所产生的代码之间很容易产生不 一致性。尽管在现有技术中数据库管理员和开发人员可以通过其它方 式进行额外的沟通来消除这种不一致性，但是，这在一定程度上增加 了商业服务系统演进的复杂程度和成本。

另外，由于手动产生重构点文件，因此，不能够确保重构点文件 完全正确反映对设计模型的修改。因此，在对模式演进脚本和数据移 植脚本的调试过程中还可能需要对重构点文件进行修改。这在某种程 度上还会增加数据库演进的复杂程度和成本。

在Deepak S.Elandassery等人的申请日为2003年9月25日、申 请号为10/670,947、发明名称为“Method for Automated Database Schema Evolution”的美国专利申请(以下称为对比文件1)中公开了 一种自动数据库模式演进的方法，该专利申请在此引入作为参考。在 对比文件1中，将新数据库和旧数据库的模式文件进行比较，以找到 二者之间的差别，并根据所述差别来进行数据库模式演进。在对比文 件1中不涉及数据移植。

在Kang Ge等人的申请日为2004年12月17、申请号为 11/016,228、发明名称为“Differential Management of Database Schema Changes”的美国专利申请(以下称为对比文件2)中公开了 一种数据库模式演进的方法，该专利申请在此引入作为参考。与对比 文件1类似，在对比文件2中，将新数据库和旧数据库的模式文件进 行比较，以找到二者之间的差别，并根据所述差别来进行数据库模式 演进。

在对比文件1和2的技术方案中同样存在上面所述的问题。

另外，在对比文件1和2中，通过比较新数据库和旧数据库的模 式文件来找到二者之间的差别，但是这种方式不能够或者很难跟踪数 据库模式改变时的语义信息。