注：既然聚合，组合关系属于关联关系，那么如何区分一般关联关系，聚合关系和组合关系呢？

　　一般关联：只要一个对象联系到另外一个对象就形成了关联关系。如：人和他的猫，黑豹乐队和窦魏，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。