（一）对象之间的关系：
1．依靠：
依靠对象通过调用被依靠对象的方法来获得服务。一种比较松散的关系，并且是短期的。我们的过程与对象往往依靠于我们的实体域对象。如在struts 的 action中调用模型层的方法。
2．关联
它使一个类指到另一个类的属性。长期的
3．聚合
聚合关系是关联关系的一种，是强的关联关系。聚合是整体和部分之间的关系。
4．组合
也叫合成关系，组成关系是关联关系的一种，是比聚合关系强的关系。对象负责代表部分的对象的生命周期。
注：既然聚合，组合关系属于关联关系，那么如何区分一般关联关系，聚合关系和组合关系呢？
一般关联：只要一个对象联系到另外一个对象就形成了关联关系。如：人和他的猫，黑豹乐队和窦魏，pc机和显示器。
聚合关系：一种强关联关系，它要求有部分和整体的关系，并且没有了整体部分也可以独立存在。在上面三个例子中人和它的猫显然没有部分和整体的关系，所以只能是一般的关联关系。而黑豹乐队和窦魏，窦魏等人组成了黑豹乐队即：窦魏和黑豹是整体和部分的关系。而窦魏脱离了黑豹（早就离开了）更或者黑豹不存在了那么窦魏仍然可以以音乐人的身份存在（即对象仍然可以独立存在）所以它属于聚合关系。组成关系是可以共享的。（窦魏也可以加入其他乐队）。
组合关系：一种更强的整体和部分的关系。它并且要求代表整体的对象负责代表部分的对象的生命周期，组成关系是不能共享的。如：pc机和显示器的关系。
我觉得：假如两个实体是整体和部分的关系，那么它们到底是聚合还是组合，这取决于你的需求。比如说：pc机和显示器的关系，假如你的系统中，显示器脱离了pc机就不存在意义了，也可以说：所有显示器的访问都是通过pc机进行的，那么你可以把关系设定为组合（如你在为一个只买品牌机的代理商作系统你可能是可以这么作的）。假如你的显示器脱离的pc机仍然可以独立存在，也就是说在系统中可以直接访问显示器对象，那么你可以将关系设为聚合（如你在为一个买散件的代理商作系统你可能是可以这么作的）
5．继续
这个我不想多讲了，用过面向对象的语言都应该知道。
（二）关系数据库的关系
一对一
一对多
多对一
多对多
（三）o/r mapping策略
1．继续：
对于继续关系一般有三种策略：
策略1继续树的每个类对应一个表<joined-subclass >
共享主键
策略2继续树的根类对应一个表<discriminator ><subclass >
需要添加一个识别字段
策略3继续树的叶子类对应一个表
不支持多态查询
2．关联
2．1 一对一
一半有两种策略：
策略1：唯一的外键
<many-to-one>+unique="true" (唯一的外键)
<one-to-one>
策略2：共享主键
<one-to-one>
<one-to-one><constrained="true"> (既是主键又是外键)
注重：生成方式需要用：foreign
2．2 一对多（无需多说）
2．3 多对一（无需多说）
2．4 多对多
策略1：A,B表多对多的关系需要引入C表。
C表中的所有属性即为主键又为外键分别参照A,B两表。
C表中不可以有其他属性
策略2：将多对多拆分成两个一对多：
A,B对象多对多的关系需要引入C对象。使得A,B两对象与C对象的关系为一对多。对应数据库中：A,B表多对多的关系需要引入C表。A,B两表与C表的关系为一对多。
C表又自己的主键
C表中又非主键的外键分别参照A,B两表。
C表中不可以有其他属性
如；学生 ，课程为多对多的关系 那么引入学生选课。
注重：策略1和策略2的不同在于：策略2引入了新的对象而策略1没有。这是因为这样：策略1的c表不能又自己的东西。而策略2有。
2．5 其他
上面说过：聚合与组成是关联的一种所以他们也符合以上策略。
非凡的：当用到组合关系的是否我们可用用到hibernate的"组件"<component>.由于"组件"它完全可以满足组成关系的强关联。
3．依靠
一般不在实体域对象中体现。
O/R MAPPING (HIBERNATE)方法小结 （补充内容）：
另外我看到了一种"键关联"的方法，感觉很有道理。我理解了一下总结如下：
1．一般关联：
这种方法对于一般的关联总是引入c表（另外的一张表）仅仅表示关系。
C表的主键有分别指向A,B两表（外键）。当指向一方的外键unique="true"即唯一，那么这一方为"一"，反之为"多"的一方。这样就可以形成一般的关联关系。但是注重的是：c表不映射为对象。C表也没有自己的属性。
2．聚合和组成
当实体A的非主键列中有一个引自实体B的时候，这种关系是B聚合A。假如这种引用是强制性的，则是合成关系，否则为聚合关系。是否为强制性，只需要将引用列设为非空即可；
3．继续
当实体A的主键引用自实体B的时候（即为外键），那么A继续 B。
总结：我觉得O/RM的方法有很多，我们可以看到"按外键"的方法思路很清楚。但是它在解决一般的关联的时候总是引入另外一张表这样势必影响效率。另外，既然聚合和组合是关联的一种那么即使是组合关系我也把它看成一般关联，也不算错的。关系数据库一开始就不是为了面向对象的语言服务的，所以我们在这里映射无论那种方法似乎都不能说是完全的，正确无误完成了O/RM。
所以我觉得一切都要看我们的项目需求。因地制宜！
