摘要
这一章节描述了两种用于映射对象间关系的模式：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]。