为剩下的实体添加属性
重复前面所讲述的过程来为其余的五个实体添加被需要的所有属性。
为 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 。
文章来源于领测软件测试网 https://www.ltesting.net/
