為剩下的實體添加屬性
重復前面所講述的過程來為其余的五個實體添加被需要的所有屬性。
為 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 。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
