用DB2 pureXML来有效的解决商业问题

　　本文主要是为使用DB2 pureXML来有效的解决商业问题与在企业应用程序中高性能的管理XML数据提供了原理与指南  。以下就是对DB2 pureXML来有效的解决商业问题与在企业应用程序中高性能的管理XML数据提供了原理与指南内容的具体描述  。

　　同时在样例中举例说明了有关基于真实世界金融应用场景的最佳实践，并示范了如果执行这个指南  。

　　这个例子可以很容易被应用于其它类型的XML应用程序  。下面是一些本文中的最佳实践的描述  。

　　XML 数据用于提高性能和存储有效性的存储选项

　　对 DB2 DMS 表空间启用自动存储  。

　　为 XML 数据使用更大的页大小，比如 16KB 或 32KB   。

　　如果性能分析需要，就为 XML 数据选择一个不同的表空间页大小  。

　　很多 XML 文档足够小并且能和其它 non-XML 数据存在数据页上，就为 XML 文档使用内 嵌存储  。否则文档存放在表之外，类似于 LOBs，并且通过区域索引来访问  。

　　使用压缩来减少 XML 文档以 inline 方式存放时的空间大小  。

　　在 DB2 数据库中添加 XML 数据的技术：

　　为了提高你在使用 insert、import 或 load 添加数据时的性能，

　　使用使用较大页大小的 DMS 表空间，比如 16KB 或 32KB   。

　　提供足够的缓冲池空间以支持 XML 区域索引和路径索引的读取  。

　　如果你有多个用户定义的 XML 索引，通常最好在添加数据之前定义它们  。

　　如果有必要，把行抽取选中的 XML 元素值放入到和 XML 文档相同的关系列中  。关系列 中存放的数据允许简单、SQL-only 的形式来访问重要的数据或经常访问数据条目、可以定义 主键、外键或其它约束、以及可以定义多列（组合键）关系索引  。

　　如果更小的片段更适合数据访问的粒度，就把大型 XML 文档分割成更小的片段  。

　　定义触发器来对插入和更新 XML 数据进行自动验证

　　有效查询并更新 XML 文档的技术：

　　使用 SQL/XML 函数 XMLTABLE 或 XMLQUERY 来从 XML 文档中抽取数据  。

　　在SQL WHERE 子句中使用 XMLEXISTE 谓词来指定对 XML 数据的谓词 ，通过检查更少的行来提高查询性能  。

　　使用一个完全指定的 XML 路径，而不要使用通配符 * 或 // 来定位到期望的 XML 元素   。这样做可以提供更好的性能，因为 DB2 可以跳过 XML 文档中不相关的部分直接找到期望的 XML 元素  。

　　出于增加商业洞察力和最大化一个混合数据库服务器的价值的需要，你在查询中需要要 对 XML 和关系数据进行连接  。

　　当在一个 XML 文档中更新多个元素时，把更新合并到一个转换描述中以获得最佳的更新 性能

　　在查询中声明名称空间，更新 XML 索引以匹配你的 XML 商业数据  。这个让你能从多个 或复杂的域中处理 XML 文档  。

　　为什么使用 XML

　　XML 提供了一个普通而具有弹性的方法来在不同的系统、应用程序和组织之间交换数据  。 使用 XML，数据是在一个可扩展自描述格式下进行维护，以提供给所有涉及的商业需求  。 XML 文档是用标签来描述它们包含的数据值，并且通过嵌套标签来表示数据条目间的层次关系  。

　　XML 可以描述高度结构化的数据并通过 XML 模式来保持结构，但是它也能描述半结构化的数 据，这些数据普遍存在于内容为导向的应用程序  。

　　以服务为导向的架构（SOA）、企业应用程序整合（EAI）、企业信息整合（EII）、Web 服 务、企业消息总线和很多依赖于 XML 作为底层数据交换技术的标准化成就  。

　　就像行业这样的机构使用标准化的 XML 模式来促进信息交换并且发展那些模式来满足变化 中的商业需求  。这些努力包括在保险行业中的 ACORD、金融行业中的 FpML 和 FIXML、供应 链管理中的 違規廣告、零售商业中的 ARTS、卫生保健中的 HL7、商业报告里的 XBRL 和在印 刷行业中用于授权、管理和发布文档的 DITA 以及整个网络  。

　　这类具体行业创新（比如管理需求）在驱动 XML 发展  。越来越多的企业事务通过基于网络 接口和电子表格来操作  。政府代理和商业企业对保留原始订单、请求、申明、交易或签名承担 更多的责任  。 XML 提供了一个简单的方法来抓取并维护和那些电子交易相关的数据  。事实上 ，XML 文档常常在基于消息的事务系统中表现事务记录  。

　　XML 和关系数据的优缺点

　　作为一个自描述数据格式，XML 允许不同的数据（有模式或没有）在不牺牲搜索或聚合能 力的情况下被同时存在一个文档中或某一行中  。应用程序可以在对底层数据库模式不进行任何 改变的情况下发展他们自己的 XML 模式  。然而，对于 XML 的这种扩展意味着比起存储在关系 表中的数据在检查和解释 XML 数据时会花费更多的 CPU 和 I/O 资源 – 这可能不切实际  。

　　对更多的刚性模式定义，关系模式需要更少的解释并允许更多的优化数据操作  。就像这样 ，他可以提供非常高的性能，不过却不能满足应用程序需要的模式弹性  。关系型数据模型非常 适合有稳定数据结构和可预知访问形式的应用程序  。 XML 更适合有复杂多变数据结构以及混 有结构化和非结构化信息的应用程序  。

　　在某些情况下，XML 提供的性能好处超过了关系模型正好是因为它的弹性  。关系型数据库 经常需要标准化来使商业数据适应简单平坦的结构  。对复杂商业数据的标准化需要在数据存取 的时候进行转化，并经常在关系型数据库中导致多路的连接需求  。

　　XML 可以在一个文档中更 自然的表现复杂的商业对象以及对象间的所有关系  。在一个 XML 文档中的层次本质上就是预 先计算的相关数据条目之间的连接  。

　　在选择一个数据模式时的另外一个考虑是应用程序使用数据  。就算数据源自 XML，如果数 据后来的处理取决于存储在表格中的数据—例如，在一个数据仓库中应用关系行在线分析处理 （OLAP）的数据—那么把这些数据存入关系格式而非 XML 可能是正确的选择  。

　　关系数据模式问题的 XML 解决方案

　　为了最大的可能范围，存储数据的模型应该和你数据的最高值和最关键的使用模式相匹配   。如果数据被模式化成为自然表格，比起 XML 这通常表现为关系型格式更好  。然而，有些情 况下关系型模式不是最好的选择而且有时用来存储数据甚至是很差的选择  。下面是用 XML 表 现比用关系型格式更好一些情况  。

　　当模式不稳定时

　　关系型数据的问题：如果数据模式经常改变，那么在关系表结果中表现的数据，更改关系 模式将产生成本和开销  。一些模式的表格更改在关系型数据库中是无痛的，比如在表中增加一 个新列、把模式的其它表加入进来，还有就是删除一列或更改一列的类型  。不过模式的其它表 要更改（比如把一个表正常化进多个表中）会非常困难  。首先要改变表然后应用程序需要改变 访问的 SQL 语句  。

　　XML 数据解决方案：模式中易变的那一部分可以作为一个单独的 XML 列存在  。 XML 天然 的自描述和易扩展功能可以无缝的处理模式变化和改进  。 XML 文档格式中的改变是在不需要 在数据库中更改表或者列并且通常不需要破坏现有 XML 查询  。

　　当数据是自然的层次时

　　关系型数据的相关问题：天然分层或递归数据在关系模式中常常很难表现  。例如包括原料 账单、工程对象或生物学数据  。一个原料清单可以存进一个关系型数据库，不过可能需要递归 SQL 来把它部分或全部重新构建  。

　　XML 数据解决方案：因为 XML 是一个层次型数据库模式，它可以非常自然的表现本身就是 层次型的商业数据  。如果相同数据表现为表格形式需要，使用 XML 可以用简单、导行的数据 访问来代替复杂的一系列操作  。

　　当数据表现商业对象时

　　关系型数据的问题：如果应用程序数据要表现商业对象，比如保险保单，它经常从保留有 数据条目和一个详细声明的组合中得到好处，而不是把它们分散到一系列表中  。这对一个保单 的那些本身没有有效商业含义并且只能在有上下文的完整表单中被解释的单独的数据条目来说 尤其如此  。

　　通过数十个关系型表来正常化这个保单意味著应用程序处理一个复杂的并且对于他 们的商业来说是不成体系的数据  。这增加了负载和出错的几率  。

　　XML 数据的解决方案：XML 让你可以表现非常复杂的商业对象比如紧密相关的文档以及截 然不同的文档同时还抓取所有组成商业对象的数据条目之间的关系  。以一个在表中单独一行里 的 XML 文档来表现每个保单（商业对象）为应用程序开发人员提供了非常直观的存储模型并 可以快速进行应用程序开发  。

　　当对象有稀疏的属性时

　　关系型数据的问题：某些程序有非常多的可能属性，它们大多数很稀疏，例如，可以适应 非常少的对象  。一类例子是一个产品编目，这里不同产品属性数目非常多，包括：大小、颜色 、重量、长度、高度、原料、款式、编织方法、伏特、决议、放水以及无止境的其它属性  。对 于任何产品，只和这些属性的子集相关  。

　　一个可能的关系型方法是存储这些数据时一个属性一 列，这意味着表中包含 NULL 值得单元占非常大的比例  。这是不期望的并且是低效率的  。对这 些稀疏数据的另一个不同的关系型方法是一个有 3 列的表，对每个产品 ID 存储了几对名字 / 值  。这意味着属性的名字不是列名不过是在 VARCHAR 列中的值  。这使得关系型数据不能精 确的估计可选约束和生成一个有效的查询计划  。要定义并执行一个约束同样非常困难，比如对 一个特定属性的唯一性约束  。

　　XML 数据解决方案：XML 的美妙之处就是元素和属性是可选的，例如，如果不需要应用一 个特定的产品他们完全可以省略  。无论是 NULL 值还是名称以及值都不需要  。 XML 模式可以 定义非常多的可选元素，却对所有对象只使用它们中的一部分  。在一个关系型表中每一行必须 有相同的列， XML 列中的 XML 文档每一行可以有不同的元素  。

　　同样，如果这个元素只有很小 的百分比，这个可选元素的 XML 索引可能非常小  。这对每一行都有严格输入的关系型索引的 一个很明显的优势  。

　　当数据需要交换时

　　关系数据的问题：如果你从关系表中导出一批记录并把它们发送到另外一个应用程序或组 织中，接收者不能在没有额外数据来描述这一列的情况下解释数据  。如果你的关系模式从你上 次发送数据开始已经改变的情况下，尤其如此  。

　　XML 数据解决方案：XML 是自描述数据  。 XML 标签是描述它们嵌套值的元数据  。

　　DB2 pureXML 超过其它存储选项的优势

　　因为 XML 已经日益变成企业运营的关键，XML 文档是一种资产共享、保持、搜索、保护和 更新并保持完全的事务一致性  。基于它的用途，XML 数据也可能需要与其它数据进行转换、审 计和整合  。为了达到这些要求，把 XML 数据在 DB2 数据库中存成自然层次格式，这有很多好 处，包括：

　　注意 XML 数据的内部结构  。这对在数据库中以字符或二进制大对象（CLIBs 或 BLOBs） 的形式来存储 XML 文档具有优势  。准确的说，你可以很容易使用 XQuery、XPath 和 SQL/XML 利用 XML 结构来查询 XML 数据，而且你可以通过对 XML 数据创建索引来提高查询性能  。另 外，你可以很容易的使用 SQL、XQuery 和 XSLT 来更新、转换并发布 XML 数据  。

　　维护 XML 数据的层次和灵活的性质  。这在分解（切割）XML 文档到关系型表中，在这里 管理员映射 XML 元素和属性到关系列中  。在分解后，XML 文档之被存储在这些表中并且没有 最初的标签  。分解常常需要大量的表，而且实际使用中非常复杂  。查询分解后的 XML 文档可 能需要复杂的 SQL 连接，这很难开发和调试  。

　　改变 XML 模式常常会破坏对关系数据库模式的 映射  。这会使维护变得昂贵和耗时，并违背了出于灵活性而选择 XML 的初衷  。这也是为什么 DB2 pureXML 允许你适应一个 XML 列来存储和查询基于不同 XML 模式的 XML 文档，或一个 XML 模式的不同版本  。

　　在一个数据库中整合 XML 文档和关系数据  。这比在两个数据库中分别存储关系数据和 XML 文档 -XML-only 数据库更有优势  。后者需要技巧和人力来操作并维护两个数据库系统而 不仅仅是一个  。同样，从两个数据库中联合数据，通常需要应用程序有额外的逻辑，而这常常 很困难且效率低  。

　　当你在一个 DB2 数据库中同时存储 XML 和关系数据时，可以在查询中联合 两种类型的数据，甚至可以根据需要把一种转数据换成另外一种  。这样做更加划算而且比起使 用两个不同的数据库，它提供了更好的性能  。

　　DB2 pureXML 的最佳实践：概述

　　DB2 pureXML 功能提供了在存储、索引、验证和查询 XML 数据上成熟的能力 – 并完全整 合了 DB2 关系型数据管理功能  。本文描述了以有效并高效的方式使用 pureXML 的原则  。本文 的目标不是介绍 pureXML 功能或者它们如何工作  。相反本文提供了保证高性能 pureXML 的指 南，也示范了如何开发 pureXML 功能来有效的解决特定的商业问题  。

　　我们使用一个现实世界的应用程序场景来安排最佳实践和本文中的例子  。这是来自金融行 业的场景而且是基于 XML 格式的叫做 FpML（金融产品标记语言）的“金融衍生交易”的交易 和管理  。你不需要一个金融专家来理解这个场景  。虽然我们只使用这个特定的场景，最佳实践 同样应用到其它 XML 使用情况，比如 XML 表格处理、订单管理系统、XML 在健康保健和电子 病历，和其它情况

　　本文的主题是根据数据库对象的生命周期粗略组织的  。我们这个章节从查看应用程序需要 的数据和表开始  。然后我们讨论 DB2 对 XML 数据（第 4 章）的存储选项  。之后 , 第 5 章 提供了添加 XML 数据到 DB2 数据库的窍门和技巧  。在第 6 章我们提供了更有效查询 XML 数 据的指南和例子  。

　　为了提高查询性能，定义和使用 XML 索引的最佳实践在第 7 章中进行了介 绍  。 XML 名称空间和 XML 更新在第 8 章和第 9 章中分别有所讨论  。第 10 章和 11 章涵盖 了对数据库管理员（DBAs）以及应用程序开发的附加的主题  。最后，12 章以总结最重要的指 南作为结束  。

　　简单场景：FpML 形式中的金融衍生交易

　　一个“金融衍生交易”是一个基于（起源于）其它一些金融资产的金融交易，比如股票、 指数、利率、流通、或其它的  。在一个金融衍生交易中，根据影响底层资产的市场条件，当事 人双方同意交易现金  。通常情况下，一方利用交易以减轻风险；另外一方利用这个交易来获得 立即的收入（通过费用或额外费用）或对未来市场情况将提供收益进行投机  。让我们看一个例 子：

　　YourWord Investments 和 MyGlobal Back 达成了一个外汇兑换交易  。他们商议在 10 月 25 号 YourWord 将支付 71,900,000 人民币给 MyGlobal，并且 MyGlobal 将支付 10,000,000 美元给 YourWorld   。如果 1 美元兑换人民币从现在到 10 月 25 日其间低于 7.19，MyGlobal 将从这次交易中获利 .MyGlobal 可能会使用这个交易来避免美元下降的风险   。 YourWorld 可以投机美元将增值，或从 MyGlobal 收取进行交易的前期费用  。

　　衍生交易的奇妙之处是（a）有很多不同的类型和变化，（b）一个特定交易的状态往往需 要单独谈判而且很复杂，（c）一个衍生交易的生命周期可以是从几天到数年的范围而且它们 的条件可以随时间而改变  。金融企业发现在定义一个可以捕捉到衍生交易高度变化标准的数据 格式时需要 XML 的灵活性和可扩展性  。结果就是，他们开发了 FpML   。

　　FpML 本质上是定义 了 XML 元素和属性如何用来描述金融衍生交易的一个 XML 模式  。 International Swaps and Derivatives Association, Inc (ISDA) 代表一个投资银行组织管理 FpML 标准使市场在场外 进行衍生交易  。更多金融衍生交易和 FpML 的信息参考，以上的相关内容就是对DB2 pureXML管理XML数据实践应用实例分析的介绍，望你能有所收获  。