一）對象之間的關係：
1． 依賴：
依賴對象通過調用被依賴對象的方法來獲得服務。一種比較鬆散的關係，並且是短期的。我們的過程與對象往往依賴與我們的實體域對象。如在struts 的 action中調用模型層的方法。
2． 關聯
它使一個類指到另一個類的屬性。長期的
3． 聚合
聚合關係是關聯關係的一種，是強的關聯關係。聚合是整體和部分之間的關係。
4． 組合
也叫合成關係，組成關係是關聯關係的一種，是比聚合關係強的關係。對象負責代表部分的對象的生命週期。
注：既然聚合，組合關係屬於關聯關係，那麼如何區分一般關聯關係，聚合關係和組合關係呢？
一般關聯：只要一個對象聯繫到另外一個對象就形成了關聯關係。如：人和他的貓，黑豹樂隊和竇魏，pc機和顯示器。
聚合關係：一種強關聯關係，它要求有部分和整體的關係，並且沒有了整體部分也可以獨立存在。在上面三個例子中人和它的貓顯然沒有部分和整體的關係，所以只能是一般的關聯關係。而黑豹樂隊和竇魏，竇魏等人組成了黑豹樂隊即：竇魏和黑豹是整體和部分的關係。而
竇魏脫離了黑豹（早就離開了）更或者黑豹不存在了那麼竇魏仍然可以以音樂人的身份存在（即對象仍然可以獨立存在）所以它屬於聚合關係。組成關係是可以共享的。（竇魏也可以加入其他樂隊）。
組合關係：一種更強的整體和部分的關係。它並且要求代表整體的對象負責代表部分的對象的生命週期，組成關係是不能共享的。如：pc機和顯示器的關係。
我覺得：如果兩個實體是整體和部分的關係，那麼它們到底是聚合還是組合，這取決於你的需求。比如說：pc機和顯示器的關係，如果你的系統中，顯示器脫離了pc機就不存在意義了，也可以說：所有顯示器的訪問都是通過pc機進行的，那麼你可以把關係設定爲組合（如你在爲一個只買品牌機的代理商作系統你可能是可以這麼作的）。如果你的顯示器脫離的pc機仍然可以獨立存在，也就是說在系統中可以直接訪問顯示器對象，那麼你可以將關係設爲聚合（如你在爲一個買散件的代理商作系統你可能是可以這麼作的）
5． 繼承
這個我不想多講了，用過面向對象的語言都應該知道。
（二）關係數據庫的關係
一對一
一對多
多對一
多對多
（三）o/r mapping策略
1．繼承：
對於繼承關係一般有三種策略：
策略1繼承樹的每個類對應一個表
共享主鍵
策略2繼承樹的根類對應一個表
需要添加一個識別字段
策略3繼承樹的葉子類對應一個表
不支持多態查詢
2．關聯
2．1一對一
一半有兩種策略：
策略1：唯一的外鍵
+unique=”true” (唯一的外鍵)
策略2：共享主鍵
(既是主鍵又是外鍵)
注意：生成方式需要用：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的"組件"。由於“組件”它完全可以滿足組成關係的強關聯。 3．依賴一般不在實體域對象中體現。另外我看到了一種”鍵關聯”的方法，感覺很有道理。我理解了一下總結如下： 1． 一般關聯：這種方法對於一般的關聯總是引入c表（另外的一張表）僅僅表示關係。 C表的主鍵有分別指向A,B兩表（外鍵）。當指向一方的外鍵unique=”true”即唯一，那麼這一方爲“一”，反之爲“多”的一方。這樣就可以形成一般的關聯關係。但是注意的是：c表不映射爲對象。C表也沒有自己的屬性。 2． 聚合和組成當實體A的非主鍵列中有一個引自實體B的時候，這種關係是B聚合A。如果這種引用是強制性的，則是合成關係，否則爲聚合關係。是否爲強制性，只需要將引用列設爲非空即可； 3． 繼承當實體A的主鍵引用自實體B的時候（即爲外鍵），那麼A繼承 B。總結：我覺得O/RM的方法有很多，我們可以看到“按外鍵“的方法思路很清晰。但是它在解決一般的關聯的時候總是引入另外一張表這樣勢必影響效率。另外，既然聚合和組合是關聯的一種那麼即使是組合關係我也把它看成一般關聯，也不算錯的。關係數據庫一開始就不是爲了面向對象的語言服務的，所以我們在這裏映射無論那種方法似乎都不能說是完全的，正確無誤完成了O/RM。所以我覺得一切都要看我們的項目需求。因地制宜！
1． 依賴：
依賴對象通過調用被依賴對象的方法來獲得服務。一種比較鬆散的關係，並且是短期的。我們的過程與對象往往依賴與我們的實體域對象。如在struts 的 action中調用模型層的方法。
2． 關聯
它使一個類指到另一個類的屬性。長期的
3． 聚合
聚合關係是關聯關係的一種，是強的關聯關係。聚合是整體和部分之間的關係。
4． 組合
也叫合成關係，組成關係是關聯關係的一種，是比聚合關係強的關係。對象負責代表部分的對象的生命週期。
注：既然聚合，組合關係屬於關聯關係，那麼如何區分一般關聯關係，聚合關係和組合關係呢？
一般關聯：只要一個對象聯繫到另外一個對象就形成了關聯關係。如：人和他的貓，黑豹樂隊和竇魏，pc機和顯示器。
聚合關係：一種強關聯關係，它要求有部分和整體的關係，並且沒有了整體部分也可以獨立存在。在上面三個例子中人和它的貓顯然沒有部分和整體的關係，所以只能是一般的關聯關係。而黑豹樂隊和竇魏，竇魏等人組成了黑豹樂隊即：竇魏和黑豹是整體和部分的關係。而
竇魏脫離了黑豹（早就離開了）更或者黑豹不存在了那麼竇魏仍然可以以音樂人的身份存在（即對象仍然可以獨立存在）所以它屬於聚合關係。組成關係是可以共享的。（竇魏也可以加入其他樂隊）。
組合關係：一種更強的整體和部分的關係。它並且要求代表整體的對象負責代表部分的對象的生命週期，組成關係是不能共享的。如：pc機和顯示器的關係。
我覺得：如果兩個實體是整體和部分的關係，那麼它們到底是聚合還是組合，這取決於你的需求。比如說：pc機和顯示器的關係，如果你的系統中，顯示器脫離了pc機就不存在意義了，也可以說：所有顯示器的訪問都是通過pc機進行的，那麼你可以把關係設定爲組合（如你在爲一個只買品牌機的代理商作系統你可能是可以這麼作的）。如果你的顯示器脫離的pc機仍然可以獨立存在，也就是說在系統中可以直接訪問顯示器對象，那麼你可以將關係設爲聚合（如你在爲一個買散件的代理商作系統你可能是可以這麼作的）
5． 繼承
這個我不想多講了，用過面向對象的語言都應該知道。
（二）關係數據庫的關係
一對一
一對多
多對一
多對多
（三）o/r mapping策略
1．繼承：
對於繼承關係一般有三種策略：
策略1繼承樹的每個類對應一個表
共享主鍵
策略2繼承樹的根類對應一個表
需要添加一個識別字段
策略3繼承樹的葉子類對應一個表
不支持多態查詢
2．關聯
2．1一對一
一半有兩種策略：
策略1：唯一的外鍵
+unique=”true” (唯一的外鍵)
策略2：共享主鍵
(既是主鍵又是外鍵)
注意：生成方式需要用：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的"組件"。由於“組件”它完全可以滿足組成關係的強關聯。 3．依賴一般不在實體域對象中體現。另外我看到了一種”鍵關聯”的方法，感覺很有道理。我理解了一下總結如下： 1． 一般關聯：這種方法對於一般的關聯總是引入c表（另外的一張表）僅僅表示關係。 C表的主鍵有分別指向A,B兩表（外鍵）。當指向一方的外鍵unique=”true”即唯一，那麼這一方爲“一”，反之爲“多”的一方。這樣就可以形成一般的關聯關係。但是注意的是：c表不映射爲對象。C表也沒有自己的屬性。 2． 聚合和組成當實體A的非主鍵列中有一個引自實體B的時候，這種關係是B聚合A。如果這種引用是強制性的，則是合成關係，否則爲聚合關係。是否爲強制性，只需要將引用列設爲非空即可； 3． 繼承當實體A的主鍵引用自實體B的時候（即爲外鍵），那麼A繼承 B。總結：我覺得O/RM的方法有很多，我們可以看到“按外鍵“的方法思路很清晰。但是它在解決一般的關聯的時候總是引入另外一張表這樣勢必影響效率。另外，既然聚合和組合是關聯的一種那麼即使是組合關係我也把它看成一般關聯，也不算錯的。關係數據庫一開始就不是爲了面向對象的語言服務的，所以我們在這裏映射無論那種方法似乎都不能說是完全的，正確無誤完成了O/RM。所以我覺得一切都要看我們的項目需求。因地制宜！
