一對象之間的關系 ．依賴
依賴對象通過調用被依賴對象的方法來獲得服務
一種比較松散的關系
並且是短期的
我們的過程與對象往往依賴於我們的實體域對象
如在struts的action中調用模型層的方法
．關聯
它使一個類指到另一個類的屬性
長期的
．聚合
聚合關系是關聯關系的一種
是強的關聯關系
聚合是整體和部分之間的關系
．組合
也叫合成關系
組成關系是關聯關系的一種
是比聚合關系強的關系
對象負責代表部分的對象的生命周期
注
既然聚合
組合關系屬於關聯關系
那麼如何區分一般關聯關系
聚合關系和組合關系呢？
一般關聯
只要一個對象聯系到另外一個對象就形成了關聯關系
如
人和他的貓
黑豹樂隊和窦唯
PC機和顯示器
聚合關系
一種強關聯關系
它要求有部分和整體的關系
並且沒有了整體部分也可以獨立存在
在上面三個例子中人和它的貓顯然沒有部分和整體的關系
所以只能是一般的關聯關系
而黑豹樂隊和窦唯
窦唯等人組成了黑豹樂隊即
窦唯和黑豹是整體和部分的關系
而窦唯脫離了黑豹（早就離開了）更或者黑豹不存在了那麼窦唯仍然可以以音樂人的身份存在（即對象仍然可以獨立存在）所以它屬於聚合關系
組成關系是可以共享的
（窦唯也可以加入其他樂隊）
組合關系
一種更強的整體和部分的關系
它並且要求代表整體的對象負責代表部分的對象的生命周期
組成關系是不能共享的
如
PC機和顯示器的關系
我覺得
如果兩個實體是整體和部分的關系
那麼它們到底是聚合還是組合
這取決於你的需求
比如說
PC機和顯示器的關系
如果你的系統中
顯示器脫離了PC機就不存在意義了
也可以說
所有顯示器的訪問都是通過PC機進行的
那麼你可以把關系設定為組合（如你在為一個只買品牌機的代理商作系統你可能是可以這麼作的）
如果你的顯示器脫離的PC機仍然可以獨立存在
也就是說在系統中可以直接訪問顯示器對象
那麼你可以將關系設為聚合（如你在為一個買散件的代理商作系統你可能是可以這麼作的）
．繼承
這個我不想多講了
用過面向對象的語言都應該知道
二關系數據庫的關系 一對一
一對多
多對一
多對多
三o/r mapping策略 ．繼承
對於繼承關系一般有三種策略
策略
繼承樹的每個類對應一個表
<joined
subclass >//共享主鍵
策略
繼承樹的根類對應一個表
<discriminator ><subclass >//需要添加一個識別字段
策略
繼承樹的葉子類對應一個表
不支持多態查詢
．關聯
．
一對一
一半有兩種策略
策略
唯一的外鍵
<many
to
one>+unique=
true
(唯一的外鍵)
<one
to
one>
策略
共享主鍵
<one
to
one>
<one
to
one><constrained=
true
> //既是主鍵又是外鍵
注意
生成方式需要用
foreign
．
一對多（無需多說）
．
多對一（無需多說）
．
多對多
策略
A
B表多對多的關系需要引入C表
C表中的所有屬性即為主鍵又為外鍵分別參照A
B兩表
C表中不可以有其他屬性
策略
將多對多拆分成兩個一對多
A
B對象多對多的關系需要引入C對象
使得A
B兩對象與C對象的關系為一對多
對應數據庫中
A
B表多對多的關系需要引入C表
A
B兩表與C表的關系為一對多
C表又自己的主鍵
C表中又非主鍵的外鍵分別參照A
B兩表
C表中不可以有其他屬性
如
學生
課程為多對多的關系 那麼引入學生選課
注意
策略
和策略
的不同在於
策略
引入了新的對象而策略
沒有
這是因為這樣
策略
的c表不能又自己的東西
而策略
有
．
其他
上面說過
聚合與組成是關聯的一種所以他們也符合以上策略
特別的
當用到組合關系的是否我們可用用到hibernate的
組件
<component>
由於
組件
它完全可以滿足組成關系的強關聯
．依賴
一般不在實體域對象中體現
O/R MAPPING (HIBERNATE)方法小結 （補充內容） 另外我看到了一種
鍵關聯
的方法
感覺很有道理
我理解了一下總結如下
．一般關聯
這種方法對於一般的關聯總是引入c表（另外的一張表）僅僅表示關系
C表的主鍵有分別指向A
B兩表（外鍵）
當指向一方的外鍵unique=
true
即唯一
那麼這一方為
一
反之為
多
的一方
這樣就可以形成一般的關聯關系
但是注意的是
c表不映射為對象
C表也沒有自己的屬性
．聚合和組成
當實體A的非主鍵列中有一個引自實體B的時候
這種關系是B聚合A
如果這種引用是強制性的
則是合成關系
否則為聚合關系
是否為強制性
只需要將引用列設為非空即可
．繼承
當實體A的主鍵引用自實體B的時候（即為外鍵）
那麼A繼承 B
總結
我覺得O/RM的方法有很多
我們可以看到
按外鍵
的方法思路很清晰
但是它在解決一般的關聯的時候總是引入另外一張表這樣勢必影響效率
另外
既然聚合和組合是關聯的一種那麼即使是組合關系我也把它看成一般關聯
也不算錯的
關系數據庫一開始就不是為了面向對象的語言服務的
所以我們在這裡映射無論那種方法似乎都不能說是完全的
正確無誤完成了O/RM
所以我覺得一切都要看我們的項目需求
因地制宜！
From:http://tw.wingwit.com/Article/program/Java/ky/201311/28093.html
