Scott W. Ambler
Ronin International 的總裁
2000 年 7 月
為什么對象-關(guān)系數(shù)據(jù)庫的映射對于現(xiàn)代開發(fā)者是一件大事呢？一方面，對象技術(shù)（例如 Java 技術(shù)）是應(yīng)用于新軟件系統(tǒng)開發(fā)的最常見的環(huán)境。另外，關(guān)系數(shù)據(jù)庫仍然是許多人都青睞的持久信息存儲方法，并且在較長時間內(nèi)這種情況不太會改變。請繼續(xù)讀下去，了解如何使用這種技術(shù)。
為什么要寫有關(guān)對象-關(guān)系數(shù)據(jù)庫之間的映射的文章呢？因為在對象范例和關(guān)系范例之間“阻抗不匹配”。對象范例基于軟件工程的一些原理，例如耦合、聚合和封裝，而關(guān)系范例則基于數(shù)學(xué)原理，特別是集合論的原理。兩種不同的理論基礎(chǔ)導(dǎo)致各自有不同的優(yōu)缺點。而且，對象范例側(cè)重于從包含數(shù)據(jù)和行為的對象中構(gòu)建應(yīng)用程序，而關(guān)系范例則主要針對數(shù)據(jù)的存儲。當為訪問而尋找一種合適的方法時，“阻抗不匹配”就成了主要矛盾：使用對象范例，您是通過它們的關(guān)系來訪問對象，而使用關(guān)系范例，則通過復(fù)制數(shù)據(jù)來聯(lián)接表中的行。這種基本的差異導(dǎo)致兩種范例的結(jié)合并不理想，不過話說回來，本來就預(yù)料到會有一些問題。使對象-關(guān)系數(shù)據(jù)庫之間的映射成功的一個秘訣就是理解這兩種范例和它們的差異，然后基于這些認識來進行明智的取舍。
本文應(yīng)該能夠消除現(xiàn)今開發(fā)周期中一些普遍共有的誤解，對對象-關(guān)系數(shù)據(jù)庫之間映射所涉及到的一些問題提供了切合實際的看法。這些策略基于我的開發(fā)經(jīng)驗，項目范圍從小到大，涉及金融、銷售、軍事、遠程通信和外購等行業(yè)。我已對使用 C++、 Smalltalk、Visual Basic 和 Java 語言編寫的應(yīng)用程序應(yīng)用了這些原則。
如何將對象映射成關(guān)系數(shù)據(jù)庫
在這一節(jié)中，我會描述一些將對象成功映射成關(guān)系數(shù)據(jù)庫所需的基本技術(shù)。
將屬性映射成列在關(guān)系數(shù)據(jù)庫中實現(xiàn)繼承將類映射成表映射關(guān)聯(lián)、聚合和組合實現(xiàn)關(guān)系將屬性映射成列
類屬性將映射成關(guān)系數(shù)據(jù)庫中的零或幾列。要記住，并不是所有屬性都是持久的。例如， Invoice 類會有 grandTotal 屬性，這個屬性由其實例在計算時使用，但它不保存到數(shù)據(jù)庫中。而且，某些對象屬性本身就是對象，例如 Course 對象有一個作為屬性的 TextBook 實例，它映射為數(shù)據(jù)庫中的幾列（實際上，很有可能 TextBook 類本身就將映射成一個或多個表）。重要的是，這是一個遞歸定義：有時屬性將映射成零或者多列。也有可能將幾個屬性映射成表中的單一列。例如，代表美國郵遞區(qū)號代碼的類可以有三個數(shù)字屬性，每個都表示完整郵政編號代碼中的每一部分，而郵政編號代碼可以在地址表中作為單一的列存儲。
在關(guān)系數(shù)據(jù)庫中實現(xiàn)繼承
在將對象保存到關(guān)系數(shù)據(jù)庫中時，繼承的概念中發(fā)生幾個有趣的問題。（請參閱
將類映射成表
類到表的映射通常不是直接的。除了非常簡單的數(shù)據(jù)庫以外，您不會有類到表的一對一映射。在以下章節(jié)中，我將討論為關(guān)系數(shù)據(jù)庫實現(xiàn)繼承結(jié)構(gòu)的三種策略：
整個類層次結(jié)構(gòu)使用一個數(shù)據(jù)實體每個具體類使用一個數(shù)據(jù)實體每個類使用一個數(shù)據(jù)實體整個類層次結(jié)構(gòu)使用一個數(shù)據(jù)實體
使用這種方法，您可以將一個完整類層次結(jié)構(gòu)映射成一個數(shù)據(jù)實體，而層次結(jié)構(gòu)中所有類的所有屬性都存儲在這個實體中。圖 2 描述了采取這個方法時圖 1 的類層次結(jié)構(gòu)的持久模型。請注意，為表的主鍵引入了一個 personOID 列 - 我在所有解決方案中都使用 OID （沒有商業(yè)含義的標識，又稱替代鍵），只是為了保持一致和使用我所知道的向數(shù)據(jù)實體分配鍵的最好辦法。
這種方法的優(yōu)點是簡單，因為所需的所有人員數(shù)據(jù)都可以在一張表中找到，所以在人們更改角色時支持多態(tài)性，并且使用這種方法，專門報告（為一小組用戶特定目的所執(zhí)行的報告，這些用戶通常自己寫報告）也非常簡單。缺點是每次在類層次結(jié)構(gòu)的任何地方添加一個新屬性時都必須將一個新屬性添加到表中。這增加了類層次結(jié)構(gòu)中的耦合 - 如果在添加一個屬性時有任何錯誤，除獲得新屬性的類的子類外，還可能影響到層次結(jié)構(gòu)中的所有類。它還可能浪費數(shù)據(jù)庫中的許多空間。我還必須添加 objectType 列來表明行代表的是學(xué)生、教授還是其它類型的人員。在人們具有單一角色時這種方法很有效，但如果他們有多個角色（例如，一個人既是學(xué)生又是教授），很快就會失效。
每個具體類使用一個數(shù)據(jù)實體
使用這種方法，每個數(shù)據(jù)實體就既包含屬性又包含它所表示的類繼承的屬性。圖 3 描述了采取這個方法時圖 1 的類層次結(jié)構(gòu)的持久模型。有與 Student 類對應(yīng)的和與 Professor 類對應(yīng)的數(shù)據(jù)實體，因為它們是具體類，但沒有與 Person 類對應(yīng)的數(shù)據(jù)實體，因為它是抽象類（它的名稱以斜體字表示）。為每個數(shù)據(jù)實體都分別分配了自己的主鍵， studentOID 和 professorOID。
這種方法最大的好處是，它仍然能相當容易地執(zhí)行專門報告，只要您所需的有關(guān)單一類的所有數(shù)據(jù)都只存儲在一張表中。但也有幾個缺點。一個是當修改類時，必須修改它的表和它所有子類的表。例如，如果要向 Person 類添加高度和重量，就需要同時更新兩個表，它會涉及很多工作。第二，無論何時，只要對象更改了它的角色 - 可能您聘用了您一個剛畢業(yè)的學(xué)生作為教授 - 則需要將數(shù)據(jù)復(fù)制到相應(yīng)的表中，并為它指定一個新的 OID。這又涉及到很多工作。第三，很難在支持多個角色的同時仍維護數(shù)據(jù)完整性。（這種情況是可能的；只是比原先困難一點。）例如，您會在哪里存儲既是學(xué)生又是教授的人的姓名呢？
每個類使用一個數(shù)據(jù)實體
使用這種方法，為每個類創(chuàng)建一張表，它的屬性是 OID 和特定于該類的屬性。圖 4 描述了采取這個方法時圖 1 的類層次結(jié)構(gòu)的持久模型。 請注意，將 personOID 用作了所有三個數(shù)據(jù)實體的主鍵。圖 4 的一個有趣的特性是，為 Professor 和 Student 中的 personOID 列都分配了兩個構(gòu)造型，而這在標準建模語言 (UML) 中是不允許的。我的意見是，這是一個必須由 UML 持久性建模概要解決的問題，甚至可能在這個建模規(guī)則中也需要更改。（有關(guān)持久性模型的詳細信息，請參閱
這種方法的最大好處就是它能夠最好地適應(yīng)面向?qū)ο蟮母拍?。它能夠很好地支持多態(tài)性，對于對象可能有的每個角色，只需要在相應(yīng)的表中保存記錄。修改超類和添加新的子類也非常容易，因為您只需要修改或添加一張表。這種方法也有幾個缺點。第一，數(shù)據(jù)庫中有大量的表 -- 實際上每類都有一個（加上維護關(guān)系的表）。第二，使用這種技術(shù)讀取和寫入數(shù)據(jù)的時間比較長，因為您必須訪問多個表。如果通過將類層次結(jié)構(gòu)中的每個表放入不同物理磁盤驅(qū)動器盤片（假設(shè)每個磁盤驅(qū)動器磁頭都單獨操作）上來智能地組織數(shù)據(jù)庫的話，就可以緩解這個問題。第三，有關(guān)數(shù)據(jù)庫的專門報告很困難，除非添加一些視圖來模擬所需的表。
現(xiàn)在，請注意，每個映射策略怎樣產(chǎn)生不同的模型。要理解三種策略之間的設(shè)計優(yōu)缺點，請考慮圖 5 中顯示的對我們的類層次結(jié)構(gòu)做些簡單的更改：添加了 TenuredProfessor，這是從 Professor 中繼承的。
圖 6 顯示了一個更新過的持久性模型，用于將整個類層次結(jié)構(gòu)映射成一個數(shù)據(jù)實體。盡管很明顯，數(shù)據(jù)庫中的空間浪費增加了，但請注意，按照這種策略操作，只需花非常小的代價就可以更新模型。
圖 7 顯示了將每個具體類映射成數(shù)據(jù)實體時的持久性模型。使用這個策略，雖然因為我們從教授提升到終身教授，這樣對象和我們的關(guān)系就有了改變（學(xué)生變成教授），所以如何處理對象的這個問題更復(fù)雜了，但我只需要添加一個新表。
圖 8 顯示了第三種映射策略的解決方案 -- 將單個類映射成單個數(shù)據(jù)實體。這需要我添加一個只包括 TenuredProfessor 類的新屬性的新表。這種方法的缺點是，要使用新類的實例，它需要好幾個數(shù)據(jù)庫訪問。
表 1. 比較映射繼承的各種辦法
不僅必須將對象映射到數(shù)據(jù)庫中，還必須將對象之間的關(guān)系進行映射，這樣才能在以后進行恢復(fù)。對象之間有四種類型的關(guān)系：繼承、關(guān)聯(lián)、聚合和組成。要有效地映射這些關(guān)系，必須理解它們之間的差異、如何實現(xiàn)一般的關(guān)系，以及如何實現(xiàn)特定的多對多關(guān)系。
從數(shù)據(jù)庫的角度看，關(guān)聯(lián)和聚合／組合關(guān)系之間的唯一不同是對象相互之間的綁定程度。對于聚合和組合，在數(shù)據(jù)庫中對整體所做的操作通常需要同時對部分進行操作，而關(guān)聯(lián)就不是這樣。
在圖 9 中有三個類，其中兩個在它們之間有簡單的關(guān)聯(lián)關(guān)系，有兩個共享聚合關(guān)系（實際上，組合可能是這種模型中更確切的說法）。（有關(guān)關(guān)系的詳細信息，請參閱
