从文本分析到数据仓库

文档选项 未显示需要 JavaScript 的文档选项 讨论 样例代码 英文原文

级别： 中级

Matthias Nicola, DB2/XML 性能负责人, IBM 硅谷实验室
Martin Sommerlandt (msommer@us.ibm.com), DB2 pureXML, IBM
Kathy Zeidenstein (krzeide@us.ibm.com), IBM Content Discovery, IBM

2008 年 7 月 15 日

文本分析使您可以从非结构化数据，例如电子邮件、客户关系管理（CRM）记录、办公文档或任何基于文本的数据中提取更多的商业价值。IBM® OmniFind™ Analytics Edition 提供了丰富的文本分析功能和交互式可视化，以帮助您发现大量非结构化信息中隐藏的模式和趋势。OmniFind Analytics Edition 的文本分析结果是 XML 格式的，这种格式也可以在 DB2 数据库中存储、索引和查询。这使您可以通过使用常规的 SQL 或 SQL/XML 查询，将文本分析结果并入到已有的业务应用程序和报告工具中。本文概述了使用 OmniFind Analytics Edition 进行的文本分析，并描述将其分析结果以关系格式或 pureXML 格式引入到 DB2 的一些方法。

文本分析概述

对于那些不熟悉文本分析的人来说，有必要对文本分析这种技术以及可通过应用文本分析而受益的一些通常的用例作一个简要的概述。如果想了解关于文本分析，尤其是 Unstructured Information Management Architecture （UIMA）中的文本分析的更深入讨论，developerWorks 和 Apache.org 上有一些更详细的文章（参见 参考资料 小节）。

文本分析是指使计算机能够从文本中提取意义的过程。文本分析常被实现为一系列的重复过程，其范围从简单的语言检测、解析和标记，一直到能识别文本所表达的感情等更复杂的过程。UIMA 为这些不同的过程提供一个标准化的输入和输出格式，以支持不同组合的、来自不同供应商的模块的即插即用特性。

文本分析的输出由原始文本和关于文本的附加元数据组成。有很多不同的应用程序可以使用增强的元数据，包括商业智能应用程序、搜索应用程序、企业内容管理系统和文本挖掘应用程序（见 图 1）。

OmniFind Analytics Edition 概述

OmniFind Analytics Edition 提供交互式地探索和挖掘文本分析结果以及通常与非结构化文本相关联的结构化数据的功能。如果熟悉商业智能应用程序，您可以将它看作以内容为中心（content-centric）的商业智能，它聚合文本分析的结果，以检测频率、相关性和趋势。通常的用例包括：

• 分析客户联系信息（电子邮件、聊天、problem ticket、联系中心记录），以洞察质量或满意度问题。
• 分析博客和 wiki，以了解企业声誉。
• 分析内部电子邮件，以检查是否违反遵从性或查找专家。

架构

图 2 是整个系统中内容和数据流的一个概要图。首先，原始的文本数据必须是 OmniFind Analytics Edition 能够理解的格式，即一种被称作 Analysis Text Markup Language（ATML）的 XML 格式。OmniFind Analytics Edition 可以自动将使用逗号分隔的文件（.csv）转换成 ATML。

如 图 2 所示，文档中既有结构化部分，也有非结构化部分。您必须指定要在哪些文本字段上运行文本分析（自然语言处理）。

在对文本进行自然语言处理时，会应用规则和字典。虽然默认的类别、规则和字典是可以立即使用的，但是也可以对它们进行定制，以识别更特定于所分析领域的信息。自然语言处理的输出是另一个被称作 Mining Markup Language（MIML）的 XML 文件格式，如 图 3 所示。

注意：通过使用 OmniFind Enterprise Edition 搜寻内容，并对 OmniFind Enterprise Edition 的 UIMA 管道中搜寻的内容运行 OmniFind Analytics Edition 文本分析，可以完全省略 ATML 步骤。这种分析的输出是一个 MIML 文件。

按照通常的流程，首先将 MIML 作为输入提供给索引构建步骤，创建一个文本索引。这种索引的设计目的是为了让用户在与挖掘（mining）接口交互时，能够非常高速地检索与聚合、关联有关的请求。MIML 文件可以在 OmniFind Analytics Edition 安装目录的文件系统中找到，其位置为 <OAE_INSTALL_DIR>/databases/<database name>/db/miml/。在下一节中，您将学习更多关于 MIML 文件的知识。

挖掘模块 是允许用户研究索引以及发现模式和关系的一个接口。用户可以使用熟悉的搜索范例，包括关键词/语义搜索和分面导航来探索信息，可以以多种不同的方式查看这些信息，例如出现频率 top-n、时间序列和 2D 相关性热图（correlation heat map）。当用户钻取信息时，在任何时候都可以直接查看一个包含文档原始文本的视图。

对于定制环境，还可以以 Java API 的形式使用挖掘接口。

使用文本分析扩展业务报告

如前所述，典型的 流程是为分析结果（MIML）构建索引，以便用户可以使用交互式界面交互式地专研内容。但是，有些用例需要使用关键的文本特性扩展已有的企业绩效报告。例如，医疗支付者可能使用挖掘接口来发现护士通过与病人通话记下的特定疾病或症状。他们可能想在数据仓库中探索有关信息，在那里他们可以将信息与已有的关于费用或死亡率的结构化数据链接起来，并做出关于这种关系的常规报告，作为一个关键的绩效指示符。

本文描述将文本分析的结果，即 MIML 文件集成到关系模式中，以供常规的业务报告工具（例如 Cognos）使用的一些选项。

回页首

MIML 文件剖析

MIML 文件是一种格式良好的 XML 文档，其根元素是 <miml>，如 图 4 所示。在该文档的第二级，可以找到很多 <doc> 元素，这些元素是根元素的子元素。每个 <doc> 元素包含对一个特定输入文档，例如电子邮件、problem ticket、CRM 记录或其他纯文本文档进行的自然语言处理的输出。由于您经常要分析很多这样的文档，所以 MIML 文件通常有很多个 <doc> 元素。

如 图 4 所示，每个文档以一个 ID 号、一个标题、原始的文档内容（“input”）和以下三组特性表示：

• 标准特性（standard feature）
• 关键词特性（keyword feature）
• textlist 特性（textlist feature）

标准特性 表示每个文档中通用的结构化信息，例如日期、来源、主题或国家。对于所有此类数据项，都有一个 <kw> 元素。<kw> 元素的 val 属性包含实际的值，cat 属性包含它的类别，例如 “date” 或 “country”。

关键词特性 描述非结构化文本内容中出现的单词和短语。对于每个不同的单词或短语，有一个 <kw> 元素，每个这样的元素有一个值和一个类别，例如 “general noun”、“proper noun”、“verb” 或 “phrase”。对于这个单词的每一次出现，有一个单独的 <occ> 元素，该元素包含出现 ID 和它在原始文本中的起始位置。

textlist 特性 包含信息性数据在文档内容中的位置。

回页首

处理 DB2 中的 MIML 数据

由于 MIML 文件是格式良好的 XML 文档，因此可以使用 DB2 中的 pureXML 功能来处理 MIML 数据，以便做出报告并与已有关系数据集成。做这项工作的两种主要方法是分解（shredding）（到关系表）和存储（storing）（XML 形式）。

通过将 MIML 数据分解到一个关系目标模式中，可以充分利用 SQL 查询和商业智能工具分析数据。DB2 提供了两种将 MIML 数据分解到关系表的方法：

• 第一种方法被称作 “带注释的模式分解”，也称 “XML 分解”。按照这种方法，需要将注释添加到 XML 模式中，以定义 XML 元素和属性值如何映射到一个或多个表中的关系列上。下面您将看到，IBM Data Studio 为可视化地定义这种映射提供了方便的 GUI 支持。
• DB2 中的第二种分解方法是使用 SQL/XML 函数 XMLTABLE，该函数通常以 XML 数据作为输入，并产生关系输出格式的元素和属性值。除了本文中的例子外，请参阅 参考资料 小节，其中提供了更详细地描述这些 DB2 pureXML 特性的其他 developerWorks 文章。

作为分解方法的另一种备选方法是将 MIML 数据存储在 DB2 表中的 XML 类型的列中，并为之建立索引。这样做虽然可以避免从 XML 到关系格式的转换，但是需要通过 SQL/XML 或 XQuery 来查询数据。本文将讨论这两种方法的优缺点。

MIML 的关系模式选项

XML 分解需要一个关系目标模式。可以以多种不同的方式定义一组关系表，以便用关系格式表示 MIML 数据。在分解性能、查询性能以及报告和分析的容易程度等方面，每种方式都有不同的优点和缺点。本节讨论三种不同的关系模式。

选项 1：简单的 4 表模式
第一种关系模式是对 MIML 数据的非常简单的关系表示（图 5）。这有一点像反范式（de-normalized），允许使用 XMLTABLE 函数或带注释的模式非常容易而有效地进行分解。

DOCUMENT 表包含每个文档的基本信息：文档 ID、标题和文档内容（“input”）。记住，一个 MIML 文档包含以下部分：

• 带有标准关键词的标准特性
• 描述关键词出现情况的关键词特性
• textlist 特性

在 图 5 中可以看到，对于以上每种类型的特性，都有一个表。标准特性存储在 STANDARD_KW 表中，关键词和它们的出现情况存储在 KEYWORD_KW_OCC 表中，textlist 特性存储在 TEXTLIST_TEXT 表中。每个特性表包含 DOC_ID，作为对 DOCUMENT 表的引用。所有 DOC_ID 都是惟一的，以满足外键约束。图 6 说明了 MIML 文件到这 4 个关系表的逻辑映射。

由于这种模式不是完全符合范式的，因此有一些数据冗余。例如，每个文档都包含一些标准关键词，例如日期和主题描述。对于给定关键词的每次 出现，关键词被重复地存储在 STANDARD_KW 关键词表中。此外，对于每个关键词，KEYWORD_KW_OCC 表中还重复地存储关键词类别（例如 noun、verb 和 proper verb）。

选项 2：星型模式
图 7 显示了另一种可用于 MIML 数据的模式。这是一个星型模式，由一个事实表和 4 个维表组成。对于一个文档中一个关键词的每次出现，事实表 DOCUMENT_ANALYSIS 中都包含一行。维表描述事实表中的每个分析条目：实际日期、关键词值和类别以及相应的文档标题和内容。与 4 表模式选项相比，这种模式更符合范式，所以可以避免重复存储相同的关键词和类别。

还需注意，这种模式并不表示原始 MIML 文件中的所有数据项。每次关键词出现的实际位置已经被忽略，被忽略的还有一些标准特性（除了日期）和 text list 特性。 虽然这些数据也可以包括在该模式中，但是这里假设它们与随后的报告不相关。

通过 DATE 维可以根据时间段（例如星期、月和季度）分析数据。还需注意，关键词类别存储在维表 CATEGORY 中，在这个表中，每个类别指向它的父类别。因此，不仅可以查询单个的类别（noun，verb），还可以查询类别组（word，phrase）。

这种模式的优点是：

• 更加符合范式，从而可以避免数据冗余和节省存储空间。
• 可能更适合报告制作，它提供比简单的 4 表模式更高的 “查询能力”。

这种模式的缺点是，将 MIML 分解到这种模式要困难得多。不能使用 DB2 的 decomp 例程或 XMLTABLE 函数直接分解到这种模式。这是因为这种关系模式要求生成并适当使用外键，而这是原始 MIML 中没有包括的键值。但是，如果 MIML 数据已经被分解到简单的 4 表模式，那么就很容易使用 SQL MERGE 语句将数据转移到星型模式（请参阅 下载 小节中的脚本）。

选项 3：改进的星型模式
星型模式可以作进一步的改进，以减少 DOCUMENT_ANALYSIS 事实表中的行数。在前面的初始星型模式中，对于每次的关键词的出现，事实表都包含一行。改进的星型模式则在实际文档分析与关键词和类别之间引入一个桥接表（图 8）。这意味着改进的事实表现在对于每个文档有一行。这进一步减少了一些数据冗余。例如，日期表的外键对于一个文档的每个关键词不会重复。逻辑上，每个事实表行现在代表一个文档，而不是关键词的一次出现。

改进的星型模式由事实表 DOCUMENT_ANALYSIS、默认的维表 DOCUMENT 和 DATE、指向关键词的桥接表 UCAT_BRIDGE 以及一些可选的 维表（例如 CATEGORY_SUBJECTDESC）组成。 可选的维表源于 MIML 数据中的标准关键词类别。可以选择为每个标准类别使用一个这样的维表，例如主题描述、国家和组织。在星型模式中包含还是排除某些标准关键词类别取决于特定的报告需求。

UCAT 表包含所有的关键词和它们的类别。在这个改进模式中，这些类别以级别 表示。每个类别，例如 .tkm_en_base_word.noun.proper，被分成级别 tkm_en_base_word、noun 和 proper。每个级别存储在一个单独的列中。因此，现在仍然可以查询类别组，例如单词或短语。

这种改进模式的优点有：

• 它更符合范式，消除了更多的数据冗余
• 事实表行现在表示文档，而不是关键词在文档中的出现。取决于实际的报告环境，这种模式可能更合适，更直观。

这种模式的缺点是稍微增加了一点复杂性，事实表与 UCAT 表之间存在多对多的关系。因此，分解到这种模式更具有挑战性，但是可以通过 SQL 存储过程来完成（请参阅 下载 小节中的脚本）。在对未来版本的计划变动中，IBM 打算在将来的 OmniFind Analytics Edition 版本中包括一个分解工具，该工具将把 MIML 分解到这种改进的星型模式中。

使用带注释的 XML 模式分解 MIML

本节使用 DB2 带注释的模式分解特性将 MIML 数据映射到简单的 4 表模式。IBM Data Studio 包括一个 GUI 工具，用于定义从 XML 模式到关系模式的映射（图 9）。概括起来，就是打开 XML 模式文件，建立一个数据库连接，然后用鼠标画出从 XML 元素和属性到关系列之间的连接。

更具体而言，首先在 IBM Data Studio 中右键单击 XML 模式文件。从上下文菜单中选择 Open with…，然后选择 Annotated XSD Mapping Editor。这将打开一个包含三部分的视图，如 图 9 所示。在左侧，可以看到 XML 模式定义的所有元素和属性的结构。在右侧，可以选择要映射到的表。中间的框包含映射。要创建一个映射，只需单击左侧面板中的一个 XML 节点，再单击一个表中的任何一个列。Data Studio 以两个端点之间的连线的形式显示映射。

在幕后，IBM Data Studio 将实际的注释插入到 XML 模式文件中，这些注释都以 db2-xdb 为前缀，如 图 10 所示。可以看到，每个属性都带有注释，其中包含该属性的路径和它在目标表中的目标列（“rowset”）。

要注册新加入注释的 XML 模式，使用 IBM Data Studio 或通过 DB2 命令行处理器执行 清单 1 中显示的命令。

                
                REGISTER XMLSCHEMA 'http://www.example.org'
FROM 'annotatedSchema.xsd' AS mimlschema
COMPLETE ENABLE DECOMPOSITION;

注册好带注释的模式之后，就可以将 MIML 文档分解到关系目标表中。如果 MIML 文档是文件系统中的一个文件，例如 miml_4711.xml，这么可以执行 DECOMPOSE 语句：

                
                DECOMPOSE XML DOCUMENT 'miml_4711.xml' XMLSCHEMA mimlschema;

或者，也可以从一个应用程序中通过一个存储过程调用来调用分解。参数占位符表示要分解的 MIML 文档。要了解更多信息，请参阅 “Shred XML documents using DB2 pureXML”（developerWorks，2008 年 1 月）。

                
                CALL xdbDecompXML('sqlschema', 'mimlschema', ?, 'documentID',
0, NULL, NULL, NULL);

使用 XMLTABLE 函数分解 MIML

除了使用带注释的模式以外，另一种选择是使用 SQL 函数 XMLTABLE 来分解 MIML 文档。在这种情况下，XML 模式不是必需的。XMLTABLE 函数读取一个 XML 文档，并返回一个关系结果集。XML 节点到关系列的映射隐含在 XMLTABLE 函数中。在 清单 4 中可以看到，对于简单关系模式中的 4 个表中的每一个表，都使用了一个 SQL insert 语句。每个 insert 语句从一个只包含一个 XML 类型的列的 staging 表 MIML 中读取 MIML 文档。或者，也可以通过一个参数占位符将 MIML 文件传递给 insert 语句。文章 “XMLTABLE by example, Part 2: Common scenarios for using XMLTABLE with DB2”（developerWorks，2007 年 9 月）对这些技巧作了更详细的描述。

                
                INSERT INTO doc
SELECT X.doc_id, X.title, X.input
  FROM MIML,
        XMLTABLE('$XMLDOC/doc'
                  COLUMNS doc_id  VARCHAR(15)     PATH '@id',
                           title   CLOB(10K)       PATH 'title',
                           input   CLOB(1M)        PATH 'input') X;

INSERT INTO standard_kw
SELECT X.doc_id, X.cat, X.val
  FROM MIML,
        XMLTABLE('$XMLDOC/doc/feature[@type="standard"]/kw'
                  COLUMNS doc_id  VARCHAR(15)     PATH '../../@id',
                           cat     VARCHAR(50)     PATH '@cat',
                           val     VARCHAR(4096)   PATH '@val') X;

INSERT INTO keyword_kw_occ
SELECT X.doc_id, X.cat, X.val, X.id, X.begin, X.end
  FROM MIML,
        XMLTABLE('$XMLDOC/doc/feature[@type="keyword"]/kw/occ'
                  COLUMNS doc_id  VARCHAR(15)     PATH '../../../@id',
                           cat     VARCHAR(50)     PATH '../@cat',
                           val     VARCHAR(4096)   PATH '../@val',
                           begin   INTEGER        PATH '@begin',
                           end     INTEGER        PATH '@end',
                           id      INTEGER        PATH '@id') X;

INSERT INTO textlist_text
SELECT X.doc_id, X.name, X.begin, X.end
  FROM MIML,
        XMLTABLE('$XMLDOC/doc/feature[@type="textlist"]/text'
                  COLUMNS doc_id  VARCHAR(15)     PATH '../../@id',
                           name    VARCHAR(15)     PATH '@name',
                           begin   INTEGER        PATH '@begin',
                           end     INTEGER        PATH '@end') X;

相对于带注释的模式分解，这种使用 XMLTABLE 函数的 insert 语句的优点是，如果分解比较简单，并且目标表的数量不多，这种方法通常可以取得更好的性能。对于 MIML 数据也是如此。而且，如果您熟悉 SQL 和/或 XPath，当有特定的应用程序需求时，还可以轻松地更改或定制这些 insert 语句。您可能会发现，这比定制前面小节中介绍的模式注释更容易。

分解到星型模式
星型模式要求生成并适当使用事实表和维表的主键或外键。不管是带注释的模式分解，还是 XMLTABLE 函数，都不能生成这些键。但是，如果将上述 INSERT 语句嵌入到一个包含一点额外逻辑的 SQL 存储过程中，就可以解决这个问题。本文附带了一个示例存储过程，该存储过程将 MIML 数据分解到改进的星型模式中（图 8）。它使用 DB2 中所谓的序列（sequences）来生成惟一的标识符。序列是一个数据库对象，它生成一系列惟一的数字。当分解列表或日期时，存储过程检查它们是否已经在维表中。如果是，则从维表中读取已有的 ID，并用它作为事实表中新条目的外键。否则，从序列获取一个新的键值，用它作为维表中新条目的主键和事实表中的外键。

将 MIML 存储在 XML 列中

作为分解的备选方法，可以简单地使用一个包含 XML 列的表来存储、索引和查询 MIML 数据：

                
                CREATE TABLE miml (document XML);

这样做有一些优点：

• 不需要设计或优化关系模式
• 不需要定义从 XML 到关系表的映射
• XML 插入性能比分解性能高很多

潜在的缺点是，不能使用纯 SQL 来查询 DB2 中的 MIML 数据。这种情况下只能使用 SQL/XML 或 XQuery，如下一节所示。对于有一定复杂度的查询，这样非常好。如果需要执行高度复杂的查询和非常多的分析处理，在分解的数据上执行纯 SQL 可以提供更好的性能。而且，对于大多数 BI 工具而言，分解到关系模式中的 MIML 数据更易于访问。但是，如果使用 XMLTABLE 函数，就可以创建 XML 数据的关系视图。“XMLTABLE by example, Part 2: Common scenarios for using XMLTABLE with DB2” 中对此作了详细讨论。

如果一个 MIML 文件包含关于数千个文本文档的信息，那么，如果将这么大的 MIML 文件拆分成较小的 XML 片段，即在 /miml/doc 路径中为每个原始文本文档产生一个 XML 文档，那么 pureXML 可以提供好得多的性能。清单 6 中显示的 INSERT 语句就是这样做的。

                
                INSERT INTO subdocuments (document)
SELECT T.xmldoc FROM miml,
                      XMLTABLE('$DOCUMENT/miml/doc'
                                COLUMNS xmldoc XML PATH 'document{.}') T;

要进一步提高 XQuery 或 SQL/XML 查询的性能，应该定义 XML 索引。清单 7 展示了如何为 MIML XML 格式中的所有关键词值建立索引。

                
                CREATE INDEX idx_keyword ON subdocuments (document)
    GENERATE KEY
    USING XMLPATTERN '/doc/feature/kw/@val' AS SQL VARCHAR(4096);

查询 DB2 中的 MIML 数据

如何编写 MIML 数据上的查询，这取决于如何在 DB2 中表示 MIML 数据：简单关系模式、星型模式还是只包含一个 XML 列的单个表。现在以一个非常简单的查询为例。假设您想查找 2008 年 2 月份包含关键词 “dental” 和 “Tennessee” 的所有文档的标题。清单 8 展示了用 SQL 编写简单 4 表模式上的这个查询的一种可能方法。清单 9 展示了用于改进的星型模式的同样的查询。

                
                SELECT title
  FROM document, standard_kw s, keyword_kw_occ kw1, keyword_kw_occ kw2
 WHERE id = s.doc_id
   AND id = kw1.doc_id
   AND id = kw2.doc_id
   AND (s.cat = '.date' AND s.val BETWEEN '20080201' AND '20080229')
   AND kw1.val = 'dental'
   AND kw2.val = 'Tennessee';

清单 9. 改进的星型模式上的示例查询

                
                SELECT doc.title
  FROM document_analysis da, document doc, date
       ucat_bridge b1, ucat cat1, ucat_bridge b2, ucat cat2
 WHERE da.document = doc.id
   AND da.date = date.id AND date.month = 2 AND date.year = 2008
   AND da.ucat = b1.id
   AND b1.annotid = cat1.annotid AND cat1.keyword = 'dental'
   AND da.ucat = b2.id
   AND b2.annotid = cat2.annotid AND cat2.keyword = 'Tennessee';

如果您选择不分解 MIML 数据，而是将它存储在一个 XML 列中，那么可以用 XQuery（清单 10）或 SQL/XML（清单 11）表达同样的查询。

                
                XQUERY
   for $i in db2-fn:xmlcolumn('MIML.DOCUMENT')/doc
   where $i/feature[@type="standard"]/kw[@cat=".date" and @val ge "20080201“ 
                                                      and @val le "20080229“] 
         and
         $i/feature[@type="keyword" and kw/@val = "dental“ and kw/@val = "Tennessee“]
         return $i/title;

清单 11. 使用 SQL/XML 的 pureXML 存储上的示例查询

                
                SELECT XMLQUERY ('$DOCUMENT/doc/title')
  FROM miml
 WHERE XMLEXISTS ('$DOCUMENT/doc/feature[@type="standard"]/kw[@cat=".date" and 
                               @val ge "20080201“ and @val le "20080229“]')
   AND XMLEXISTS ('$DOCUMENT/doc/feature[@type="keyword" and
                               kw/@val = "dental“ and kw/@val = "Tennessee“]');

回页首

选项比较

如前所述，当将 OmniFind Analytics Edition 文本分析结果（MIML）与 DB2 集成时，有几种选择。首先，必须决定是要将数据分解到关系模式还是将它存储为 XML 数据类型。如果决定将 MIML 分解到关系表，那么对于关系目标模式和实际的分解方法又有不同的选项。表 1 和 表 2 总结和比较了大多数相关的选项。

表 1 将简单的 4 表模式、改进的星型模式和 pureXML 存储作了比较。前两者需要分解，而 pureXML 方法不需要。这对于摄取大量 MIML 数据所花的时间有很大的影响。我们对一个包含关于 50,000 个输入文档的信息的大型文档进行了测试。将数据插入 DB2 时，不需要分解的 pureXML 存储是最快的方式。这种选项的插入时间被用作其他选项的基准。用一个经过合理优化的存储过程分解 MIML 数据比将 MIML 数据插入 XML 列要多花 2.25 倍的时间。在 下载 小节包含的文件中可以找到这个存储过程的原型。

使用简单的 XMLTABLE 语句（清单 4）将 MIML 分解到简单的 4 表模式也比使用 pureXML 存储多花 2.25 倍的时间。使用 DB2 的 decomp 例程（带注释的模式分解）比用 XMLTABLE 分解到同样的目标模式要多花 2 倍的时间，后者比插入到 pureXML 列多花 4.5 倍的时间。

在这个比较中，注意使用改进的星型模式的方法只是将一部分 MIML 数据转换成关系格式。例如，所有关于关键词出现情况的详细信息（MIML 元素 <occ>）已经被省略。在示例数据中，这种数据要占数据量的 45%。还应注意，取决于所使用的特定硬件和软件配置，性能表现会有所不同。

关系存储和 XML 存储之间的选择不仅会影响插入性能，还会影响 MIML 数据的查询和索引。如果您选择将 MIML 数据分解到关系表，那么可以使用纯 SQL 和关系索引来分析数据。XML 存储意味着使用 XQuery 或 SQL/XML 来查询 MIML 数据。对于复杂度较低或中等的查询，包括 查询 DB2 中的 MIML 数据 小节中的查询，查询性能很好。对于复杂度较高的查询，被分解的数据上的纯 SQL 查询可能更易于编写，并且能提供较好性能。而且，对于大多数 BI 工具而言，被分解到关系表中的 MIML 数据更易于访问。

表 2 总结和比较了带注释的 XML 模式和用于分解的 XMLTABLE 函数。对于 XMLTABLE，分解是在 XMLTABLE 函数的参数中隐式地定义的。带注释的模式分解的优点是，IBM Data Studio 提供了一个图形化的向导，以便定义从 XML 到关系表的映射（图 9）。

回页首

结束语

本文回顾了 IBM OmniFind Analytics Edition 的文本分析功能，包括对 XML 格式的文本分析结果 MIML 的分析。然后，本文研究了通过将分析结果从 MIML 文件存储到 DB2 中，以支持标准的商业智能操作和使用 SQL 或 SQL/XML 全部功能的报告，扩展 OmniFind Analytics Edition 文本分析的价值的不同方法。下面总结了在决定使用哪种方法时应遵循的决策过程：

1. 分解到关系表还是存储为 XML？
   1. 如果想使用标准的 SQL 和 BI 报告工具，选择分解。进入步骤 2.
   2. 如果可以使用 SQL/XML 和 XQuery，并且想要最高的插入性能和最小的模式和插入复杂度，存储为 XML。这样就可以了。
2. 如果已经选择了分解，那么接着选择一种最适合查询和报告需求的目标关系模式。
   1. 如果模式是否简单、可以使用现成的工具和函数轻松分解对您来说比较重要，并且不需要通过优化达到最小存储空间，那么可以考虑简单的 4 表模式。
   2. 如果需要通过 BI 和报告工具获得更好的 “查询能力”，那么考虑星型模式或改进的星型模式。如果想最小化数据冗余和存储消耗，并且愿意花更多的系统资源在分解上，那么您可能也会偏爱星型模式。
      1. 如果希望每个事实表行表示一个文档中的一个关键词，那么选择更简单的星型模式。
      2. 如果希望每个事实表行表示一个文档，那么选择改进的星型模式。

清楚地理解了每种方法的优缺点之后，就可以选择最适合分析和报告需求的方法。

致谢

感谢 IBM India Lab 的 Balunaini Prasad、IBM Silicon Valley Lab 的 Sreeram Balakrishnan、日本 IBM Yamato Lab 的 Iwao Inagaki 为本文和关系星型模式提供的帮助。

回页首

下载

	关于下载方法的信息

注意：

1. 本下载包含一组示例 DDL 和 SQL/XML 脚本，以及一个原型 SQL 存储过程，该 SQL 存储过程将 MIML 数据分解到一个星型模式中。

参考资料

• 您可以参考本文在 developerWorks 全球站点上的 英文原文。
  
  
• “IBM OmniFind Analytics Edition: An advanced text analysis and mining platform”：深入研究这个产品。
  
  
• “XML Support in DB2 Universal Database”：学习更多关于这个重要专题的知识。
  
  
• “XMLTABLE by example, Part 2: Common scenarios for using XMLTABLE with DB2”（developerWorks，2007 年 9 月）：研究使用 XMLTABLE 函数处理 XML 数据的威力。
  
  
• “使用 DB2 pureXML 分解 XML 文档”（developerWorks，2008 年 3 月）：这篇文章深入讨论了如何将 XML 数据映射到 DB2 中的关系表，并给出了一些例子。
  
  
• “DB2 9 中的 pureXML：怎样查询您的 XML 数据？”（developerWorks，2006 年 6 月）：获取关于如何查询 XML 数据的信息。
  
  
• DB2 pureXML wiki：继续关注 DB2 的 XML 技术。
  
  
• “Apache UIMA”：阅读更多对文本分析的深入讨论，尤其是 Unstructured Information Management Architecture（UIMA）中出现的文本分析。
  
  
• developerWorks Information Management 专区：在这里可以学到更多关于 DB2 的知识。还可以找到技术文档、how-to 文章、培训、产品信息等等。
  
  
• 随时关注 developerWorks 技术活动和网络广播。
  
  

• IBM OmniFind Analytics Edition 产品网站：这里有很多关于 IBM OmniFInd Analytics Edition 的信息。
  
  
• 访问 IBM Data Studio 产品网站。
  
  
• 使用可直接从 developerWorks 下载的 IBM 试用软件 构建您的下一个开发项目。
  
  

• 参与论坛讨论。
  
  
• 通过参与 developerWorks blogs 加入 developerWorks 社区。

作者简介

		Matthias Nicola 是 IBM 硅谷实验室负责 DB2 pureXML™ 的一名高级软件工程师。他的工作重心是 DB2 中 XML 性能的所有方面，包括 XQuery、SQL/XML、存储、索引和性能。Matthias 与客户和业务合作伙伴紧密协作，协助他们设计、实现和优化 XML 解决方案。在加入 IBM 之前，Matthias 曾在 Informix Software 公司负责数据仓库性能方面的工作。他从德国的亚琛科技大学获得计算机科学博士学位。

		Martin Sommerlandt 是 IBM 硅谷实验室的一名为期 18 个月的实习生。他在德国德累斯顿工业大学读计算机科学专业，2007 年作为一名实习生加入 IBM，从事 DB2 pureXML™ 解决方案方面的工作。他的兴趣包括 XQuery、SQL/XML、XML 性能和定制 XML 解决方案。Martin 是一名 IBM 认证的 DB2 应用程序开发人员和 IBM 认证的 DB2 数据库管理员。他还曾经担任过 DB2 管理和编程方面的教员。

		Kathy Zeidenstein 在 IBM 工作了很多年。目前，她在 IBM Data Studio 支持团队工作。在担任这个职务之前，她是 IBM OmniFind Analytics Edition 产品行销经理。

对本文的评价

太差！ (1) 需提高 (2) 一般；尚可 (3) 好文章 (4) 真棒！(5) 将您的建议发给我们或者通过参加讨论与其他人分享您的想法.

回页首