使用 Rational Data Architect 集成数据源

领测软件测试网 信息的集成无疑是具有挑战性的。许多的业务决策都需要文档化，许多变革都要执行。IBM Rational Data Architect可以帮助你文档化你的决策，并且这个过程的一部分是自动完成的。通过学习这篇文章，你可以了解只用五个步骤进行联邦设计的一个工具支持的过程。

简介

当你试图集成数据源时，你需要考虑许多活动。Rational Data Architect可以帮助你进行文档化决策，并且自动执行你的部分任务。在这篇文章中，向你介绍了一个你可以使用的过程，你可以根据你的特定数据集合需要作相应的更改。这篇文章中提到了一个成功设计所需要的五个步骤，他们是：

1. 注释现有的基础构架
2. 在数据源之间做映射
3. 建立一个联邦模型
4. 映射联邦数据源
5. 产生联邦代码

 

回页首

Rational Data Architect产品概览

Rational Data Architect是一个数据建模，集成设计工具，被用来帮助数据架构师理解信息资源，他们之间的关系是相互依赖的，资源之间是相互映射的，并且建立集成的计划。为任何大小的团队建立构架，Rational Data Architect 通过映射发现和模型来集成数据建模，并进进行数据库分析——所有都在一个单一的工具中完成。另外，Rational Data Architect支持企业标准的执行。Rational Data Architect 使用一个不同种类的方法——促进联邦设计，它是一个信息集成项目的经典工具。

Rational Data Architect提供简化设计和开发时间的工具。这个新式的软件建立在开放的Eclipse平台之上，它可以帮助构架师在多样的信息源基础上进行建模，发现，映射和分析数据，并且可以在复杂的环境中自动的进行信息集成。

注释现有的基础构架

五个步骤中的第一步是帮助用户评估他们现有的情况。虽然这个阶段的很多过程都是自动执行的，但是像逆向工程等等这些过程还是需要手动完成的，因为每一个注释都是根据它出现的概率推测出的。让数据源最初的设计者和数据源的用户参与这个步骤是很重要的。

注释你现有的基础构架：

1. 连接到现有的数据源。

   为了访问数据结构，你需要遵守标准连通性协议。 你需要了解数据源的类型，连接到它的驱动程序以及注册信息（大多数情况需要注册和密码）。 Rational Data Architect使用标准的JDBC连通性去连接数据源。 数据源之间所有深层次的交流都是使用数据源系统表的本地查询来实现的。

2. 从数据源中选择可用数据结构的子集。

   很多数据源包括的数据都是和存储信息无关的，例如计数器，用来分类数据的临时助手以及用户接口的多种语言文本。在这个步骤的开始消除这些数据结构是件非常简单的事情。

   Rational Data Architect允许在Database Explorer的任何数据结构层级进行过滤操作，如图1所示： 我们准备定义一个只允许相关信息的过滤器。

   
   
   图1：连接到数据源。
   
   
   
   
3. 在所选的子集中建立一个模型。

   从数据源建立模型有两个原因：

   • 大多数据库不能够捕获到一个成功集成过程所需的详细程度的业务相关注解和文档信息。

      

   • 变更管理。集成需要被设计在一个稳定的数据构架之上。一旦数据源的结构发生了变化，你就需要为集成执行更新的操作，从而产生一个新版本的模型。
   从数据源建立的一个物理的数据模型基本上是一个数据源数据结构的摘要拷贝。察看图2：

    

   
   
   图2：建立物理数据模型
   
   
   
   
4. 在模型中文档化数据结构。

   当一个模型显示大多数层级的数据源规范细节时，这对我们理解数据是不够的。 例如，CLNR中的CHAR(16)并不是会被每一个开发人员使用相同的方式解释。 在这种情况中，你把文档添加到模型的每一个元素中，包括每个列，每个表，每个约束和每个触发器。 你应该列出业务相关的名称，这样可以允许模型具有更好的可读性。

   同样我们强烈建议你建立背景相关的图表。但是这不意味着你要建立一个从很多会议室墙壁上收集来的巨大图表。 取而代之的是你应该使用大约七个要点元素来建立一个小型的图表。（你可以使用更少的元素，但是尽量不要多用。）

5. 建立一个与模型相关的术语表。

   使用活动4，你可以建立一个术语表，它定义了数据源中名字的含义。设计人员和开发人员经常会使用各种名称来使他们的工作简单。 当名字的长度受到限制时，命名标准就会为简化名称而被使用。连贯性是依靠每一个数据源的规则和生命周期的。

   你可以查阅Rational Data Architect的术语表，它包含很多可用的业务名称的缩写。如图3所示： 例如缩写CL，它表示client，缩写NR表示number等等。 有些数据源的缩写很极端，并不是人们的常规想法，例如J9表示client，或者O1表示的是identifier等等。 虽然Rational Data Architect并不限制同时使用术语表的数量，但是我个人建议你一个模型只使用一个术语表。（这并不是一个出于技术上的建议，而是出于用户体验的建议。）

   
   
   图3：定义术语表
   
   
   
   

这五个注释你现有情况的活动或许显得有些不足，而大多数用的情况下是很耗时的，并且包括很多手动的工作。

回页首

数据源之间的相互映射。

集成的过程包括从很多数据源集成，每一个数据源在你使用之前都需要注释。 在注释现有的基础结构之后，虽然你了解每一个数据源，但是你并不了解集合在一起的所有数据源。

映射现有的数据源是可选的，因为它不会产生更多注释过程需要的结果。但是我们仍然强烈建议你执行映射，这样可以帮助你理解集成数据的完整性，并且可以预见不同数据源之间可能出现的冲突。

数据源之间的相互映射：

1. 在每一对数据源模型之间建立一个新的映射模型。

   一个映射是两个数据之间的依赖，它在数据源的实现时并不被执行。一个映射模型是两个独立数据源或者数据模型之间映射的概要。映射模型随着数据源的增长而快速的增长。你可以使两个资源拥有一个映射模型，三个资源拥有三个映射模型，四个资源拥有六个映射模型——这些都随模型的变化而变化。 如果你使用很多的数据源，你就不需要建立所有的模型。 而只是使用它们中的一部分作为参考，为这些模型建立映射模型，如图4所示：

   
   
   图4：映射数据源模型
   
   
   
   
2. 发现（自动或者手动）数据源结构之间的映射。

   还记得之前章节建立的术语表么？ 现在，它可以帮助你注释一个方法了。 映射发现可以使用术语表来为可能的映射建立更好的建议。 每一个映射表达了数据源结构的目标结构的建立规则。 例如，假设你有一个作为目标的driver's license和作为源的birth certificates之间的映射，映射在驾照上的"name"应该是出生证明上的"first name，" "middle name，"和"last name"。 这是一个包含转换的映射的例子。 模型包含上百个这样的元素。 你可以手动定义所有这些映射，但是它会花费好几周的工作。

   Rational Data Architect可以帮助你分辨所有实际应用中的简单的映射：一对一映射。 例如，从"family name"到"surname,"的映射。 在Rational Data Architect的第一个版本中，映射块可以使用一个五个发现算法的结合。

   最简单的映射是把模型元素的名称作比较，并且随意的使用术语表模型来增加结果的精确性，这个过程是在比较之前把缩写展开到业务名称中来实现的。 大多数复杂的映射发现是使用外部购买的辞典来从数据源中查找同义词或者数据样本，从而验证映射的可能性。 对于每一个映射模型都必须完成映射发现，并且为了模型的易读性，同时还应当有单个映射的文档。

3. 完成数据源模型的注释。

   你可以从映射模型获得关于数据源模型的更多的理解。 例如，你可能会发现第一个数据源中一些数据结构和另外一个数据源中的数据是结构相关联的。 它经常是一个无效的通告，部分的数据集成过程中应该不会被考虑，因为他们是错误的。完成现有数据源之间的映射是非常有价值的操作，即使你不打算集成信息。

映射的结果会从两个试图展现：

• 来自不同模型之间数据的竞争。竞争数据可以导致更加复杂的集成规格的产生，无论数据是来自两个不同的数据源还是包含最新的数据。
• 数据结构的排外性。这些结构应该检查他们是否必须在联邦模型中包含他们。

 

两种检查方式导致了业务的决策并且依靠于你的信息集成原因。

回页首

建立联邦模型

对数据源有很好的理解是验证你是否能够完成信息集成过程的关键。这个过程的一个主要部分是指定目标，或者是计划，这在集成之后是可见的。这个过程应该把集成过程中的业务需求统一化。

1. 建立一个业务（逻辑）模型的解决方案。

   业务模型定义了实体和实体之间的关系，并且忽略执行平台。 模型需要解决业务问题。 如果业务问题之需要一个数量上的汇总，那么模型就不需要包括次序信息。

   Rational Data Architect把这个模型作为逻辑数据模型执行，如图所示：图5：

   
   
   图5：逻辑数据模型
   
   
   

   一个逻辑数据模型不受不同实体之间关系的限制。 它可以包含任何种类的关系，包括图表类型和多到多的关系。 在逻辑模型设计过程中，业务人员正在确认和业务过程的拥有者是非常重要的。 只有当有些东西缺少或者模型之间的关系以及规则不正确的时候他们才能识别出来。

   想要让模型更加好的理解，你应该按照需要建立很多图表来表达不同的业务视图。 文档和注释是模型最重要的两个部分。 想象一下如果有人给你一个未加任何文档的模型去读——这样这个模型就会失去很多它的意思，并且你不会比画一个图表来表达它理解的更多。

2. 把逻辑模型放到一个物理执行模型中。

   逻辑模型表达了信息的业务视图。 下一个环节是把这个模型放到一个物理模块中，这个问题受限于我们实现它所使用的技术。这个过程是和第一次转换相关联的，并且在模型更新中需要多加关注。

   Rational Data Architect允许你把一个逻辑模型转换成一个物理模型。 在转换的过程中，Rational Data Architect会自动地解决所有目标模型的约束，例如缺少多到多的关系或者图表类型，然后为选中的目标正确的执行这个过程。 Rational Data Architect同时还允许你把逻辑模型和物理模型作比较，并且通过比较来为物理模型进行更新，这个过程使用Compare & Synchronize函数。

这个物理模型并不是WebSphere Information Integrator中执行计划所产生的模型；而是集成模型的原型，它是在代码产生和使用相关匿名和试图改变表格时建立的。

回页首

映射联邦数据源

这个信息集成设计的第四个主要步骤是在物理模型所表达的原始数据源和目标联邦模型中建立映射。 这个映射需要完成并且要可以产生代码。

这个映射的例子是和 在数据源之间相互映射一部分非常类似的，它们之间只有细微的差别。

1. 在每一个数据源模型和联邦模型之间建立映射模型。

   这个步骤导致模型的数量和数据源的数量一致。 这些模型的概要定义了如何从现有的数据源建立完整的联邦计划。 在不同数据模型元素中非常有可能产生竞争规范。 我们并没有在这个过程中使用他们，但是在稍后会组织他们。

2. 数据源结构之间的发现（自动或者手动）映射。

   在先前的例子中，你需要数据源和联邦计划之间的发现映射，如图所示：图6： 这个例子和先前讨论的不同源计划的例子基本相同。 你需要关注更多复杂的情形，它们使用映射组来存放更多的表结构。 一个映射组比用一个源数据选择出的结果更能达到联邦数据的要求（或者一个"选择"语句）。

   你可以使用Rational Data Architect中映射组的替代来评估和定义连接的复杂性。 如果连接已经存在于源模型中，那么它将会自动在映射编辑器中显示。

   
   
   图6：映射发现
   
   
   
   
3. 完成数据源模型之间的映射转换。

   使用映射建立联邦代码，你需要定义可执行的转换。 当需要格式，内容或者数据结构变化时，你需要指定这是如何执行的。 这就需要服务器的转换代码——这个例子中就是：WebSphere Information Integrator。

   使用语法构建器或者在Rational Data Architect的映射语法属性中直接输入转换。 语法构建器已经预先定义了WebSphere Information Integrator挑选的函数供你使用。

下面你需要定义所有从源到联邦计划的转换。 这只是一个问题：有太多的转换了。 由于独立的映射编辑器被使用，你不能具有任何的控制来超过被在目标中每一个元素（列）中定义的映射的数量，。 如果你想要产生代码，就需要解决这个问题。

回页首

产生联邦代码

最后一步是从模型回到可执行代码的转换。 你可以从映射模型完成这个步骤。 但是你如何确定能够产生正确的代码？

从所有的数据源为信息集成接收正确的代码：

1. 把所有映射模型合并到一个模型中。

   首先，你需要有一个数据源到联邦模型的整体视图。 如果你在一端覆盖所有源模型那么你就可以这么做，并且把单个联邦模型作为目标留在另外一端。 这个步骤使用很多映射导致一个非常忙碌的模型，并且没有很大的关联，你将会在下一步中删除其中的很多关联。

   Rational Data Architect能让你使用多种方法把两个模型合并成一个模型。 其中的一个方法就是使用同样的目标。 我们重复这个过程直到所有的模型都添加到一个模型中。

   另外一个合并两个映射模型的方法是当一个目标和另一个目标的源相同的时候。

2. 除去竞争映射。

   如果你想得到一个单独的可用模型，那么这个步骤是关键。 结果是需要每一个目标元素（列）都有一个单独的可执行的映射。 合并所有的映射模型建立了很多元素，它们是单个映射的目标。 我们将要看到这种元素并且选择一个单独的映射。 所有其它的映射都不需要了，所以可以删除掉。

   当然你也可以删除一个你认为不需要的映射组。

   你还需要删除说有空的映射组。 你可以通过选择结果映射模型中的映射组细节来轻松的完成这些工作。

3. 从映射模型产生目标计划。

   虽然你可以从模型中产生DDL，但是这个过程还是要小心。 请记住每一个物理模型都要了解目标的容量。 你需要选择一个WebSphere Information Integrator产生的模型来使用匿名和产生试图来接收联邦代码。

   映射模型的代码产生向导中，Rational Data Architect允许为任何产生的元素更改名称，如图所示：图7： 代码的产生结果是一个带所有目标集成模型中的模型的计划，还有代码产生的脚本。

   
   
   图7：产生集成的计划
   
   
   
   
4. 使用WebSphere Information Integrator执行计划DDL。

   它值得去查看产生的脚本并了解它变化的可用性。 我建议从模型自身产生代码，因为你可以把它根目标和产生代码作比较。

   当产生代码的时候，你会使用一个到WebSphere Information Integrator的连接——和反向工程初始模型一样。

现在你已经完成了设计过程。现在要考虑测试和部署问题了。

回页首

总结

这篇文章描述了联邦设计产生集成计划的五个步骤的过程。 你将以一系列的中间模型结束，他们都可以被再度使用，在下次开发中将会缩短过程的时间。这个过程还能增加你对总体信息结构的理解。

Rational Data Architect的建立帮助你理解信息的集成。我建议你访问资源以获得更多的信息。

延伸阅读

文章来源于领测软件测试网 https://www.ltesting.net/