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