（一）对象之间的关系：
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．依赖
一般不在实体域对象中体现。