UML在關系型數據庫設計中的應用

1. 介紹

許多人認為面向對象概念和關系型數據庫相互不一致，并且不能結合。事實上完全相反！經過靈活的使用，一個關系型數據庫能夠為面向對象（OO）模型提供一套優秀的實現。同樣的模型能夠用來開發編程代碼和關系型數據庫結構。

關系型數據庫技術是意義深遠的、強大的，但它比許多開發商使你相信的要難得多。單個表是簡單易懂的、直觀的。但由數以百計的表組成（這是常見的）的應用要徹底了解是相當困難的。這正是OO模型有用之處。 OO模型使你深入地、連貫地思考問題。

OO模型提供一種問題的超結構（superstructure）的思考方式，然后該方式能夠用關系型數據庫的更低層的組成塊來實現。

本文章綜合地討論了關系型數據庫技術，而不是集中于特定的產品上。我們將不討論物理設計細節（例如存儲分配和物理聚集），因為它們是依賴于產品的。

用關系型數據庫實現UML模型有兩個方面：映射結構（第2節）和映射功能（第3節）。第4節注解了面向對象到關系型數據庫的擴展。第5節總結本文章。

2. 結構映射到表

UML對象模型在本質上只是一個擴展的實體-關系（ER）模型 。使用設計數菘獾腅R模型的方式受到普遍接受，而我們以一種近似的但更強大的方式－使用UML對象模型。OO模型的主要優勢在于編程和數據庫的相同的模型工作。而且，作為考慮功能性的一種方式（第3節），我們強調OO模型的導航。這一節顯示如何實現UML對象模型的主要構造。

2.1 標識（identity）

實現對象模型的第一步是處理標識。我們從定義幾個術語開始。

1）候選鍵（candidate key）是一個或多個屬性的組合，它唯一地確定某個表里的記錄。一個候選鍵里的屬性集必須是最小化的；除非破壞唯一性，否則屬性不能從候選鍵刪除。候選鍵里的屬性不能為空。

2）主鍵（primary key）是一個特定地選定的候選鍵，用來優先地參考記錄。

3）外鍵（foreign key）是一個候選鍵的參考。外鍵必須包括每個要素屬性的一個值，或者它必須全部為空。外鍵用來實現關聯和一般化。

正常地你應該為每個表定義一個主鍵，盡管偶爾有例外。我們強烈建議所有的外鍵都只指向主鍵而不是其它的候選鍵。

定義主鍵有兩種基本的方法：

1）基于存在的標識。你應該為每個類表加一個對象標識符屬性，并將它設為主鍵。每個關聯表的主鍵包括一個或更多的相關類的標識符?；诖嬖诘臉俗R符有作為單獨屬性的優勢，占位小且大小相同。只要你的關系型數據庫管理系統（RDBMS）受支持，基于存在的標識符就沒有性能的劣勢。（多數RDBMS提供有效的基于存在的標識符的分配順序號碼。）唯一的劣勢是基于存在的標識符在維護時內沒有固有的意義。

2）基于值的標識。一些真實世界的屬性的組合確定了每個對象?；谥档臉俗R有不同的優勢。主鍵對于用戶有固有的意義，容易進行調試和數據庫維護。在另一面，基于值的主鍵很難改變。一個主鍵的改變需要傳播到許多外鍵。一些對象沒有自然的真實世界里的標識符。

我們推薦你在超過30個類的RDBMS應用里使用基于存在的標識?；诖嬖诤突谥档臉俗R都是所有RDBMS應用的可行選項。

2.2 域（屬性類型）

屬性類型是UML術語，對應于數據庫著作里的域的術語。比起直接用數據類型，域提升到更一致的設計，并便利了應用的定位。

簡單域很容易實現。你僅僅要定義相應的數據類型和大小。并且每個用了域的屬性，你都必須為每個域約束加入一條SQL查詢子句。簡單域的一些例子是：名字（name），長字符（longString）和電話號碼（phone-Number）。

一個枚舉域把一個屬性限制在一系列的值里。枚舉域比簡單域實現起來更復雜，圖表1顯示了四個方法。

圖表1：枚舉的實現方法

2.3類

正常情況下，我們把每個類映射為一個表，每個屬性映射為一個列。你可能因一個已產生的標識符（基于存在的標識符）、隱藏的關聯（第2.4節）和通用鑒別器（第2.5節）需要一些另外的列。

2.4關聯

現在我們討論關聯的實現。我們已經把我們的陳述分為建議的映射（我們正常使用的映射），可選的映射（我們偶爾使用的映射）和不鼓勵的映射（我們遇到的應該避免的錯誤）。我們所有的例子都采用基于存在的標識。

原文轉自：http://www.anti-gravitydesign.com