SOA 设计的信息透视图，第 7 部分: SOA 中数据质量分析模式的执行方法

文档选项 未显示需要 JavaScript 的文档选项 英文原文

Brian Byrne, IFW/IAA 过程和集成模型架构师, IBM
John Kling, 顾问和服务架构师, IBM
David McCarty, IT 架构师, IBM
Guenter Dr. Sauter, 高级 IT 架构师和管理者, IBM
Harald Smith, 产品经理, IBM
Peter Worcester, 服务解决方案营销经理, IBM

2008 年 10 月 10 日

本文是“SOA 设计的信息透视图” 系列的第三篇文章。本文的目的是向架构师社区演示在 SOA 环境中如何执行详细的数据质量分析。本文关注数据质量分析的实现，而不考虑使用的具体技术，本文之后将会有一篇相关的文章更详细地描述如何在这个上下文中使用相关的 IBM® 产品（WebSphere® Information Analyzer）。

简介

阅读本系列的所有文章 1. SOA 架构的信息透视图简介 2. 在 SOA 中应用业务术语表模式的价值 3. 在 SOA 设计中使用 IBM WebSphere Business Glossary 4. 在 SOA 中应用标准建模模式的价值 5. SOA 中 Rational Data Architect 的使用 6. 在 SOA 中应用数据质量分析模式的价值 7. SOA 中数据质量分析模式的执行方法 8. 在 SOA 设计中使用 IBM WebSphere Information Analyzer

要让 SOA 服务获得成功并且可重用，重要的是这些服务所公布的数据具有所有消费者可接受的质量。在任何 SOA 计划中，公布高质量的数据都是必不可少的。无论是公布应用程序服务还是生成的简单的数据查询服务，产生的数据都必须适合业务上下文，并且足够精确，如此才具有价值。

本系列的第 6 部分概述了通过分析技术审查数据质量的价值和方法。数据质量分析实践的焦点是数据质量级别的度量。这种度量跨越三个核心领域：

分析源系统

• 将数据质量度量指标应用到来自已识别的数据存储的数据上，以确定数据质量级别。
• 解释数据度量指标结果，并将这些结果翻译为业务术语。创建详细的报告、图表和总结，以描绘数据质量级别和提供建议。
  

分析目标系统

• 发现所分析的源系统与目标系统之间的差异。创建用于消除差异的建议。
  

评估每个相关数据元素的校准（alignment）和协调（harmonization）需求

• 将数据质量度量应用到识别出的数据元素上，以评估当前的标准化和相匹配的支持，并将这些结果翻译为业务术语。创建详细的报告、图表和总结，以描绘标准化和匹配的级别，并提供建议。

在 SOA 分析和设计中，这些领域至关重要，因为它们直接影响服务实现的决定。在使用自上而下业务需求确定并设计好服务接口之后，接下来的步骤是决定如何利用已有的系统或者编写新代码实现服务。每个服务都将功能和数据公布给服务消费者，与此同时，它必须满足约定的服务级别，包括数据精确性、响应时间等。只有在服务设计者理解存储在每个系统中的数据的特征，理解源系统与服务实现提供的数据之间的差别，并且清楚如何适当地校准和协调复杂或复合服务中不同的数据元素的情况下，才能实现这一点。数据质量分析就能提供这样的理解。

本文介绍 SOA 项目中数据质量分析执行的最重要的几个方面。

回页首

数据质量执行计划

作为数据质量分析的一部分，执行计划已经被公式化，如本系列 第 6 部分 所述。在这里，数据分析已经确定谁在执行计划，测试什么，使用什么工具进行测试，何时进行测试，以及计划的预期输出是什么。必须清楚地陈述目标交付内容，以确保计划能够有效地执行并完成。

根据已定义的执行计划，数据分析发生在三个核心维（dimension）内。在这个 SOA 上下文中执行数据分析的过程类似于大多数流行的数据分析项目，其目标是降低项目风险，消除潜在差异。

随着每个测试的执行，都会产生和收集结果，并将结果并入到更广阔的数据质量评估中。通过清晰地关注服务的核心需求，数据质量分析的价值将得以实现。

表 1 表示执行阶段进行的分析步骤。下面详细列出了执行过程、核心问题和每个步骤中潜在的问题。

当发现重大问题时，SOA 设计者有三个选项：

• 更改服务实现，以规避数据问题。
• 请求在 SOA 项目小组之外做出更改。对于还没有企业数据质量计划的组织，这可能是启动一个企业数据质量计划的催化剂。
• 如果服务不能满足业务服务级别需求，那么选择不公布它。

回页首

在项目框架内进行数据质量分析

这个基于项目的方法的中心点是数据质量分析的实际执行。任何项目的具体实现路径都因项目级的决定而变化。可用的和正在使用的工具也会影响所需的工作量。本系列的第 8 部分将讨论一种非常特别的基于产品的方法。

1. 源系统分析

如前所述，在 SOA 项目中有三个级别的源系统分析在起作用：域级技术维、实体级技术维和业务流程维。为什么要进行源系统分析？很少有 SOA 解决方案是作为全新的信息系统来开发的 – 这些解决方案几乎都利用已有的应用程序和数据。通过开发可重用的服务，并谨慎地公开已有系统的功能，企业就可以发展它的 IT 功能，以便更好地适应变化。只有理解所公布的源数据的性质，SOA 服务设计者才能实现这个目标。对于每个数据源，可以执行以下类型的分析。通过这些分析的结果，可以洞察支持 SOA 解决方案的已有数据的价值和完整性。

评估域级技术维

技术维表示给定数据源的物理数据内容。域级涉及物理数据的显式字段或属性。表 2 列出了相关的域级技术维：

在域级，即单个数据元素内，数据分析将首先理解实际的底层数据内容，并以此为基础，看看数据内容对于数据结构和数据质量的含义。

必须应用以下技术：

• 频率分布
• 域完整性（或 Column Content Analysis）
• 结构分析（或 Key Analysis）
• 关系分析（或 Cross Domain Analysis）
• 业务规则评估
• 元数据完整性（或 Business/Technical 文档）

频率分布

这是对一个数据元素或实体内不同值的数量和出现频率的计数。换句话说，频率分布显示的是一个值出现的频率。这是 Source System Analysis 的大多数后续技术所需的基本步骤。

频率分布可以从两个方面来看。首先，一个特定值的实际出现可能表明是否存在问题，例如由于 Null 值、空格等造成的不完整的值。其次，一个特定值的出现频率可以引起对数据条件范围的关注 — 事件是否经常出现或很少出现，以及是否有生僻的值。换句话说，如果有 90% 的值落在某个范围内，那么频率分布将告诉您有什么生僻的值，并且可能表明那些生僻的值存在质量问题。

频率分布可以用很多方式来生成 — 从一系列的值手动生成，发出一条 SQL 查询以获得不同值的计数，或者使用数据概要分析工具，这种工具可以自动生成用于一个表中所有列的频率分布。频率分布的结果必须能够访问，以便进行其他的分析。

域完整性（或列内容分析）

在频率分布中没有隐式的分析 — 它只是关于一个特定数据元素或域的内容的统计表示。 域完整性 是特定条件下分析列内容的技术。

域完整性技术可以解决完整性、精确性、有效性、惟一性以及部分理解性等技术维。列内容还解决结构一致性，但不是值一致性，值一致性需要一个比较焦点，列内容也不解决及时性，及时性需要一个引用点。

列内容分析产生一个详细而复杂的输出，显示一个源存储中任何特定列的内容。它应该回答以下问题：

• 是否有缺失的数据？这可能以 null 值或其他空白值（例如空格）的形式出现。缺失的数据表示数据不重要或者缺少完整性检查（强制设置默认值）。
• 是否有默认的数据？这可能以特定的设置值（例如所有的 9 或 ‘Do Not Use’）或空白值（一个空白表示一个按键，这不同于一个 null 值）的形式出现。默认的数据表明数据或者不重要，缺少完整性检查，或者使用未知的标准。
• 数据是否为常量？这表明一个列中的大多数数据都是相同的。这可能表明使用了同类的填充，但是允许系统在将来增加，或者可能反映出元素基本上是默认的条件。
• 数据是否惟一？这表明所有数据或大多数数据只出现一次，是惟一的。最常见的惟一的域是一个标识符，它是潜在的数据的键，但是也包括基于文本的描述。
• 数据是否倾斜？如果频率分布显示数据值从经常出现变为较少出现，则存在数据倾斜。这样的倾斜可能是正常的（例如在产品价格范围中），可能表明有生僻的情况，或者可能存在有效性问题。

域完整性还考虑结构一致性。通过在频率分布中生成一个值列表，可以使用值列表本身来推断数据的键属性。这些包括实际数据的长度（或者数字值的精度和范围），数据的模式或格式（例如字符 ‘A’ 后面跟 4 个数字），以及数据类型（即整数、小数、字符等）。这些推论应该回答以下问题：

• 数据是精确的吗？值的长度越短，就越精确，键入错误或其他错误就越少。如果数据是精确的，则当在系统之间移动数据时，需要对数据进行修改。
• 数据在结构上是否一致？这可能以混合数据类型或混合格式的形式出现，但是如果缺少一致性，就很可能影响数据的可用性。
• 数据是否可理解？与精确性问题相反，简短的数据看上去紧凑，但是如果没有外部的指导或参考，将难以理解。如果注明存在理解问题，则表明需要进一步评估可用的元数据。

通过查看精确性、结构一致性和可理解性，该分析还确定已有数据源在何处有问题，并在数据本身中包含嵌入式逻辑 — 它们实际上包含多个 “域” 的信息。假设一个列恒定地包含一个值 -9999；这告诉使用该数据的程序，应该执行备选的处理。这个例子展示可以将嵌入的业务逻辑包含在列中。

结构（或键）分析

某些数据元素或域本身或它们的组合对于理解整个记录或实体非常关键。它们可以是主键或惟一键，或其他数据元素的标识符。它们可以将不同的数据部分链接在一起。

在域完整性分析期间完成的惟一性评估形成了这个组件的基础。该过程的输入提供的元素不仅用于关系分析，而且用于目标分析、校准及协调分析。

结构分析产生一个详细的输出，显示惟一性、重复和对其他数据元素的支持。它应该回答以下问题：

• 标识符是完全惟一的吗？任何重复的值都会损害数据链接信息的能力。一个典型的例子就是美国的社会保险号（Social Security Number），理论上讲，社会保险号应该标识一个特定的个人，但是如果将它用于多种用途，例如标识一个还没有社会保险号的小孩，那么它的使用就会受到损害。
• 如果没有惟一的单个元素，数据元素的组合是否可以惟一地标识数据？ 元素组合的频率分布可以发现能够惟一确定数据的复合元素。

关系分析

当使用分布在多个文件或表中的数据，或者收集来自不同源的数据时，必须有一种方式将数据关联在一起。关系分析以之前的域完整性分析和结构分析为基础，旨在发现共同的键或数据元素和域。共同的键支持实体级的技术分析。共同的域允许域级和实体级的值一致性评估。

关系分析产生一个详细的输出，显示键标识符的引用完整性和域的一致性（或冗余）。它应该回答以下问题：

• 两个表或源之间的标识符引用是否完整？取决于项目的目的，可以从一个方向或同时从两个方向检查引用完整性。如果一个引用链接缺失，则可能表明某个实体缺少一些数据（例如，某个客户可能缺少一个独特的帐单地址），或者链接被断开（例如假定每个客户有一个账单地址），又或者存在多个记录（例如，某个客户有多个不同类型的地址）。
• 某个源是否是一个引用源？一个源可能是一个主引用，而其他源利用它的数据。如果查看每个源的频率分布发现存在多对一的情况，并且一个源只有一个惟一的值，那么它很可能就是引用源。
• 域之间数据是否一致？这表明数据值的一致性是否被损害。如果值大部分是相同的，那么也有可能数据是冗余的，在这种情况下需要确定正确的数据源。
• 是否有虚假的重叠？仅仅由于两个值是重叠的并不意味着它们就是相同的。代码字段可能使用字母值的一个抽象集。标识符可能使用代理键。日期和数量很可能会重叠，但它们之间也许没有关系。对于这种情况必须进一步加以理解和分析，以剔除无关的关系。

业务规则评估

一个给定的域的完整性、有效性和及时性并不总是可以孤立地加以评估。例如，如果一个订单的状态字段是 ‘Open’，那么发货日期应该为 null 或空白。在这里，null 或空白值并不表示不完整的数据，而是反映需要尚未出现的数据的业务情况。类似地，如果没有检查一个 Address Modification Date 字段，那么就不能说一个地址字段是否是及时的。

这一级别的分析只能通过评估业务或数据规则条件来完成。为此，需要对数据进行精化或细分，以便显示清楚的值关系。对用于产生频率分布的数据进行过滤和选择，使用 SQL 查询的 WHERE 子句，或者为一组列生成一个频率分布，这些技术都可以用于这一级别的评估。

业务规则评估的结果显示是否符合这些条件，或者存在异常。它应该回答以下问题：

• 是否有缺失的或不完整的数据？如果数据是必需的，这可能以 Null 值或其他空白值（例如空格）的形式出现。
• 是否有默认的数据或无效的数据？这通常以特定的一组值的形式出现，这组值在有效值集合内，但是在符合条件的有效值集合之外。默认的值或无效的值表示缺少完整性检查，或者未知的标准。
• 数据是否及时？这表明特定字段的创建或更新日期是否在可接受的有效日期范围内。除非某个特定字段与一个特定的日期有关，否则不可能回答这个问题。

业务规则评估还涉及 Business Process Quality Dimension of Accuracy。这意味着生成一系列的值，以对文件中的记录进行交叉检查，但这通常超出了 SOA 的直接作用范围。

元数据完整性（理解）

这是一个分析和处理步骤，用于帮助确保理解数据，并利用所有上述分析为当前数据源编制文档。而且，这一步应该解决 Business Process Dimension of Semantic Definition，以验证对数据、元数据和它的使用的理解。通过回顾业务流程和系统文档、功能或技术规范、数据字典、主题专家或其他数据知识源，可以进一步丰富内容。然后将这些知识与前面的源系统分析步骤获得的内容相比较。如果有差异，则会标记出来。这个评估应该回答以下问题：

• 语义和数据定义是否可用？这表明是否具有理解数据元素的知识库。
• 数据是否能被理解？这表明可以在多个个体之间清晰、一致地对数据元素或域进行讨论。如果业务和系统资源以不同的方式描述一个数据元素，并且该数据元素被不能合理解释的有歧义的代码（例如用 0/1 表示女性/男性）引用，或者缺少信息，则在使用数据时出现错误的风险就会更大。
• 元数据是否与数据内容一致？如果缺乏一致性，那么在 SOA 项目的交付方面发生错误的风险就会更大。

评估实体级技术维

实体级表示数据元素或属性的一个组合，该组合形成一个独特的单元或实体（例如，一个人或一个位置）。这些技术首先理解实际的数据内容，但是将这些内容看作一个组，并以此为基础，查看这些内容对数据结构和数据质量意味着什么。实体级（它的维在表 3 中标出）常常被忽视，但是它对于将来自多个源的数据集中在一起非常关键，并且是随后的校准和协调分析的基础。

例如，对于复杂或复合服务，从中收集数据的数据库有两个不同的客户视图，一个视图包括预期客户，另一个视图不包括。而且，一个源将客户姓名解析成不同的字段，并且总是应用邮政地址验证，而另一个源则使用未解析的姓名字段和非标准化的地址。什么是实体的重叠？是什么构成一个完整的实体?哪个数据更及时？这些都是实体级问题。

必须应用下面的技术：

• 跨数据元素的频率分布
• 记录链接
• 重复评估
• 实体完整性

频率分布

存储在多个数据元素中的分组数据（通常由标识符、文本或日期字段连接而成）可能为匹配或连接实体（例如客户、产品、账户）提供另一条途径。与前面一样，这仍是不同值的数量和它们的出现频率的计数，但这一次是在一组数据元素的上下文中。当将实体视为一个表时，不同的无重复记录的计数提供了基本的评估。但是，在很多情况下，重要的实体是一个记录的一个子集，或者跨多个表，需要通过公共键链接数据。

记录链接

这种技术在两个数据源公共的指定元素上对数据进行分组，然后估计其他数据元素的相同程度或差异程度。虽然 SQL 查询也能获得所需的结果，但是如果数据包含标准化程度较低的高级文本信息，或者发生键入错误的可能性较高，那么很可能需要一个用于记录链接或匹配的工具。它应该以技术域的关系分析步骤期间讨论的关系为基础。实际上，记录链接可以识别实体内的备选数据关联。可以将字段的不同组合视为可能的访问点，例如一个包含出生日期的 tax ID 和一个包含出生日期的名称可以作为姓名和地址链接的备选方案。

重复评估

这是实体的数据元素之间不同值的数量和重复出现次数的计数。重复评估可以解决惟一性的技术维。它应该回答以下问题：

• 实体是惟一的吗？通过频率分布或记录链接发现的单个源内或跨多个源的重复表示，需要通过合并来提供数据。

实体完整性

实体完整性是应用到一个实体所需的多个元素上的域完整性的扩展。作为一个基本级别，它实现了这些数据元素的域完整性，包含实体以及是否填充元素的状态信息。实体完整性解决完整性和一致性的技术维，并且，对于复杂或复合的 SOA 系统，还通过提供一个数据组合视图，直接回答有关校准和协调的问题。它应该回答以下问题：

• 是否有缺失的数据？对于实体的一个或多个数据元素，这可能以 Null 值或空白值（例如空格）的形式出现。
• 是否有一致的数据？查看重复或被链接的实体，包括的域是否一致，或者它们是否需要经过校准或协调才能使用？
• 数据是否校准？如果数据按照预期直接在表或系统之间传递，那么不同频率的数据重叠或者没有发生重叠可能表明识别或链接特定数据实例时出现问题。
• 数据是否正确地聚合？如果数据发生重叠，但两方数据的频率都大于 1，这可能表明在聚合或合并数据方面存在问题。

源系统分析的结果

下面列出了运行这个源系统分析的结果：

• 关于每个源系统所有方面的一组完整的报告，这些报告向最初的企业和技术社区显示源数据的一个初始概述。
• 通过对结果进行分析，可以捕捉文档，并将其用于很多上下文中。

• 为功能和技术规范提供内容的映射规则规范
• 需要企业去解决的后续内容和问题的文档
• 可在未来的项目或组织的其他领域中使用的信息

• 项目范围和对数据转换工作的初始风险评估
• 重复使用数据提取加速器以进行基准评估和开发

2. 目标系统分析

对于 SOA 项目中的数据分析工作，“目标系统” 有以下这些可能性：

• 对于服务设计，目标是规范的消息模型，该消息模型表示 SOA 项目中创建的所有服务所公布的数据结构的超集。对于这种情况，没有数据按目标格式存储。
• 如果要创建一个操作数据存储（operational data store，ODS）或主数据管理（MDM）系统来支持 SOA 解决方案，那么目标是这个数据存储的物理数据模型。在某些情况下，数据分析不仅包括对所使用的结构的验证，还包括对填充目标系统的已有数据的调查。
• 如果正在创建将数据提供给下游系统的服务，那么目标系统就是该服务的消费者。同样，在这种情况下，数据分析可能不仅需要调查目标的结构，还需要调查任何已有的数据，以确保进入的数据的兼容性。

对于目标系统，可以执行以下任务。

• 属性差异分析（Attribute Gap Analysis）
• 数据差异分析（Data Gap Analysis）
• 字段长度分析（Field Length Analysis）
• 数据迁移范围界定（Data migration scoping）

属性差异分析

分析是否能适当地定义目标实体和属性，以及是否可以从已有的源系统映射那些实体和属性。

在最基本的一级上，该分析将目标属性列表放在一个电子表上或放在一个映射工具中，然后将已知的源属性列表（来自一个或多个系统）映射到目标属性。在这一级，属性的定义或语义最为关键。源系统常常缺乏定义信息。应该使用元数据完整性分析和域分析来评估哪些源属性适合确定的目标属性。

如果没有从已有的源系统到目标的映射，则可以确定存在属性差异。然后，检查源系统分析，看是否有可能消除差异或采取补救措施。

当有属性映射时，必须整理源属性集并用于范围界定，包括识别所有语义校准需求。

数据差异分析

该分析确定现有的源数据是否能填充目标模型，以及是否需要执行大量的转换。

类似于属性差异分析，该分析将目标数据元素列表放在一个电子表上或放在一个映射工具中，然后将已知的源数据元素列表（来自一个或多个系统）映射到目标数据元素。数据差异分析必须超越基本的语义映射，考虑目标需求中的数据域、数据格式、映射、转换、标准化和聚合。如果目标模型跨多个表，数据差异分析还必须考虑数据键和键关系，以便有效地链接数据元素。

如果从已有源系统到目标的映射并不良好，则确定有数据差异。然后，检查源系统分析，看是否有可能消除差异或采取补救措施。

当进行数据映射时，必须整理源数据元素集并用于范围界定，包括识别格式化、转换、标准化和聚合或匹配需求。

字段长度分析

字段长度分析是分析当前的源系统是否可以正确映射目标模型的字段长度。如果不能，那么在映射阶段必须执行转换。这可以为数据架构师提供反馈，以便在必要时调整标准数据模型。

该分析处理数据差异分析和源-目标映射域集合，检查这些映射以发现数据属性中的问题。该分析最常用于确保字段长度（对于数值型数据，则包括精度和等级）是一致的，但是也可以解决数据类型不匹配的问题。

数据迁移范围界定

这个处理步骤帮助界定需要执行的数据迁移的级别。如果 SOA 解决方案创建一个 ODS 或 MDM 系统，那么很可能需要执行将初始数据装载到目标数据库的数据迁移。在其他情况下，服务消费者可能还要求在新的解决方案投入生产之前进行初始数据的填充或同步。无论我们是否有所需的所有源数据，也不论需要什么类型的转换，这个范围界定的目的是帮助判断需要多少工作量。

3. 校准和协调分析

在复杂和复合服务中，多个组件必须在相同级别上以一致的方式放在一起并进行集成。这些组件必须满足预期的业务流程数据质量维（Business Process Data Quality），以确保实现正确的集成。校准和协调主要致力于表 4 中列出的 5 个维。

校准和协调真正意味着什么？通过前 2 节内容已经能够理解源数据和目标数据。

校准 是确保源数据与目标数据之间采用相同等级和语义定义的一种方法，它可以使用 1:1 的直接映射、域的解析和标准化，也可以通过转换实现。

协调 是通过去掉重复的数据或重叠的定义，确保填充重叠和类似的通用化和聚合级别。如果在处理多个源，那么要不断地进行协调，直到剩下单独的一个定义或数据实体进行映射。在这个阶段，源-目标映射是关键。

校准和协调最终表明，当在一个新的服务中使用来自一个系统的数据，或者为复合或复杂服务连接来自多个系统的数据时，如何满足业务数据质量维。通过标准化和属性校准，可以取得相同的语义理解。通过标准化到一致的级别并匹配到一致的级别，以及将属性校准和聚合到一致的级别上，可以取得一致的通用化和聚合。标准化确保应用相同的等级和度量。匹配确保以适当的方式连接重叠的填充，从而满足业务需求。

作为校准和协调分析的一部分，必须确定如何将记录结构标准化和转换到给定的格式，以及如何匹配记录实例。如果相同的信息有多个版本存在，需要确保总是在处理正确的记录。对于这种情况，数据分析必须建立控制 “存活”（哪些记录保留下来）的策略。甚至必须基于来自不同源的不同属性，构建一个复合的记录。

在此过程中，通常执行以下分析。

• 标准化分析
• 匹配补救分析
• 属性校准分析

标准化分析

标准化分析用于理解为将源数据标准化到适当的格式而对其进行的操作。这对于诸如地址和姓名之类的术语通常最为常见，但是也适用于其他业务术语。基于之前的源系统分析，尤其是关系分析的输出，这一点很明显。例如，比较两组区域代码时，源系统之间的差异可能表明需要进行标准化。

标准化分析过程利用早期的域和跨域分析理解默认的和无效的值，从而评估在什么情况下域的默认值重叠或者不重叠，从而检查对标准化拼写格式和缩写的需求，并验证可用的标准化例程支持需求的能力。通常，标准化分析是在早期的源系统分析期间确定的单个域或特定于字段的过程中执行的。这需要一种工具或技术来测试已知的标准化。应该在业务需求已经完成并经过检查，并且源系统分析和差异分析完成之后，才进行标准化需求的评估。这有助于确保标准化规则不被添加到用于不必要的域的应用程序中。应该对标准化工具或过程的输出进行评估，就好象经过解析和标准化的域是来自初始数据的任何其他域或字段一样（也就是说，可以对这个输出应用源系统分析技术，以确认标准化需求）。

要解决的核心问题包括：

• 哪些字段需要被标准化？通过报告或电子表格，将识别出的输入字段与建立的公司标准列表相匹配，以确定哪些输入字段需要定义标准。输入信息将映射到的目标字段的需求应该可以帮助定义如何标准化给定的字段。
• 新的公司标准是否将应用到目标中？很多系统都采用较旧的遗留标准，在新的目标系统中，这些遗留标准需要更新。如果存在新的标准，那么应该通过映射值，根据一个查找表或一个定义好的模式或算法，将数据映射到那些新的标准上。
• 默认的或缺失的数据如何标准化？对于单个源数据，这些默认值的标准化可以通过根据一个查找表或定义好的模式或算法，在数据中指定映射值来完成。对于复合和复杂的服务，由于必须链接或匹配数据，应该去掉默认值，以防止记录与相同的默认值相链接。对于缺失或有冲突的数据，值可以在链接的记录之间传播，以便在所有链接的记录中提供名称或 tax ID 的通用表示。还可以通过匹配源文件和外部的第三方文件 [例如，CASS（Postal Validation）、Zip-4 处理（Zip Code 增强）、Dun & Bradstreet 或其他信息提供者] 来增强数据字段。这里的目的是优化匹配结果，对于目标而言，需要对这些默认的/有冲突的值进行不同的处理。如果为了匹配服务和更新目标系统而需要对给定的字段进行不同的处理，那么应该创建该字段的两个版本，以满足那些不同的目的。处理这些不同目的的另一个选项是将所需的匹配值送到匹配过程，但是在将数据装载到目标系统之前，从摘要中检索初始的源字段值（通过惟一的 Source ID 与摘要相连接）。
• 是否需要解析自由格式的字段（姓名、地址、描述、注释等），并将它们的组成部分装载到目标数据结构的单个域字段中？ 单个域字段可以简化应用程序中详细的查询和候选匹配，但是通常需要重新装配，以生成诸如客户声明之类的输出。在某些情况下，更好的做法是同时使用自由格式的和单个域的字段，以简化输出和查询/匹配。但是，如果将发生匹配处理，至少应该创建某种形式的匹配键文件，以防当只将自由格式的字段（姓名、地址行 1 & 2 等）装载到目标系统时，需要从源数据库记录重新解析这些域。
• 将指定的标准化应用到数据上时，是否所有数据都处理成功？特别是对于自由格式的文本字段，要确保所有字段不但被处理和解析，而且成功标准化特定的解析过的组件。

匹配补救分析

分析当集成和转换数据时，为了创建正确的记录，必须指定什么样的转换来匹配和保留数据。该分析应该利用源系统分析中的实体完整性分析来理解什么链接是可行的以及匹配的原因。

匹配补救分析（Match Remediation Analysis）需要进一步钻取数据，特别是文本字段，从而理解数据中发生的微妙变化。拼写的变化、击键错误、一定范围内的日期的变化（例如临床测试或配药记录日期在门诊病人来访的日期之后）等等，这些都给出了可能会限制匹配和数据关联的条件。在匹配补救分析中，利用实体完整性分析的输出和用于特定字段的频率分布，得出一组要解决的核心问题。这些问题可能包括需要的标准化或数据更正，为标准化分析提供信息，或者只是为数据匹配和存活（特别是用于复合或复杂的服务）而定义的规则。

匹配补救分析通常需要一个能执行复杂记录链接的工具。这些工具通常产生匹配输出，以确定如何匹配或链接记录，并允许洞察匹配记录之间的域的变化。还可以通过源系统分析技术对匹配输出作进一步的分析，以进一步理解域级别的问题，也可以将匹配输出与重复分析的结果相比较，以理解实体级别的问题。

该分析应该帮助回答以下问题：

• 是否有一个规范来描述连接键实体（例如客户和位置）的业务规则？最终，匹配补救分析关注重组和连接数据的标准业务实践。这些业务规则必须从业务的角度说明何时以及如何表述一个实体是相同的。例如，对于一个客户可能有两条主要规则：1）如果姓名和 tax ID 相同，那么这是相同的实体；2）如果姓名、地址和出生日期相同，那么这是相同的实体。但是，可能会有其他的区别导致细微的变化，例如拼写错误。这些规则是产生和回答随后问题的准则。
• 什么数据将用于驱动匹配和存活控制？例如，tax ID 是用来标识惟一实体的极好标识符。但是，如果 tax ID 只出现在一个源文件上，那么 tax ID 对于匹配到一个不包含 tax ID 的数据文件来说没有用。但是，对于有交叉引用匹配的记录，tax ID 可以作为复制到目标系统的字段之一。有助于定义实体的其他字段有：人口统计学信息[姓名、出生日期、性别和其他标识符（D&B # 等）]；地理信息[地址、电话号码、坐标位置（geocode）]；产品或部件信息[产品或部件号、标准产品代码或类别、产品或部件描述]等等。
• 在匹配中如何处理空白或缺失的值？不正确的匹配的一个常见的原因就是缺少足够多相同或不同的值来确定两个记录是否真正相关。例如，如果一个记录中没有 tax ID 和出生日期，惟一剩下的字段是姓名（匹配）和 PO Box 地址（不匹配），那么两个记录很可能被认为是不匹配的。在实际中，那两个记录可能是用于同一个人的，但是由于邮件地址不同，并且没有相同的 tax ID，那两个记录没有链接起来。
• 匹配中如何处理有冲突的键值？如果现实中属于同一个人的两个记录有不同的 tax ID，那么这种冲突可能阻止那两个记录的匹配，因为 tax ID 通常是关键的匹配字段。另一种潜在的冲突是有不同姓名的个人具有相同的 tax ID。同样，由于这些键字段对于标识个人非常重要，这些字段可能被错误地通过一个通用键链接在一起。
• 是否有记录排除在匹配之外？如果记录不包含姓名，那么企业没有理由链接 “未知” 实体的记录。这种链接也是可疑的，因为如果没有姓名，就不能确认这些的确是相关的记录。如果链接的记录没有地址，那么这些记录链接起来后没有商业价值（尤其是当记录用于直接邮递营销时），因为没有地址可用于直接邮递活动。这些记录通常被标识出来，并从匹配中移除，直到可以更新源系统，使之包括一些关键的匹配信息。
• 当两个或更多记录相关（连接），但在一个或多个域上有冲突的值时，如何解决冲突，使之与业务规则一致？有时候，不是创建一个单独的代表性记录，而是保留所有链接的记录，在匹配的记录之间传播最高质量的数据，以便填充缺少的数据或标准化填充的字段值。这种情况下需要创建用于这些填充重叠的存活规则，以确定哪个（或哪些）源将是更高质量的传递给目标的字段值的 “供应者”。
• 重复的记录将被合并到单独的记录中吗？通常，当集成记录时，给定的记录上会存在特定于源的信息，该信息不需要带到代表性目标记录中。要识别出应该将来自哪些源的哪些字段填充到目标记录中。
• 将使用什么标准来合并记录？用于创建代表性记录的存活规则将需要 “链接中断（tie-breaker）” 标准作为每个规则的一部分。这可能是必需的，因为对于给定的字段，可能有多个链接的记录满足最高优先级选择标准。

属性校准分析

确定需要执行什么类型的转换来将一个源项或实体映射到一个目标项或实体。通过在解决方案分析和设计阶段估计数据匹配策略的成功率，SOA 设计者可以确定哪些情况需要使用备选策略或额外的数据准备工作，以确保服务交付需要的服务级别。

与标准化分析一样，属性校准分析利用早期的域和跨域分析，但是这一次，其目的是理解诸如数据类型、长度、精度和等级之类的数据属性或底层的数据格式中的差异，以评估哪些位置没有匹配域，从而发现转换需求，并评估支持校准所需的转换例程。

• 源记录与目标之间是否有一对一的映射？如果没有，则可能需要特定的转换、合并或聚合，以适当地合并数据。通常，对于 SOA 服务来说，更常见的是匹配前面匹配补救分析中提到的策略，但是不排除使用其他转换策略。
• 哪些字段需要转换？通过报告或电子表格，将标识出的输入字段与建立的目标输出列表相匹配，以确定哪些输入字段需要定义转换。对输入信息将映射到的目标字段的需求应该驱动这些决定，但是，如果多个源没有与目标对准，那么也可以考虑修改标准模型和标准消息模型。
• 是否需要聚合数值型数据？如果两个源系统之间或源与目标之间存在不同级别的数据聚合，那么数值型数据尤其需要聚合。早期的域分析可能表明不同等级的数据。而这里的校准将标识出哪些字段需要聚合。

回页首

结束语

SOA 为实现广泛的功能和数据重用提供了机遇。与此同时，SOA 还要求更多的责任，即确保服务实现能满足那些服务消费者要求的服务级别。

本文介绍了一种数据质量计划的执行方法，可以完成数据质量分析，从而提高 SOA 服务的有效性。随后，本文列出了一些基本步骤，详细调查和分析这些问题并做出适当的实现选择。

参考资料

• 您可以参考本文在 developerWorks 全球站点上的 英文原文。
  
  
• IBM WebSphere InformationAnalyzer and Data Quality Assessment：该 IBM Redbooks® 刊物在一个典型的金融服务企业场景中讨论了如何实现 IBM WebSphere Information Analyzer 和相关技术。
  
  
• 在 developerWorks 的 Information Integration 专区，可以获得所需的参考资料以扩展您在 IBM 的 Information Platform & Solutions 产品组合方面的技能。
  
  
• 浏览 技术书店，阅读有关这些主题和其他技术主题的书籍。
  
  

• 下载 IBM 产品评估版，并获取来自 DB2®、Lotus®、Rational®、Tivoli® 和 WebSphere® 的应用程序开发工具和中间件产品。

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

作者简介

		Brian Byrne 在 IBM 六年了，他是过程集成和 SOA 领域中行业模型的主任架构师。Brian 具有大规模分布式系统方面的工作背景，以及在主要的世界银行的 SOA 项目方面有着广泛的客户经验。

		John Kling 是 IBM Global Business Services 的一名 Information Services Practice 架构师。他负责领导大型的客户管理，主要领域有数据质量、数据集成和主数据管理。他目前是一家 Fortune 500 强实业公司负责 SAP 实现的数据小组的主管。

		David McCarty 在法国 La Gaude 的 IBM European Business Solution Center 工作，在为 IBM 客户设计和开发 IT 系统方面有 20 年经验，他当前是 Information as a Service Competency Center 的成员，为在 SOA 解决方案中使用数据系统而开发技术和最佳实践。

		Guenter Sauter 是 IBM 软件组的 Information Platform & Solutions 部门中的架构师。他当前从事 IBM 主数据管理和信息平台技术上的体系结构模式和使用场景研究。不久之前，他是一个架构师团队的主管，负责开发 Information as a Service 的体系结构方法、模式和最佳实践。他是 IBM 的 SOA Scenario on Information as a Service 的技术主管之一。

		Harald Smith 是 IBM Information Management 软件组的一位产品经理，负责数据配置和分析解决方案。他在最近 9 年一直直接参与信息质量工作，包括咨询、产品软件开发和支持。Harald 从事信息技术和解决方案已经超过 25 年，在系统实现、解决方案体系结构、项目方法、数据审计和分析、实体和对象建模以及业务过程重构方面具有丰富的经验。他曾经在软件、金融服务、医疗保健和教育组织中工作过。

		Peter 在三年前加入 IBM，之前在美国国防部、GE 公司和 Morgan Stanley 等机构工作了差不多 25 年，他在那些机构中担任技术领导职位，并在企业体系结构和企业数据集成方面获得了丰富的经验。他加入 IBM 时最初担任 Information as a Service 架构师团队的高级 IT 架构师。他当前是 IPS Global Services 组织的解决方案营销经理，主要研究 MDM 解决方案。

对本文的评价

太差！ (1) 需提高 (2) 一般；尚可 (3) 好文章 (4) 真棒！(5) 建议？

回页首