|
现在我们讨论关联的实现。我们已经把我们的陈述分为建议的映射（我们正常使用的映射），可选的映射（我们偶尔使用的映射）和不鼓励的映射（我们遇到的应该避免的错误）。我们所有的例子都采用基于存在的标识。
2.4.1 建议的映射
- 多对多关联。用一个单独的表（图2）来实现一个多对多关联。关联的主键是每个类的主键的合并。那些省略号（...）表示在模型里没有显示出来的属性。主键用黑体字体显示。
- 一对多关联。把一个外键隐藏在“多”表（图3）。角色名字成为外键属性名字的一部分。
- 零或一对一关联。把外键隐藏在“零或一”表（图4）。
- 其它一对一关联。把外键隐藏在任一表里。
图2 建议的实现：单独的多对多关联表。
图3 建议的实现：隐藏的一对多关联。
图4 建议的实现：隐藏的零或一对一关联。
2.4.2 可选的映射
正常情况下我们使用建议的映射。但有些偶尔的情况，可选的映射更合适。
- 单独的表。你也可以用单独的表（图5）来实现一对多和一对一关联。单独的表给了你更统一的设计和更大的扩展性。无论如何，单独的关联表打碎了数据库，并增加了表的数量。此外，单独的关联表不能强迫一个更低的多重性限度为“一”。
2.4.3 不鼓励的映射
我们已经注意到有些开发者选择有缺陷的映射。我们要注意避免这些映射。
- 合并。不要合并多个类，不要把关联强制成为一个单独的表（图6）。这样减少了表的数量，但会干扰第三范式。
- 两次隐藏一对一关联。不要把一个一对一关联隐藏两次，每次隐藏在一个类里（图7）。这是多余的，无助于性能。
- 相同的属性。不要用相同的属性来实现多个关联角色（图8）。相同的属性使编程复杂，降低了扩展性。
图5 可选的实现：单独的一对x关联表。
 >
图6 不鼓励的实现：类的合并。
 >
图7 不鼓励的实现：两次隐藏的一对一鼓励。
 >
图8 不鼓励的实现：相同的属性。
 >
上一页 [1] [2] [3] [4] [5] [6] 下一页
 【责编:Lili】 |
