使用 Rational XDE Data Modeler 建模和设计数据库 第二部分
内容：
使用 Rational XDE 进行数据建模
2004 年 9 月
简介
如果你在你的项目或者公司中参与了数据的架构，这篇文章或许可以帮助你。这篇文章为数据库设计者、管理员或者负责实现数据模型的开发人员而准备的，不论是逻辑的和物理的，还是实际厂商的数据库（尤其是 DB2 Universal Database）。
如果你对关系数据库的基础（普通的表单和特定的实体关系设计）有所了解，对你理解本文中的内容将会很有帮助。如果你对统一建模语言（UML）有所了解，尤其是类图，他们在 Rational? 工具中被用作实体关系图的虚拟代替品，这也将对你很有帮助。
本文介绍了关于 IBM? Rational XDE 工具集的 Data Modeler 组件的，和如何与 IBM 的 DB2? UDB 数据库管理系统一起结合使用的。本文包括两个部分：
第一部分：Rational XDE 和数据建模（Data Modeling）透视图简介
Rational XDE 简介 描述 Rational 工具如何成功的使用统一建模语言（UML） ，和如何使 UML 对数据库建模和设计可用。这个部分通过一个零售业的样例引入了实体的列表，这个样例构成了这篇文章的核心。
数据建模（Data Modeling）透视图 向你介绍了关于在 IBM WebSphere? Application Developer (或者 Eclipse) 中的数据建模（Data Modeling）透视图的主要特性，并带你在 Rational XDE 中建立你的第一个数据建模（Data Modeling）项目。
第二部分：使用 Rational XDE 进行数据建模
逻辑数据建模 将实体列表转成羽翼丰满得逻辑数据模型，并演示如何转换整个逻辑数据模型成为（物理）数据模型。
物理数据建模和 DB2 UDB 集成 展示从逻辑数据模型中生成数据模型，和如何对这个模型进行一些变更以包括其他的（比如表空间）物理实现特性。这个部分演示如何直接正向工程数据模型成为一个 DB2 UDB 数据库中的模式（schema ）。
逆向工程 显示逆向工程的整个过程。在早期被创建的 DB2 UDB 数据库被逆向工程成为一个最新的数据模型。从这个数据模型，你能够产生一个逻辑数据模型。
同步工具 展示同步工具在管理和传播在逻辑模型、物理模型和实际数据库之间的变化的能力。
软件要求
本文的主题是 Rational 的 Data Modeler ，它是 Rational XDE 的 Rational 开发者工具集的一个主要的部分。 Rational XDE 被集成进了IBM 的其他开发工作台工具中。在本文中，它被与 IBM WebSphere Studio Application Developer, version 5.1.1 一起使用。
在自由下载的 Eclipse 开发工具 2.1 版本中运行 Rational XDE 是可能的。将 Rational XDE 安装进入 WebSphere Studio Application Developer 中超出本文的范围，但是这个安装过程是相当直接的。 本文的目标数据库是 IBM DB2 UDB 。你能够下载一个 DB2 Universal 数据库或者 Personal Edition version 8.1.3 的 试用版本
逻辑数据建模
创建逻辑实体
你已经创建了数据建模的项目了，你可以准备开始一个逻辑数据的建模工作了。你将回想一下到目前为止所有你已经有的超市样例的六个实体，在表格了列出了实体的属性集合。为了真正的说明实体之间是如何关联的和解释设计，你需要一个更加令人兴奋的和信息丰富的介质 － 也就是一个实体关系图。这是 Data Modeler 能够给你的作为你设计的逻辑模型的一部分。
这里有一些机制。你将与 Logical Data Model:Main 图进行工作。创建六个分离的 UML 类来代表原始列表中的六个逻辑实体：
1. 为 Logical Data Model:Main 图选择编辑窗口。
2. 注意，Toolbox 视图的 UML Class 面板（左边）会自动的展开。选择 Data Model:Main 和 Logical Data Model:Main 中的任意一个 － 注意当物理图被选中时 Data Modeler 面板是如何被展开的。确保你已选择了 Logical Data Model:Main 为结束。
3. 引入第一个实体。从 UML Class 面板列表中点击 Class 然后在点击 Logical Data Model:Main 图的任意位置点击鼠标。等待片刻，Class1 以一个盒子的形式出现在图中。重命名它为 Order 。
4. 重复上面的步骤来创建其他五个类（逻辑实体），分别命名为：Order Detail、Supplier、Product、Garment 和 Food Item
5. 注意，当你创建类时，他们作为新的节点出现在 Logical Data Model 的 Model Explorer 视图中。
6. 保存图（Ctrl-S）。
你的逻辑数据模型图应该象下图：
实体原型
你已经有了你的超市数据库逻辑设计的框架了，你的逻辑实体看起来非常象 UML 的类。你的任务是产生一个实体关系图。为了使 UML 类更象实体，给他们一个实体的原型。他们的图标在 Model Explorer 视图中会有所变化，这样就有了一个可视化的提示告诉我们数据模型与你的超市对象模型有所不同。 应用实体原型：
1. 依次选择每一个类。
2. 在 Properties 视图中找到 stereotype 特性。
3. 点击这个特性有边的按钮。一个 Properties 窗口被打开（见下图）。
4. 在 Properties 窗口列表中，选中 Entity 。
5. 点击 OK 。
在 Model Explorer 中，注意你选择的类的图标是如何从一个档案柜样子图形编程黄色圆圈下带一条直线的图形。 你也许也注意到了逻辑图也使用了相同的图标，稍微大一些。如果你宁愿将可视化的原型作为平淡的文字（<<entity>>），找到 Appearance 工具栏：
使用一个或者多个被选中的类，点击 Show stereotype as... 下拉列表并选择 Shape Stereotype: Label 。
注意，在帮助文字中所说的："<<entity>> 原型被需要转化类到数据模型表"。将类指派成为实体是很好的。
一些技巧：
有时 Appearance 工具栏很难被找到。如果你不能找到它，Window > Reset Perspective 通常能够使它可见。
有时类有选择的出现，但是 Appearance 工具栏按钮会变灰或者不可得到。远离类点击鼠标，然后重新选择就会解决这个问题。
你的超市逻辑设计现在是可理解的了，即使还有些不丰满。你加了一些类并将他们转换成了实体，但是到此为止他们还缺乏属性。现在是时候添加这些属性了。
添加属性的一个方法是在 Model Explorer 视图中右键点击实体，并从上下文菜单中选择 Add UML > Attribute 。这不是非常高效的。在这点上你能做的所有事情是给属性一个名字（任何为属性添加类型的尝试都会被拒绝）。
直接编辑图形是更好的方法。在逻辑数据模型图中右键点击 Order 类，并选择 Add UML > Attribute 。这个时候为属性命名，后面跟着一个冒号，然后是一个类型。这就是第一个属性，Order Id ，看起来象：
Order Id: Integer
作为一个被添加的特性，当你按下回车键时，你会发现在下一行上已经立即添加了下一个属性。
Order Description: String
Order Type: ProductType
Order Status: OrderStatus
Created By: String
Created Date: Date
在你为最后一行按下回车键后，按 Escape 键，它能够删除新的将要添加的属性。仔细的输入上面所示的属性。两个词的名字，比如 Order Description 之间有一个空格；两个词的类型则没有。
为剩下的实体添加属性
重复前面所讲述的过程来为其余的五个实体添加被需要的所有属性。
为 Order Detail:
Order Detail Id: Integer
Sequence: Integer
Quantity: Single
Price: Currency
为 Supplier:
Supplier Number: Integer
Supplier Type: ProductType
Location: String
Active: Boolean
Address: String
为 Product:
Product Id: Integer
Product Description: String
Product Type: ProductType
Units In Stock: Long
Units Sold: Long
Cost Price: Currency
Selling Price: Currency
为 Garment:
Size Range: String
Color: String
Fashion Season: String
为 Food Item:
Sell By Date: Date
Perishable: Boolean
你的逻辑数据模型图看起来应该与下面的图非常相似：
在这个阶段，你已经为超市的样例在最初的实体列表中输入了所有的信息表示。虽然信息是相同的，但是在 Data Modeler 中的信息提供了两个独特的优点。第一个是，你拥有了一个立即被创建的图；第二个是，你输入到图中的大部分数据都成为了结构化模型中的数据。你可以非常自由的产生图。
在数据类型上的词
对于例子中的多数部分，被使用的数据类型是 Ratioanl XDE 中的分析数据类型。他们具有能够直接转换成为 DB2（和其他数据库管理系统）的数据类型的优点。Raional XDE 的在线帮助中包含了一个有用的映射表。为了找到整个信息：
1. 从 WebSphere Studio 的菜单中选择 Help > Help Contents 。
2. 点击 Rational XDE 。
3. 对内容的层次浏览找到：Modeling Data with Rational XDE > Transforming Tables, Classes and EJBs > Class to Table Transformation Data Type Mapping > Class to DB2 Table > Transformation Data Type Mapping 。
然而，有两个数据类型，他们是被用户定义的。他们是 ProductType （被 Order 、 Supplier 和 Product 实体的属性引用），和 OrderStatus （被 Order 实体的Order Status 属性引用）。在你的逻辑数据模型中，这些类型被建模成为枚举类型。
现在，让我们来看看在超市的样例中 Data Modele 如何支持用户定义的数据类型的。在逻辑数据模型中，建模这些类型成为枚举类型。
枚举类型
枚举类型为被给定的属性提供了一个相关的文字选择的集合的机制。在这个例子中 ProductType 有三个可能的值：
G -- 对于 garment 。
F -- 对于 food 。
B -- 对于 garment 和 food 。
首先，让我们对逻辑数据模型图引入 ProductType 和 OrderStatus ：
1. 从 UML 类面板中选择 Enumeration 。
2. 在逻辑数据模型的自由区域点击鼠标。
3. 重命名第一个枚举类型为 ProductType 。
4. 重复上面的步骤，命名第二个枚举类型为 OrderStatus 。
为枚举类型添加文字表达
好于添加属性到枚举类型，你能够添加枚举类型的文字表达。过程非常类似于添加属性。
1. 在逻辑数据图中，鼠标右键点击代表枚举类型的图形，并选择 Add Enumeration Literal 。
2. 在枚举类型的文字表达的值域中输入值并按回车。
3. 在最后一个枚举类型的文字表达被输入后，按 Escape 键清除被新添加的行。
4. 保存你的工作。
对于 ProductType 文字的表达是：
G F B
对于 OrderStatus文字的表达是：
Created Approved On Hold Rejected Completed Part Delivered
枚举类型的命运
在超市的样例中逻辑设计已经合并了用户定义的数据类型。这些数据类型的使用不能是更加容易的：当你添加被用户定义的数据类型的属性时，你简单的输入数据类型的名字（甚至，虽然你在那时还没有定义数据类型）。
逻辑设计不是故事的结束。甚至在这个阶段，Data Modeler 允许你为向物理模型进行一个平滑的转换设置基础。
当这发生时，每一个枚举类型都有两种命运：或者被表示成一个独立的表，或者变成一个目标数据库中的域。如果这个区别对于你来说不是很清晰，不要担心 － 你将在本文的后面看到他们的不同。
对于现在，你要设置决定你的两个枚举类型正确命运的特性。
首先，在逻辑图中点击 OrderStatus 。注意，在 Properties 视图中，有一个在 Enumeration Data Modeler 特性部分被命名为 IsSeparateTable 的特性。这个特性的缺省值是 True 。这正是你想要的。OrderStatus 关联到一个供应链的工作流上，它可以良好的改变。
实体的 Class 特性：代理键
点击 ProductType 并改变 IsSeparateTable 特性为 False 。ProductType 被作为一个域被实现。这稍微有些缺乏灵活性。我能够想象在将来会有不同的类型出现，因此一个表也许是更好的选择。对于本文的目的，用一个域来实现是更为合适的。
为了转换到物理模型更多的准备是必要的。点击 Order 实体，并注意 Properties 视图的 Class Data Modeler 部分，有一个 UseSurrogateKey 特性。这个特性的缺省值是 True 。
当你保留这个值为 True 时，就没有必要识别任何属性来唯一的标识你的实体 － 换句话说，属性担当了主键。相反，到物理模型的转换过程生成了一个额外的担当代理键的属性。
代理键的概念被在数据库设计的周期中良好的理解。通过提供缺省的对代理键的自动化支持，Data Modeler 节省了时间和工作量。然而，通常会存在一些原因保留了在逐渐说明上的手工控制。在超市样例中的多数例子中，你将任命"candidate"为主键。
为 Order 改变 UseSurrogateKey 特性的值为 False 。对 Order Detail、Product 、Garment 和 FoodItem 重复这个操作。在 Supplier 实体中保留值为 True ，以便你能够在晚些时候看到代理键生成的例子。
Attribute 特性：候选键
超市实体的每一个都必须有一个或者多个主键来唯一识别每一行。不仅是整个标准的数据库设计实践和良好的常识，它也满足标准化的规则。Supplier 实体将拥有一个为它产生的代理键。对于其他的五个实体，你需要任命候选键。
最方便的方法是使用 Model Explorer 和 Properties 视图进行工作。
在 Model Explorer 视图展开 Order 实体。
点击 Order Id 属性，它是一个候选键。你的透视图的右边看起来象下图。
注意，在 Properties 视图的 Candidate Keys Data Modeler 部分的两个特性： IsNullable 和 OID 。IsNullable 决定属性是否能够作为 null 处理 － 缺省的值是 True （它能）。不是特别明显 OID 特性指定属性作为一个候选键 － 缺省是 False （它不能）。
1. 为 Order ID 属性改变 IsNullable 的值为 False 和 OID 的值为 True 。
2. 在 Model Explorer 视图中按下 Control 键同时点击其他五个 Order 属性以选择他们所有的。
3. 在 Properties 视图改变 IsNullable 的值为 True （它能够一次改变所有的五个属性）。保留 OID 的值为 False 。你可以说它对于其他五个属性是一个强制 － 他们不能是 null －但是他们不是候选键。你的透视图的右边看起来应该与下图类似：
在逻辑数据模型图中进行可视化的属性改变。
1. 选择逻辑数据模型图（在编辑窗口的任何地方点击鼠标）。
2. 点击 Diagram > Layer Selection
3. 在 Layer Selection 窗口的 Select Layers 中，选中 Data Modeler 以启用列表。
4. 点击 OK 。
你应该能够看到在 Order Id 属性的左侧有一个银色的钥匙的图标，指明这个一个候选键。
重复上面的步骤指定下面的候选键：
Order Detail: Order Detail Id
Product: Product Id
你能够在任何非空标记的实体上产生一些或者所有的属性。
实体关系：强关联
你现在有了具有完整属性的实体了，并通过代理键和候选键分配了主键的值。然而，超市数据库的设计还不是非常完整。你还没有引入任何在实体之间的关联 － 在实体关系图中你有责任产生的实体之间的"关系"。为了完成这个，在 Toolbox 视图中从 UML Class 面板中使用各种关联。
首先，看一下在 Order 和 Order Detail 之间的关联。这是一个典型的父－子关系：如果没有父 Order，将不会有 Order Detail 的存在。在 Data Modeler 中，这是一个强关联。使用工具栏中的 Composition Association 关联来表示它。
1. 选择逻辑数据模型图。
2. 在 UML Class 面板上点击一下 Composition Association 。
3. 在图中的 Order 实体上点击一下。
4. 在图中的 Order Detail 实体上点击一下。
一个关联被画在了两个实体之间。这是在 Properties 视图中使用它的可见的特性被自动选择的。如下调整特性：
1. 改变 End1Name 为 _Child Order Lines 。
2. 改变 End2Name 为 _Parent Order 。
3. 改变 End2Multiplicity 为 1 。
逻辑数据图中的结果看起来应该如下图：
关系的命名在实体关系建模中是被鼓励的，虽然有时你也许会争论关系是如此的明显，命名是没有必要的。
多样性确认：
一个 Order 的实例能够为一个 Order Detail 而存在（甚至虽然你还没有到物理这一级）。
为一个 Order 视图能够有零个和任何数量的 Order Detail 实体存在。这是由星号对面的被命名为 _Child Order Lines 的关系决定的。
当在 Data Modeler 的结构化的模型中处理多样性时， Data Modeler 再一次的提供了图形化显示关系的优点。
实体关系：弱关联
一个 Order Detail 的实例需要一个 Order 实例的存在，因为在他们之间存在着强关联。然而， Order 和 Supplier 实体能够很好的独立存在 － 每一方都不一定需要对方的存在（因为是弱关联）。这种关联并不是至关重要的：一个 Order 实体的创建包含了选择适合他们的供应商。这就是一个弱关联。
你可以使用正规的 UML 关联建模它。
1. 选择逻辑数据模型图。
2. 从 Toolbox 视图中的 UML Class 面板点击一下 Association 。
3. 在图中的 Order 实体上点击一下。
4. 在图中的 Supplier 实体上点击一下。
一个关联被画在了两个实体之间。适当的调整这个关联。
1. 将 End1Multiplicity 改为 1 （一个 Order 实例必须有一个并只能有一个相关联的 Supplier 实例）。
2. 将 End2Multiplicity 改成 * （一个 Supplier 实例可以与零个、一个或者很多个 Order 实例相关联）。
3. 可选的，为关系的两端指定名字（End1Name 和 End2Name 特性）。
结果应该象下图所示：
在 Order Detail 和 Product 之间添加一个关联，使用与上面相同的步骤。End1Multiplicity 还是 1 并且 End2Multiplicity 是星号（*）（一个 Order Detail 实例能够引用一个并只能引用一个 Product 的实例；然而，相同的 Product 实例能够在多个 Order Detail 实例中存在）。
实体关系：一般化的角色
两个实体被剩下还没有任何关联：Garment 和 Food Item 。他们是典型的实体子类型。现在你能够看到 Data Modeler 如何能够简单并自然的建模这个概念。对任何产品（不论是衣服还是食品）的可应用的属性都在 Product 实体中被保存。属性被指定的类型分别保存在 Garment 或者 Food Item 中。
如果父 Product 实例不存在的话，Garment 或者 Food Item 的实例也就不会存在，因此乍一看一个强关联应该是合适的（使用面板中的 composition 关联）。然而，Data Modeler 为这类关心开发了一般化（generalization ）关联。将它引入到你的图中：
1. 选择逻辑数据模型图。
2. 在 UML Class 面板中点击一下 Generalization 。
3. 在图中的 Garment 实体上点击一下。
4. 在图中的 Product 实体上点击一下。
5. 在 UML Class 面板中再点击一下 Generalization
6. 在图中的 Food Item 实体上点击一下。
7. 在图中的 Product 实体上点击一下。
结果应该如下图所示：
物理数据建模和 DB2 UDB 的集成
建立数据模型的数据库
对于你的超市需求的下一个任务是创建一个（物理）数据模型。好消息是大部分困难工作已经被完成了。Data Modeler 将会自动化从逻辑数据模型到物理域的转换过程。有两个原因需要一个物理模型：
1. 允许将物理实现与逻辑和设计分开
2. 封装创建和维护实际的 DB2 数据库所需的定义。
在现实生活中，在物理建模阶段你可能要进行多次的手工调整。对于本文的目的，你要很大程度的接受你创建逻辑设计向一个物理设计的直接转换。在这个阶段你的产品化需求也许要引入多个新的表和关系。
因为目标数据库是 DB2 数据库，所以以一个 DB2 数据模型开始是最好的。当你创建你的数据建模项目时，你被提供两个数据模型。你已经在逻辑数据模型上进行了许多的工作了，在（物理）数据模型上没有任何事情要做了。因此你将删除被给的（物理）数据模型并自己创建一个 DB2 的数据模型。通过下面的步骤可以完成：
1. 在 Model Explorer 视图中，右键点击 Data Model ，并选择 Close 。
2. 切换到 Navigator 视图。
3. 右键点击 DMTutorial 项目中的 Data Model ，并选择 Delete 。
4. 右键点击 DMTutorial 项目，并选择 New > Model 。
5. 在 Create XDE Model 窗口，从 File Types 中选择 DB2 UDB ，并从 Templates 中选择 DB2 Data Model （如下图所示）。
6. 点击 Finish 。
确认（物理）数据模型图在编辑窗口中被打开，并选择它。如果没有打开，在 DB2 Data Model （例如，物理数据模型分支）的 Model Explorer 视图中双击 Main 。注意 Toolbox 视图的 Data Modeler 面板是如何变得可见的，现在它已经装入了一些工具：
现在让我们创建一个数据库：仍然不是一个 DB2 中的实际数据库，但是它是一个数据模型图中的一个代表。
1. 在 Toolbox 视图中的 Data Modeler 面板中点击一下 Database 。
2. 在数据模型图中的任意地方点击一下鼠标。
3. 一个数据库说明窗口被打开。为数据库命名为 OrderDB 。如果还没有设置，将目标数据库设为 IBM DB2 8.x 并点击 OK 。
4. 现在再看一下 Data Modeler 的缺省设置（之前再三个 Data Modeling Preferences 面版中看到的）。点击 Window > Preferences ，展开 Rational XDE ，并选择 Database Defaults 。选中：
Settings For: 被设置为 (DM Tutorial) DB2 Data Model 。
改变缺省的数据库为 OrderDB （从下来菜单选择），它是你之前几步创建的数据库。
确保缺省的数据库目标被设置为 DB2 UDB 8.0 。
改变最到标识符长度为 18 （这可以确保 DB2 的约束标识符有合法的长度）。
点击 OK 退出 。
转换逻辑数据模型
现在你已经将逻辑数据模型转换成了一个（物理）数据模型。"转换"这个词可能会使你认为逻辑数据模型以一些方式被改变了。实际上，它没有被改变，虽然在逻辑和物理数据模型中有一些关联元素的元数据被创建了。物理数据模型实际上是从逻辑数据模型中的信息中生成的。
1. 确定 DB2 Data Model 在 Model Explorer 中被打开。
2. 确认在 DB2 Data Model 中仅仅是（物理）数据模型被打开。这是 XDE 如何确定要转换的目标模型的方法。
3. 在 Model Explorer 中鼠标右键点击 Logical Data Model 。
4. 选择 Transform > Transform to Table....
5. 在 Available Packages 面板中，（DMTutorial）DB2 Data Model 应该已经被选中了。
6. 目标数据库应该被设置为 DB2 UDB 8.0 ，变灰并且不可得到。
7. 检查 Generalization 被设置在 Separate Table 的缺省值上。
8. 检查前缀是空白的。
9. 确认 Create Indexes for Foreign Keys 被选中。窗口看起来如下图：
10. 点击 OK 保存数据模型。
转换到表的结果
在这个阶段转换到表的结果仅仅出现在 Model Explorer 视图中，如下图所示。
注意，这个阶段，数据模型图仍然仅仅包括数据库。尤其是如果这是你第一次接触 XDE 工具集合的使用，存在于模型中但不在图中的元素是没有价值的。实际上，你能够从图中删除图形，但是他们仍然会保留在数据模型中。为了向数据模型图中引入最新创建的表：
1. 选择 DB2 Data Model 图。
2. 在 Model Explorer 中依次点击每一个表，并将表拖到图的表面。以你习惯的方式对这些表进行布局。
3. 注意，通过在图的表面上拖拉表你将得到表之间的关系。
4. 不要在图的表面上拖动域 － ProductType ：它要用不同的方式被处理。（如果你已经这样做了，你只能从表中删除它）。
数据模型图
在被从逻辑模型中转换而来的数据模型上有很多值得注意的有趣的特性，如下图所示：
首先是， UML 类的原型被改变了：代替在盒子的顶部有一个 <<entity>> ，现在你有了一个 <<table>> 。这标注了从逻辑到物理模型的适当转移。
在表中的每一个属性都有一些描述的文字。
PK -- 用红色表示 -- 表明是主键。
FK -- 用红色表示 -- 表明是外键。
P 在 F 上面然后是 K -- 用红色表示 -- 表明既是主键又是外键的属性。
N -- 用黑色表示 -- 表明对属性的值允许为空。
NN -- 用黑色表示 -- 表明空值（ null ）别允许。
主键出现了，因为你将他们任命为逻辑模型中的候选键（注意为主键域自动产生的名字， Supplier_ID，很巧妙的与手工命名的主键区分开来）。
很多的外键（或者主/外键）出现了，因为你建立了关联，并且早期 Data Modeler 参数的设置能够自动的跨于关系移动这些键。因此例如，如果你看一下 Order Detail 表：它有一个 Product Id 的外键属性。你从来都没有明确的为逻辑模型添加这样一个属性；相反，它被引用成为在 Order Detail 和 Product 之间关系的适当的物理实现。
对于 DB2 来说，数据类型与他们的来自于逻辑模型的匹配物有了很大的改变（比如，TIMESTAMP 代替了逻辑的 Date）。这个映射在 Rational XDE 的帮助部分的文档中可以被找到。Data Modeler 已经指明了所有被创建一个数据模型需要的数据类型都要完全的与一个数据库管理系统兼容。
枚举类型和一般化关系的转换
当在逻辑数据模型中建立 OrderStatus 枚举类型时，你指明了属性 IsSeparateTable 为 True 。现在在转换中这已经成为了过去。OrderStatus 被一个独立的表所代替，一个带有 INTEGER 类型的键的 Order 表。它拥有被称作 Enumeration 和 Description 的属性。
ProductType 的 IsSeparateTable 属性被设置为 False 。这样它在物理模型中被转换成了一个域 － 不再在一个图中了，但是它在 Model Explorer 中是可见的。仍然有单个表属性(Order 中的 Order Type , Product 中的 Product Type 和 Supplier 中的 Supplier Type ) 引用了 ProductType 作为他们的数据类型。当你创建 DB2 UDB 数据库时，他们被作为数据库的约束实现。
你可以回忆一下在 Transform to Table 窗口中，你选择了 "separate tables" 作为实现一般化关系的方式。现在你可以看到它的结果了。 Garment 和 Food items 已经被不同的表实现了。你能够期望，如果在 Product 表中的一行描述了一个 Product ，在 Garment 表中应该存在一个对应的行。匹配被实现了，因为转换将 Product Id 作为 Garment 表的主键，同时也作为了外键 － 指回到了在 Product 表中匹配的 Product Id 上。上面的做法对 Food Item 同样很好。 作为一个开始点，作为转换的结果 String 到 VARCHAR(255) 的转化是可以的，但是看起来对许多域来说似乎有一个太高限制。你能够为你想要修改的属性调整 TypeExpression 属性。
1. 在 Model Explorer 视图中，展开 Order 表。
2. 选择 Order Description 属性。
3. 在 Properties 视图中将 TypeExpression 改为 CHAR(50) 。
对任何或者所有的 VARCHAR(255) 属性重复这个步骤。
ProductType （域 － 一种用户定义的数据类型）仍然没有在任何图中被显示。当域去向于恒定不变时，它就可以在很多物理模型中被反复的使用，这是一种良好的集中维护的想法。找到他们的最佳地点时在分离的 DB2 Domain Model 中。现在创建它。
1. 选择 Navigator 视图，并鼠标右键点击 DMTutorial 。
2. 选择 New > Model > File Type of Data > DB2 UDB > Template of DB2 Domain 。
在 Model Explorer 视图，将 ProductType 从主数据模型移到这个为域新建的模型中。
1. 在 Model Explorer 视图中鼠标右键点击 Model Explorer 并选择选项 cut 。
2. 模型中鼠标右键点击 DB2 Domain 文件夹。
3. 选择选项 paste 。
最终的结果应该象：
接下来，对 ProductType 进行一些改变。
1. 右键点击 ProductType 并选择 Data Modeler > Open Specification...。
2. 在 General 标签上，将 Datatype 改为 CHAR 并且 Length 为 1 。
3. 确保 Generate on Server 不被选中。
4. 对其他的域使用缺省值。
注意: 选中 Generate on Server 选项会导致当你对 DB2 数据库正向工程时，产生一个为 ProductType 的 CREATE DISTINCT TYPE DDL 语句 ，对于 ProductType 的有效的值以一种更加简单的方式被实现。
5. 在 Check Constraint 标签上，将表达式 ProductType IN ('G','F','B') 改为 @ProductType IN ('G','F','B') 。
6. 在 Model Explorer 中找到 ProductType 。有一对假的约束被附加到 ProductType 上作为 Transform to Table 过程的结果。从模型中将他们删除。
将 DB2 数据模型和 DB2 域模型绑定到一起
确保主物理模型（DB2 Data Model）能够在 DB2 Domain Model 中使用 ProductType 域：
1. 从 Model Explorer 视图中，选择并拖动 (DMTutorial) DB2 Data Model 到 DB2 Domain Main 图的表面。选择并拖动 DB2 Domain 文件夹到相同图的 (DM Tutorial) DB2 Domain 的最外边的文件夹下。
2. 从 UML Class 面板中点击 Dependency 。
3. 点击 DB2 Data Model （在图上）然后点击 DB2 Domain （在图上）。你正指明对于域的定义 DB2 Data Model 依靠 DB2 Domain 模型。最终的结果看起来应该象下图：
如果你没有这样做，现在保存 DB2 Data Model 和 DB2 Domain 模型。
Data Modeler 中的表空间（Tablespaces ）
你已经准备正向工程到一个真正的 DB2 UDB 数据库了。然而，在你这样做之前，你将为表分配表空间。表空间管理表数据的物理位置到分别的磁盘空间，这对一个小的数据库样例来说是没有必要的，但是对于你的超市订单系统来说，有些事情可能是你希望在产品环境中想要的。
1. 分配表到 OrderDB 数据库。这是定义表空间的一个要求。完成这个非常简单：在数据模型图中的 OrderDB 上右键点击并选择 Data Modeler > Assign 。在输出窗口（Rational XDE tab）中，你应该看到一些象下面的输出：
2. 为了看到分配的证据，展开 Model Explorer 中的 OrderDB 节点。表名被列出图标指示realization 关系到数据库：
3. 通过在你的图中右键点击数据库来创建一个表空间，并选择 Add Data Modeler > Tablespace 。在创建窗口中接受所有的缺省设置，包括名字：Tablespace1 。添加第二个表空间叫作 Tablespace2 。
4. 为了向表空间添加表，右键点击 Food Item （在图中或者在 Model Explorer 视图中）并选择 Data Modeler > Open Specification... 。选择 Storage 标签。
o 对于 Tablespace 的说明，从下拉列表中选择 Tablespace1 。
o 对于 Index Tablespace 说明，再次选择 Tablespace1 。
5. 为其他的表重复这个过程，有一个例外：对于 Supplier 表使用 Tablespace2 作为表空间和索引表空间。
6. 为了在 Model Explorer 中检查这些变化的结果，展开 OrderDB 数据库节点。你将看到表空间出现在 OrderDB 节点和它的实现关系的中间。
在 DB2 UDB 中的表空间
在 Data Modeler 中建立表空间还不是足够的。相应的表空间也必须存在于 DB2 UDB 中。 这里是建立他们的一个简要的指南。
1. 打开 DB2 控制中心。
2. 展开层次结构以显示你的目标数据库。
3. 右键点击表空间并选择 Create ，就像下面的图那样。
Create Table Space Wizard 出现。
4. 在向导的第一个窗口，指定一个名字：TABLESPACE1 。
5. 跳过向导的第五个窗口，并通过点击 Add 指定一个容器，然后挑选一个位置。例如，选择 DB2 安装阶段和数据库目录下的一个位置，并且命名为 TABLESPACE1 。结果见下图。
6. 点击 完成。
7. 重复上面的步骤来创建 TABLESPACE2 。
验证模型
确保所有的规则对于你的目标数据库都是符合的。Data Modeler 能够帮助你完成这。右键点击 Model Explorer 中的 DB2 Data Model 并选择 Validate 。
偶尔你将看到一对错误显示在 Tasks 视图中：
依次双击每一个错误，你将在 Model Explorer 中得到错误的来源。在一种情形中，有一个列名表示符 Product Description 。右键点击并重命名为 Product Desc 。在其他的情况下，有一个外键约束标识符 FK__Child Order Lines 。重命名它为 FK_ChildLines 。在 DB2 Data Model 中右键点击，并选择 Validate 。应该不再会有错误。
正向工程
最后你准备生成超市的样例数据库了。在 Data Modeler 中这被叫作正向工程，并且是一个一步完成的过程。首先你能够生成一个 DDL 脚本，然后使用 DB2 的命令中心来执行这个脚本。为了更加方便，从 Ratioanl XDE 中直接连接数据库并运行 DDL 脚本。
这里有一个可重复的问题：当你进行正向工程时，一个"green field"（空的）目的地被假设。你不会得到一个脚本来应用改变，而是一个创建整个数据库的脚本。如果你准备在运行正向工程之前删除数据库，这是非常好的。否则，要存在一种避免这个必要性的同步方法，这会在本文的结尾部分作简要的介绍。
1. 在 Model Explorer 视图中右键点击 Data Model 并选择 Data Modeler > Forward Engineer 。
2. 在第一个对话框窗口中点击 Next 。
3. 在第二个对话框窗口中检查所有的选项除了 Fully qualified names 和 Quoted identifiers：
4. 在第三个对话框窗口点击 Next ，使用 Browse 按钮找到一个合适的目录并命名一个文件来存储 DDL 脚本。你能够将它推迟到以后再做以看到实际被应用的脚本语句。
5. 在对话框窗口中选中 Execute 选项。在 vailable fields 中：
o 检查驱动设置是 IBM DB2 APP DRIVER 。
o Leave Location 保持不变
o 输入 DB2 UDB 的一个用户名和密码。
o 使用下拉列表选择一个数据源（数据库）。注意：对于本文，缺省情况下，唯一可见的数据库是一个已有的叫作 DWCTRLDB 的样例数据库。如果你有其他的数据库想用，你能够将他们设为可见。在 Windows 下，为你的数据库建立一个系统定义的 ODBC 数据源。
o 推荐： 按下 Test Connection 按钮。你应该得到一个简单的消息说"连接成功"。
全部的对话框看起来如下图：
6. 点击 Next ，Forward Engineering wizard 完成了它的工作。你应该在最后一个对话框窗口看到一个消息，"You have successfully completed the Forward Engineering wizard"。
7. 点击 Finish 并检查 Output 视图中的输出结果。
对于 Windows 用户的重要提示
如果你正在使用 windows 运行这个例子，在运行正向工程之前，检查记录 DB2 JDBC driver software (db2java.zip) 的注册表入口是重要的。你将在 XDE 的帮助部分找到一个参考： Connecting to Database Management Systems － DB2 Database Connections 。
Rational XDE 安装后，你将发现一个注册表键： HKEY_LOCAL_MACHINE\SOFTWARE\Rational Software\XDE\AddIns\Data Modeler
对于本文，在安装之后，这个值被设置为：
C:\Program Files\SQLLIB\java\db2java.zip
这个键的值必须改变为下面的值：
C:\Program Files\IBM\SQLLIB\java\db2java.zip
假设你成功的完成了正向工程的过程，你应该在你的物理数据中有一些表和索引。缺省的情况下，当你连接到数据库后，他们被附在一个被命名的模式上。
这里是 DB2 控制中心的一个截图，显示了被创建的表：
如果你想查看 DDL 脚本，在文本编辑器中打开他们。下面是一个短的例子：
CREATE TABLE Supplier ( Supplier_ID INTEGER GENERATED ALWAYS AS IDENTITY, Supplier_Number INTEGER, Supplier_Type VARCHAR ( 255 ), Location VARCHAR ( 255 ), Active SMALLINT, Address VARCHAR ( 255 ) ) IN Tablespace2 INDEX IN Tablespace2 ; CREATE TABLE Order_Detail ( Order_Detail_Id INTEGER NOT NULL, Sequence INTEGER, Quantity REAL, Price DOUBLE, Product_Id INTEGER NOT NULL, Order_Id INTEGER NOT NULL ) IN Tablespace1 INDEX IN Tablespace1 ; CREATE INDEX Foo_Constraint26 ON Food_Item ( Product_Id ) PCTFREE 0 ;
恭喜你！你已经为你的超市数据库需求完成了从逻辑数据模型到（物理）数据模型再到实际的 DB2 UDB 数据库的转换！你也许想使用 DB2 UDB 的工作来添加一些数据并测试一些唯一键和其他的约束。
显然，到此为止你已经在 Rational XDE 中做了大量的工作。甚至对于这样一个较少数量的表的例子，比起使用 DDL 来创建你的数据库，Data Modeler 输入是更加简单又快速的。考虑一下你现在的情况，你不仅有物理的 DB2 数据库，而且：
你还有一个逻辑的数据模型和一些相关的图，他们可以用来与你的用户进行进一步的需求讨论。
你拥有连接到逻辑数据模型的一个物理模型，相关的图，你也可以用他们作为你所有未来数据库维护的基础。
逆向工程
采取逆向工程
到现在为此，你已经获得了一个逻辑业务需求并将他们作为一个数据库而实现。很可能在你的开发项目中已经遇到了逆向的需求：你已经拥有了一个数据库并且想做一个或者多个以下的事情：
可视化 表和关系
维护 你的数据库是以图形为载体的
获得 将你的已存在的数据库设计还原回逻辑模型以便重新设计或者对他进行扩展。
现在我们将通过使用你刚刚创建的样例数据库，并将它转换回到（物理）数据模型，在转换到逻辑数据模型，来看一下在 Rational XDE Data Modeler 中对于这点的支持。
要注意的一点是：这不是你能够称为的现实世界的例子。你所创建的样例数据库非常接近我们的逻辑模型的直接反映。因此，这是在没有太多人工干预下将物理数据库转化成逻辑模型的机会。
你将很可能发现你拥有的遗留的数据库与逻辑模型不是非常相符。有一个现象，物理数据通常是非常不规格化的（通常是因为性能的原因），而你的逻辑模型希望显示这种规格化。因此，列名就需要被大量的改写。我曾经使用过列名只有 6个字符的数据库，因为这是在我们选择编程语言时带来的约束。我们的逻辑模型需要可描述的名字以使最终用户能够理解。 Data Modeler 在这种情况下，能够给你带来很大的好处。，因为它允许逻辑名与十分不同的物理名进行同步。
创建一个新的 DB2 数据模型
让我们来看一下将样例物理数据库转换成为数据模型的实际步骤。你将为这个目的创建一个新的模型。你能够创建的新的模型将保存在相同的 XDE 数据建模项目中。
创建新模型的一个方法是在 Navigator 视图中右键点击项目，并选择 New > Model... 。在 New XDE Model 窗口中，选择 DB2 UDB Data Model-DB2 UDB 作为文件类型和数据模型的模板。将它命名为 DB2 Data Model 2 。
当你在窗口中点击Finish 时， 你将会得到一个新创建的模型的空白的主图。保存模型，并关闭图。
逆向工程到 DB2 数据模型
现在你要将样例数据库转换进入新创建的数据模型。
1. 在 Model Explorer 视图中右键点击模型，并选择 Data Modeler > Reverse Engineer... 。你会看到 Reverse Engineering 向导的欢迎对话框。
2. 点击Next 。
3. 从数据库（而不是一个DDL 脚本） 中选择以进行逆向工程。
4. 在下一个对话框，接受缺省设置，但要提供用户名、密码和数据源：
5. 点击 Next 。
6. 选择匹配 Order Retail 样例的合适的模式。
7. 点击Next 。
8. 检查所有额外的元素。
9. 点击Next。向导将为你生成模型
。
10. 在最后的窗口中点击Finish ，并检查 Output 视图中显示的错误。
缺省情况下，一个新的 Storage Modeling Diagram 被打开，显示你的物理数据库中的所有表空间 － 不仅仅是你放置在 Order Retail 中的表的 TABLESPACE1 和 TABLESPACE2 。关闭这个图，将注意力转移到 Model Explorer 视图。
在这个视图中，你应该发现一个新的被命名的包。展卡这个包，你能够看到 Order Retail 样例的表。将也将看到在这个包的级别上有一个 Main 图 － 现在打开这个图。图是空的。将表一个一个的拖到图中，按照你的习惯对他们进行布局。下图显示了最终的结果：
注意，加强外键和主键的约束是如何被转换成多样性的关联的。甚至如果关系没有被显示（因为在你的数据库中缺少适当的约束），这个技术能够被用来显示在哪里应该添加约束。
通常情况下 － 如果你开始时除了 Order Retail 数据库什么都没有 － 这是以最小的工作量来获取一些图形化的文档的最好的方法。
表到类 － 转换回到逻辑模型
现在你已经看到了从物理数据库生成数据模型是多么的简单了，你只剩下一个步骤要做了：将数据模型转换成逻辑数据模型。
1. 在 DMTutorial 项目中创建一个新的逻辑数据模型（例如 Logical Data Model 2）。
2. 在新的逻辑数据据模型中一个新的 Main 图被打开；保持这个图在打开状态。
3. 在 Model Explorer 视图中，右键点击（物理）数据模型包，并选择 Transform > Table to Class... 。
4. 一个窗口打开了可用的目标包。这应该是一个条目的列表，显示了你新建的逻辑数据模型。接受其他的选项并点击 OK 。
5. 检查 Model Explorer 视图中的逻辑模型。应该有几个新的实体类与被转换的表相对应。将新的实体拖到逻辑图中，按照你习惯的方式布局。这个例子显示如下：
通过很少的工作，你已经返回到你的零售数据库的逻辑视图了。
评估整个过程
这个过程包括：
正向：(A) 逻辑数据模型 > (B) 数据模型 > (C) DB2 数据库
逆向： (C) 相同的 DB2 数据库 > (D) 新的数据模型 > (E) 新的逻辑数据模型
有意义的部分是在 (A) 中的逻辑数据模型与被在 (E) 通过逆向过程完成的逻辑数据模型的比较。存在一些不同和一些值得注意的地方：
什么是已经被回复到类的实体。
在原来的实体和属性名中的小写字母和空格编程了大写字母和下划线（DB2 的命名规则被传递到了逻辑层）。
一般化的关联已经变成了合成的关联。
候选键已经消失了。现在每一个实体指定了一个代理键。
这是使用 Data Modeler 的直接结果。更进一步，你将发现你在三个层次上保持了同步 － 逻辑数据模型、数据模型和 DB2 数据库。
Data Modeler 能够支持所有这些，比如类到表的映射报告、和对数据库的同步。
同步工具
保持模型和数据之间的同步
在 Data Modeler 中的同步工具是非常广泛的。这部分将使你兴奋并了解这种同步的特性。
逻辑到物理模式的链接
在本文的前面 ，你获得了逻辑数据模型并使用"Transform to Table"工具将它转换成了物理数据模型。通过选择 Class to Table Report 选项报告在逻辑实体与物理表之间链接是可能的（右键点击逻辑数据模型以选择这个选项）。屏幕截图如下：
这给出了很好的在实体/表级别上的图形的指示。如果你需要在更低的级别展示链接 － 属性/列名级别 － 你能够这样做。如果你在物理模型中展开一个列名的视图，你将看到一个命名逻辑属性的依赖图标。如果你右键点击依赖，并选择 Select Supplier ，你将使用被选择的属性转换到逻辑数据模型。
你能够改变源属性的名字，并重新运行 Transform to Table ，重命名会正向的同步到物理数据模型。
数据库到物理模型
在数据库和物理模型之间，有一个比较和同步变化的选项。在被逆向工程的数据模型（DB2 Data Model 2）中， Order Description 的列名被改为 Order Desc 。右键点击 Model Explorer 中的数据库，并选择 Data Modeler > Compare and Sync 。通过几个向导对话框，你将看到变化被实现，并且有一个选项可以选项变化和根据变化采取的动作。
恭喜你！ 到此为止这篇文章已经结束了。你应该可以释放 Data Modeler 在数据库设计、实现和维护上的潜力了。
