簡介
這個準則說明將設計模型中的持續性設計類別對映到資料模型中之表格的方法。
將設計模型元素轉換至資料模型元素
設計模型中的持續性類別可以轉換成資料模型中的表格。下表顯示設計模型元素和資料模型元素之間的對映摘要。
設計模型元素
|
對應的資料模型元素
|
類別
|
表格
|
屬性
|
直欄
|
關聯
|
非識別關係
|
關聯類別
|
交集表格
|
組合聚集
|
識別關係
|
多對多關聯
|
交集表格
|
對應關係
|
基數
|
限定關聯
|
交集表格
|
一般化(繼承)
|
個別表格
|
將持續性類別對映到表格
設計模型中的持續性類別代表系統必須儲存的資訊。在概念上,這些類別可能類似於關聯式設計。(例如,設計模型中的類別可能會以某種樣式,反映為關聯式綱目中的實體。)
不過,當專案從詳述進入建構時,設計模型和關聯式資料模型的目標便分道揚鑣了。這是因為關聯式資料庫開發的目標在於資料的正規化,設計模型的目標則是封裝日漸複雜的行為。這兩個角度(資料和行為)分離之後,兩個模型的相關元素之間,便有了對映的需要。
在第三種正常形式所撰寫的關聯式資料庫中,表格中的每一列(每個值組)都會被視為物件。表格中的直欄相當於類別的持續性屬性。(請記住,持續性類別可能會有暫時性屬性。)
因此,在不關聯於其他類別的簡單案例中,兩個世界之間的對映很簡單。屬性的資料類型對應於允許使用的直欄資料類型之一。
範例
下列 Customer 類別:
當在 RDBMS 中建立模型時,會轉換成稱為 Customer 的表格,含有 Customer_ID、Name 和 Address 等直欄。
這份表格的實例可以依照下列方式來視覺化:
對於每個持續性屬性,您必須問一些問題來引出將在關聯式資料模型中用來適當建立持續性物件模型的其他資訊。 例如:
-
這個持續性屬性可以作為索引鍵或索引鍵的一部分嗎?例如:「X 屬性與 Z 屬性可用來一起唯一識別物件」。在 Customer 表格中,Customer_ID 代表主鍵。
-
屬性的最小值和最大值是什麼?
-
有可能利用這個屬性作為索引鍵來搜尋嗎?比方說,它可能是 Select 陳述式中之過濾器的一部分,例如,「通常會搜尋 Y > 1000 的所有實例」。
-
屬性有「X 屬性是每 100,000 個傳輸字元重新傳輸的數目」之類的說明嗎?
-
屬性有可能的數值嗎?需要在不同數值之間轉換嗎?
-
誰可以更新屬性?例如:「只有 nn 權限等級的人可以變更 T」。
-
誰可以讀取屬性?例如:「yy 和 zz 權限等級的人可以讀取 P」或「P 包括在 Vi 和 Vj 視圖中」。
-
有數量和頻率的相關資訊嗎?例如:「A 最多出現 50,000 次」或「每天平均變更 2000 次」。
-
屬性唯一嗎?例如:只有一個人可以有相同驅動程式的授權號碼。
兩個持續性物件之間的關聯以相關物件的外鍵來實現。外鍵是表格中含有相關物件主鍵值的直欄。
範例:
假設 Order 和 Customer 之間有下列關聯:
當這對映到關聯式表格時,結果便是 Order 表格和 Customer 表格各一份。Order 表格有列出之屬性的直欄,以及一個稱為 Customer_ID 的直欄,其中含有指向 Customer 表格中相關列之主鍵的外鍵參照。對於給定的
Order,Customer_ID 直欄包含 Order 所關聯之 Customer 的識別碼。外鍵容許 RDBMS 將相關資訊結合起來。
聚集也是利用外鍵關係來建立模型。
範例:
假設 Order 和 Line Item 之間有下列關聯:
當這對映到關聯式表格時,結果便是 Order 表格和 Line Item 表格各一份。Line_Item 表格有列出之屬性的直欄,以及一個稱為 Order_ID 的直欄,其中含有指向 Order 表格中相關聯的列之外鍵參照。對於給定的
Line Item,Order_ID 直欄含有 Line Item 所關聯的 Order 之 Order_ID。外鍵可讓 RDBMS 將結合運算最佳化。
另外,實作連鎖刪除限制來提供資料模型中的參照完整性,也非常重要。這項作業完成之後,每當刪除 Order 時,也會刪除它的所有 Line Item。
標準關聯式資料模型不支援直接建立繼承關係的模型。您可以利用許多策略建立繼承關係的模型。這些可以總結如下:
-
利用獨立的表格來表示超類別和子類別。子類別表格必須包括指向超類別表格的外鍵參照。如果要建立子類別物件的實例,這兩份表格必須合併。這種方式在概念上很簡單,它會促成模型的變更,但它通常會因為額外工作而效能不好。
-
在子類別表格中,將所有繼承的屬性和關聯複製成為個別直欄。這類似於標準關聯式資料模型中的反正規化。
關聯式建模中的標準技術是利用交集實體來代表多對多關聯。 這裡適用相同的方法:利用交集表格來代表關聯。
範例:
如果 Suppliers 可以提供許多 Products,且一項 Product 可由許多 Suppliers 來提供,解決方案便是建立一份 Supplier/Product 表格。這份表格只會包含 Supplier 和 Product
等表格的主鍵,但可以鏈結 Suppliers 及其相關 Products。物件模型沒有這份表格的類似項目;它嚴格用來代表關聯式資料模型中的關聯。
修正資料模型
設計類別轉換成表格及資料模型中的適當關係之後,便依照需要來修正模型,以利用概略表和儲存程序來實作參照完整性以及將資料存取最佳化。如果需要詳細資訊,請參閱準則:資料模型。
大部分應用程式設計工具都支援從資料模型產生資料定義語言 (DDL)
Script,以及/或從資料模型產生資料庫。資料庫的正推必須規劃成整體應用程式開發和整合作業的一部分。從資料模型正推資料庫的時機和頻率,會隨著特定的專案狀況而不同。對於建立新資料庫的新應用程式開發專案而言,在詳述階段結束時,可能需要在穩定應用程式架構版本的實作中,完成起始的正推工程。在其他案例中,起始正推工程可能是在建構階段的初期反覆中完成。
資料模型中可以正推的模型元素類型,會隨著專案所用的特定設計工具和 RDBMS 而不同。一般而言,資料模型的主要結構元素,其中包括表格、概略表、儲存程序、觸發程式和索引,都可以正推到資料庫中。
|