SOA 设计的信息透视图，第 6 部分: 在 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 项目中完成数据质量评估项目所需的基本步骤。通过分析这些问题，选择适当的实现方式。本文是 “SOA 设计的信息透视图” 系列的第 6 篇文章，下一篇文章将详细描述如何在 SOA 环境中使用相关的 IBM® 产品（WebSphere® Information Analyzer）。

简介

阅读本系列中的所有文章 1. 面向服务体系结构的信息透视图简介 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 计划必须具备的特性。无论公开的是应用程序服务，还是生成的简单数据查询服务，产生的数据对于业务上下文必须是准确和适当的，这样才能提供数据的价值。

数据配置和质量分析（尤其是质量分析）是企业数据体系结构的传统组成部分。设计良好的企业数据环境应该包含一个连续的数据质量改进周期，这个周期分为三个阶段：

1. 识别数据质量问题：
   
   • 寻找由与项目需求相关的业务用户和 IT 用户所引发的数据质量问题。
   • 为与项目相关的每个业务术语和实体定义业务规则和数据质量需求。
2. 度量数据质量水平：
   
   • 分析源系统
     
     • 对来自识别出的数据存储的数据应用数据质量标准，从而确保数据质量水平。
     • 解释数据度量结果并把这些结果转换为业务术语。创建描述数据质量水平的详细报告、图表和汇总，并提出建议。
   • 分析目标系统
     识别分析的源系统和目标系统之间的差距，提出改进建议。
   • 评估每个相关数据元素的一致性和协调性需求。
     在识别出的数据元素上应用数据质量度量，以评估当前的标准化和匹配支持，将这些结果转换为业务术语。创建描述标准化和匹配水平的详细报告、图表和汇总，并提出建议。
3. 解决数据质量问题：
   
   • 识别问题的根源。
   • 根据业务情况，描述特定数据质量改进的过程。

在 SOA 分析和设计中，数据质量分析还起另一个作用，也就是影响服务实现决策。使用自顶向下业务需求识别和设计服务接口之后，下一步是决定如何利用现有系统或编写新代码来实现服务。每个服务向服务消费者公开功能和数据，因此服务必须满足公认的服务水平，包括数据准确性、响应时间等等。这要求服务设计者详细了解服务实现所使用的每个系统中存储的数据的性质。数据质量分析的目的正是了解这些情况。

本文讨论造成数据质量差的原因。介绍如何在 SOA 项目中执行数据质量分析，并推荐一种寻找和研究这些问题的方法。本系列的第 7 部分介绍数据质量分析的概念和详细方法。

回页首

数据质量定义

SOA 中的数据质量可以分为两个维：

• 技术性数据质量维（technical data quality dimension） 定义数据质量标准。数据质量标准常常可以在逻辑数据建模中的实体完整性和引用完整性关系规则中找到。这个维包括跨源系统以及源系统和目标系统之间的比较评估。
• 业务过程数据质量维（business-process data quality dimension） 按照数据质量元素的业务定义定义关键的数据质量元素，以及与元素相关联的业务规则。这个维把数据质量元素的业务需求整合在一起，包括数据质量元素的标准化、匹配和链接等。

这两个数据质量维影响 SOA 服务和过程设计。数据质量分析在使用数据的上下文中对操作性数据的性质进行量化。通过理解这些性质，服务设计者可以确保每个服务满足其服务水平需求，在某些情况下可以识别出问题，进而对服务或底层系统的设计进行修改来满足这些目标。

回页首

数据质量差的原因

在 SOA 项目的分析和设计阶段，识别并正式地指定一组服务，并为实现完成必要的准备步骤。一定要了解需要通过服务公开的数据是否满足业务需求。例如，在为多个存储库中存储的数据指定 retrieveFullCustomerDetails 服务时，一定要了解如何集成来自各个数据源的信息。是否可以访问每个数据源并直接合并产生的信息？这种方式是否有问题？回答这些问题可以为服务的实现提供重要信息。

图 1 给出一些典型的数据质量问题，这些问题可能导致服务设计复杂化。

数据质量对业务决策的影响可能出现在数据定义的技术层面和业务层面。

技术驱动的数据质量问题是由于在数据库中或数据集成期间没有应用技术约束造成的。这些问题包括：

• 无效的数据：
  例如，由于没有应用约束，字母数字数据就能够在数字数据字段（或列）中输入。
• 不完整或缺失的数据：
  由于没有在数据库中应用键约束，必须包含信息的字段却是空的。

业务驱动的数据质量问题是由于最终用户不适当地维护数据造成的。例子包括：

• 不准确的数据：
  当在数据库中输入不准确的数据时，数据质量就会受损。例如，用户为 “Ms. Anthony Jones” 而不是 “Mr. Anthony Jones” 创建了记录，就会不必要地损害数据质量。
• 不一致的定义：
  由于存在不同的数据质量定义视图，不正确地使用数据会导致数据质量差。在 SOA 环境中，创建数据的用户或应用程序不需要了解服务消费者的业务上下文，所以这个问题尤其突出。

为了研究 SOA 项目的数据质量，数据分析师必须全面彻底地了解技术性和业务性数据质量问题，以及它们如何影响 SOA 解决方案。

技术性数据质量维

技术性数据质量维定义在逻辑数据建模实体完整性和引用完整性规则中常见的数据质量标准。这个维可以分为两个级别：领域（数据元素）级和实体级。领域级代表一个原子性组件（一个属性），比如输入日期或性别。实体级代表一个单独的对象，比如人、位置或产品，它由不同的领域或属性组成。在需要把来自不同数据源的信息集中在一起的复杂或组合的服务中，必须在技术和业务上下文两方面考虑这个额外的聚合/实体级。

这个维的关键方面包括：

业务过程数据质量维

根据数据质量元素的业务定义，业务过程数据质量维定义关键的数据质量元素以及与元素相关联的业务规则。

业务过程数据质量维的问题是，许多组织对于相似的数据存在不一致的定义和不同的业务规则。每个业务线对于元素的含义可能有不同的理解。数据的含义总是依赖于：

• 业务领域的上下文
• 应用程序的上下文
• 设计者的选择
• 最终用户的使用方法和实践

而且，在应用程序之间这些情况并不相同。例如：

• 市场部门对净销售额的定义是销售额减去销售开支
• 财务部门对净销售额的定义是销售额减去销售开支，再减去销售退回

因此，当比较来自不同业务线（LOB）的信息时，由于数据质量元素和相关业务规则有不同的视图，就会认为存在数据质量问题。

在构建集成的信息服务来集成来自多个数据源的数据时，如果误解或错误地应用了数据定义，那么察觉到的数据质量问题可能会变成现实。下表描述了在通过 SOA 解决方案中的服务公开信息之前，应该考虑的语义性互操作性问题。

对数据元素应用公认的业务定义和规则，就可以防止不一致数据质量问题。构建一个企业范围的业务术语表和概念性数据模型，可以为整个企业共享数据元素和实体提供一致的标准和规则。

回页首

案例研究

工业领域的一家 IBM 客户实现了一个数据仓库，但是没有进行数据质量分析。这个数据仓库的数据模型基于在需求阶段识别出的属性。这些属性被映射到源系统的逻辑数据模型，从而确保能够在源系统中找到提供给数据仓库的属性。

在数据模型级，所有东西都正常。数据模型由一个业务术语表支持，这个术语表提供每个属性和领域的详细定义，包括有效值。问题在于，遗留系统并不进行数据输入编辑和检验，因此不能确保应用程序中捕捉的数据与逻辑数据模型保持一致。因为很容易错误地使用字段，所以随着时间的推移，输入的数据值逐渐偏离了数据模型中的定义。例如，当需要 “信用批准日期” 却没有这个字段时，用户就使用了一个未使用的地址行字段。 “短名称” 中包含关于客户类型的嵌入信息。

在实现之前，客户的看法是，“我们在这些数据上运行我们的业务。对于数据仓库来说，这样就够了。” 这只说对了一半儿。对于以自己的方式运行业务的特定部分的用户来说，这就够了。但是，经理和分析师依靠基于元数据的报告标题来理解数据的含义，对于他们，这就不够了。这个数据仓库产生的报告和查询反映出了这些缺陷。这使这个数据仓库显得非常糟糕。随着运行报告并识别出缺陷，逐渐纠正了这些问题。但是，修复花费了很多时间，而且也丧失了信任。

数据质量分析可以帮助避免这些问题。与向 ERP 系统进行数据转换相比，这对于数据仓库更重要。对于 ERP 数据转换，在装载过程中 ERP 系统本身的编辑特性会识别出有缺陷的数据。在数据仓库中，情况不是这样的。定制的数据仓库在 ETL 过程中对装载的数据进行的编辑非常少。对于有缺陷的数据，早晚要付出代价。提前进行数据质量分析虽然有一定成本，但是可以避免日后出现更麻烦的局面。

回页首

SOA 项目的数据质量分析

SOA 中的关键组件是服务接口，因为它把底层数据提供给服务消费者。在服务接口公开的数据元素和底层物理数据存储之间，可能有直接的联系，也可能没有。

图 2 的示例给出了不同的服务实现类型以及服务接口和物理数据存储之间的映射。

如果不进行数据质量分析，所有实现方法都容易受到数据质量问题的影响。服务实现类型包括：

• 简单的应用程序服务：服务 A 的实现是一个应用程序 API 包装器。这个服务接口公开的数据是通过应用程序代码从底层数据库获得的。要想了解这个服务的数据质量，分析师首先需要了解服务接口如何映射到应用程序 API，然后了解 API 如何访问底层数据。掌握了这些信息之后，就可以识别和分析正确的数据元素。根据业务逻辑的复杂性不同，仅仅了解持久化层中信息的质量，可能还不足以评估服务层中信息的质量。
• 简单的信息服务：服务 B 的实现是对物理数据库直接进行简单的数据访问。对于这个场景，只需分析服务接口到物理数据的映射，就能够识别出应该分析的数据元素。
• 复杂的信息服务：服务 C 的实现是对相关数据库的数据集成访问。对于这种情况，必须识别数据集成规则并映射到服务接口。掌握了这些信息，分析师就可以判断在进行数据质量分析时应该检查的数据元素。
• 复合服务：服务 D 代表最复杂的情况 —— 复合服务。在这种情况下，数据流要通过服务组合逻辑、服务实现逻辑以及应用程序和数据集成逻辑。分析师必须了解这些组件的所有规则和映射，才能识别出分析数据质量所需的源数据和规则。

了解了每个服务实现的复杂性之后，就需要采用一种结构化方法了解应该在 SOA 项目的什么地方应用数据质量分析。这个结构来自在服务分析和设计阶段执行的数据建模活动。图 3 说明了这个过程：

在 SOA 中，服务设计生命周期是迭代式的，但是从数据设计的角度来看，会有以下一系列活动：

1. 在业务术语表中定义业务术语，这些术语为在所有设计工件中使用的术语提供统一的业务定义。
2. 规范化数据模型定义业务过程和服务建模所用的数据结构、属性和关系。
3. 随着在服务模型中添加更多的细节，开发规范化消息模型，这个模型代表规范化数据模型的物理实例。
4. 针对现有的数据存储，利用 SOA 规范化数据模型和 SOA 规范化消息模型之间的映射，定义数据质量分析目标。使用这些映射识别在服务模型上下文中研究数据质量所需的映射和集成规则。
5. 然后，把数据质量分析的结果反馈到服务模型，从而检验实现决策是否适当，或者是否需要改变设计决策来实现数据质量水平目标。
6. 数据质量分析的结果还可以反馈到规范化数据模型。例如，如果在数据配置期间发现有隐藏的属性嵌入在文本字符串中，就可以修改规范化数据模型，把它们变成显式的属性。

所以，在进行数据质量项目之前，一定要记住以下要点：

• 根据公开数据的服务接口评估数据质量。
• 数据质量分析的主要目标是回答以下问题：“计划中的服务实现能够提供让服务消费者满意的数据质量水平吗？”

回页首

为 SOA 项目执行数据质量分析的方法

对于 SOA 项目，数据质量分析方法与其他项目的数据质量分析相似，但是在任务细节方面有一些差异。要想获得成功，数据质量分析本身必须被视为 SOA 项目中的一个独立项目。

每个项目应该包含以下任务：

1. 定义范围：

服务模型是企业数据的最终定义，这就是数据分析的范围。数据质量分析的第一个活动是，把这个范围从 “可以” 检查的东西缩减到 “将” 检查的东西。

• 审查服务模型接口，了解它们如何映射到物理数据存储。
• 与业务和 IT 主题问题专家进行会谈，识别重要的实体和数据元素。不需要寻找与数据质量相关的所有列、字段和元素，只需要找到影响信息结构和信息理解的那些元素。数据分析师要与业务领域专家和应用程序专家协作，评估哪些数据元素对于数据质量分析比较有意义。

2. 审查现有的数据质量信息：

收集并审查数据元素和实体现有的数据质量信息。这包括以前的正式数据质量分析结果、用户报告的数据质量问题以及主题问题专家指出的问题和意见。这个任务的目标是，通过利用已知信息减少所需的工作量，确定以后工作的优先次序，避免重复。

3. 识别项目级数据需求：

在 SOA 分析和设计期间识别服务时，会同时收集功能性和非功能性需求，以便定义每个服务的服务水平协议。数据分析师应该参与这个过程，确保其中包含高水平的数据质量需求。然后，使用这些需求制定项目评估和分析所用的数据质量标准。这些标准包括本文前面描述的所有技术性和业务过程数据质量问题。应该从业务和 IT 两方面审查产生的标准，确保其完整性。

解决解决方案中的所有数据质量问题往往是很艰巨的任务。既然资源是有限的（人或产品），那么如何把注意力集中在最重要的数据上呢？要分析多少数据？因此，在收集数据质量标准的同时，应该根据每个问题的严重程度以及相关联的业务风险，确定它们的优先次序。

4. 设计数据质量分析执行计划

识别出数据质量标准之后，数据分析师就必须设计执行计划。这需要确定：由谁执行这个计划、由谁进行测试、使用什么测试工具、什么时候进行测试以及计划应该产生什么输出。数据分析师必须清晰地了解要实现的目标以及需要交付的工件，从而确保有效地执行计划。

在执行计划中，需要确定满足项目级数据需求所需的测试。一些测试可能是手工的，比如审查收集到的模型以确保了解技术领域。一些测试可以实现为查询，或者在规定的项目时间框架内通过配置数据质量分析和配置工具来完成。测试应该检查识别出的数据质量问题并生成量化的结果。

在执行计划中，数据分析师必须确定运行测试所用的数据集，还要确定谁对这些数据集有访问权。要想获得最准确的结果，就应该针对完整的生产数据进行测试。但是，由于许多原因，这常常是不可行的，比如工作负载限制、安全性和隐私规则，或者大部分数据是未知的。在这样的情况下，数据分析师必须从现有的测试数据或生产数据生成有代表性的数据样本。如果这样做，就必须仔细审查测试的结果，从而确定哪些问题如实地反映了生产数据中的问题。

还必须考虑数据集的安全性和授权。一定要确定哪些人可以执行特定的测试，以及是就地执行数据分析，还是通过数据提取进行分析（尤其是对于生产数据）。

5. 执行数据质量分析

对于 SOA 项目，执行数据质量分析的过程与其他项目的数据质量分析相似。这个分析过程可以减少项目风险和成本，并提供更准确的项目范围。

在这个任务中，要执行测试并收集结果。具体过程依赖于所用的工具。如果执行的时间比较长，那么必须确保时间和数据同步问题不会造成虚假的错误。

通常，完整的数据评估分为三个阶段。表 5 给出在每个阶段执行的分析步骤。本系列的第 7 部分将详细地定义和描述这些步骤。

6. 分析和报告结果

在这个任务中，对结果进行整理、注释和总结，以便向业务和项目团队报告和进行讨论。尽管具体的格式依赖于工具，但是结果常常由汇总表和图组成，可以从这些图表向下钻取到详细数据。如何以及由谁报告结果应该在数据质量分析计划中提前指定，并在执行计划中明确说明。数据分析师应该确保为结果创建一致且标准的注释。如果不这样做，就可能给别人带来不必要的审查，还可能导致重新进行测试。

如果结果不满足识别出的需求，或者结果与预期不一致，那么可能有必要重复测试或增加补充性测试，以便解释结果。与其他项目一样，这些额外的测试可能会改变范围，必须审查它们对项目进度的风险和影响。使用自动化工具可以帮助应对这样的范围扩展，避免显著影响项目的进度。

如果发现了重大的问题，SOA 设计者可以选用三种处理方法：

• 修改服务实现来解决数据问题。
• 请求在 SOA 项目团队之外进行修改。这可能会促使在组织中发起企业数据质量活动（如果还没有的话）。
• 对于无法满足业务服务水平需求的服务，可以选择不公开它们。

回页首

结束语

SOA 为功能和数据提供了广泛的重用机会。这种自由也带来了更多的责任，必须确保服务实现能够满足服务消费者所需的服务水平。

本文描述了影响 SOA 服务效果的数据质量问题。讨论了在 SOA 项目中进行数据质量评估并分析这些问题所需的步骤，从而帮助您做出适当的实现决策。

本系列的第 7 部分将详细讨论数据质量分析模式。

参考资料

• 您可以参考本文在 developerWorks 全球站点上的 英文原文。
  
  
• IBM WebSphere InformationAnalyzer and Data Quality Assessment：这份 IBM Redbooks® 讨论如何在典型的金融服务业务场景中实现 IBM WebSphere Information Analyzer 和相关技术。
  
  
• 通过 developerWorks 上的信息集成区域 中的参考资料提高自己在 IBM Information Platform & Solutions 产品组合方面的技能。
  
  
• 浏览 技术书店，寻找关于这些主题和其他技术主题的图书。
  
  

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

• 参与 developerWorks blog 并加入 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) 建议？