摘要
把繼承層次映射到關系型數據庫表有很多種做法。以下展示的模式是單種的映射方式，在實際中，你可以混合使用不同的映射方式。(2002-08-20 12:28:52)
By axing
繼承映射模式
把繼承層次映射到關系型數據庫表有很多種做法。以下展示的模式是單種的映射方式，在實際中，你可以混合使用不同的映射方式。
以下的討論沒有涉及多重繼承。在領域層中很少會遇到有多重繼承的情況。大多數多重繼承的使用都可以使用協議繼承來實現，一個類從虛基類中繼承多種協議。協議類很少有需要持久性的，因此我們只討論簡單的繼承。
運行實例
我們選用了一個稱為合伙人（partner）的系統中的一部分。一個群體（Party）由任何形式的人（person）組成，可以是自然人（natural person）或法人（institution）。客戶和員工都是群體。對于員工，我們將之區分為專職員工（SalariedEmployee）和兼職員工（FreelanceEmployee）。見下圖：
圖中使用的屬性比較少，現實中的系統中會有更多的屬性，但是我們這里只是列出了可以表示我們所討論的模式不同之處的屬性。因此它們之中都沒有涉及到讀咱的屬性或關系。并且我們假設以上層次中每一個類都不是虛基類，所有的五個類都可以生成實例。
模式: One Inheritance Tree One Table
摘要
該模式展示了一種方法，將一個完整的繼承層次映射到單個的數據庫表中。
問題
怎樣把一個完整的繼承層次映射到單個的數據庫表中？
約束
除了文章一開始列出的通用約束，還包括了如下的約束：
- 多態讀取、存儲空間和寫/更新性能的對比：在一個繼承層次中，你需要支持這樣的查詢：在給定的條件下，查找所有匹配的Party對象。結果集還必須是多態的。在該例中，包括Employee、FreelanceEmployee或SalariedEmployee。這種方案雖然能夠支持多態查詢，但是既浪費空間，也影響了寫/更新性能。
- 數據庫的鎖模式：有些數據庫只是實現了頁面鎖，這樣的話，你就需要注意數據庫的流量，不要讓一個表中的鎖超出了限制的數量而影響性能。如果把過多的類映射到單個表中，很明顯，你必須注意流量的問題。
- 繼承層次的深度：某些方案適合于處理扁平性的繼承層次，但難于處理縱深的繼承層次。
- 維護負擔：把單個的對象的數據跨越多個表來存放，這樣的做法可以加快多態讀取的速度，但缺點是增加了維護量，一旦對象需要新增或刪除屬性，模式的發展也需要考慮物理數據模型中數據的重復問題，這極易導致維護的噩夢。其它的維護實例還包括在一個繼承層次中插入類和刪除類。
- 用戶自定義的查詢：如果你希望給用戶賦予自定義查詢的權利，那么你需要從用戶的角度考慮該映射是否能為用戶所理解。
解決方案
把繼承層次中的所有對象的屬性全集對應到數據庫的單個表中。每條記錄中那些無用的字段使用Null值。
結構
解決方案示例
上例中的表設計如下圖：
結論
- 寫/更新性能：One Inheritance Tree One Table允許在單詞的數據庫操作中對任何基類的任何一個子類讀取和寫入。
- 多態讀性能：象全部的基類的子類都可以在一張表中找到一樣，多態讀也很簡單。唯一的難點就是為一條選中的記錄構造正確的對象類型。處理這種情況的模式有很多，例如Abstract Interface[Col96]。
- 所占空間：就像你在上面的映射中所描述的，存儲對象的屬性會浪費一些空間，浪費空間的多少取決于繼承層次的深度。層次越深，不同的屬性越多，屬性的全集就越大，也就越浪費空間。
- 通過多個表來均衡數據庫負載：將過多的類映射到單個表中會導致低性能。可以在如下的數據庫行為中發現這些問題的來源：
- 如果數據庫使用頁面級鎖，一張表上的過量的傳輸量會大大降低數據庫的訪問速度。巧妙的安排簇可以抵消部分的開銷。如果單個表上的傳輸量超過限制，性能將繼續惡化，甚至引起死鎖。
- 在單個表上太多的鎖還會導致鎖擴散。鎖的數量是關系型數據庫系統中鎖擴散問題的罪魁禍首。
- 某些類需要次級索引來提高搜索速度。如果你在一個單獨的數據庫表中實現了很多類，相應的你也需要在表中加入索引。一張表上過多的索引會使得更新的時候需要同時更新所有的索引，降低了速度。
- 維護成本：當映射比較直接、比較簡單的時候，只要繼承的層次不會很多，模式的改進相對也會比較直接和簡單。
- 特殊查詢：由于映射和直觀，因此一些特殊的查詢也會相對較容易。
實現
- 考慮將所有的對象都映射到單個的表：你可以把所有的對象類型都放在單個表中－－這將導致表上的大傳輸量。對于小型的應用系統類說，這不失為切實可行且靈活的方法。
- 空間的浪費：你需要檢查關系數據庫是否允許空值壓縮。如果允許的話，那么這種映射方法無疑將更具吸引力，因為空值也不會浪費空間。類型標識：表中需要插入類型信息。可以在Synthetic Object Identities中包含類型信息。
相關模式
參看Representing Inheritance in a Relational Database [Bro+96]
模式：One Class One Table
摘要
該模式討論了如何把一個繼承層次中各個類映射到不同的數據庫表中。
問題
如何把繼承層次中的類映射到數據庫表中？
約束
參見One Inheritance Tree One Table模式。
解決方案
將每個類的屬性放到不同的表中。在每個表中插入一個Synthetic OID，將子類的行和父類所在表的行關聯起來。
結構
解決方案示例
將前例中的類映射到數據庫后產生五張表－－每個類一張。單個的SalariedEmployee將存儲在五張表其中的三張中：
結論
- 寫/更新性能：該模式提供了非常靈活的映射機制，但缺乏一個較好的性能。考慮在上例中讀取FreelanceEmployee的一個實例。它將會包括三次的數據庫讀操作：一次讀FreelanceEmployee表， 一次讀Employee表，一次讀Party表。寫同樣需要三次操作，并更新一個或多個索引。在讀寫相關的任務上，這種映射方式相當費資源，這個代價還隨著繼承層次的增多而增大。
- 多態讀性能：在我們的例子中，FreelanceEmployee的實例分別對應于不同表的Employee實例和Party實例。因此，多態讀只需要讀取一張表。這是該模式除去節約空間的優點之外吸引人的另一大優點。
- 所占空間：這種映射幾乎有最佳的空間節約性。唯一的容易就是額外的synthetic OID，來連接不同的層級層次。
- 維護成本：由于這種映射比較直接，也易于了解，模式的改進也相應較為直接、容易。
- 特殊查詢：由于映射需要訪問多個表來獲取一個對象實例的數據，特殊的查詢比較難以組織，尤其是對于無經驗的用戶。
- 根表上的重負載：該模式將會導致根對象類型表上的重負載。在該例中，持有FreelanceEmployee表的寫入鎖的事務將同時持有對Party表和Employee表的寫入鎖。參看One Inheritance Tree One Table的結論部分對數據庫表瓶頸的負面影響的討論。
實現
- 虛類：注意虛類也需要映射到單獨的表中。
- 類型標識：從前一個模式的例子中，我們假設Synthetic Object Identity已經包含了類型信息。為了從多態讀取查詢返回的結果中構建正確的類型，需要了解某些類型信息。
相關模式
參看Representing Inheritance in a Relational Database [Bro+96]。
模式：One Inheritance Path One Table
摘要
該模式顯式了一種將繼承路徑中的所有屬性放到單個的數據庫表中的方法。
問題
如何把一個繼承層次中的所有類映射到數據庫的表中？
約束
和One Inheritance Tree One Table模式的約束相同。
解決方案
將每個類的屬性映射到不同的表中。并在表中加入該類的父類的所有屬性。
結構
解決方案示例
上例中映射的結果將會產生五張表－－每個類一張。SalariedEmployee用其中的一張表就可以表示，SalariedEmployee的映射方法如下：
結論
- 寫/更新性能：映射需要單次的數據庫操作來完成對一個對象的讀寫。
- 多態讀性能：本例中，對所有的Party對象的查詢意味著要訪問五張表。和One Class One Table模式移機One Inheritance Tree One Table模式比起來是不小的開銷。
- 所占空間：這種映射提供了最佳的空間占用。沒有任何的冗余屬性，甚至連額外的synthetic OID都沒有。
- 維護成本：產物一個新的子類意味著需要更新所有的多態查詢。增加或刪除父類的屬性將會導致對所有子類的表結構的修改。
- 特殊查詢：由于映射需要訪問不只一張表來完成多態搜索，特殊的多態查詢對無經驗的用戶來說難以編寫。對葉結點類的查詢將會非常的復雜。
實現
- 虛類：注意虛類不要映射到表。
- 類型標識：不需要在表中插入類型信息，因為可以通過表的名稱來區分對象類型。因為Synthetic Object Identities包含了類型信息，可以考慮減少它的長度來節省部分的空間。
相關模式
參見Representing Inheritance in a Relational Database [Bro+96]。
模式：Objects in BLOBs
摘要
該模式展示了一種使用BLOB，將對象映射到單個數據庫表的方法。該模式覆蓋了繼承、聚合和關聯。
問題
怎樣把對象映射到關系型數據庫？
約束
參見One Inheritance Tree One Table模式。
解決方案
表包括兩個字段：一個是synthetic OID，另一個是變長的BLOB，后者囊括了一個對象內的所有數據。使用流把對象的數據存放到BLOB中。
結構
解決方案示例
任何一種的設計方案都和上圖相似。
結論
- 寫/更新性能：Objects in BLOBs可以在單次的數據庫操作中讀取、寫入基類的任何子類。注意，在很多RDBMS中，BLOBs都不是最快的訪問數據的類型。
- 多態讀：搜索類來獲得屬性是非常困難的。由于你沒有辦法訪問BLOB的內部結構，因此就需要在數據庫中注冊函數，以便于訪問屬性。這種函數的實現可以參考[Loh+91]。定義和維護這些函數也需要付出客觀的代價。
- 特殊查詢：由于搜索類中的屬性難以實現，因此特殊查詢也同樣難于表達。還必須要額外的定義函數。
- 所占空間：如果你的數據庫可以實現變長的BLOBs，所占空間就是最小的。
- 維護成本：數據庫模式的演進將會和面向對象數據庫一樣容易。
實現
- 相似實現的起源：Objects in BLOBs已用于原型的研究，該原型正盡可能的像OODBMS靠近，只不過它是使用一個關系型數據庫作為存儲管理。因此該模式的實現機會等于是在一個已存在的存儲管理器的基礎上實現OODBMS。
- 表間的數據庫負載均衡：把過多的類映射到一個單獨的表會造成低性能。具體的討論可以參見One Inheritance Tree One Table模式的相關章節。
- 把OODB的特點和關系型數據庫相結合：把這個模式同其它類的對象/關系映射相結合是切實可行的。在這個例子中，BLOB存儲了復雜的對象的結構，類似于一個項目計劃圖一樣。可以設置其它的字段來存儲信息，以供那些訪問已結構化的數據的特殊查詢使用。（見圖3，這種用BLOBs來存儲對象的方式已用于SMRC原型研究[Rei+94, Rei+96]。 SMRC中的BLOBs不僅存儲單個類的屬性，還包含了一個對象網，這個對象網采用流方式存儲在BLOBs中。流方式存儲在圖3中描述）。此外，除了我們上面介紹的純粹的使用這種方法外，它還允許關系型數據和OODBMS共存。
圖3：對象數據和關系型數據的共存。
相關模式
當只使用該模式的時候，這個模式類似于One Inheritance Tree One Table映射，參看Representing Inheritance in a Relational Database [Bro+96]。