Dominant role，mandatory與dependent

1 PD 中的 CDM 階段 ,ER 模型的三要素 :  實體型，屬性和聯繫。

 

2  實體屬性的使用

        2.1 General  項目  

               Name ：是用來在模型中標識一個實體，通常用於模型在界面中的顯示（這個能夠                   經過更改選項設置進行改變）。在一個模型當中，實體的名字不能重複。

               Code ：在模型轉化時通常做爲對象的物理名稱，好比把實體屬性的 Code 轉化爲數            據庫中的列名，固然咱們如今沒必要爲了這個實體未來叫什麼而費神，通常採起與                       Name 一致便可。

               Generate ：默認是選擇狀態，若是取消，則在轉化爲其餘模型時，會忽略這個實體。  

        2.2 Attributes  項目

               M ：此屬性不容許爲空值  

               P ：此屬性爲主鍵標識  

               D ：爲可顯示屬性

 

3 RelationShip 的相關參數使用

     3.1 Dominant role( 1 對1 )

當兩個實體之間的關係是1..1  時（儘管這種關係比較少見，常見於面向對象的設計方法當中，依賴實體中的主鍵一般與外健重合），你須要明確指定這兩個實體，哪個是父實體，哪個是依賴 實體，不然，系統在由概念模型轉化爲物理模型時，將不能肯定須要在哪一端生成外鍵，這時就須要用到「Dominant role」 選項，這個選項只有在1..1  的關係中才容許進行設置。咱們假定這樣的業務描述，企業中的部分僱員擁有一個系統帳號，而且是惟一的一個帳號，這些僱員須要保存一些額外的信息，好比帳號 名稱、密碼等等。咱們添加了一個新的實體「User」 ，其與僱員之間爲1..1  的關係，因爲一個用戶帳號一定屬於一個僱員，而一個僱員則可能沒有用戶帳號，因此咱們定義實體「Employee」 支配實體「User」 。同時，因爲 「User」 依賴於「Employee」 而存在，因此再定義一個由前者到後者的依賴關係，以下圖：

 

　

Dominant role  選項中，箭頭所指的實體爲被支配的實體，即做爲依賴實體。在模型圖中，支配實體的一方會出現一個用圓括號括起來的大寫字母「D」 。

 

　

轉化出來的物理模型中，表User 中，empNo 做爲單獨的主鍵，同時也是引用Employee 表的一個外鍵。

3.2 mandatory( 1 對多或多對1)
   聯繫是否具備強制性，指的是實體間是否是必定會出現這種聯繫；或者換句話說，當咱們在談及一個聯繫的應用場景的時候，聯繫對應的那兩個實體型的實體實例的 個數可不可能爲零。也許這樣的解釋仍是有點抽象，讓咱們舉兩個聯繫的例子，一個是對兩邊的實體都有強制性的，另外一個則否則。
 （1 ）教師-- 學生 聯繫
   這個聯繫首先是一個多對多聯繫，由於每一個老師能夠教多個學生，每一個學生也都有多個老師來負責他們的學業。同時，這個聯繫對教師和學生都是強制性的，也就是說，不存在任何一個老師，他不負責任何一個學生的教學；也不存在任何一個學生，他沒有任何一個任課老師。
 （2 ）學生-- 俱樂部 聯繫
   這個聯繫也是一個多對多關係，但它對學生這個實體型而言就不是強制的（Optional, 可選的）。每一個俱樂部都有至少一個學生參加，但並非每一個學生都要去參加俱樂部的活動。徹底能夠有一些學生，他們什麼俱樂部都沒參加。
 上面的例子主要是從概念的角度來區分了mandatory 和optional 的區別。實際上若是把這個模型對應到咱們最後生成的表，若是A-B 間的聯繫對 A 是mandatory 的話，那麼若是在A 裏面若是包含B 的外鍵，這個外鍵不能爲空值，反之能夠爲空值。後面咱們談到PDM 和實際數據庫的時候，你們會看 到這一點。

3.3 Dependent (1 對多或多對1)

仍是使用上面的例子，咱們假定這樣的業務描述：僱員享有假期，僱員每次休假，須要記錄僱員休假的起始日與結束日，假期以天爲單位，一個僱員和一個開 始日惟一肯定一個假期。根據這個業務描述，咱們知道，對於假期而言，其必須依存於實體「Employee」 而存在，即一個休假，一定有一個主體僱員。咱們 在上一個模型的基礎之上，添加一個實體，名稱是「Holiday」 ，定義假期的屬性開始日與結束日，這裏並不須要重複定義一個僱員編號，而是替代的，使用 依賴關係，來表示實體「Holiday」 依賴於實體「Employee」 ，關係定義以下圖：

 

　

在實體「Holiday」 中，咱們須要設置開始日爲主鍵標識符，開始日與其依賴實體中的僱員編號一塊兒做爲實體「Holiday」 的標識符，用來惟一肯定一個假期。這種依賴關係在概念圖中表現以下：

 

　

從途中能夠看出，在實體「Holiday」 一端多了一個朝外的三角▲ 箭頭，這個含義就是這個實體「 的依賴於三角箭頭所指的另一個實體，在轉化出來 的物理模型當中，實體「Employee」 的empNo ，在Holiday 實體中不只會做爲一個外鍵，還同時會做爲主鍵出現（與startData 一塊兒做 爲複合主鍵）。

   每個Entity 型都有本身的Identifier ，若是兩個Entity 型之間發生關聯時，其中一個Entity 型的Identifier 進入另外一個 Entity 型並與該 Entity 型中的Identifier 共同組成其Identifier 時，這種關聯稱爲標定關聯, 也叫依賴性關聯(dependent relationship) 。一個Entity 型的Identifier 進入另外一個Entity 型後充當其非Identifier 時，這種關聯稱爲非標定 關聯, 也叫非依賴關聯。
   概念的定義提及來仍是有些拗口，說白了其實就是主- 從表關係，從表要依賴於主表。
   對於依賴型聯繫，必須注意它不多是一個多對多聯繫，在這個聯繫中，必須有一個做爲主體的實體型。一個dependent 聯繫的從實體能夠沒有本身的identifier.

3.4  多對多(n..n) 的關係

在概念模型中，通常不多看見兩個實體之間是直接的n..n  的關係，通常這種狀況下咱們會增長一箇中間實體，在Power Designer 中，提供了一個專門的符號來對應，叫作「Association」 。請考慮如下的情形：

企業中擁有帳號的僱員在系統中具備不一樣的操做權限，這經過用戶角色來進行管理，權限已經分配給了多個不一樣的角色，一個用戶帳號至少屬於一個角色，並 且可能會同時屬於多個角色，一個角色能夠包含0 個或多個用戶帳號。根據以上描述，咱們添加一個實體「Role」 ，它與實體「User」 之間是n..n  的關係，爲了表達這種關係，咱們增長一個「Association」 並分別使用「Association Link」 與其餘兩個實體創建關係，表示以下：

 

使用一個普通的實體，合理定義關係，並選擇「Dependent」 選項，是能夠替代「Association」 的，但使用 「Association」 更方便、直觀，使模型更容易理解，並能夠減小因不謹慎而可能致使的錯誤。

3.5 關係的取名

      通常最好爲關係取一個貼切的名字，本例的業務關係描述以下：一個部門有多個員工，咱們使用「Has」 做爲這個關係的名字。

一樣的咱們 也能夠描述爲：多個員工屬於一個部門，可不可使用「Belong to」 做爲關係名字呢？通常不推薦這樣作，在概念圖中有一個約定，關係的名字採用從「1,n」 中「1」 所在的方向向「n」 所在一方進行讀取的語義。本例即 「1」 在部門一方，從部門一方向僱員一方讀取語義，即：部門有（Has ）多個員工。

---------------------------------------------------------

---------------------------------------------------------

從實用的角度來說，一對多和多對一沒什麼分別。這裏你要注意的是，一對多實際上能夠理解爲主表和子表。主表的一條記錄能夠和子表的N條記錄有關係。若是要想讓主表的主鍵到子表中繼續作主鍵，子表的記錄就依賴主表的記錄而存在，此時應該在(子表 to 主表)選項裏面的 Dependent 上打勾，這時 Mandatory 自動被選上。若是不須要主表的主鍵到子表中繼續作主鍵，主表的記錄僅對子表作約束或者說是強制，這時只在(子表 to 主表)選項裏面的 Mandatory 上打勾。若是不須要主表的主鍵到子表中繼續作主鍵，子表裏的這個字段能夠是主表裏的數據同時也能夠爲空，在(子表 to 主表)選項裏面的 Mandatory 上的勾去掉。