在OracleXMLDBg中管理复杂的XML数据

《在OracleXMLDBg中管理复杂的XML数据》由会员分享，可在线阅读，更多相关《在OracleXMLDBg中管理复杂的XML数据（14页珍藏版）》请在金锄头文库上搜索。

1、在在 OracleOracle XMLXML DBDB 1111g g 中管理复杂的中管理复杂的 XMLXML 数据数据作者：V.J. Jain 了解如何使用了解如何使用 OracleOracle XMLXML DBDB 1111g g 管理复杂的管理复杂的 XMLXML，包括如何联机更改模式，包括如何联机更改模式 2007 年 12 月发布 在过去几年里，XML 已经成为数据传输的新标准,随着企业不断采用基于 XML 的解决方案，其应用也越来越普遍。随着更多组织对所有数据传输执行 XML 标 准，日益复杂的 XML 格式不断出现。这些复杂的格式可以包括多个命名空间、 数千个元素和递归定义。随

2、着这些格式所生成的 XML 文档的大小和复杂性的不 断增加，管理这些内容变得越来越具有挑战性，而有关应对这些挑战的信息却 极为有限。 在本文中，您将了解如何使用 Oracle 数据库 11g 中的 XML DB 特性管理复杂 的 XML 内容，以及与商用 ETL 产品相比它所具有的优势。您将看到一个用于 演示下述内容的复杂 XML 模式的示例：注册复杂的 XML 模式 将 XML 文件插入到数据库中 通过关系查询检索 XML 数据 XML 模式修改的原地演变 此外，您还可以大致了解使得 Oracle XML DB 解决方案的性能和吞吐量最大化的策略以 及复杂 XML 格式的实际应用。 Orac

3、leOracle XMLXML DBDB 的背景的背景Oracle XML DB 是 Oracle 数据库的一个特性，它提供了一个用于管理 XML 内 容的强大工具，包括存储、操作和检索。它提供不同的存储选项，以满足不同 XML 格式的独特要求。这些选项包括非结构化、二进制和结构化存储： 非结构化（字符大对象，即非结构化（字符大对象，即 CLOB） 。通过将文档作为一个大对象并将其插入到数 据库中，此方法可获得最佳插入次数。然而，对于数据的关系访问而言，此存储方 法消耗的空间最大且性能最差。如果需要采用关系访问，这不是一个管理大型复杂 XML 文档的实用解决方案。如果磁盘空间不是问题且目标以文

4、档的原始格式对其 进行存储，非结构化存储是一个实用的解决方案。 二进制存储。二进制存储。 这是 Oracle 数据库 11g 中的一个新增选项，以专门针对 XML 数 据设计的分析后的二进制格式来存储数据。该选项与非结构化存储相比有许多优势，它可以感知 XML 模式，从而可以获得更高的磁盘空间效率和查询性能。尽管该 选项可以提供非结构化存储无法比拟的性能，但它的查询性能却逊色于结构化存储。 只要可以接受二进制存储在关系访问时的性能，它就是一个很好的选项。由于该存 储选项易于使用，因此在选择结构化存储前值得对其进行评价。 结构化存储。结构化存储。 也称作基于模式的存储，该选项使用对象关系模型在数

5、据库中存储 XML 文档。此存储选项在磁盘空间和关系访问方面效率最高。它在文件插入时的 开销也是最高的，要求为模式注册进行额外的准备。在要求最佳关系访问时，结构 化存储是最佳选项。在处理复杂的大文件并要求高效的关系访问时，该存储选项通 常是最好的选择。 不同组织对 XML 文档的大小和复杂性的看法可能迥然不同。一方面，对于使用 XML 进 行电子数据交换 (EDI) 或其他事务数据交换的联机事务处理 (OLTP) 数据库而言，具有有 数千行的文件会被视为一个非常大的文件。另一方面，一个多 TB 的数据仓库可能经常处 理以 GB 计的 XML 文档，因此只将包含数百万行的文件看作大文件。对于 X

6、ML 文档 复杂性的看法，这一概念同样适用。 就本文而言，具有以下属性的文档被看作是一个“复杂”文档：具有单根节点和多个命名空间的文档。 具有灵活的 XML 定义、在维持有效性的同时允许较大变化的文档。 具有递归或循环引用的文档。 具有非静态 XML 模式的文档。 在本文中，如果 XML 文档是单根节点且大于 20MB，就被看作“大型文档”。这些属性介 绍了一个强健的企业解决方案所必须解决的可伸缩性和管理问题。 在最佳存储选项的选择上，没有什么金科玉律。最佳选项将随文件结构、性能 目标、可用资源和预期数据量的变化而变化。如果您无法确定哪个存储选项最 符合您的特定需求，不妨试试不同的格式再确定最

7、符合您特定需求的最佳选项。 一般而言，如果您要处理大型文档并且需要进行关系访问，非结构化存储从性 能或资源角度是不可接受的。如果查询性能可以为业务使用所接受或者业务需 要维护时间最短的选项，二进制 XML 可能是最佳解决方案。然而，如果关系访 问是主要目标，并且用户需要快速访问 XML 文档中包含的任何数据，结构化存 储最有可能是最佳选项。 使用结构化存储使吞吐量达到最大使用结构化存储使吞吐量达到最大虽然使用结构化存储选项时存在因插入文件所导致的开销成本，但是您可以通 过将大文档分解成多个小文档来减少这一开销。例如，如果有一个 700MB 的单 根节点的 XML 文件，可以将它分解为 10 个

8、 XML 模式有效的小文件。插入 10 个不同的 70MB 文件要比插入一个 700MB 的文件快得多，但最终结果相同。并 发级别应由数据库的可用处理能力决定。该策略利用了数据库并发性，并且使 吞吐量达到最大。 使用 Oracle XML DB 时的另一个考虑事项是，单个 XML 文件的插入时间通常 受单个 CPU 速度的限制。换言之，拥有多个处理器对于单个文档的吞吐量没什 么帮助。例如，考虑这一情况，一个复杂的、单根节点的 700MB 文档需要使用 基于模式的存储进行插入。使用 1.35GHz 的处理器时，无论数据库有 12 个还 是 72 个 CPU （假定任何情形下至少有一个 CPU 可

9、用），插入该文件所用的 总时间可能是 10 分钟。要提高单个 XML 文档的吞吐量，您可能需要使用更快 的 CPU。使用 3.4GHz 的处理器时，插入同一个文件可能需要 4 分钟。相反地， 当您处理多个 XML 文件时，拥有多个处理器可以提高插入的并发性，从而可以 更大幅度地提高吞吐量。例如，将 700MB 的文件被分解为 10 个不同的 70MB 文档时，如果您使用具有 1.35GHz 处理器的数据库，每个 70MB 文档的插入时 间可能小于一分钟。如果这些 CPU 都可用，这 10 个文档可以并发插入到数据 库中。采用此策略，插入整个 700MB 文档总耗时约一分钟。 不幸的是，计算这些

10、比较不是一门真正的科学。每个数据库的性能可能都不同， 这取决于若干因素，包括操作系统、可用的处理能力、内存和模式定义。在您 的环境中进行性能优化的最佳方法是实施这些策略并确定它们各自的优势。OracleOracle XMLXML DBDB 与商用现成与商用现成 (COTS)(COTS) ETLETL 产品的比较产品的比较一些商用的提取、转换和加载 (ETL) 工具可用于将文件中的数据加载到数据库 中。这些工具的特色是通常有一个具有拖放功能的简单前端，可以隐藏实际过 程的复杂性。当您在商用 ETL 工具中创建 XML 加载进程时，需要定义要提取 的域。如果未指定特定的 XPath，将无法从文档中

11、收集数据。In the case of complex XML documents, the advantage of Oracle XML DB is that it takes a database-centric view of documents and shreds each document into an object-relational model.将文件成功插入数据库后，该文件中包含 的所有数据都可供访问，而无需重新进行分析。Oracle XML DB 最大的优势之一在于它是 Oracle 数据库的一个标准特性，无 需额外的许可。但如果某个组织并不在意许可费用，它为什么要使

12、用 Oracle XML DB 进行 XML 内容管理，而不采用以 ETL 为重点的公司的工具呢？要了解 答案，有必要了解 Oracle XML DB 技术是如何满足管理非常复杂的 XML 的独 特要求的。 复杂复杂 XMLXML 内容所带来的挑战内容所带来的挑战当 XML 的内容灵活、经常变化、递归并且非常庞大时，开发人员无疑将遇到简 单格式情况下不存在的某些挑战。复杂 XML 文档的一种可能情况是，它的 XML 模式可能非常庞大，并且在保持有效的同时允许极大的灵活性。使用灵活的 XML 模式是一种常见策略，旨在满足公司具体要求的同时支持整个业界的标准。例如，考虑一个被三家公司作为标准采用的

13、 XML 模式。除了共享元素或标准元 素之外，此 XML 模式还需要包括各家公司的所有特定于公司的定义。为满足这 一要求，此 XML 模式的设计借助通用容器元素获得了极大的灵活性，这些通用 容器元素引用所有可能的公司特定元素，并且允许大多数的元素引用发生零次 或多次。因此，元素完全不同的文档对于相同的 XML 模式都有效。从开发的角 度来看，这种灵活性使得编写用于提取所需数据的 XML 分析器变得困难，这是 因为元素的出现难以预测。由于 COTS ETL 工具和自定义分析器需要特定的 XPath 来提取数据，因此需要检查每个可能的 XPath 以确保捕获文档中所有的 数据。这是一个不切实际的解

14、决方案，因为可能 XPath 的数目惊人。而且，如 果模式中存在递归或循环引用，XPath 的数目将是个无限值。如果检测到未捕 获的数据，唯一的解决方案是重新分析整个文件，这是一个代价高昂的操作， 应尽可能避免。 考虑下面的 XML 模式（注意因通用元素所产生的循环引用和灵活性）：startData.xsdxmlns=“http:/www.w3.org/2001/XMLSchema“ xmlns:xdb=“http:/ targetNamespace=“startData.xsd“ elementFormDefault=“qualified“ attributeFormDefault=“unq

15、ualified“standardData.xsdCompanySpecific.1.0.xsd该 XML 模式可用作传输销售和库存数据的行业标准。注意，在 standardData.xsd 命名空间中，childContainer 元素和 companySpecificContainer 元素是可选的自引用。在这个特定的定义中，该设 计使各个公司能够使用父/子关系决定数据的粒度。该模式还允许每个公司选择 库存数据和/或销售数据。它还进一步允许每个公司包括零个或多个店铺、产品 和销售，这一切都取决于各自的需求但要符合相同的灵活格式。 例如，如果一家假想的公司 ABC 希望包括多家店面的库存和销

16、售数据，它可以 使用 CompanySpecificContainer 元素集合来标识各家店面（父），使用 CompanySpecificContainer 元素集合来标识各家店面的产品（子）。ABC 的一 个有效文档可以是CompanyABC.xmlStore 0001 InventoryStockcsStoreCompanySpecific.1.0Store 0001Product 1In StockcsProductCompanySpecific.1.0Product 1Quantity10Store 00011234520-SEP-2007Product 11110.00然而，如果另一家公司 XYZ 只有一个店面并且选择在文件中只包含标准的销售 数据，它可以省略 childContainer 元素，只包括 salesInformation 元素集 合。XYZ 公司仅描述标准销售数据的一个有效文档可能如下所示： Company