内容


SOA 设计的信息透视图,第 8 部分

在 SOA 设计中使用 IBM WebSphere Information Analyzer

Comments

系列内容:

此内容是该系列 # 部分中的第 # 部分: SOA 设计的信息透视图,第 8 部分

敬请期待该系列的后续内容。

此内容是该系列的一部分:SOA 设计的信息透视图,第 8 部分

敬请期待该系列的后续内容。

简介

WebSphere Information Analyzer 是可以发现已有数据存储的质量问题并对其进行概要分析的工具。它还可以帮助用户执行源系统与目标系统之间的差异分析。

WebSphere Information Analyzer 的主要优点有:

  • 更好地理解数据源结构、内容和质量
  • 在项目整个生命周期内进行评测并报告数据质量
  • 消除整个企业内出现坏数据的风险和不确定性

本系列之前的文章已经解释了在 SOA 服务设计期间分析数据质量的重要性,以及实现方法。其目的是评估服务实现在数据质量方面是否将满足要求的服务级别,以及是否需要附加的数据转换或数据清理操作。无论服务类型是什么,或选择什么样的实现,这种评估都是有必要的。考虑一个例子:一个服务聚合来自多个系统的信息。

无论选择什么集成方法 – SOA 还是数据集成 – 都需要理解被集成的数据。您是否具有可用于跨多个系统匹配数据的键或标识符?如果有,是否需要处理缺失或重复的记录?WebSphere Information Analyzer 可以确定有问题的数据集的特征,以便基于充分的信息最有效地做出决定,并有效地将它们集成起来,产生完整、准确的结果。

最常见的情况是,这些存储是关系数据库,不过 WebSphere Information Analyzer 也支持 XML、平面文件和其他结构化文件类型的分析。

WebSphere Information Analyzer 利用 IBM Information Server 的统一元数据储存库。由于这个储存库是在所有产品之间共享的,当使用 WebSphere Information Analyzer 进行数据概要分析时,表定义和概要分析信息(例如主键和外键实例、违反约束、标注等)可以为 DataStage and QualityStage Designer 中的 Information Server 用户所用,如图 1 所示。

图 1:对 WebSphere DataStage 中的分析细节的元数据访问
图 1:对 WebSphere DataStage 中的分析细节的元数据访问
图 1:对 WebSphere DataStage 中的分析细节的元数据访问

IBM Information Server 的统一元数据管理平台还提供很多用于性能和可伸缩性的服务,WebSphere Information Analyzer 可以利用这些服务。例如,WebSphere Information Analyzer 用户可以使用它提供的常见的调度服务来确定执行概要分析的时机。

注意:本文不会详细论述基本的产品使用,而是主要关注 WebSphere Information Analyzer 产生的支持 SOA 中数据质量分析模式的信息类型。用户手册和 IBM Redbook 中提供了关于产品使用的信息:IBM WebSphere Information Analyzer & Data Quality Assessment(参见 参考资料)。

数据质量分析的项目方法与 WebSphere Information Analyzer

第 6 部分 所述,数据质量分析本身必须看作更宽范围的 SOA 项目之内的一个项目。建立一个特定的分析范围,有助于将焦点放在那些对于项目成功至关重要的数据源上(例如,用于具有法律或金融风险的服务或错误恢复的代价较高的服务的数据)。使用像 WebSphere Information Analyzer 这样的工具并不会消除对有效处理(包括适当的目标构造)的需求。用于执行数据质量分析的资源和时间是有限的,而最终目标是交付拥有支持 SOA 功能的数据的 SOA 服务。

WebSphere Information Analyzer 和底层的统一元数据架构为在一个更大的上下文中组织工作和保存获得的知识提供了框架。

  • 共享的元数据:WebSphere Information Analyzer 合并并共享 Information Server 的元数据储存库中关于数据源的信息,包括连接、模式、表和列定义。这提供了一个容易理解的元数据位置。图 2 显示了储存库中可用的丰富的元数据。这可能包含数千个模式和表,以及数百万个来自不同数据库和文件的列。
    图 2. IBM Information Server 中的共享元数据
    IBM Information Server 中的共享元数据
    IBM Information Server 中的共享元数据
  • 基于项目的结构:WebSphere Information Analyzer 使用基于项目的方法来进行分析,这使用户可以根据需要来分离他们的工作,例如根据业务单元、SOA 或数据集成项目,或者任何其他所需的配置。项目结构允许基于角色的用户配置,并且可以将特定的数据源包含到分析中。在项目中,安全性和设置也是可配置的,这样便可实现前面所述的访问级控制。在诸如 SOA 之类的项目上下文中,这样的分离是很重要的,因为它允许将分析的范围缩小到对分析比较重要的数据源上。这有助于使分析集中于重要的东西,而不是试图翻遍所有潜在的数据源。当发现新的信息,或者需要包含新的源时,项目框架为添加它们提供了便利。
  • 审查状态(Review Status):WebSphere Information Analyzer 允许在每个分析级别跟踪分析审查,并提交到项目级别。这种方法便于洞察定义的工作范围是否已经完成,或者是否仍有未解决的项,如图 3 所示。
    图 3. WebSphere Information Analyzer 中的项目审查状态
    WebSphere Information Analyzer 中的项目审查状态
    WebSphere Information Analyzer 中的项目审查状态
  • 图形化支持:WebSphere Information Analyzer 同时包含数据的文字表示和图形化表示。这使得用户可以以多种方式查看信息,从而快速发现问题或异常,并相应地标注这些发现。
  • 标注(Annotation):通过在整个 WebSphere Information Analyzer 中使用标注,可以捕捉特定的细节和发现,扩展给定列或表的知识库。使用标注状态标志可以跟踪和报告问题审查(如图 4 所示)。
    图 4. 在 WebSphere Information Analyzer 中跟踪注释的状态
    在 WebSphere Information Analyzer 中跟踪注释的状态
    在 WebSphere Information Analyzer 中跟踪注释的状态

在 WebSphere Information Analyzer 中,项目主管可以使用正确的数据、具有适当角色的适当用户和用于管理分析周期的框架,为 SOA 数据质量评估建立合适的上下文或焦点。不过,过程和人员仍是成功的关键。

数据概要分析并不神奇 —— 它帮助揭示数据质量问题,但是仍然需要一个数据或业务分析师或者主题专家来对结果加以评价,并得出适当的结论。分析师必须理解项目的范围和目标。如果他们不知道 SOA 项目的目标,那么就不能发现将对项目造成影响的真正问题和异常。分析师必须清楚他们要得到什么,以及需要交付什么。他们需要一种方法来对结果作出一致、标准的标注,以便从事该项目的其他人能理解标注的意义。分析师还必须理解,概要分析不是这个过程的目的 –- 分析才是关键。有些分析师倾向于认为一旦运行 WebSphere Information Analyzer 过程,就会执行数据概要分析和数据质量评估。数据概要分析只是便于快速洞察大量的信息并作出推断,仍然需要由分析师来解决问题并确定下一步做什么。

使用 WebSphere Information Analyzer 进行数据质量评估

SOA 解决方案通过服务公布数据。服务实现有多种形式,从应用程序 API 的重用,到封装的数据查询,再到自定义编写的代码,但是在任何情况下,服务的设计者都必须确保所公布的数据满足服务消费者的要求。当在已有的数据源上执行数据质量评估时,需要尝试理解数据的结构(例如,它的数据类型和关系),并试着理解现有数据对这些结构的遵从情况。

几乎所有的数据集都包含不规则和异常的数据。例如,如果一个列的数据中有 99% 都是 25 到 30 之间的一个整数,那么在此范围之外的任何数据都值得怀疑。因此,需要识别统计性异常和物理结构信息。

另外,还需要寻找内嵌的业务规则或逻辑,它们告诉访问数据的应用程序要接受对某个业务术语的某种形式的异常处理。例如,如果查看某个字段时发现,该字段中有一个像 -9999 这样的数字,那么完全有可能是一个程序的指示符,它告诉该程序从其他地方寻找本应在这个字段中的数据。大多数初始的评估发现,将近 15% 的遗留数据有某种形式的内嵌逻辑或异常处理。

简言之,就是要确定数据现有的状态,并确定它满足将在 SOA 解决方案中公布它的服务的数据质量需求。另外,如果数据当前不满足这些需求,还需要确定重新实现或标准化、清理和充实数据的工作量和复杂度。

在一组 SOA 需求的上下文中执行数据分析的过程非常类似于数据质量项目。WebSphere Information Analyzer 的过程和使用是一样的。这种结果分析可用于降低项目风险和成本,并提供更准确的项目范围。

第 7 部分 所述,当执行完整的数据评估时,通常需要考虑 3 个阶段。表 1 给出了每个阶段中执行的分析步骤。

表 1. 数据分析的步骤
源系统分析目标分析校准和协调分析
  • 技术维 - 域级
    (元数据、域、结构
    和关系完整性,以及业务
    规则评估)
  • 技术维 – 实体级
    (实体完整性)
  • 属性差异分析
  • 数据差异分析
  • 字段长度分析
  • 数据迁移范围界定
  • 属性校准分析
  • 标准化分析
  • 匹配补救分析

源系统分析可以使用 WebSphere Information Analyzer 中提供的技术来解决,这也是本文关注的焦点。目标分析方面可以通过 WebSphere Information Analyzer 来识别,本文对此也将加以讨论。WebSphere Information Analyzer 可以提供对校准、标准化和匹配技术的输出的审查,不过本文没有讨论这一点。在接下来的小节中,我们将更详细地描述可用于为前两个阶段中的分析提供便利的技术。

使用 WebSphere Information Analyzer 的源系统分析

为什么要做源系统分析?很少有 SOA 解决方案是作为全新的信息系统开发的 —— SOA 解决方案几乎总是要利用已有的应用程序和数据。通过开发可重用的服务,谨慎地公布已有系统的功能,企业就可以发展它的 IT 功能,以便更好地适应变化。只有理解所公布的源数据的性质,SOA 服务设计者才能实现这个目标。对于每个数据源,可以执行以下类型的分析。通过这些分析的结果,可以洞察支持 SOA 解决方案的已有数据的价值和完整性。

可以应用下面的技术来评估域级技术维:

  • 频率分布
  • 域完整性(或列内容分析)
  • 结构分析(或 Key Analysis)
  • 关系分析(或 Cross Domain Analysis)
  • 业务规则评估
  • 元数据完整性(或 Business/Technical 文档)

频率分布

频率分布是由 WebSphere Information Analyzer 自动生成的,作为执行列分析的一个核心工件。频率分布存储在元数据储存库中,其形式为一组不同的值和与之相关的出现次数计数。在屏幕上,频率分布表现为一个图形或数字图像,显示一个列或域中的值的分布。频率分布是随后的分析步骤的基础。图 5 中的屏幕截图显示了频率分布的图形化表示,并显示了由一个值对支配的高度倾斜的集合。

图 5. 频率分布图形化视图
频率分布图形化视图
频率分布图形化视图

域完整性(或列内容分析)

频率分布是统计性计数。WebSphere Information Analyzer 根据数据值的分布和特征作出推断。这些推断包括基本数据类别的识别、数据类型、长度、数值型值的精度和等级、惟一性以及基本格式模式的识别。分析师使用这些推断和基本频率分布来评估域或列的完整性,并报告得到的发现。

虽然分析师可以通过给定的数据源直接逐列地进行分析,但是 WebSphere Information Analyzer 会产生一个数据分类,以帮助更有效地组织信息,尤其是在处理较少见的数据源时更是如此。图 6 显示了列分析总结屏幕,其中突出显示了为组织数据审查而按照推断的数据分类存储的列。

图 6. 列分析总结:数据分类
列分析总结:数据分类
列分析总结:数据分类

WebSphere Information Analyzer 使用 7 个主要的数据分类,如下所示:

  • 标识符(Identifier)— 一组高度惟一的不同值,基于设置的阈值,每个值具有较低的频率
  • 指示符(Indicator)— 一组二进制值(例如 0/1、True/False、Yes/No)
  • 代码(Code)— 一组有限的值(通常具有有限的数据长度,并以某种频率出现)
  • 量词(Quantifier)—一组数值型值,表示诸如数量、价格、薪水之类的项
  • 日期(Date)— 一组基本上使用日期格式的值
  • 文本(Text)— 不属于其他分类的一组由字母数字组成的字符串值
  • 未知(Unknown)— 没有适合的数据来分类的列

通过使用这些被分类的数据,对于每种数据类别,都可以将数据分析集中于关键的元素。例如,类别为 “未知” 的数据通常表明一个列只有 null 值或者为空,可能不被使用。在大多数情况下,这些列可以忽略,因为这表示它们不重要,或者缺少完整性检查。但是,也可能会发现服务通过标准数据模型使用这个列。在这种情况下,就会存在差异,分析师必须记录和报告该问题,以便作进一步的调查。这可以通过 WebSphere Information Analyzer 的 Notes 特性,在生成的报告中添加注释或者通过共享的元数据来完成。

下面是使用 WebSphere Information Analyzer 情况下,基于特定数据类别的源系统分析的核心焦点和期望。

表 2: 基于数据分类的域分析
数据类别完整有效一致精确 & 可理解惟一
标识符 总是被填充 在有效范围内,没有默认值 固定的格式(所有值都具有相同的格式) 有定义 总是惟一
指示符 两个值,总是被填充,不使用 null 没有异常或无效的值;倾斜分布 固定格式 简单而清晰的值;有定义 不适用
代码 有限的值,没有默认值 在有效的引用集合内;倾斜分布 标准表示(每个业务值只有一个代码) 有域和代码的定义 不适用
量词 没有默认值 在有效的引用集合内;倾斜分布 标准数据类型 有定义 不适用
日期 总是被填充,没有默认值或 null 在有效的引用集合内;倾斜分布 标准数据类型 有定义 不适用
文本 总是被填充,没有默认值或 null 可能存在嵌入式业务逻辑或无效的值 没有预期的格式;标准格式优先;没有混合的域 有定义 一般是惟一的

WebSphere Information Analyzer 中的分析方法随 SOA 项目的需要而变。注意,这里获得的发现要输入到差异分析(预期的源中缺少数据或数据不一致)和校准分析(数据没有标准化的或一致的格式)。目的是回答对域级别技术维评估的相关核心问题,并编制文档。由于项目受到资源和时间的约束,该分析常常集中于主要的数据元素和域。

域的审查和分析

域分析是一个详细的输出,它显示一个源存储中任何特定列的内容。它可以告诉我们是否缺少值,或者是否存在生僻的值。在 图 3 中,通过查看不同的值,可以快速评估完整性和有效性。

  • 是否有缺失的值?这可能以 Null 值或其他空白值(例如空格)的形式出现。对于大多数字段,Null 值不是预期的值,但是在输入数据时,编辑可能允许输入那样的值,以表明未知的情况(例如,不知道社会保险号,或者没有一致地收集社会保险号),或者表明不具备处理条件(例如,表中有一个创建日期,但是没有填充)。
  • 是否有默认的数据?这可能以特定的设置值(例如所有的 9 或 ‘Do Not Use’)或空白值(一个空白表示一个按键,这不同于一个 null 值)的形式出现。对于复杂或复合的服务,这些可能会大大损害正确链接数据的能力。例如,社会保险号可能会触发内部财务条件,例如一个破产状态,处于此状态的所有帐户都有相同的默认值。另一个例子是,出生日期必须默认为一个实际的有效日期,例如当年的 1 月 1 日。不管何种情况,频率较高或倾斜的数据需要这种用法。
  • 数据是否为常量?这表明一个列中的大多数数据都是相同的。这可能表明使用了同类的填充,但是允许系统将来的增长,或者可能反映元素基本上是默认的条件。
  • 数据是否惟一?这表明所有数据或大多数数据只出现一次,是惟一的。最常见的惟一的域是一个标识符,它是潜在的数据的键,但是也包括基于文本的描述。
  • 数据是否倾斜?如果频率分布显示数据值从经常出现变为很少出现,则存在倾斜。这样的倾斜可能是正常的(例如在产品价格范围中),可能表明特定数据中的常态(例如 OBGYN 的女性病人),可能表明有生僻的情况(例如罕见的疾病代码),或者可能存在有效性问题。

对值的检查只是分析过程的第一步。这里需要捕捉和报告定义、标注和决定,以便将来使用,包括用于其他的分析步骤、给关键用户的报告、将实际的 SOA 过程放在一起,或者在构建长期的知识库时使用。

在 WebSphere Information Analyzer 中,可以直接在 Frequency Distribution 文本屏幕上添加定义,如图 7 所示。考虑这里给出的值,想想看到这些值的人对它们的理解程度如何。在下面的例子中,如果没有上下文或定义,‘C’ 可以表示 ‘Complete’(正确的定义)、‘Created’ 或 ‘Cancelled’。对于性别字段,考虑哪组值容易理解:M/F 还是 0/1?在后一种情况下,需要附加的上下文(可能没有提供)来断言 ‘0’ 是等于男性还是女性。分析师添加的定义可以为这种知识共享提供便利,并提高域的可理解程度。

图 7. 数据值定义
数据值定义
数据值定义

通过 Domain and Completeness 屏幕,可以根据特定的值、范围或通过一个引用表做出关于值的完整性和有效性的决定。数据分类可以帮助简化域的评估。代码值很可能在一个引用表中。量词和日期很可能有一个有效范围。指示符或标志值很可能只有有效和无效两种值。在此,分析师与主题专家协作,对这些值和可用的参考资料进行检查,并增加适当的决策。

图 8 突出显示了这个评估,它也可以生成报告,供业务分析师和专题专家审查,或者直接并入到引用表中,供 SOA 开发人员使用。

图 8. 数据值完整性和有效性
数据值完整性和有效性
数据值完整性和有效性

在整个审查过程中,可以在 WebSphere Information Analyzer 中添加对于任何列或表的标注。这些标注可以提出或回答问题,记录决定,以及跟踪问题状态或进度。图 9 突出显示了用于一个给定列的标注条目。

图 9. 标注条目
标注条目
标注条目

随着时间的推移,针对一个给定源的知识库会增加这些标注。这些标注不仅提供关于列或表的特定信息,而且还可以跟踪一个给定源的进度或状态。上面的 图 4 显示了一个报告实例,它按照标注状态(例如打开、暂挂、关闭)跟踪标注。

域结构分析

关于结构一致性和数据精度的问题,是通过查看列的数据属性的定义和推断来回答的。通常,这可以从是否存在混合数据类型或混合格式看出。字符串数据长度的变化或数值型数据精度和等级的变化也表明在数据的表示、验证和使用上存在潜在的问题。

WebSphere Information Analyzer 的 Column Analysis 细节的 Properties 视图是一个相当复杂的输出(图 10),从中可以看到数据类型、物理结构/表示、是否为空等,既有它们原有的定义,也有基于实际的数据内容作出的推断。通过选择和记录最适当的数据类型、长度、精度或等级,分析师可以提供重要的信息给 SOA 项目中的设计者和开发人员,从而可能为标准数据模型提供反馈。

图 10. 数据结构和属性分析
数据结构和属性分析
数据结构和属性分析

键结构分析

WebSphere Information Analyzer 从惟一性、null 值和重复等方面自动评价所有单个的列,看是否适合作为主键,以避免在列分析之后仍要对单个列作进一步的处理。用户可以将分析扩展到多个列,利用前面提到的内建的虚拟列支持。通过这种功能,分析师可以根据数据样本评价很多的列组合,或者根据所有数据评价特定的目标组合。评价结果立即显示出来,使用户可以快速理解重复的值,或者回过头查看单个或多个列的全部频率分布,如图 11 所示。

图 11: 重复检查结果视图中的主键分析
图 11: 重复检查结果视图中的主键分析
图 11: 重复检查结果视图中的主键分析

关系分析

在外键分析中,WebSphere Information Analyzer 支持测试和查看来自相同数据源或跨不同数据源的表之间的主-外键关系,以帮助解决数据集成的问题。用户可以从早期的分析步骤获取定义的元数据或推断。而且,这种分析是累积的,用户可以只关注特定时间特定位置的感兴趣的项,然后在必要时扩展分析,以评估其他的键关系。外键分析得出的详细信息使用户可以理解实际值的重叠,并快速消除差异。

WebSphere Information Analyzer 在 Foreign Key Analysis 包括一个显式的引用完整性测试。主键与外键之间的冲突,例如孤立的值或没有子记录的父记录,都可以查看到,如图 12 所示。

图 12: 引用完整性分析
图 12: 引用完整性分析
图 12: 引用完整性分析

内嵌的业务规则

该分析确定已有的数据源在什么地方被断开,并在数据本身中包含内嵌的逻辑。如果一个列连续地包含值 -9999,那么这是向使用该数据的程序表明需要执行备选的处理。这是包含在列中的内嵌式业务逻辑,WebSphere Information Analyzer 中有些技术可用于评估这种逻辑。

首先,通过 Column Analysis detail format 屏幕查看已有的数据格式(或实际的域值),这样可能揭露不寻常的情况,例如前面提到的值 -9999。对于姓名、地址和产品描述等文本数据,查看可变的数据格式是识别包含多个域的字段的关键。如果存在多个域,那么在校准和协调分析中,应该将这些字段标注为需要进一步标准化。图 13 突出显示了地址中嵌入的 “Care of” 信息和 ‘*’ 形式的可能的处理逻辑。

图 13: 数据格式分析
图 13: 数据格式分析
图 13: 数据格式分析

其次,WebSphere Information Analyzer 允许将多个列连接到一起,形成虚拟列。用户可以使用表中任意的列组合构造虚拟列,然后依次分析那些虚拟列。例如,用户可以评估州-邮政编码对,以查找不常见的格式,甚至可以比较多个虚拟列,以发现公共的域值。

对这些虚拟列的分析与任何其他列一样,通过这种分析可以洞察域值、格式和属性。对键的洞察可能包括:不完全的组合(需要数据的地方缺少数据或只有 null 值)、无效的组合(例如州代码和邮政编码组成的不兼容的组合)或潜在的重复数据(多次出现一个社会保险号和出生日期组合)。

第三,通过在 WebSphere Information Analyzer 中设置不同的数据片段(通过使用表的 Analysis Where 子句选项),可以专门地针对不同的数据范围查看一组列值。这可以基于特定的值来完成,例如源系统或帐户类型、日期范围或其他基于查询的条件。建立一个 Analysis Where 子句之后,列分析像平常一样,从实际的概要分析开始,一直到数据查看。在这种情况下,根据选定的数据片段,会突出显示特定的业务逻辑。

元数据完整性(或业务/技术文档)

这个过程帮助使用前面的所有分析为当前数据源编制文档。该过程也可以从 WebSphere Information Analyzer 中丰富统一元数据库中的元数据,以便与 WebSphere Business Glossary 或 WebSphere DataStage/QualityStage 任务共享。这个文档可用于需求说明、功能说明和其他信息服务文档,还可以编写开放的问题。

通过 WebSphere Information Analyzer,每个源列或表可以添加别名、定义和业务术语,如图 14 所示。这个过程有助于在后面的属性或数据差异分析中通过定义的术语将数据源映射到目标模型。

图 14. 将业务定义添加到技术性元数据中
将业务定义添加到技术性元数据中
将业务定义添加到技术性元数据中

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

  • 关于每个源系统所有方面的一组完整的报告,这些报告向初始的企业和技术社区显示源数据的一个初始的概述。
  • 通过对结果进行分析,可以捕捉文档,并将其用于很多上下文中。
  • 为功能和技术规范提供内容的映射规则规范
  • 发现需要企业去解决的内容和问题的文档
  • 可在未来的项目或组织的其他领域中使用的信息
  • 项目范围界定和对数据转换工作的初始风险评估
  • 可以将数据提取加速器重复用于基准评估和开发

使用 WebSphere Information Analyzer 进行目标系统分析

对于 SOA 项目中的数据分析,“目标系统” 具有以下的可能性:

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

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

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

属性差异分析

分析是否能适当地定义目标实体和属性,以及是否可以从已有的源系统映射那些实体和属性。如果目标实体已经存在,则可以使用 WebSphere Information Analyzer 的 Cross-Domain Analysis 来评估这些属性关系,并识别出潜在的差异。

在图 15 中,查看了两个源之间的实体,查找重叠和潜在的映射,包括值中可能的差异(成对的列中有 673 个不同的值不在基本列中)和字段长度的差异(一个列的精度是 8 位,一个列的精度是 9 位)。

图 15. 跨域一致性评估
跨域一致性评估
跨域一致性评估

通过使用 IBM Information Server FastTrack 产品,可以进一步简化属性差异分析和映射。

数据差异分析

该分析确定现有的源数据是否能完成目标模型,以及是否需要执行大量的转换。图 16 是数据差异报告的一个例子。这是已有源之间的一个示例概要分析。这个报告量化地显示已有系统中哪里有重叠,以及每个方向上的重叠程度。例如,该报告指出,基本表 ITM_MSTR 中的 Supplier 列完全映射到 ITM_SPLR 表中成对的 Vendno 列。这个报告跨多个表,它可以表明数据之间的支持程度。

图 16. Cross-Domain Analysis 域比较报告
Cross-Domain Analysis 域比较报告
Cross-Domain Analysis 域比较报告

字段长度分析

字段长度分析是分析当前的源系统是否能在字段长度上与目标模型映射。如果不能,那么在映射阶段必须执行转换。这可以为数据架构师提供反馈,以便必要时校准标准数据模型。该信息可以从 图15 中显示的报告中得出。

数据迁移范围界定

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

结束语

任何 SOA 解决方案要想获得成功,它的服务必须交付准确的数据。本文描述了 WebSphere Information Analyzer 如何通过源系统和目标分析,帮助确定计划的服务实现是否达到了目标,即交付来自已有数据源的受信任的信息。


相关主题


评论

添加或订阅评论,请先登录注册

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=Information Management, AIX and UNIX
ArticleID=344316
ArticleTitle=SOA 设计的信息透视图,第 8 部分: 在 SOA 设计中使用 IBM WebSphere Information Analyzer
publish-date=10102008