XML 和数据模型的扩展性

 

随着业务的不断发展，以及信息技术的不断进步，摆在信息部门人员面前的一个永恒的主题就是，怎么样建设一个更加符合业务需求，更能引导业务发展的企业信息系统，这就需要我们的数据模型具备更强大的扩展能力。

那么怎么样才能让我们的数据模型具有更加强大的生命力呢？更能适应灵活多变的业务的需求的同时，还能够针对未来业务的发展留下一定的扩展空间呢？这就是我们本文需要讨论的重点。需要指出的是，我们这里探讨的数据建模的方法目前在DB2V9的数据库上能够具体实现，针对其他数据库的数据模型的扩展性考虑，可能还需要根据其他数据库的具体技术特点去具体实现。

数据模型和业务系统之间的关系

首先我们需要了解一下数据模型与业务系统的关系。我们这里可以将业务和数据模型整个分为三个层次：

• 业务层面：这个层次是我们客观世界中真实的业务层面的问题。
• 数据模型层面：这个层次是将真实的业务层面的个体抽象成抽象的，独立的实体和概念。
• 业务模板层面：这个层次介于业务层面和业务层面之间，通过该层面来实现数据模型层对业务层面的具体问题的映射。

我们将这种关系简单的用下图描述成下图的三个层次：

图 1. 数据和业务关系图

通过上图，我们了解到，数据模型层其实是一个个抽象的，独立的概念和实体。这里实体与实体之间发生的关系，我们可以视为不同的实体组合，组成了不同的业务模板。而业务层的不同的具体业务问题，可以对应成一个个的业务模板。因此，在这三个层次中，数据模型层的一个个实体就是整个数据模型的基础，通过实体间不同组合生成的业务模板，可以解决具体的业务中的相应问题。

理论上来说，如果一个完美的数据模型应该包含了所有的业务问题，所有的业务层的业务问题，都能通过相应的业务模板层找到相对应的业务模板。但是，在实际的数据建模的过程中，由于各种条件的限制，对业务理解的不够深入，以及业务本身的发展，往往会导致数据模型随着时间的推移也需要做出符合业务需要的修改。那么，在数据建模的过程中，必须要充分考虑到未来数据模型的扩展可能。

数据模型面临的挑战

如上面所说，我们的数据模型从诞生那一刻起，就面临着各种各样的挑战。由于方法论的不同，导致了在数据建模的过程中，各种流派对同一客观事物的不同抽象和划分的方法，从而最终生成各自的数据模型。因此，从这个意义上说，每个数据模型，从开始就面临着各种各样的挑战。

除了上述方法论上方面的挑战之外，在具体的技术层面，数据模型同样也面临着挑战，而这一部分将是本文需要着重介绍的一部分，总的说来，我归纳为以下两个方面：

• 业务发展的挑战
• 业务整合的挑战

下面，我们将就这两个方面作详细的介绍。

业务发展的挑战

运动是绝对的，静止是相对的。从这个意义上说，业务的发展是一个不可避免的现实。发展，不可避免带来一定业务过程的变化，以及一些业务主体的变更，而这些，不可避免的需要反映到我们的数据模型中来。

一般来说，业务的发展包含两个层面：

• 业务过程发生变化，指随着新的业务规则的变化，可能会影响到旧有的业务过程，需要按照新的业务规则生成相应的数据模型。
• 业务主体发生变更，指随着业务的发展，出现了新的事物主体或者原有的事物主体的新的属性的增加，需要我们按照新的业务主体修改我们原有的数据模型。

对于业务过程的变化，我们可以理解为正常的业务模板的变更，一般我们可以通过新的业务模板，通过新的实体与实体的组合来反映业务流程的变化。如图 2 所示。

图 2. 业务流程的变化

在图 2 中，我们可以看到由于营销的业务过程发生了变更，导致对应的业务模板发生了变更，其对应到数据模型的变化就是在新的业务过程中，加入了实体四的组合，由原先的实体一和实体二的组合变成了实体一，实体二和实体四的组合。对于这种业务过程的变更，恰好能够反映出数据模型的重要性，将整个应用的变更局限在业务模板层，底层的数据模型不发生任何变化，就能够灵活的响应新业务的需求。

对于业务主体的变更，涉及到底层数据模型的改动，这个是我们在数据建模的过程中必须要重视的问题。如图 3 所示。

图 3. 数据模型的改动

从上图中可以很明显的看出，同样是营销业务发生变化，但这次发生变化的是业务主体，需要针对我们老的数据模型中增加一些新的实体属性才能完成相应的数据模型针对业务问题的映射。在这里，扩充/变更主体属性，以及新增实体等针对数据模型层次的变动会导致整个数据模型层的变动，而数据模型的变动的直接后果就是应用的变动，一旦应用发生变动会动摇我们整个系统的基础，这是我们不希望看到的一个后果。

因此，如果在数据模型层中考虑到这些可能的变化，避免导致整个应用基础的动摇，就是我们在数据建模的过程中面临的一个迫切需要解决的挑战。

业务整合的挑战

任何事物都存在一个发展的过程，不仅我们的数据模型有自己的发展历史和发展过程，我们的IT建设也有相应的发展过程。IT建设走到今天，在一般的客户的实际环境中，已经存在了非常多的IT系统，新系统的建设，往往需要考虑客户现有的IT系统环境和数据。因此，在新系统的建设过程中，我们会面临越来越强大的业务整合的需求。

同样，在为客户的特定的应用进行数据模型的设计的时候，我们也需要考虑数据模型与客户现有数据的兼容性的问题。以笔者的经验，在越来越强调信息交互的今天，这方面的考虑是我们在数据建模的今天需要非常重视的一个问题。

在一个实际的客户环境里，我们在建设新的数据模型的时候，必须要考虑与已有系统数据模型的兼容性问题。如图 4 所示。

图 4. 系统数据模型的兼容性

从上面的图中，我们能够非常清楚地看到，在新系统的建设中，由于A，B 两个系统是已经存在的现有系统，而 A 和 B 系统需要和我们新系统的数据实现兼容，就是说，我们需要新系统能够完全兼容已有的 A 和 B 系统的客户数据。那么在这种情况下，基于关系型数据库设计的原理，我们在新系统的客户数据模型的设计的时候，就必须要考虑到 A 系统特有的属性“职务”和 B 系统特有的属性“职业”。所以在上面的模型设计的时候，我们必须给新系统的客户加上属性“职务”和“职业”。

考虑到在实际的项目建设过程中，我们经常会遇到这种情况，一方面我们希望我们的系统的数据模型能够兼容其它数据模型，另外一方面，兼容哪些系统的业务需求在系统设计之初可能无法确定。因此，我们在很多的系统设计文档里看到了“预留字段一”，“预留字段二”，“预留字段三”等属性。这些属性什么时候能用上，到底能不能满足业务的需求，很多时候，困扰着我们数据建模和系统设计人员，往往最终还是会导致在需求不能满足的情况下，重新进行数据模型的设计以及应用的调整。这种情况又是我们最不愿看到的一种情况。那么，在现有关系型架构的方法下，到底如何来解决这些系统整合过程的兼容性要求，如何能够更好的满足不确定的业务整合的要求呢？

DB2 V9和数据模型的应对方法

现有的数据建模的方法完全是基于关系型数据库的架构，因此，在考虑数据建模的过程中，我们主要采用范式建模法。通过关系型数据库的范式约定，来表现业务主体之间的基本关系，这种方法在规范业务流程的开发方面做出了巨大的贡献。但是随着业务的发展，现有关系型数据建模的范式约定从另外一个方面对业务主体做出了相当大的限制，现有的关系型的描述已经越来越不能满足灵活多变的业务发展的需求。

近10年来的 IT 应用开发技术已经得到了长足的发展，基本上完成了从 2 层架构到 3 层架构的转变，完成了面向过程到面向对象的转变，而我们的建模方法仍然被限制在了传统的关系型数据模型中。最近，IBM 新推出的 DB2 V9 第一次结合了 PureXML 的技术，突破了传统关系型的框架，结合了灵活的层次型 XML 存储的技术，使得我们的数据建模理念的扩展拥有了现实的基础。如下图 5 所示，目前 DB2 V9 结合了关系型数据库和 XML 两种数据存储的优点。

图 5. 混合数据库 DB2 V9

从上图中我们可以很清楚地看到，DB2 V9 数据库结合了关系型和层次型的存储方式，使得数据管理技术第一次突破了关系型数据库的理念，从而使得现有的数据建模技术突破关系型理论成为现实。除了 DB2 V9 推出 PureXML 技术之外，其他数据库厂商，例如 MS SQL 和 Oracle 等也纷纷推出了针对 XML 技术扩展的特性，也开始宣称支持 XML 存储和 Xquery 标准。

在这之前，一些建模工具，例如： ERWIN 和 Power-Designer 已经看到了数据建模中 XML 技术的巨大优势，在其工具中纷纷加入了 XML 数据建模的支持，从这些情况来看， XML 技术和数据建模的融合也代表了整个信息产业的发展方向。

下面我们将详细介绍结合XML技术扩展数据模型的方法。

XML（eXtensible Markup Language） 介绍

在介绍 XML 数据建模之前，我们首先来看一个具体的 XML 文件，如下图所示，这个 XML 文件描述的是关于书的一些信息：

图 6. 图书的 XML 文件描述示例

从上图我们可以看出，XML 本质上是一种语言，他的主要功能有：

• 存储数据
• Web 服务

Web 服务不是我们这里探讨的重点，我们这里着重讨论 XML 的数据存储的功能。从上面我们给出的案例来看，相对于关系型数据存储模式，通过 XML 存储数据有以下优势：

• XML 是标注型的数据格式，能够让业务人员非常容易理解。
• XML 层次型的数据格式，更能实际的反应出对象和业务的层次关系。
• XML 灵活的数据存储方式，更能反应业务的变化，能够存储相对更广泛的数据。

正是因为 XML 相对于关系型有上述的优势，因此，在数据建模的时候，我们完全可以结合 XML 来进行数据模型的设计，这样，能够保证我们的数据模型的扩展能力。

XML 技术提高数据模型的扩展能力

上面介绍了XML 相对于关系型的优势，在数据建模的过程中，我们采用XML的技术将极大的帮助我们提高数据模型的扩展能力，同时，帮助我们简化数据建模的复杂程度。在我们实际进行数据模型设计的时候，有两种使用XML的方式：

• 完全XML 化的数据模型设计
• 部分XML 化的数据模型设计

我们下面详细的介绍这两种数据模型的设计。

完全 XML 化的数据模型设计 图 7. 完全 XML 化的数据模型设计

我们仍然以上述的系统为例，在新系统的数据模型的设计过程中，我们完全可以设计一个纯 XML 的客户实体，如图 7 所示。

在上图中，我们完全以一个 XML 的方式来设计我们新系统的客户属性，在这里，由于 XML 特有的特点，我们可以给这个客户任意的添加属性，这样，就可以保证我们的数据模型无论是在响应新业务的变更时，还是在与其他系统进行整合时，都具有充分的伸缩性。

考虑到我们信息技术发展的现状，完全采用XML的方式来设计我们的数据模型同样会带来以下的一些问题：

• 完全XML化的数据模型设计虽然简化了很多数据模型的工作，但是要求开发人员必须熟悉 XML 的 Xquery 语言，而且完全抛弃掉已有的SQL规范，给现有的技术体系的延续性带来了一定的难度。
• 完全XML化的数据模型设计虽然节省了模型设计的工作，但是现有的一些开发工具可能还不能很好的支持XML的技术，因此，在某些时候需要手工的进行一些开发的工作，在这个意义上增加了一定的开发工作量。

部分 XML 化的数据模型设计 图 8. 部分 XML 化的数据模型

正是由于有上面的缺点，因此，我们在实际的生产过程中基本上采用关系模型和 XML模型相结合的方式来进行数据模型的设计，通过关系模型来延续现有的体系架构，而通过 XML 模型来帮助我们现有的数据模型的扩展能力。

如下图所示，我们在这里采用了部分 XML 的方式来设计我们的数据模型。

在上图中，我们新系统的客户表的主体仍然采用关系模型来设计。在这里，我们充分考虑到现有系统的延续性，在共有的部分，我们针对目前的业务分析，设计了客户主体的属性，包含了“号码”，“姓名”，“性别”，“地址”等部分，而对于每个系统独有的一些属性，在新的系统里并没有用到，而仅仅是为了兼容其他的系统，那我们就创建一个 XML 属性列，将这些属性统统放置在“扩展字段”这个属性列中。同样，对于未知的业务的变更，我们同样也可以根据业务的需要，随时对这个扩展字段的内容进行扩充。

采用部分 XML 化数据模型的设计，其实是兼容了关系模型和 XML 模型的优点，发挥了两者的长处，规避了两者的短处。可以概括成以下两点：

• 部分 XML 化数据模型的设计，完全延续了现有的关系模型的体系，兼容了现有的开发环境，使得开发人员能够很容易理解和执行。
• 部分 XML 化数据模型的设计，充分考虑了未来业务发展的需要，以及系统整合的需要，能够灵活的针对现有的数据模型进行数据的扩充。

正是因为部分 XML 化数据模型的设计同时兼顾了关系模型和 XML 模型的优点，因此，在目前的数据建模设计的方法中成为越来越流行的一种设计方法。

数据模型的扩展性设计样例

前面介绍的是一些抽象的方法，可能读者理解起来有一定的困难。下面，我们通过一个实际的应用案例，来为大家介绍一下怎样结合 XML 技术帮助我们的数据模型的设计工作。

系统的背景是这样的。某地需要建设一个用工备案系统，其主要目的是将每个企业的用工合同录入到系统中，以备政府能够详细地掌握每个城市的劳动用工情况。在这个系统中，核心的业务主体主要有三个，劳动者，单位，以及劳动用工备案信息。这个系统的难点在于：

• 业务需求可能随时发生变化：目前还不能准确地掌握所有的业务需求，每个城市可能有自己对劳动用工备案信息的特殊要求，因此，录入到系统中的指标可能不尽相同。
• 数据的兼容性问题：目前有些城市已经收集了一些相关的数据，并且按照自己的分类标准进行分类，在这个系统完成之后，需要完全兼容这些城市的数据。

如何针对这样一个业务系统进行数据建模，这是我们系统分析人员必须要解决的一个问题。这里，以劳动用工备案信息为例，按照传统的关系模型设计的方法，我们设计的劳动用工备案信息表如下所示：

图 9. 劳动用工备案信息表的关系模型

如上图所示，整个劳动用工备案信息包含了三张表，其中，劳动用工备案信息表记录的是每一个劳动者的当前状态的所用劳动用工备案信息，而副表中记录的是每一个劳动者的过往的所用劳动用工备案信息历史，扩充表中记录的是当前没有考虑到的，预留给将来业务变动，以及每个城市专门特有的一些指标，将来需要和各地进行数据兼容的字段也需要从这里预留一些相应的字段。

显然，细心的读者很快就发现了这种数据模型的设计存在的问题：

• 用户需求是有层次需求的，而我们的扩充表方式不能表达这种需求。采用关系模型的设计，我们只能把上一级政府的需求和各个城市的需求归结在一个层次的扩充表中，导致这个扩充表的字段可能会不可控。
• 需求的不确定性，而我们只能通过预留字段的方式来实现。由于我们不能明确的了解各地数据的分类情况，因此我们也不能准确地估计需要预留多少字段，因此，我们在设计的时候只能做一个大概的估计而已，而这一点，可能会成为一个潜在的问题。

那么，我们怎么解决这一系列挑战呢？我们采用了和XML技术结合的数据模型设计的方法，如下所示：

图 10. 结合 XML 的数据模型设计

如图中所示，我们采用了增加一个 XML 扩展字段的方式，通过 XML 字段内增加的相应不同的内容，就能够响应不同城市的特殊需求，同时，上一级政府的新需求也可以在这个字段内增加相应的指标。通过这种方式，可以非常容易的实现了数据模型对新业务的扩展的同时，保证整个数据模型的基本框架不变。

例如在本次数据模型设计中，没有考虑到退休返聘人员的用工信息情况，要想反映这个指标，我们只有在“地方扩展字段”中增加这一新的属性，如下图所示：

图 11. XML 扩展字段的方式

上图中，我们在劳动用工备案信息表中增加了一条记录，其主要描述的是一个在城市B中的退休返聘人员的劳动用工情况，且其竞业限制行业为保险业。在这条记录中，“退休返聘”和“竞业限制”这两个新属性是后面按照业务的要求扩充进来的，而对于用工的工资信息则是城市B的特有业务需求。从上面的操作我们可以看出，采用XML技术后的数据模型设计充分考虑到了不同层次的业务人员的不同需求，能够在同一个数据模型中同时得到满足，而这种设计思想是传统的关系型数据模型设计所难以企及的。

在完成记录的插入后，我们同样可以通过 SQL 和 Xquery 结合在一起的方式，针对这部分数据进行查询，如下图所示：

图 12. 结合 SQL 和 Xquery 进行查询

这是一个典型的 SQL 和 Xquery 结合在一起的一个查询，这个查询的意思是，查询 cstop 时间小于 2007 年 1 月 1 号的，工资大于 1000 并且小于等于 5000 的劳动用工备案信息情况。很显然，这个查询应该是城市B的操作人员发起的，原因很简单，只有城市 B 才需要记录用工信息的工资情况。这个查询中同时进行了关系型和 XML 型数据的检索，完美的融合了 SQL 和 Xquery 的标准，使得对数据的检索便得非常的简单。

在这里，我们注意到，对于不同的数据，不同的操作，基本的关系模型的框架没有发生变化，而发生变化的只是 XML 字段中的内容和格式而已。因此，对于我们的开发人员来说，整个开发的框架没有任何的改动，在业务发生变动的时候，我们只需要变化 XML 字段中的一些内容，而只需要调整相应的开发代码中的 SQL/Xquery 语句而已，对于应用的政体框架不需要任何的变动。而这正是我们进行数据模型设计所希望达到的效果。

通过这个案例，我们能够了解到同 XML 技术结合后的数据模型模型的优势如下：

• 能够同时满足不同层次的业务需求。通过 XML 得分层方式，实现不同层次业务需求的和谐共存。
• 能够更好的响应业务变化的需求。通过扩展的 XML 字段的方式，能够灵活的实现新增业务的需求而不影响整个应用的框架。
• 能够更好的实现不同数据之间的兼容性。通过扩展的 XML 字段的方式，能够兼容其他的系统的数据而不会同当前系统的架构发生冲突。

通过上述的一个实际的数据模型的案例，我们了解了XML技术具体怎样和数据模型结合在一起，怎样在应用设计阶段就能定义灵活的架构，怎样反映出灵活的业务需求等一系列问题，希望能够对读者有些帮助。

结束语

本文的最后，笔者需要提醒大家的是，任何一个新技术的出现都可能对当前的行业或者技术的发展带来深远的影响。我相信 DB2V9 的 XML 技术与现有的关系型数据库的结合，将会对当前的信息管理以及整个 IT 产业都将会产生巨大而深远的影响。

同样，XML 技术对于数据建模，应用设计开发以及整个系统的架构的影响是非常深远的，笔者在这里也只领略了一些皮毛而已。更多的，更深刻的应用还需要读者在实际的生产应用中，自己去体会和发掘。