3.2 關系
如果我們只定義數據模式中的表，數據建模工具就不那么重要了。各個表之間的關系、依賴情況往往很復雜，有一個管理和顯示這些關系的工具將帶來很大的幫助。對于一個給定的關系，必須收集的重要信息包括：
父表和子表。 兩個表之間的強制關系。例如，父表可能有一個子表，但子表必須有一個父表。 關系基數（Cardinality）。即，一個父表可以有零個或者多個子表，但一個子表有且只能有一個父表。 關于關系的注釋、意見和角色說明。大多數建模工具通過在兩個或者更多表之間畫出連線的方式定義關系。默認情況下，關系往往被定義成為一對多關系，而且它對于關系中的任何一方都是可選的。要修改關系，你必須打開關系的屬性窗口，更新實體關系的特征信息。圖4a和圖4b顯示了兩個不同的工具允許為關系定義的部分屬性：
圖4a：PowerDesigner的關系屬性設置界面
圖4b：Visio的關系屬性設置界面
該圖顯示了一個一對多關系——一個典型的父-子關聯關系。部門（Branch）和雇員（Emplyee）的關系是強制的。它意味著一個部門必須至少有一個雇員（1-N強制關系）；另一方面，它意味著一個雇員必須屬于且只能屬于一個部門（1-1強制關系）。圖5a和圖5b反映了修改后的關系。
圖5a：PowerDesigner中兩個表之間的關系
圖5b：Visio中兩個表之間的關系
這個圖顯示了如何把信息轉換成符號。強制的關系由一條實心垂直線（而不是橢圓）表示。某些工具用虛線表示可選的關系。關系中屬于“多”的這一邊用一個類似鳥爪的圖形表示，關系的基數在靠近它所描述的那一端顯示。
你可能已經注意到，Employee表沒有定義外鍵列。這個圖仍舊處于“概念設計”階段——此后，從概念圖到物理數據模型之間的轉換是必不可少的。大多數工具區分概念和物理數據模型——概念數據模型描述信息的需求，但不關注細節問題，例如索引和強制性的引用完整性。
有些時候，你可能要定義自我引用的表。自我引用的表一般用來描述層次型關系。如下面的圖形所示，大多數數據建模工具能夠處理這類關系。注意在這個例子中，雇員可以有零個或者一個上級——它使你能夠處理一些特殊的情況，比如總統沒有直接的上級。
圖6a：PowerDesigner中自我引用的表
圖6b：Visio中自我引用的表
四、圖的規劃
定義表和關系只是挑戰的一部分，圖的清楚明白同樣很重要。雖然一些工具提供自動布局能力，我還沒有看到過一個完善的實現。相反，你的目標應該是遵從“孔雀東南飛”這一規則（這里的“孔雀”是關系中代表“多”這一方的符號，它是連接到表的三條分叉線，象個鳥爪）。換句話說，子表應該位于父表的右方和下方。這種安排使得從邏輯上組織和理解數據模型更加方便。最重要、最高級別的表應該出現在左上角，讓級別較低的表出現在頁面的右下角。為了清楚起見，減少圖中交叉線的數量也是很重要的。正如Eberhardt Rechtin在The Art of Systems Architecting中強調的，“一個好的設計往往看起來很舒服”。如果無論怎樣安排，你的數據模型看起來都很混亂，那么，它可能正在告訴你數據模型本身有一些值得注意的問題。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
