转自ibm官网

信息系统交付使用之初，数据库表结构的设计往往逻辑结构清晰，管理使用方便，但是当信息系统项目运行一段时间，随着业务的不断变化和增加，处理流程不断的变革，信息系统需要从前台界面到后台数据库的完善和修改，势必要对数据库表结构必须要进行扩展。我们通常的数据库扩展往往采用增加备用字段、扩展字段的内涵、增加主从表和管理表的方式，这种数据库表结构的扩展往往会带来营运的中断和操作的风险，本文通过分析常见的数据库库表结构的扩展方法中的不足，提出了几种基于 pureXML 方式的数据库表结构的扩展模式，可以成功的结束数据库扩展的技术难题。

概述

信息系统的建设往往遵循业务调研、需求分析、再进入到数据库和软件的概要设计、详细设计、代码编写等等阶段，在这个过程中数据库设计者往往根据已有的业务调研、需求分析的成果进行数据库表结构的设计，这时的数据库的设计者是通盘考虑，全局谋划所设计的数据库结构，整个库表结构逻辑清晰，管理方便并且符合 3NF 的要求。信息系统项目运行一段时间，随着业务的不断变化和增加，处理流程不断的变革，这种业务需求的驱动下，我们的软件体系也需要不断的修改和完善，这种修改和完善不仅是界面的调整和模块的增加，而且必须对数据库表结构进行必要的调整和修改。

这种项目维护期间的数据库调整和扩展，必须对数据库设计文档进行修改，对数据字典进行调整，理想的情况是文档齐备、资料完整，但实际工作中，由于设计和开发人员的责任心和对文档的轻视，每次对数据库表结构的调整都会造成数据库库表结构混乱，为今后的工作带来系统管理、维护和软件的再次修改和调整带来隐患；其次，数据库的扩展和调整中，对数据库设计者要求很高，很容易导致数据库设计中范式设计的隐患，进而造成数据库性能的急剧下降；最值得注意的是，由于数据库存储有大量的业务数据库，每次对数据库字段的修改和调整必须停机操作，从而带来运营的中断和操作的风险。特别是对于上线运行的核心业务系统，和若干 7×24 小时的业务系统，每次的数据库停机操作对营运的影响非常的巨大，而且还可能引来不良的社会影响。

为了对数据库进行有效的扩展，实际工作中往往采用预留备用字段、字段内涵扩展、增加从表扩展和增加关联表的方式进行扩展，这种扩展往往存在若干的问题：

设计之初预留备用字段带来的不足

为了减少对今后对数据库表中的字段调整，某些设计者在设计之初，根据经验对若干可能扩展的表中预留部分备用字段。预留备用字段的方式在某些程度上可以增加扩展的灵活性，但是确存在如下隐患：

预留字段的数量无法预测 , 预留 N 个还是预留 N+1，由于无法预知需要预留的数量造成扩展的不确定性；

预留字段的类型无法预测，预留字符型还是数值，无法去预测和评估；

常见在预留的扩展字段中，这些预留的扩展字段往往会破坏数据库最基本的范式要求，数据库的范式的最基本要求就是原子性和唯一性，而扩展的字段本身的定义是不明确的，这是不未确定的，也就是非原子的和非唯一的。

表结构的字段数据量不扩展，扩展若干字段的内涵

数据库的调整会带来运营的风险，部分数据库设计者为了应付数据库存储的需要，不对数据库表结构的字段的数量进行增加，而是非常“聪明”的将某个字段的内涵进行扩展，使得某些字段中同时存入 2+ 以上含义，由程序分析存入该字段的值的属性和内容。例如：某字段原定义为 VARCHAR(4)，如果存储字母开头的值，如 A001 表示意思 XX；存储数值开头的值，如 1000 表示意思 YY；还有一种方式就是采用间隔符，对字段进行扩展，例如 A001+1000 等形式。我们的数据库设计中，数据库表中的每一个字段都是单一属性，是不可再分的、原子性的，这个是数据库设计的第一范式理论，任何的数据库设计都应该遵守第一范式。这种设计不仅违反的数据库设计的第一范式理论，而且造成读取数据时需要程序进行“解码”后才能进行查询、统计等等，使得数据库的整体性能大大降低。

增加从表，但又不能确定从表的数量

当对库表进行扩展时，往往遇到存在 1:N 的情况时，这时必须增加从表来应对数据库的扩展，但是由于每次增加数据库从表时，无法预测需要增加多少个从表，每次增加从表都会造成数据库的修改和调整。

增加关联，但关联表的字段无法预测

由于业务逻辑的改变，如果发现原表 T1,T2 存在 N:M 的关系时，必须增加关联表，但是关联表的字段数量又无法预测 , 每次对关联表的调整又会造成对数据库的影响。

通过对数据库表结构中经常采用表和字段扩展的方式进行分析，我们都会发现对数据库的修改，往往会造成诸多的不便，而且值得注意的是每次修改数据库往往是业务需要非常紧迫，考虑到之前确保之前程序的稳定性和可靠性，此时又不能对原有的数据库进行调整和重组，DBA 往往只能进行部分数据库表结构的字段，往往最终导致数据库表结构混乱，以及管理维护的失控。

数据库表结构扩展原则

要做好数据库的调整工作，为了减少对原系统的影响和历史数据的存储，我们在调整中往往按照以下三条原则来进行数据库的调整：

对修改的关闭，对扩展的开放。原有的表结构中各字段都含有数据信息，不能对原有字段的删除修改。如果删除这些字段往往造成数据丢失，特别是对于某些关联表的数据库操作更是风险极大；

对表结构的修改最关键是减少对运营的影响。数据库的调整，每次都需要备份数据，中断业务系统，中断业务系统会造成生产经营的巨大损失和不良的社会影响，所以对数据库的调整必须采取措施减少对生产系统和运营系统的影响；

表结构很少重组结构，而只是增减字段。表结构的扩展是基于已有系统的运行，考虑到已有系统的稳定运行，我们很少去重构重组原表结构，只是增加和扩展表中的字段和数据库表。

DB2 v9 的 pureXML 的技术特点

考虑到参加的表和字段扩展中遇到的问题和数据库表结构调整的几个基本原则，我们认为 pureXML 能够帮助我们较好的解决这个问题。DB2 v9 中的 pureXML 技术第一次真正意义上提供了一种与 XML 层次型结构相匹配的层次型存储方式和相对应的操作访问方式．在 pureXML 中，XML 作为一种新的数据类型。几乎每个 DB2 组件、工具和实用程序都已得到增强，以识别和处理这种新数据类型。新的存储模式以解析后的注释树形式（类似于 XML 文档对象模型 (DOM)）保留 XML，它与关系数据存储分开。

图 1. DB2 的新 XML 关系存储模型

在两种数据存储（关系和 XML）的顶部的数据库引擎可以处理 XQuery、Xpath、SQL 和 SQL/XML。该引擎采用带有 SQL 和 XQuery 解析程序的双语查询编译器。因此开发人员可以根据具体情况更适用的原则使用 SQL 或 XQuery 任何一种语言（或同时使用这两种语言），支持事务级的 XML 操作。

基于 PureXML 技术的数据库表格的扩展模式

为了应对数据库的表结构的扩展，我们可以利用 XML 具有自我描述和层次行等特性，可以非常方便的存储各种类型的数据库。针对不同的数据库表结构的扩展，提出字段模式的扩展、从表模式的扩展和主从陌生的扩展，可以方便的应对各种类型的库表结构的调整。

对于需要对表结构进行增加字段的扩展需要，只需要对 XML 的列进行扩展就可完成数据库的扩展。

方法：左表需要增加多个字段，右表只需要对 XML 字段进行扩展；

优点：适应于对数据库字段的扩展，由于基于 XML 的字段，字段数量扩展没有限制，字段类型没有限制，且修改时无需停机处理；

适用范围：适合于只对主键有唯一依赖关系的属性

主从模式的扩展

图 3. 主从扩展模式介绍图

对需要对增加从表来对主表进行扩展的模式，也只需对列末的 XML 类型进行扩展，扩展的从表全部由 XML 来存储。

方法：左边需要增加多个外键和从表；右边只需要对 XML 字段按照从表结构进行扩展

优点：适应于对从表的扩展，由于基于 XML 的字段，从数量扩展没有限制，而且从表中字段类型没有限制。

适用范围：适合于需要增加从表的扩展。

关联模式的扩展

图 4. 关联扩展模式介绍图

图 2. 字段扩展模式介绍图

字段模式的扩展