從PowerDesigner概念設計模型（CDM）中的3種實體關係說起

原文地址為：從PowerDesigner概念設計模型（CDM）中的3種實體關係說起

注：本blog上所有隨筆均屬EagleFish在cnblogs上的原創，歡迎轉載，但請註明出處。

  CDM是大多數開發者使用PD時最先建立的模型，也是整個資料庫設計最高層的抽象。CDM是建立在傳統的ER圖模型理論之上的，ER圖中有三大主要元素：實體型，屬性和聯絡。其中實體型對應到CDM中的Entity，屬性對應到CDM中每個Entity的Attribute，在概念上基本上是一一對應的。但在聯絡上，CDM有了比較大的擴充套件，除了保留ER圖原有的RelationShip概念之外，還增加了Association，Inheritance兩種實體關係，下面就讓我們分別看看這些關係的用法和之間的區別（下圖中被標紅的工具欄按鈕就是用來向實體中新增這些關係的）。

  另外，在介紹所有這些CDM中的元素之前，筆者先給出一個很簡單的CDM圖，是對我們最最熟悉的學校場景的一個建模，下文中提到的所有概念在圖中都有體現，大家在看下文的時候可以對照著來看：


一. RelationShip(聯絡)
  先給出PD手冊裡對聯絡的定義：“A relationship is a link between entities. For example, in a CDM that manages human resources, the relationship Member links the entities Employee and Team, because employees can be members of teams. This relationship expresses that each employee works in a team and that each team has employees.” 可見，也許聯絡的概念真的太簡單了吧，所以反而不那麼好表述，所以PD的文件裡也是用一個例子來說明出現了什麼樣的情況我們就認為兩個實體間是有聯絡的。
  當我們提起實體間聯絡的時候，最先想到的恐怕是one to one，one to many 和many to many這三種聯絡型別，這些聯絡型別也是大家最熟悉的。筆者對ER圖原本的概念並不精通，但在CDM中，聯絡還有另外三個可以設定的屬性：mandatory（強制性聯絡）, dependent（依賴性聯絡/標定關聯） 和dominant（統制聯絡）。這些屬性對後面PDM的生成都有比較大的影響，需要我們一一有所瞭解。它們都是在聯絡的屬性控制皮膚中設定的，見下圖：

1.mandatory
  聯絡是否具有強制性，指的是實體間是不是一定會出現這種聯絡；或者換句話說，當我們在談及一個聯絡的應用場景的時候，聯絡對應的那兩個實體型的實體例項的個數可不可能為零。也許這樣的解釋還是有點抽象，讓我們舉兩個聯絡的例子，一個是對兩邊的實體都有強制性的，另一個則不然。
（1）教師--學生 聯絡
  這個聯絡首先是一個多對多聯絡，因為每個老師可以教多個學生，每個學生也都有多個老師來負責他們的學業。同時，這個聯絡對教師和學生都是強制性的，也就是說，不存在任何一個老師，他不負責任何一個學生的教學；也不存在任何一個學生，他沒有任何一個任課老師。
（2）學生--俱樂部 聯絡
  這個聯絡也是一個多對多關係，但它對學生這個實體型而言就不是強制的（Optional,可選的）。每個俱樂部都有至少一個學生參加，但並不是每個學生都要去參加俱樂部的活動。完全可以有一些學生，他們什麼俱樂部都沒參加。
上面的例子主要是從概念的角度來區分了mandatory和optional的區別。實際上如果把這個模型對應到我們最後生成的表，如果A-B間的聯絡對A是mandatory的話，那麼如果在A裡面如果包含B的外來鍵，這個外來鍵不能為空值，反之可以為空值。後面我們談到PDM和實際資料庫的時候，大家會看到這一點。
2.dependent
  每一個Entity型都有自己的Identifier，如果兩個Entity型之間發生關聯時，其中一個Entity型的Identifier進入另一個Entity型並與該 Entity型中的Identifier共同組成其Identifier時，這種關聯稱為標定關聯,也叫依賴性關聯(dependent relationship)。一個Entity型的Identifier進入另一個Entity型後充當其非Identifier時，這種關聯稱為非標定關聯,也叫非依賴關聯。
  概念的定義說起來還是有些拗口，說白了其實就是主-從表關係，從表要依賴於主表 。比如在我們系統裡要記錄教師休假的情況，有一個實體型Holiday，其屬性包括休假的開始時間和天數，每次有教師休假的時候，都要在這個表留下記錄。從我們的場景描述中可以看到，實體型假期必須依附於實體型教師，即對於每一個假期例項，必須指向某一個教師例項。
  對於依賴型聯絡，必須注意它不可能是一個多對多聯絡，在這個聯絡中，必須有一個作為主體的實體型。一個dependent聯絡的從實體可以沒有自己的identifier.
3.dominant
  這個聯絡屬性是最為簡單的，它僅作用於一對一聯絡，並指明這種聯絡中的主從表關係。在A,B兩個實體型的聯絡中，如果A-->B被指定為dominant，那麼A為這個一對一聯絡的主表，B為從表，並且在以後生成的PDM中會產生一個引用（如果不指定dominant屬性的話會產生兩個引用）。 比如老師和班級之間的聯絡，因為每個班級都有一個老師做班主任，每個老師也最多隻能做一個班級的班主任，所以是一個一對一關係。同時，我們可以將老師作為主表，用老師的工號來唯一確定一個班主任聯絡。

二.Association（關聯）
  先來看一下PD給association的定義：“An association is a connection between entities. In the Merise modeling methodology an association is used to connect several entities that each represents clearly defined objects, but are linked by an event, which may not be so clearly represented by another entity.”。
  在上一小段提到的那些RelationShip，在很多情況下（特別是多對多關係中），我們會把聯絡專門提出來，作為一個實體型放在兩個需要被關聯的實體型中間（在PD中，選中任何一個聯絡，在右鍵的彈出選單中選擇“Change to Entity”命令即可完成聯絡轉實體的操作）。但有的時候，把若干個實體型之間的聯絡抽象為一個實體型可能不太合適，這個時候你可以選擇為這些實體型建立一個association，那麼在生成PDM的時候，所有這些相關實體型的identifier都會被加入到association對應生成的表模型中。所以，說白了，其實association就是實體型的一種特例，用來在建模的時候更確切的表達實體間的關聯資訊。在PD的文件中舉了一個錄音帶、顧客、商店三個實體型在租借錄音帶這個場景上發生關聯，然後把租借定義為上述三個實體型之間的association的例子，非常確切。在我們的學校模型裡，我定義了家訪做為老師和學生實體型中間的一個association，在接下來產生的PDM中大家就可能看到這種定義所產生的效果。

三.Inheritance（繼承）
  這種關係在概念層面是最容易理解的了，本文就不贅述了。

前面已經介紹了CDM中關於實體間關係的主要內容，接下來我們就來看看根據這個CDM所生成的PDM是一個什麼樣子：

上圖中所有標紅的部分是我們最應該關注的內容，因為他們都是由於我們對實體型間的關係的定義而產生的，下面給出一些簡單的說明。
1. “師生關係”和“學生俱樂部”這兩個表是由於我們的多對多關係而產生的。
2. “假期”表的“工號”欄位是由於我們將教師-假期關係指定為dependent而產生的。
3. “班級”表的“工號”欄位是由於我們將教師-班級關係制定為dominant而產生的。
4. “家訪”表中的“工號”和“學號”欄位是由於家訪是教師和學生實體型的association而產生的。
另外，記得我們在提到dominant屬性的時候說過，一個沒指定dominant方向的一對一聯絡將產生兩個引用，下面我們就把原本的CDM中的教師-班級關係進行一個小小的修改，去掉這個relationship的dominant定義，那麼最終產生的PDM中教師表和班級表將互相包含對方的主鍵(由於我們的班級表沒有自己的主鍵，所以只能在班級表中看到多出來的列)，截圖如下：

對照這個PDM截圖和上一個PDM截圖之間的區別，大家可以很容易得看出dominant屬性對一個一對一關係的作用。

  好了，說到這裡，本文就暫時告一段落了。文中提到的，都是經常使用PD的同志和筆者一樣每天都會碰到的一些概念。只有我們把這些概念弄得很清楚，對PD的使用才能事半功倍。筆者也在網上找過關於PD的資料，發現有價值的資源很少。如果哪位老兄有比較好的資源或者書，還請推薦一二。
應一位朋友的要求，將本文中用到的CDM檔案放在這裡： school.rar


轉載請註明本文地址：從PowerDesigner概念設計模型（CDM）中的3種實體關係說起