摘要
這一章節(jié)描述了兩種用于映射對象間關(guān)系的模式：Foreign Key Association和Association Table。注意，1:n關(guān)聯(lián)背后隱藏的問題和Representing Collections in a Relational Database [Bro+96]中描述的問題是一致的。(2002-08-20 12:29:17)
By axing
將對象關(guān)聯(lián)映射到表的模式
這一章節(jié)描述了兩種用于映射對象間關(guān)系的模式：Foreign Key Association和Association Table。注意，1:n關(guān)聯(lián)背后隱藏的問題和Representing Collections in a Relational Database [Bro+96]中描述的問題是一致的。
模式：Foreign Key Association
摘要
該模式展示了如何將對象間的1:n的關(guān)系映射到關(guān)系型數(shù)據(jù)庫表中。
示例
考慮經(jīng)典的訂單/訂單明細（Order / OrderItem）的例子，一張有效的訂單將包含0個以上的訂單明細。
問題
如何把1:n的關(guān)系映射到關(guān)系型數(shù)據(jù)庫表中？
約束
參見一般約束
解決方案
在依賴（dependent）對象的表中插入所屬（owner）對象的OID。這個OID可以是數(shù)據(jù)庫的關(guān)鍵字或一個Synthetic Object Identity。
結(jié)構(gòu)
結(jié)論
- 讀性能：讀取一個訂單對象將需要一個連接操作或兩次讀操作。可以在訂單對象中加入到訂單明細的引用集合。
- 寫性能：該模式將按照1:n的關(guān)聯(lián)寫入依賴對象，如果寫入操作不寫入未改變的對象的話，那么寫入的成本依賴于改變的依賴對象的個數(shù)。
- 性能和冗余 VS 維護成本和普通窗體：該映射模式是關(guān)系數(shù)據(jù)庫中最常見的模式，因此它和普通的窗體并沒有任何的沖突，因此它的維護成本是比較合理的。
- 所占空間接近于最優(yōu)－－除了在依賴對象表中需要的外鍵字段以外。
- 特殊查詢：由于映射是關(guān)系數(shù)據(jù)庫應(yīng)用最為常見的形式，因此特殊的查詢也是不難實現(xiàn)的。
- 應(yīng)用程序類型：這種映射模式最適合于關(guān)系型應(yīng)用程序。它不適合用于CAD或CASE應(yīng)用系統(tǒng)中。因為它是基于以外鍵形式連接關(guān)系表的。實現(xiàn)一個關(guān)聯(lián)需要一次的連接操作或兩次的數(shù)據(jù)庫訪問。基于頁面的存儲系統(tǒng)，例如OODBMS，能夠更快的處理類似的問題。
- 和舊有系統(tǒng)的集成：因為大多數(shù)的舊有系統(tǒng)正式使用這種映射關(guān)系的，把1:n的關(guān)聯(lián)轉(zhuǎn)換為對象不會出現(xiàn)任何新的問題。
實現(xiàn)
- 一般性能：如果性能上出現(xiàn)低效的情況，你可以考慮在對象/關(guān)系映射層下面再增加一個關(guān)系型數(shù)據(jù)庫訪問層，并應(yīng)用性能改進模式，例如Controlled Redundancy、Denormalization、或Overflow Tables [Kel+97]。這些模式的目的是為了讓你在不影響邏輯映射模式的前提下優(yōu)化物理表模式。
- 更新性能：當更新訂單明細對象（依賴對象）時，你應(yīng)該只更新那些已經(jīng)被修改的對象。更新和插入操作都是較為昂貴的操作。
- 預(yù)取依賴對象：在這個例子中，大多數(shù)的用例都需要讀入所有的依賴對象（如訂單明細），你可以使用連接操作來獲得所有的數(shù)據(jù)，并從單個數(shù)據(jù)庫操作的返回值中構(gòu)建所有者對象和依賴對象：
select * from Order O, OrderItem I
where O.key = ‘YourOrderKey’ and
O.key = I.OrderKey
相關(guān)模式
在實踐中，1:n的關(guān)聯(lián)總是難以和聚合分離開來。因此在研究本模式時也需要同時參考聚合模式Single Table Aggregation和Foreign Key Aggregation。后者和該模式同樣的解決方案，只有稍許的不同。
使用外鍵的備選方案，包括Controlled Redundancy、Denormalization和Overflow Tables [Kel+97]。
該模式和Association Table模式非常相近，后者是用戶解決n:m映射的問題。參看Representing Object Relationships as Tables [Bro+96]。
模式Association Table
摘要
該模式展示了怎樣把對象間n:m的關(guān)系映射到關(guān)系型數(shù)據(jù)庫表中。
示例
員工對象和部門對象間存在著n:m的關(guān)系。一個員工可以在多個部門中工作，一個部門通常也包含了不只一個的員工。
問題
怎樣把n:m的關(guān)系映射到關(guān)系型數(shù)據(jù)庫？
約束
參見通用約束
解決方案
創(chuàng)建一張單獨的表，來存放兩種對象類型的關(guān)系中的對象標志（或外鍵）。其它的對象類型到表的映射可以使用另外適當?shù)哪Ｊ絹硖幚怼?/p>
結(jié)構(gòu)
結(jié)論
這里的結(jié)論和Foreign Key Association中是類似的，只是在環(huán)境上有些許的不同，因此這里我們就不重復(fù)了。
實現(xiàn)
- 一般性能：如果性能沒有達到預(yù)期效果，可以考慮使用數(shù)據(jù)庫優(yōu)化模式，例如Controlled Redundancy、Denormalization、or Overflow Tables [Kel+97]。我們的例子中處理了n:m的關(guān)系，這會使關(guān)系變得更為復(fù)雜。因此可以把它打散，以便于實行數(shù)據(jù)庫優(yōu)化。
- 預(yù)取對象：如果在上面的例子中，你預(yù)先知道大多數(shù)的用例都需要讀出所有的依賴對象，例如部門中的員工。那就可以使用連接操作獲取所有的數(shù)據(jù)，并從數(shù)據(jù)集中構(gòu)建部門對象和員工對象。如：
select * from DepartmentTable D, EmployeeDepartmentTable ED,EmployeeTable E
where D.SyntheticOID = ‘YourDepartment’
D.SyntheticOID = ED.DepartmentKey and
ED.EmployeeKey = E.SyntheticOID
相關(guān)模式
該模式，非常接近于Foreign Key Association。參看Representing Object Relationships as Tables [Bro+96]。
已知應(yīng)用
Single Table Aggregation, Foreign Key Aggregation, Foreign Key Association, 和Association Table已用于Persistence [www.persistence.com]和TopLink的Smalltalk框架[www.objectpeople.com/toplink/]，以及其它的大多數(shù)持久性框架中。這些模式還被用于HYPO-Bank [Col+96,Kel+96]的對象/關(guān)系訪問層，和POET [POE96]的對象/關(guān)系網(wǎng)關(guān)。
One Inheritance Tree One Table and One Class One Table曾在POET [POE96]的對象/關(guān)系網(wǎng)關(guān)被討論過，同時被提及的還包括One Inheritance Path One Table。后者還被Champs和HYPO的項目中[Col+96, Hah+95, Kel+96]。
Objects in BLOBs曾用在SMRC搜索原型上[Rei+94, Rei+96]。