简介

模型驱动的方法正被广泛用于软件开发。在模型驱动的软件开发中，要么是从应用程序建模开始，要么是从数据建模开始。然而，应用程序建模和数据建模互相之间是非常相似的。应用程序建模捕捉关键业务信息，使用统一建模语言（UML）的类模型形式将它们表示为类和关联。然后，可以以类模型为基础，派生出用于数据建模的逻辑数据模型。另一方面，数据建模使用逻辑数据模型（LDM）捕捉业务实体、它们的关系及约束，然后，可以用它们派生出用于应用程序建模的类模型。

格式良好的 LDM 可以提供企业中关键业务信息的正确表示。它可以包含很多应用程序和物理数据源，并且具有更长的存在期限。当企业执行应用程序建模任务时，LDM 中的清晰、准确和完整的语义为类模型提供了极好的基础。

无论是从应用程序建模开始，还是从数据建模开始，当这些不同形式的建模被组合成一个整体时，模型驱动的软件开发的威力将被释放出来，因为我们具备以下优势：

• 实现跨企业及其各层架构的模型互操作性，
• 可用于多个应用程序的可重用的信息模型，
• 解耦的数据语义和物理实现
• 分离应用程序建模师和数据建模师的工作。

IBM 在提供应用程序建模工具方面走在前列，最近还增加了数据建模工具。用户可以在 Rational Software Architecture (RSA) 中进行应用程序建模，在 InfoSphere Data Architect (IDA) 中进行数据建模。IBM 认识到在模型驱动的软件开发中集成应用程序建模和数据建模的重要性，并开发了 UML 到 LDM 转换和 LDM 到 UML 转换，以便将这些工具链接在一起。UML 到 LDM 转换是 RSA 的一项可选特性，LDM 到 UML 转换是 IDA 的一项可选特性。这两个产品的在线文档详细描述了安装和使用这些转换的过程，并包括了对象映射信息。

本文首先对 RSA 和 IDA 作一个简要的概述，然后列出三种 RSA-IDA 集成场景中的高级步骤。对于 UML 到 LDM （自上而下）和 LDM 到 UML（自下而上）场景，本文进一步就企业应该何时使用它们给出了一些建议。接着，本文讨论 RSA 中的应用程序建模、IDA 中的数据建模以及 UML 到 LDM （自上而下）转换和 LDM 到 UML（自下而上）转换。本文还讨论 UML Logical Data Model Profile，它支持 RSA 中的数据建模，并增强了 UML 到 LDM 和 LDM 到 UML 转换。

请注意，虽然 UML 到 LDM 转换和 LDM 到 UML 转换是 RSA 与 IDA 集成的核心，但是 RSA 与 IDA 集成中也有其他一些值得一提的重要方面：

• 便于部署和提高易用性的普通安装和 shell 共享
• 使用 Clearcase 的公共模型库
• 公共的模型驱动的开发工具集（EMF 模型、转换框架、可扩展性等等）

对这些话题的讨论超出了本文范围。

还要注意，本文中讨论的 RSA 和 IDA 集成完全适用 Rational Software Modeler (RSM) 和 IDA 集成。

Rational Software Architect

Rational Software Architect（RSA） 是一种应用程序建模工具，它使企业可以建模、分析、设计和生成应用程序。它利用模型驱动的开发和 UML 创建设计良好的应用程序和服务。RSA 执行以下操作：

• 扩展开放的、可扩展的软件开发环境 Eclipse 。
• 利用最新的建模语言技术，支持跨各种不同领域灵活建模，包括 UML 2、用于 Java 的类 UML 标注等等。
• 支持用于并行开发和架构重构的灵活的模型管理；例如，可以拆分、组合、比较和合并模型和模型片段。
• 通过模型到模型、模型到代码转换，包括反向的转换，简化架构与代码之间的转换。
• 简化 Java™/J2EE、Web 服务、SOA 和 C/C++ 应用程序的设计到代码的体验。
• 包括 IBM Rational Application Developer 的所有特性，提供集成的设计和开发体验。

RSA 中的类 是应用程序中可以被创建、组装、检查、测试、修改或处理的任何内容。图 1 显示了一些示例类以及它们之间的关联 – 一个名为 Invoice 的示例 RSA 项目中的 Invoice、InvoiceItem、ProductInvoice 和 ServiceInvoice。注意，图 1 中显示了三种不同类型的关联：组合（invoice — item）、聚合（main — associate）和简单的关联（product — service）。本文后面将讨论这些关联。

InfoSphere Data Architect

InfoSphere Data Architect (IDA) 是一种企业数据建模和集成设计工具。它简化了数据建模和集成设计，使架构师可以发现、建模、可视化和关联不同的、分布式的数据资产。通过使用 IDA，可以：

• 创建逻辑和物理数据模型。
• 适用维度记号扩展逻辑和物理数据模型。
• 比较和同步两个数据模型的结构和元素。
• 分析数据模型的正确性以及与企业标准的一致性。
• 发现、探索和可视化数据源的结构。
• 使用映射发现潜在的关系，并识别不同数据源之间的关系。
• 与其他建模（应用程序、数据和维度）工具和存储库集成和交换逻辑和物理数据模型。

图 2 显示了一个示例 LDM，该 LDM 来自示例 IDA 项目 Invoice。注意，这里有三种类型的关系：标识（item — invoice）、非标识（associate — main）和多对多（service — product）。还应注意，key inheritance 用于泛化，key migration 用于标识和非标识关系。本文后面将对此加以讨论。

在软件开发周期中，逻辑数据模型过去常常被忽视，但是由于很多原因，现在已经变得越来越重要。LDM 提供企业中数据实体的一个视图，而不暴露实现细节。它将数据语义与实现分开，在处理如今日益复杂的异构 IT 环境时尤其有用。其他逻辑或物理模型，例如服务模型、消息模型、类模型和数据仓库模型，都可以追溯到一个共同的 LDM。借助成熟的模型驱动开发工具，例如 InfoSphere Data Architect 和 Rational Software Architect，用户甚至可以根据 LDM 生成下游模型和物理实现。毫不夸张地说，LDM 是企业的信息中心。LDM 可提供数据的企业视图，从而帮助减少数据冗余、提高数据质量和加快集成。

回页首

探索集成场景

应用程序建模和数据建模的集成主要有三种场景：自上而下、自下而上和中间会合。接下来的小节详细描述每种场景。这里假设有两个主要的 IT 角色：应用程序建模师执行应用程序建模，数据建模师执行数据建模。

自上而下：应用程序建模到数据建模

在自上而下场景中，RSA 中的类建模元素（类、属性和关联）被转换为 LDM 建模元素（实体、属性和关系），以便在 IDA 中使用。下面是这个场景的高级步骤：

1. 应用程序建模师在 RSA 中进行应用程序建模。业务或应用程序数据被捕捉为类模型。
2. 应用程序建模师使用 UML 到 LDM 转换将全部或部分类模型转换为一个 LDM。
3. 数据建模师 在 IDA 中访问和导入 LDM。
4. 数据建模师将 LDM 转换为物理数据模型（PDM），并使用 IDA 进一步生成数据库模式。

图 3 显示在自上而下场景中应用程序建模师与数据建模师之间的交互：

当同时符合以下条件时，建议考虑使用自上而下场景：

• 应用程序建模驱动项目计划。
• 应用程序跨越业务单元筒仓（silo）。
• 应用程序以对象为中心，除了持久性以外，对于数据管理的需求很少。
• LDM 不可用。
• 不存在物理数据库模式。

然而，人们有时会因为一些错误的原因而选择采用自上而下场景。下面列出了这些决定采用自上而下场景的错误理由，从而起到了反作用：

“我们以前从未实现过 LDM”。

凡事总有第一次。如果您的企业过去曾经在 LDM 方面走捷径，那么 LDM 发挥的效用越快，企业获得的长期收益越好。

“我们没有 LDM 技术”。

优秀的数据建模师值得企业为其投资，因此，您应该雇用拥有 LDM 技术的人员或在内部进行培训。

“我们只需要持久数据，以供这个应用程序使用。”

大多数企业应用程序都将需要与其他企业应用程序共享持久数据。LDM 有利于减少总体拥有成本。

最后，有必要提到使用自上而下方法的缺点：

• 数据模型可能与特定应用程序紧密耦合。
• 由于应用程序建模中的不规范和以对象为中心的建模，可能无法在 LDM 中立即重用类模型。

自下而上：数据建模到应用程序建模

在自下而上场景中，LDM 建模元素（实体、属性和关系）被转换为类建模元素（类、属性和关联），以便在 RSA 中使用。从企业角度长远来看，使用自下而上方法比使用自上而下方法更好，正如前面小节所说的那样，自上而下方法有一些局限性，而 LDM 则有很多优点。

此外，自下而上方法便于分离工作。数据建模师只需专心开发企业级词汇表和数据模型；应用程序建模师只需进行应用程序建模。

这个场景中的步骤是：

1. 数据建模师使用 IDA 在一个 LDM 中建模数据。如果已经有一个数据库模式，但是没有物理或逻辑模型，那么数据建模师根据已有的模式生成一个 PDM。
2. 数据建模师将 PDM 转换成 LDM。
3. 数据建模师使用 LDM 到 UML 转换将 LDM 的全部或一部分转换成一个类模型。
4. 应用程序建模师在 RSA 中访问和导入类模型。

图 4 显示在自下而上场景中应用程序建模师与数据建模师之间的交互：

当同时满足以下条件时，建议考虑使用自下而上场景：

• 域内的 LDM 可用。
• 具有一些现有数据源（关系数据库或其他数据源）。
• 企业希望从应用程序中解耦数据并实现企业级数据管理。
• 企业希望创建可跨整个企业重用的信息。
• 涉及多个计划。例如，业务应用程序重写并需要绑定到数据仓库。
• 应用程序过于复杂，并经常变化。
• 应用程序以数据为中心。
• 项目需要考虑已有的数据模型（至少需要考虑一部分）。如果有遗留的应用程序、第三方应用程序或需要实现基于标准的界面，就需要考虑这一点。

自下而上方法有以下不足：

• 在从 LDM 转换到类模型时，有些语义可能会丢失，因为 LDM 的数据语义比类模型更加丰富（例如主键）。
• 由于 LDM 往往比类模型更完整，如果未经恰当交流就将 LDM 推入类模型，那么应用程序建模师就会面对大量的信息。如果应用程序建模师不理解 LDM，那么他们最后可能不得不从头开始重新定义 LDM 中已有的实体或属性。因此，数据建模师和应用程序建模师之间需要进行恰当的培训和交流。理想情况下，应用程序建模师经过培训后应该能理解和利用逻辑数据模型。

中间会合方法

前面的小节描述了自上而下和自下而上场景，它们主要侧重于全新的开发。然而，软件开发的永恒主题就是变化。应用程序建模和数据建模并不是件一劳永逸的事。为了避免过时，应用程序建模和数据建模需要反复进行，并迅速转化为业务价值。因此，应用程序建模和数据建模工具应该支持模型更新功能。例如，可以对类模型中的修改进行更新，并自动（适用于简单修改）或手动（涉及复杂过程）反映到 LDM 中，反之，从 LDM 到类模型这个过程也一样。

实际上，对于类模型和 LDM 的同步和变更管理并不容易，因为它们处在不同的工具中，并且常常由不同的角色 – 应用程序建模师和数据建模师 – 来处理。但是，通过认真的计划、积极的交流和严格的变更管理，可以有效地利用工具特性，并实现端到端的数据治理。

本节描述中间会合场景中的两个用例，具体取决于要更新类模型还是 LDM。

在第一个用例中，当类模型被转换到 LDM 并在 IDA 中使用之后，应用程序建模师在类模型中作了一些修改，例如增加了新的属性。LDM 在 IDA 中更新，以反映更新后的类模型。这个用例是自上而下场景的一个扩展，只是另外还需要在 IDA 中用新的或被修改的信息同步已有的 LDM。

第一个用例中的步骤是：

1. 数据建模师在 IDA 中使用 LDM 版本 1，它是之前在 RSA 中从类模型版本 1 转换而来的。
2. 应用程序建模师在 RSA 中修改类模型版本 1，然后将更新后的类模型（版本 2）转换为 LDM 版本 1+。
3. 数据建模师在 IDA 中访问并导入 LDM 版本 1+。
4. 数据建模师进行比较，并在 IDA 中将 LDM 版本 1+ 和版本 1 合并为 LDM 版本 2。

图 5 显示在第一个用例中应用程序建模师与数据建模师之间的交互：

在第二个用例中，当类模型被转换到 LDM 并在 IDA 中使用之后，数据建模师对 LDM 作了一些修改，例如增加新的列。RSA 中的类模型被更新，以反映更新后的 LDM。这个用例是自下而上场景的扩展，只是另外还需在 RSA 中用新的或被修改的信息同步已有的类模型。

第二个用例中的步骤是：

1. 应用程序建模师在 RSA 中使用类模型版本 1，它是之前从 IDA 中的 LDM 版本 1 转换而来的。
2. 数据建模师在 IDA 中修改 LDM 版本 1，然后将更新后的 LDM（版本 2）转换为类模型版本 1+。
3. 应用程序建模师在 RSA 中访问并导入类模型版本 1+。
4. 应用程序建模师进行比较，并在 RSA 中将类模型版本 1+ 和版本 1 合并为类模型版本 2。

图 6 显示在第二个用例中应用程序建模师与数据建模师之间的交互：

回页首

理解模型转换

模型转换是集成应用程序建模与数据建模的核心。在前面讨论的自上而下场景中，需要使用 UML 到 LDM 转换将类模型转换为逻辑数据模型；在自下而上场景中，需要使用 LDM 到 UML 转换将逻辑数据模型转换为类模型。

UML 类模型

类模型定义以下内容：

模型和包

其他模型元素的结构组件和名称空间。一个包可以包含包、图、类、关联、关联类和数据类型。

类

表示被建模系统中的概念。同一个类的不同实例具有相同的特征。一个类有以下子类：

属性

对类的特征的描述。属性具有类型，用来定义属性值的类型。

泛化

一个类与更泛化的类之间存在泛化关系。类与更泛化的类完全一致，但是包含额外的属性。

关联

表示实例之间存在联系的两个类之间的语义关系。除了简单形式的关联外，另外还有两种形式的关联：

聚合

这种关联指定一个聚合体（一个整体）与一个组成部分之间的整体-部分关系。

组合

聚合的一种形式，组成部分严格隶属于组合体（整体），并且部分与整体的生命周期一致。一个部分一次只能属于一个组合体。

关联类

关联类是一个关联，同时也是一个类。关联类连接两个类，并且有自己的属性。

数据类型

数据类型是一组值的描述符。数据类型包括：

预定义的基本类型

Boolean、Number、String、UnlimitedNatural

用户定义数据类型

基本类型或枚举类型

参见 图 1，看看示例类模型。

IDA 逻辑数据模型

逻辑数据模型定义以下组件：

包

其他模型元素的结构组件。包可以包含包、图、实体和域。

实体

表示概念、事件、人、位置或关于保存什么信息的内容。同一种实体的实例具有相同的特征。实体可以是独立的，也可以是非独立的。对于一个实体，如果没有确定它与其他实体的关系就不能惟一地标识它的实例，那么它就是非独立实体。否则，它就是独立实体。

属性

对实体特征的描述。属性具有类型，可定义其值的类型。

主键

惟一地标识实体的一个实例的一个或多个属性。

泛化

实例与更泛化的实例之间存在泛化关系。实体与更泛化的实体完全一致，但是包含更多的属性。

关系

两个实体之间的连接、链接或关联。有三种类型的关系：

标识关系

子实体的实例通过它与父实体的关联来标识。父实体的主键属性成为子实体的主键属性。

非标识关系

子实体的实例不 是通过它与父实体的关联来标识。父实体的主键属性成为子实体的非主键属性。

多对多关系

两个实体之间的关系，第一个实体的每个实例与第二个实体的 0 个、1 个或多个实体相关联，第二个实体的每个实例与第一个实体的 0 个、1 个或多个实体相关联。

数据类型

数据类型是一组值的描述符。数据类型包括：

预定义数据类型

BINARY、BLOB、BOOLEAN、CHAR、CLOB、CURRENCY、DATALINK、DATE、DECIMAL、DOUBLE、FLOAT、INTEGER、INTERVAL、LONG、NUMERIC、ROWID、SHORT、TIME、TIMESTAMP、VARBINARY、VARCHAR、XML

用用户定义数据类型

原子域

参见 图 2，查看示例逻辑数据模型。

自上而下：类模型到逻辑数据模型

UML 类模型与 IDA 逻辑数据模型在建模结构和语义上都非常匹配。因此，将类模型转换为逻辑数据模型通常比较简单，不会丢失信息。

表 1 显示类模型（源）到逻辑数据模型（目标）之间的映射。在这个表中，需要注意：

• 类没有主键；它有一个隐式的 OID（对象标识符）。这被转换为一个代理键。
• 如果关联的任意一端的重数为 0.1 或 1，则简单关联被转换为非标识关系；否则，它被转换为多对多关系。
• 属性可能将类引用为类型，这与聚合的语义相同。因此，类引用被转换为非标识关系。
• 关联类是逻辑数据模型中没有的概念。为保留关联类的语义，关联类被转换为一个实体和两个关系。

图 7 显示了使用 图 1 中的示例类模型通过 UML 到 LDM 转换生成的目标逻辑数据模型。在比较源模型和目标模型时，请注意：

• 对于每个实体，会生成代理键（例如 Invoice 的 Invoice ID）。
• 对于泛化，会发生键继承（例如从 Invoice 到 ProductInvoice 的 Invoice ID）。
• 对于组合，会发生键转移（例如从 Invoice 的 Invoice Id 到 InvoiceItem 的 invoiceInvoice Id）。
• 对于聚合，会发生键转移（例如从 Invoice 的 Invoice Id 到 Invoice 的 mainInvoiceID）。
• 对于键转移，默认情况下，子外键属性的名称是通过将父角色名称加在父主键属性名称前面生成的。

UML 逻辑数据模型配置文件

并不是应用程序建模期间定义的所有的类都一定与数据建模有关，或者具有持久的数据；同样，也不是所有的主键或枚举都一定与数据建模或持久数据所需的数据类型相对应。UML 逻辑数据模型配置文件可用于：

• 允许用户控制将哪些类、主键类型或枚举转换到逻辑数据模型。
• 指定对逻辑数据建模重要但是 UML 中没有的概念，包括：
  • 主键属性
  • 用户定义数据类型：基本类型或枚举所不能指定的更多信息
  • 引用完整性：例如父删除规则

实际上，UML 逻辑数据模型配置文件使用户可以在 RSA 中使用 UML 进行逻辑数据建模。

表 2 显示逻辑数据模型配置文件提供的模板（stereotype）和属性。请注意：

• 枚举或基本类型可能被模板化为 Domain。如果是这样，则可以指定更多的信息（例如对于基本类型）。
• 类可以被模板化为 Entity。默认情况下，它们是持久的，不使用代理键。
• 属性总是被模板化为 Attribute。默认情况下，它们不是必需的。
• 属性可能被模板化为 PrimaryKey。
• 关联和关联类总是被模板化为 Relationship。可以指定外键属性名（以主键属性名、外键属性名对的形式）和父删除规则（NONE / RESTRICT / CASCADE / SET NULL / SET DEFAUL）。类似地，还可以指定子删除规则。 另外，还可以指定一个 transform-as 选项（SEPARATE_TABLE / MERGE）。
• 泛化总是可以被模板化为 Generalization。transform-as 选项（SEPARATE_TABLE / ROLL_UP / ROLL_DOWN）和定义属性都可以被指定。

表 3 显示当将逻辑数据模型配置文件应用到类模型时，从类模型（源）到逻辑数据模型（目标）的映射。值得注意的是：

• 只有模板化为 Entity 的类被转换为实体。默认情况下，它们是持久的，不使用代理键。
• 模板化为 PrimaryKey 的属性被转换为主键属性，此时必须生成属性。
• 只有模板化为 Domain 的基本类型/枚举被转换为原子域。

图 8 显示应用逻辑数据模型配置文件后的示例类模型。请注意：

• 所有基本类型已经被模板化为 Domain。
• 所有类已经被模板化为 Entity。
• Invoice 和 InvoiceItem 的 ID 属性已经被模板化为 PrimaryKey。

图 9 显示通过 UML 到 LDM 转换生成的目标逻辑数据模型。这个转换中使用的示例类模型源自 图 8。在比较源模型和目标模型时，请注意：

• 没有生成代理键。相反，生成了主键属性（Invoice 的 ID 和 InvoiceItem 的 ID）。
• 对于泛化，发生了键继承（从 Invoice 到 ProductInvoice 的 ID）。
• 对于组合，发生了键转移（从 Invoice 的 Invoice Id 到 InvoiceItem 的 ivoiceID）。
• 对于聚合，发生了键转移（从 Invoice 的 ID 到 Invoice 的 mainID）。
• 默认情况下，对于键转移，子外键属性名是通过在父主键属性名之前加上父角色名生成的。

自下而上：逻辑数据模型到类模型

和自上而下转换类似，将逻辑数据模型转换为类模型通常也比较简单，不会发生信息丢失。表 4 显示从逻辑数据模型（源）到类模型（目标）的映射。

图 10 显示通过 LDM 到 UML 转换生成的目标类模型。这个转换中使用的示例逻辑数据模型源自 图 2。在比较源模型和目标模型时，请注意：

• 主键信息（例如 Invoice 的 ID）在类模型中丢失，因为 UML 类模型不支持主键的概念。
• 外键属性（例如 InvoiceItem 的 invoiceID）没有被转换到类模型，因为它们是通过逻辑数据模型中的键转移生成的，不是模型中固有的。

为了在目标类模型中保留逻辑数据模型的概念和信息，在 LDM 到 UML 转换期间，逻辑数据模型配置文件默认应用于目标类模型。表 5 显示应用逻辑数据模型配置文件时从逻辑数据模型（源）到类模型（目标）的映射。请注意：

• 实体被转换为模板为 Entity 的类。
• 主键属性被转换为模板为 PrimaryKey 的属性。
• 原子域被转换为模板为 Domain 的基本类型和枚举。

图 11 显示通过使用 LDM 到 UML 转换，并对目标类模型应用逻辑数据模型配置文件所生成的目标类模型。这个转换中使用的示例逻辑数据模型源自 图 2。在比较源模型和目标模型时，请注意：

• 主键信息（例如 Invoice 的 ID）被保留在类模型中。
• 外键属性（例如 InvoiceItem 的 invoiceID）没有被转换到类模型，因为它们是通过逻辑数据模型中的键转移生成的，不是模型中固有的。

回页首

结束语

本文简要概述 RSA 和 IDA 以及它们的集成。您看到了三个场景，并学习了自上而下场景和自下而上场景各自的采用标准。要创建格式良好的应用程序模型和数据模型，仅仅知道如何使用工具是不够的。同样重要的是，要了解采用某种场景的原因，要定义健壮的、可重复的变更管理过程，还要创建能利用应用程序建模与数据建模之间的协作的策略。要想成功实现应用程序建模和数据建模的集成，还可能需要进行组织和文化上的变更。希望本文能够在集成应用程序建模和数据建模方面提供帮助。

本文还详细讨论了 UML 到 LDM 转换和 LDM 到 UML 转换，以及 UML 逻辑数据模型配置文件。通常，无论类模型是作为转换的源还是目标，在类模型上应用 UML 逻辑数据模型配置文件都是有益的。在前一种情况下，它允许用户控制将哪些类主键或枚举转换到逻辑数据模型，并指定对逻辑数据模型重要但是 UML 中没有的概念和信息。在后一种情况下，它使转换具有可逆性，因为重要的逻辑数据建模概念和信息都被保留在生成的类模型中。

如 图 12 所示，逻辑数据建模是数据建模集成的关键。在本文中，可以看到如何将 RSA 中的应用程序建模与 IDA 中的逻辑数据建模相集成。逻辑数据建模与关系数据建模之间的集成是 IDA 的标准特性。WebSphere Business Modeler (WBM) 中的业务建模与 IDA 中的逻辑数据建模之间的集成，以及 IDA 中逻辑数据建模与 XML 数据建模之间的集成在 developerWorks 文章 “集成 WebSphere Business Modeler 和 Rational Data Architect”（developerWorks，2007 年 11 月）中加以讨论。

回页首

致谢

感谢 Der Ping Chou、Davor Gornik、Gary Robinson 和 Hong-Lee Yu 对本文的审校和意见。感谢 Andreas Drasdos (GAD) 就 UML 到 LDM 转换和 UML 逻辑数据模型配置文件提供的宝贵反馈。

参考资料

学习

• 深入了解 Rational Software Architect 和 InfoSphere Data Architect。
  
  
• 访问 IM 和 Rational 集成应用开发，阅读文章和教程，并涉猎其他参考资料，扩展您在 RSA 和 IDA 方面的技能。
  
  
• 在 developerWorks Information Management 专区 了解关于信息管理的更多信息，获取技术文档、how-to 文章、培训、下载、产品信息以及其他资源。
  
  
• 随时关注 developerWorks 技术活动 和 网络广播。
  
  

获得产品和技术

• 下载 Rational Software Architect 免费试用版。
  
  
• 下载 IBM 软件下载：InfoSphere Data Architect 免费试用版。
  
  

讨论

• 参与 developerWorks 博客 并加入 developerWorks 中文社区，developerWorks 社区是一个面向全球 IT 专业人员，可以提供博客、书签、wiki、群组、联系、共享和协作等社区功能的专业社交网络社区。
  
  

关于作者

为本文评分

评论

回页首

内容

• 简介
• 探索集成场景
• 理解模型转换
• 结束语
• 致谢
• 参考资料
• 关于作者
• 建议