原文地址：http://blog.163.com/wcllu/blog/static/4624456920103813347480/
在powerdesigner的概念模型中，實體之間的關係是非常重要的，也決定了從概念模型轉化到物理模型時的表現形式，所以有必須深究其中的相關設置。做數據庫重要的就是表與表之間的關係，而這個關係是連接所有數據庫系統的紐帶，所以即使我們不用PD，也應該重視表與表之間的關係。這也是關係型數據庫的由來。
PD中的表與表之間的關係有四種，分別是one-one(一對一)，one-many(一對多)，many-one（多對一），many-many（多對多）。在實際中使用得最多的只有前面兩種，而多對一和一對多其實沒有什麼區別，只是二者關係的反向描述，所以其可以看成是一種類型。而多對多在實際的數據庫設計中也是時有出現的，這種情況下，我們一般不直接處理多對多的關係，而是通過一種技巧，將多對多轉化爲多對一，和一對多的關係，這樣可以簡化數據庫關係的複雜性。將多對多轉化爲多對一，再一對多意思是通過提供一個關聯關係表，來使多對多的關係表與該關聯關係表發生關係，而不讓其直接發生多對多的關係，這樣就可以簡化這樣的關係。前面文章中已經說明如何創建這種關聯表了。這裏也就不再說多對多的關係。後面只重點說明一對一，一對多的關係。
在CDM中，實體之間的關係更符合現實情況一些，以一對多的關係來說，如果一個實體對應多個實體，通常含有“包含，擁有”等這樣的意思在裏面。比如一個部門擁有多個員工，一個企業擁有多個部門等。而如果多個實體對應一個實體，則通常含有“屬於，包含於”等這樣的意思。比如多個員工屬於一個部門，多個部門包含於一個企業等。在PDM中就很具體了，且與實際的有些區別了，這主要是由於在軟件的實現角度上的體現，比如一對多的關係，比如T1與T2的關係爲T1一對多個T2，在PDM中，通常表現在T2中有一個外鍵，用來存儲T1的主鍵，這樣就叫一對多，而這樣的表現與實際上具有一定的差別。當然這是沒有什麼問題的，因爲PDM纔是我們真正在軟件實現時所採用的方式。我只是想說的是CDM中這種關係的描述，可能更和實際情況接近一些，也就更加容易明白一點。
好了，下面分別說明一下一對多和一對一的關係詳細說明：
1.對於一對多的說明
當兩個實體需要進行一對多的關聯時（比如T1與T2的關係爲T1一對多個T2，T1和T2爲兩個實體），我們通過Relationship，從T1拉至T2時，二者關係就建立起來了。默認情況下就是個一對多的關係，即T1爲1，T2爲多。
雙擊拉的關係線，則彈出二者關係描述的對話框，我們就可以在這個彈出的屬性對話框裏進行我們所需要的設置了。在彈出來的默認屬性爲General屬性選項。我們可以在這個屬性頁裏面修改關係名稱以及對這個關係的描述等。點擊Cardinalities屬性頁，在上面默認顯示的就是一對多的關係，我們現在是描述一對多的關係，所以不修改它。在關係下面有個Dominant role，這個右邊有個下拉框，不過是被置灰了，不可操作，這裏先不管，後面在說一對一時再說說這裏。
在T1 to T2的內容裏面，有個Role name，在其右邊有個輸入框，可以輸入T1表的角色名字，這裏就可以用前面提到的比如“擁有，包含”等這樣的內容，可以用來說明T1表的職能。在Role name下面的Dependent默認是置成灰色，意即不可操作，這裏我們就不管了。然後是Mandatory，這個是什麼意思呢？這個是否選擇決定了某個東西是否爲空。是什麼東西呢？指的是和本實體發生關係的對方實體的主鍵在本實體的外鍵字段是否爲空。比如現在有種情況是T1中某個字段，如par1，該字段爲外鍵，它將存儲T2中的主鍵，則如果Mandatory被選中，則par1不爲空，意即它必須存儲某一個T2的值，而如果不選上，則表示該字段值可以爲空。在現在的情況下T1與T2是一對多的關係，我們知道在PDM中，出現的情況是T2中會生成一個外鍵，用來存儲T1表的主鍵，而T1表不會有任何字段來存儲T2的主鍵 ，所以這個Mandatory是否被選擇上，不會對關係造成任何影響，所以這裏我們就不用管它了。當然，我們從實際的描述中，可以這樣來說明這個值的選取相關的情況，比如現在T1指的是部門，而T2指的是員工，當你選擇了該值，則在後面的Cardinality中會變成1,n，即如果選擇這個值，則表示一個部門至少有一個員工，而如果不選，則表示一個部門至少有0至n個員工，就這個區別，因爲爲一對多，T1表中不會存儲T2表中的主鍵，即使你選擇了Cardinality，用於說明是部門至少含有1個員工，但是，T2表此時仍爲空，沒有任何員工，也不會出現問題的（這是因爲一對多這個關係，導致T1表中不會有T2的任何相關信息造成的，當然在一對一的關係中，則不一樣的，後面會說到）。
現在再說說T2到T1的內容裏面的東西，其中的role name仍可以加入你所描述的T2的角色職責，比如“屬於，包含於”等。在其下面，我們發現Dependent沒有置灰了，是可以勾選的。我們先不管它，先趁熱把Mandatory再說清楚點，此時由於我們已經知道T2表中會含有T1的主鍵的了，因爲一對多的關係，則在生成的T2表時，會生成一個外鍵，用來單獨存儲T1的主鍵的，現在有個問題出現了，就是T2的存在是否依賴於T1，即說白一點就是一個員工是否一定要屬於某一個部門？如果你的數據庫系統中要求一定屬於，那麼你就把Mandatory選擇上。反之，如果你認爲新來的員工還沒有分配好部門，可以暫時不讓其屬於某一個部門，到後面在人爲的選擇某一個部門，那麼你就可以不用選擇上Mandatory了。Cardinality會根據你是否選擇Mandatory來決定其值是0,1還是1,1，意思很明確，就是是否T2一定屬於T1，即一個員工是否一定屬於一個部門。爲這進一步確認Mandatory是否選中對PDM的實際表現造成的影響，可以通過CDM轉化爲PDM，查看其中的外鍵字段是否允許爲空就可以明確了，如果你選擇了Mandatory，則在PDM中T2生成的外鍵中將不允許爲空，即必須含有T1的某一主鍵，而如果不選擇Mandatory，則在PDM中T2生成的外鍵是可以允許爲空的。
好了，現在來說說Dependent的意思，如果其不選，則沒有什麼變化，如果其被選擇中了，則會在PDM中對T2中生成的用於存儲T1主鍵的那個外鍵（FK）將會成爲T2的另外一個主鍵，這就是這個值的意思，如果你不需要T2中的外鍵同時成爲主鍵，則不用選擇該值。通常情況下，都不需要選擇這個。
2.一對一的關係說明
在兩個實體表中的關係中，如果一個表和另一個表是一對一的關係，這種一對一的關係有兩種形式，以T1表和T2表爲例。一種是T1中有個字段（外鍵）是T2表的主鍵，T2中有一個字段（外鍵）是T1表的主鍵，另一種情況是隻有其中的一個表含有另一個表的主鍵，而另一個表不含有前一個表的主鍵。前面說的第一種情形是指兩個實體互相感知，互相擁有對方的信息，另一種情況是指二者含有一定的依賴關係。某一個實體的存在依賴於另一個實體的存在。
相對來說，在軟件領域中，第二種情形更常見一些，完全平等的兩個實體在現實中存在的意義不大，畢竟社會是一個充滿着各種聯繫的實體，實體之間存在的着一定的依賴關係，就象孩子依賴於父母，員工依賴於企業，當然存在着兩個互相感知的實體，這樣帶來的一個好處是在查詢時非常迅速。下面說一下一對一關係的某些屬性的改變帶來的變化。
當T1和T2實體建立好了關係之後，正如前面所言，默認情況下是個一對多的關係，我們這次就要改變這種關係了。在關係線的屬性中，在Cardinalities屬性頁，我們將one-many修改爲one-one，當我們選中one-one後，下面的Dominant role由原來的置灰不可操作狀態變爲可操作狀態了。Dominant role的意思是佔支配地位的角色，在其右邊的下拉框中默認值爲none，這裏要求我們選擇的是兩個實體，誰佔支配地位，誰佔被支配地位。即誰支配誰。默認值中的none表示二者雙方都不佔支配地位，意即二者地位平等，則就是前面所述的第一種情況，即二者互相感知。這種情況下，在PDM中會發現T1表和T2表中都會生成一個外鍵，用於存儲對方的主鍵。而下面的Dependent和Mandatory和前面描述一對多的關係時表現是一樣的。這裏就不再贅述了，只是需要注意的一點是如果你的關係是二者互相平等的話，在選擇Mandatory中，不要將T1和T2都同時選擇上，不然就會出現互斥現象，永遠不成立。
現在我重點說一下關於第二種情形，現在假設我們需要T2中的外鍵來存儲T1的主鍵，那麼這種情況下誰是支配地位的角色呢？在Dominant role中是選擇T1->T2還是T2->T1呢？在->前面的是支配地位，後面的是被支配地位。想一下，爲什麼T2需要用一個外鍵來存儲T1的主鍵呢？是因爲T2需要T1的信息，需要T1來支持T2的存在，即T2依賴於T1，則說明T1應該是支配地位角色，那麼在Dominant role項中，我們就需要選擇T1->T2。明白了這個，就明白了爲什麼在一對多的關係裏，這個Dominant role是置灰的呢？原因很簡單，不需要我們指定這種支配角色，因爲一對多的關係中，爲一的那個必定是支配地位的角色，不需要我們改變。
好了，關於實體之間的關係就結束了。如果你不是很確定關係的選項對後來的PDM造成的影響，你可以通過試驗，通過簡單的兩個實體表，從CDM轉化爲PDM，實際看一下二者關係的表現，就明確了，這是我在實際的使用過程中，所用的方法。
摘自: qiuhong101
http://blog.csdn.net/2000killer/archive/2009/04/24/4103685.aspx