级别： 中级 Brian Byrne, IFW/IAA 过程和集成模型架构师, IBM
David McCarty, IT 架构师,
IBM
Guenter Dr. Sauter, 高级 IT 架构师和管理者,
IBM
Peter Worcester, 服务解决方案营销经理,
IBM
2008 年 3 月 27 日 发现如何使用 IBM® Rational® Data Architect、IBM Industry Models 和 IBM Information Server 的统一元数据管理使过程、服务和数据模型保持一致。使用这些工具加快 SOA 项目。本文是 “SOA 设计的信息透视图” 系列的第 5 部分，描述了这些产品中支持 SOA 中的数据建模模式的关键特性。
简介
Rational Data Architect（RDA）是解决信息管理领域各种建模和设计需求的战略性 IBM 工具的一部分。它构建在 Rational Software Development 平台（自然也包括 Eclipse）之上。这提供了一个集成的工具环境，将 RDA 的功能与 Rational Software Architect（RSA）、Rational Requisite Pro、ClearCase 和 Rational Software Development 平台的其他关键部分的功能连接在一起。图 1 显示了 RDA 主要功能的概图。
图 1. RDA 功能概图
RDA 的核心功能不仅仅是数据建模。本文介绍 RDA 的主要功能，并展示这些功能如何在 SOA 分析和设计过程中发挥作用。这些功能包括：
-
标准化（Standardize）- 支持业务词汇表
本系列的 第
2 部分 讨论了数据命名标准如何促进对业务术语的共同理解。如果跨组织边界共享这些术语，则可以通过更加一致的数据需求表达，从而整合同义的和重叠的数据术语，最终减少数据冗余。
-
模型（Model）- 支持概念、逻辑和物理数据模型
本系列的 第 4 部分 概述了 SOA 中概念数据建模和逻辑数据建模的作用。RDA 提供了大量的功能在概念、逻辑和物理级别上定义数据模型，并且可根据需要在 UML 与 Information Engineering 标记法之间转换。这样便可以在不同级别的抽象上进行数据建模，同时又维护这些模型之间的一致性和可跟踪性。
-
可视化（Visualize）- 支持概念数据建模、逻辑数据建模和物理数据建模
数据模型很快就会变得非常庞大，包含很多实体和关系。RDA 通过一套图形类型支持数据模型的可视化。这些模型可能非常详细，显示全部的实体、关系和属性结构，甚至具有粗粒度概念之间的核心关系的更高级的可视化表示。RDA 还通过物理数据模型的摘录支持被部署的数据库的可视化。
-
XML
XML 是服务规范的标准语言（通过 WSDL/XSD）。服务所处理、共享和交换的很多数据都需要持久化到数据库中。RDA 支持 XML 模式定义和 XML 模式到逻辑数据模型的映射的可视化。必要时，RDA 还可以帮助将 XML 数据分解成关系形式。
-
关联（Relate）
RDA 支持一个模型的不同级别之间的复杂关系。例如，它可以在逻辑模型与物理模型之间映射，也就是规范化数据模型的概念与这些概念在数据平台中的实现之间的映射。这使得跨业务线和在不同级别抽象上的数据模式之间的关系可被分析和跟踪。
-
同步（Synchronize）
一个组织的 IT 基础设施是动态的，会随着时间而改变。可能逻辑模型已发生了变化，但是这种变化并没有传播到物理模型中，或者物理模型中的变化没有传播到逻辑模型中。当不同的数据模型 “失去同步” 时，重要的是可以比较它们，识别不同点，然后通过同步模型解决这些不同点。
-
联邦（Federate）
RDA 允许通过映射模型指定来自多个源的信息的连接。它将信息连接起来，放在一个虚拟联邦视图中，并生成必要的语句，这些语句可部署到 IBM Information Server（WebSphere® Federation Server）或 DB2 上。
-
代码（Code）
指定一个数据模型之后，RDA 允许创建用于 DB2 的 SQL 代码，以便将数据模型部署到一个数据库上。RDA 还允许围绕这个数据模型开发用于 Java 应用程序的代码，或者开发存储过程。
-
存储（Store）
RDA 模型可以存储在 RDA 工具中，可以导出到 IBM Information Server 的统一元数据平台上，或者记录到一个版本控制系统中，例如 Rational ClearCase。
-
团队（Team）
RDA 通过与 Rational ClearCase 和 Rational ClearQuest 的集成为团队协作提供支持。这可以促进模型在团队成员之间的共享，并且使跟踪模型变化更加容易。
-
集成（Integrate）
RDA 与很多数据库和数据建模工具以及 SOA 工具和环境集成。这使得表达可重用数据概念的规范化数据模型与其他工件紧密集成，例如业务术语表、服务定义和业务流程。
-
导入/导出（Import/Export）
RDA 可以与多种环境，例如 CA ERwin 相互导入和导出工件。这对于将已有数据建模的成果集中到单个的环境，并最终集中到单个模型至关重要。
RDA 提供大量的数据建模功能，以便在不同级别的抽象上定义数据模型。RDA 支持术语表模型、逻辑数据模型、物理数据模型以及它们之间的关系和转换的指定。RDA 可用于采取自下而上或自上而下的方式开发数据模型，允许分析已有数据库和通过对已有数据资产的反向工程开发数据模型。
SOA 分析和设计过程中的信息建模
本系列的 第 4 部分 介绍了可应用于 SOA 项目的信息建模活动。图 2 显示了这些信息建模活动与 SOA 分析和设计过程中其他一些重要活动之间的主要集成点和依赖关系。
图 2. SOA 分析和设计过程中的信息建模
有很多不同的建模工具和方法可用于 SOA。本文解释一些常见的方法，并解释 IBM 工具如何支持这些方法。
术语表建模
适当的 SOA 设计主张使用一致的业务术语表，这样的术语表使企业中的业务术语得以统一。这个系列的文章将 WebSphere Business Glossary 定位为 IBM 用于定义业务术语表并在企业中广泛共享该术语表的战略软件解决方案。RDA 与 WebSphere Business Glossary 紧密集成，使业务术语表可以在数据建模环境中访问和操纵。可以将 RDA 术语表模型导出到 IBM Information Server 中，在其中填充业务术语表，然后将其重新导入到 RDA 中，从而更新初始的术语表表明。安装在 RDA 上的一组 “元代理（metabroker）” 为此提供了支持。这意味着可以在 RDA 中维护术语表模型与概念模型/逻辑数据模型之间的可跟踪性。
可以通过手动定义一个新模型，或者导入已有资产，例如 IBM 的 Industry Models，使用 RDA 术语表模型（.ndm）作为术语表规范的入口点。或者，也可以先在 WebSphere Business Glossary 中创建一个术语表模型，然后将其导出到 RDA 中，以便将它映射到其他数据建模工件。
图 3 显示了 RDA 中的业务术语表模型。
图 3. RDA 中的业务术语表模型
不论出处如何，当术语表模型在 RDA 中时，就可以将标准业务术语映射到规范化（概念/逻辑）数据模型的形式化结构。正如 第 4 部分 所述，这种规范化模型不仅影响数据平台的分析和设计，而且影响企业中的共享服务以及使用这些服务的业务流程的分析和设计。这意味着数据和服务架构师在定义或扩展规范化数据模型和服务模型时，可以直接使用结构化的、一致的业务术语。这样便可产生在各种传统数据筒仓（例如 LOB 或产品）上保持一致的设计，同时这些设计也与业务需求一致。
RDA 显式地支持数据模型定义期间的术语表建模。当选择一个实体或属性的名称时，RDA 的内容辅助键（ctrl+space）会显示已定义的词，如图 4 所示。
图 4. 使用 RDA 内容辅助
在查看模型时，可以分析逻辑模型中使用的术语是否遵从术语表模型，如图 5 所示。
图 5. 在 RDA 中分析模型
本系列 的第 2 部分和第 3 部分已提供了关于术语表模型的作用以及 WebSphere Business Glossary 中对术语表的支持的更多细节。
业务需求和用例
很多 SOA 项目使用用例建模这项广为人知的技术来捕捉业务需求和驱动业务流程模型。Rational RequisitePro 提供了用于将这一过程形式化的需求管理工具。业务术语表提供一套清晰、明确的业务实体定义，用例文档中可以使用这些业务实体定义，以提高下游任务，例如过程和服务建模的准确性和有效性。RequisitePro 提供了一个基于 Eclipse 插件的用户界面组件，该组件可插入到 RDA、RSA 或 WebSphere Business Modeler 中。这意味着 RequisitePro 中的需求定义可直接跟踪到 RDA 中的术语表定义。这样便可以用术语表中的术语表达业务规则、服务需求或其他需求。然后，将这些结构直接映射到它们所引用的术语。WebSphere Business Glossary Anywhere 的这个用户界面还可用于在需求定义期间广泛地访问术语表中的术语。
规范化数据建模
正如第 4 部分中所述，规范化数据建模是定义项目范围内最终扩大至整个组织内的信息的公共表示。它包括概念数据建模和逻辑数据建模的概念。虽然概念数据建模和逻辑数据建模会产生两个不同但是相关的数据模型，但更常见的是，它们是在同一个数据模型上进行的两个连续分析阶段。
概念数据模型定义主要的业务实体、这些实体的泛化（generalization）以及实体之间的关系。它可能包括实体的一些属性的规范，但它主要是定义范围，而不是全面的或完整的属性定义。逻辑数据模型（LDM）包含实体和属性、关系、惟一标识符、子类型和超类型以及关系之间的约束的表示，同时保留那些数据结构的物理表示的独立性。LDM 不仅驱动 PDM 中定义的和运营系统或仓库中实例化的下游数据持久结构的分析和设计，而且还驱动 LDM 的结构和 SOA 开发过程中其他一些模型的定义，如 图 2 所示。
规范化数据模型到服务模型的集成
服务建模通常是在 Rational Software Architect（RSA）中使用 UML 进行的。这是一个迭代的过程，常常需要多次与 Rational Data Architect 中的规范化数据模型进行互换。这种内容的互换是在 RDA 和 RSA 提供的 UML-LDM 和 LDM-UML 转换的支持下进行的。这使得 RDA 中表达的 LDM 可以转换为 RSA 中的 UML 模型，以便在服务分析期间使用。从 图 2 中逻辑数据模型与服务分析模型之间的连线可以看出这一点。类似地，对这个 UML 模型的更改（也许是基于 RSA 中的业务用例）可以被导入，作为对 RDA 中 LDM 的更新。通过创建转换配置（标识源和目标模型）和运行转换，就可以使用 UML-LDM 和 LDM-UML 转换，如图 6 所示。
图 6. 同步 UML 和 LDM 模型
在自上而下方法中，可以基于通过信息工程和基于 UML 的分析表达的统一需求来开发 LDM，开发时，对概念数据模型逐次改进，并在随后添加属性、键、域结构等，所有这些都遵从通过业务术语表表达的命名标准。特别是，UML2LDM 转换从 UML 模型（在此是一个服务分析模型）中提取类型、子类型、关系和属性定义，并使用它们构造一个 LDM。反过来，LDM2UML 转换则从逻辑数据模型中获取同样的信息，并使用获得的信息构建一个 UML 模型。在这个来回中，元数据结构（比如 UML 域中的操作和 LDM 空间中的键）并没有发生转换。但是，可以使用 RSA 或 RDA 各自提供的模型合并功能维护这些结构（以及用于每个模型类型的图形）。
在实体和关系被完全定义为一个逻辑关系模型之后，可以使用 RDA 将逻辑模型转换成物理数据模型形式的特定于数据库的物理表示。物理数据模型是特定于数据库的模型，表示关系数据对象（例如表、列、主键和外键）以及它们的关系。可以使用物理数据模型来生成数据定义语言（DDL）语句，然后可以将这些语句部署到一个数据库服务器上。RDA 允许建模者更改数据模型，并查看对从这个模型生成的 DDL 的更改。然后，可以直接在一个服务器上执行这种 DDL，以更新数据库规范，或者将 DDL 存储为一个文件，以便在企业内发布。
规范化数据模型到规范化消息模型的集成
正如本系列第 4 篇文章所述，规范化消息模型表示用于在服务总线上交换业务信息的标准化格式。并不是通过架构中各个层传递的每个数据结构都一定遵从这个模型。实际上，这种模型只是提供默认的业务数据交换格式，使所有组件只需知道它们自己的数据格式和默认的数据格式（在一个服务总线上共享）。在大多数情况下，新的服务或者驱动消息格式，要不就实现成遵从这一消息格式。
规范化消息模型的一种常见的表示法是使用一组 XML 模式。定义这样一组模式的过程因项目而异。图 2 中显示的例子是一个典型的自上而下驱动的项目。在这里，XML 模式是使用 UML 的技术性服务设计（在此是用于金融服务的 IFW 模型）的一个输出，这种设计产生用于服务和组成服务消息的数据元素模式定义的 WSDL 定义。图 7 展示了 RSA/RDA XML 编辑器中的 XML 类型；要查看更大的版本，请参阅 sidefile。
图 7. RSA/RDA XML 编辑器中的 XML 类型
在其他强调 ESB 或自下而上方法的项目中，可以直接用 XML 开发规范化消息模型，也可以从生成的服务类和消息流提取规范化消息模型。对于这个场景，可以直接从逻辑模型中导出基本数据类型，作为 XML 开发的起点。图 8 显示了 RDA 中的这项功能。
图 8. 从 RDA 中将 LDM 导出为 XML
规范化数据模型到业务流程的集成
在 SOA 项目中，业务流程模型通常在两个阶段中开发。
- 业务分析师执行高级流程建模，以定义业务活动和流，识别 KPI，并通过模拟分析潜在的更改的成本和好处。WebSphere Business Modeler 为这些活动提供了工具。
- 业务流程设计者使用业务分析师设计的模型，并装配出实现。这可以在 WebSphere Business Modeler 和/或 WebSphere Integration Developer 中执行。
业务分析师在 WebSphere Business Modeler 中定义表示在业务流程中传递的信息实体的业务项。在 WebSphere Business Modeler V6.1 中，这些业务项定义可以直接从 Rational Data Architect 中定义的一个 LDM 导入。取决于业务分析师在流程模型中需要多细的粒度，Rational Data Architect 中的两种形式的规范化数据模型（概念数据模型或逻辑数据模型）都可以提供所需的源业务项定义。另外，流程分析期间的数据需求的表达可以作为原文需求，回头引用术语表中的业务术语。这实际上取决于流程分析师社区的技能、在流程分析时逻辑数据模型的成熟度以及其他因素。特别是，可以由流程分析本身，以及随后对该流程的服务需求的基于用例的分析，来驱动定义规范化数据模型的一些需求。
业务流程设计者增添业务流程的细节，然后将服务实现绑定到这些细节。在业务流程中传递的数据采用以 XML 模式描述的业务项的形式。这些业务项被用作业务流程中的任务的输入和输出，并且常常是用服务设计阶段产生的可重用的 XSD 类型构建的。可以通过 import -> File System 和在业务集成项目中指定 xsd-includes 目标目录，将规范化消息模型直接作为 XML 模式导入到 WebSphere Integration Developer 中。图 9 显示了这一步骤。
图 9. 将规范化消息模型类型导入到 WebSphere Integration Developer 中
这导致消息模型中定义的所有数据类型可以作为业务对象使用，如图 10 所示。在实践中，常常在 WebSphere Integration Developer 中将这些业务对象表达为可重用的库结构，然后用它来描述服务参数和业务流程中的数据流。
图 10. WebSphere Integration Developer 中导入的业务对象
管理 RDA 模型
RDA 支持在企业范围内比较和同步数据模型。在维护企业 LDM 时，对模型的扩展可能同时在很多不同的项目中发生，并由一个模型管理器进行协调，所以这一点特别有用。RDA 可以识别模型中的差异，接受或拒绝这些差异，将接受的更改并入到一个结果模型中。可以使用一个源文件控制管理系统（比如 ClearCase 或 CVS）来管理这个结果模型。
RDA 工具还可以将一个或多个源模型关联或映射到一个或多个目标模型。例如，您可能想映射相关但又是独立开发的模型，例如一个或多个遗留系统中的规范化数据模型和物理数据模型。这可以帮助您理解数据概念在企业中的分布，以及用多个模型表达的相同概念的联系。同样，这个功能在基于多个离散系统的物理模型定义一个单独的联邦数据模型时也十分有用。RDA 还支持将 XML 模式映射到其他模型类型，这在需要将一个模式持久化到一个数据存储中时十分有用，因为此时需要模式与数据源的 PDM 之间的映射。
图 11. XML 模式与 PDM 的映射
映射可以由建模者显式地表述，也可以由 RDA 发现。RDA 所识别的映射可以接受到映射模型中，也可以拒绝，这使得建模者可以保持对映射的控制。
结束语
在本文中，您看到了可以使用 Rational Data Architect 来遵循本系列第 4 部分中提出的模式，以支持规范化数据建模。而且，可以使规范化数据模型遵从通过业务术语表表达的标准化术语。这样产生的规范化数据模型的模型结构可以与 SOA 项目开发过程中使用的其他工具进行交换。Rational Data Architect 为设计信息系统提供了工具，包括创建必要的 SQL 代码以实现这些更改。
参考资料 学习
- 您可以参考本文在 developerWorks 全球站点上的 英文原文。
-
阅读 本系列 的其他文章。
获得产品和技术
讨论
作者简介  | | | Brian Byrne 在 IBM 六年了，他是过程集成和 SOA 领域中行业模型的主任架构师。Brian 具有大规模分布式系统方面的工作背景，以及在主要的世界银行的 SOA 项目方面有着广泛的客户经验。 |
| 
| | 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 的技术主管之一。 |
| 
| | Peter 在三年前加入 IBM，之前在美国国防部、GE 公司和 Morgan Stanley 等机构工作了差不多 25 年，他在那些机构中担任技术领导职位，并在企业体系结构和企业数据集成方面获得了丰富的经验。他加入 IBM 时最初担任 Information as a Service 架构师团队的高级 IT 架构师。他当前是 IPS Global Services 组织的解决方案营销经理，主要研究 MDM 解决方案。 |
对本文的评价
| 
