概述
??? 從80年代中期開始，隨著C++語言的成功，面向對象語言已經成為軟件開發中的主導語言。現在很多商用軟件，尤其是企業信息系統，都是使用面向對象語言進行開發的。應用面向對象方法，我們通過類來抽象不同類別的實體，屬性來表示實體的靜態特征，關聯來抽象實體間的聯系，繼承來抽象類別的包含關系。


很多的應用程序都需要進行數據存儲，關系型數據庫是最常用的數據管理系統。在關系型數據庫中，表、列和外鍵是抽象數據的基本元素。關系型數據庫是建立在關系計算和布爾代數基礎之上的，SQL是數據庫的操作語言，通過關系運算，連接、聯合等，來操作數據。


我們很容易的看出，面向對象模型和關系模型是不完全匹配的。比如
1. 對象可以存儲到多張表，表也可以存儲多個類的對象。
2. 對象之間的關系是雙向的，而表之間的關系是單向的。
3. 對象之間有繼承關系，表之間沒有。

為了解決這種不匹配，人們定義了很多映射模式來建立兩種模型間的對應關系。這些映射模式邏輯上解決了模型間的不匹配，使得面向對象程序能夠正確地和關系關系型數據庫進行交互，但是對于程序的開發，仍然有很多問題需要解決。

問題
??? 對于設計人員來說，他們需要找到并且描述這兩種模型元素間的映射關系，以便編程人員能夠正確地實現數據的存儲和查詢。現在很多建模工具僅提供其中一種模型的支持，比如Together僅支持對象建模，ERWin僅支持數據建模。即使同時支持兩種模型，這種支持也很不完整，比如Rose中的數據建模功能。分析設計人員常常需要兩種不同的工具來進行建模，如果他們想描述這兩種模型元素間的對應關系，他們只能通過文檔或者表格的形式。這很容易產生錯誤，并且如果模型發生改變，這些文檔需要手工更改，容易造成不一致，維護起來很困難。

?? 對于編碼人員，他們需要應用某種技術來實現模型的這種對應關系。如果通過語言提供的數據庫訪問接口，比如Java的JDBC或者.Net的ADO.Net，對于每一個對象的每一個存儲操作，編碼人員需要編寫存取操作的SQL，數據庫控制和訪問代碼，這是一項繁瑣、重復性的勞動。即使應用O/R 映射的框架，比如Hibernate, EJB 3.0或者.Net平臺的NHibernate，他們需要編寫映射文件或者通過標記來定義O/R映射框架所需要的映射元數據。這些映射元數據只不過是我們在設計階段定義的映射關系另外一種表現方式，轉換成XML或者標記的方式，無疑這種轉換增加了錯誤的可能性和維護的難度。

PowerDesigner解決之道

??? PowerDesigner提供對于多達8種模型的支持，其中包括面向對象模型和關系數據模型。作為一個集成的企業建模工具，PowerDesigner并不是簡單的將幾種模型工具羅列在一起。各種模型相互之間可以建立關聯，通過這種關聯，它提供了企業模型統一、一致的視圖。其中模型間的映射和自動生成是建立模型間關聯重要的手段。

??? 模型可以描述系統的靜態特征和動態特征，而靜態特征可以用來表述系統的持久狀態，比如面向對象模型中的實體類，數據庫模型的表，XML模型中的元素節點等。在PowerDesigner中，我們可以在各種可以描述持久狀態模型間建立映射，比如XML模型到面向對象模型間的映射，面向對象模型到關系數據模型的映射等。下面我們就來看一下，PowerDesigner是如何支持面向對象模型到關系模型的映射的。

1.1 對象/關系映射

下表列出了PowerDesigner中面向對象元素和關系模型元素間的對應關系：

OOM 元素	PDM 元素
域	域
類	表
接口	無
屬性	列
標識符	鍵
操作 （具有存儲過程范型）	存儲過程
操作 （具有存儲功能范型）	存儲功能
關聯	外鍵或者表
關聯類	表和兩個指向關聯的類所生成表的外鍵
繼承	表或者外鍵
依賴	無
實現	無
引用	無

在PowerDesigner中，我們可以通過三種方式來建立面向對象模型和關系模型間的映射：
1. 手工建立映射。
2. 自動模型生成。
它們分別適用于不同的開發需求，下面我們就來看如何通過這兩種方式來建立映射。

1.2 手工建立映射

這種方式適用于以下幾種情況：
1. 在已經存在的模型間建立映射。企業的信息系統是一個異構的環境，很多應用程序和數據庫都是獨立開發的，它們具有不同的模型，如果它們之間需要進行數據交互，則需要建立它們之間的映射，比如新的ERP系統中和企業原有的數據庫間的映射。

2. 數據庫和程序由不同的組負責設計。大型的企業應用程序可能包含很多業務子系統，每個業務子系統只考慮如何實現它自己的業務需求，而數據庫設計要從整體出發，考慮整個應用程序的需求。對于每個業務模塊，需要定義它的邏輯模型和數據庫模型間的映射。

在建立映射之前，我們需要給面向對象模型創建數據源，然后添加要映射的數據庫模型。表1中可以映射的面向對象元素都有一個映射的定義窗口，比如下圖所示的類的映射屬性頁。通過這個映射屬性頁，用戶可以添加或者刪除對應的數據庫模型元素，這些元素只能是表1中該元素對應的類型。


像其他模型的元數據一樣，PowerDesigner會把映射元數據存儲在模型中，映射元數據通過快捷方式來記錄對應的模型元素。如果對應的模型發生改變，比如表的名稱發生改變，對于映射元數據沒有影響。當用戶需要得到對應元數據的屬性的時候，PowerDesigner會解析快捷方式，找到目標元素，用戶得到的是當前元素的信息，對比于文檔或者表格，這種方式提高了一致性和可維護性。而且PowerDesigner提供了變更影響分析視圖，它可以幫助用戶在變更之前分析可能產生的影響，比如在改變列的類型之前，用戶可以了解到是否會造成映射到此列的屬性類型的不匹配。

也許用戶認為這種操作方式太復雜，用戶需要切換到每個面向對象的窗口來定義它的映射。從PowerDesigner 12開始，用戶可以通過另外一種更加便捷的方式，映射編輯器，來定義元素間的映射關系。映射編輯器提供了一種All-In-One的操作方式，通過元模型和目標模型的樹狀視圖，用戶可以方便的通過托拽的方式來定義所有的映射。

1.3 模型自動生成

??? 在很多時候我們要開發一個全新的系統，而數據庫僅僅考慮這個系統的數據管理需求，或者開發新的應用程序訪問已有的數據庫。采用面向對象方法的軟件開發通常采用自頂向下的開發過程，先建立企業的應用模型，然后再進行數據庫設計。用戶也可以采用自底向上的開發過程，也就是以數據為中心的開發過程，先進行數據庫設計， 或者應用已有的數據庫模型，再設計應用程序模型。

??? 既然我們定義了模型間映射模式，如果有了一種模型，為什么不能自動生成另外一模型，并且建立它們間的映射。PowerDesigner就提供了這種模型的自動生成功能，使得用戶能夠重用現有的模型，方便的生成目標模型。對于面向對象模型和數據庫模型來說，這種自動生成功能是雙向的，即可以通過面向對象模型來生成數據庫模型，也可以通過數據庫模型來生成面向對象模型。

1.3.1 自動生成數據庫模型

這種模式適合于自頂向下的開發過程，即先建立應用程序模型，再設計數據庫。我們可以應用PowerDesigner提供的轉換模式，將應用程序模型中描述持久信息的面向對象元素，實體類、關聯、繼承，生成數據庫模型對應的元素。
根據已經被證明的映射模式，PowerDesigner提供了一些缺省的轉換模式，用戶也可以定制轉換模式來控制生成過程

1.3.1.1 基本轉換模式

1. 類
用戶可以通過類的持久屬性和生成類型來控制類的自動轉換，PowerDesigner僅會自動轉換持久的類。轉換的類型有表、遷移列和抽象數據類型，其中表和抽象數據類型都容易理解，遷移列主要控制繼承中類的轉換，我們會在繼承轉換中詳細討論它的用法。用戶還可以指定生成表的名稱。

2. 屬性
如果持久類的生成類型不是抽象數據類型，PowerDesigner會將該類中的持久屬性轉換成表的列。PowerDesigner提供了一些缺省的轉換模式，比如數據類型的對應關系。用戶可以定制轉換的過程，他可以定義生成列的一些屬性，名稱、類型、長度等。

3. 標識符
持久類的標識符會被轉換成表的鍵，主標識符會被轉換成主鍵。

4. 操作
如果持久類的操作具有存儲過程或者存儲函數的范型，相應的存儲過程或者存儲函數會被生成。

1.3.1.2 關聯轉換

PowerDesigner會根據關聯生成外鍵和表，支持所有的關聯映射模式。

關聯	轉換規則
一對一	對于單向的關聯，一個外鍵會生成，外鍵的方向和關聯的方向一致，父表的主鍵會遷移到子表中作為外鍵。對于雙向的關聯，兩個外鍵會被生成，用戶需要手動刪除其中的一個
一對多	不管單項還是雙向，只有一個外鍵被生成，多端持久類生成的表為子表，父表的主鍵會遷移到子表中作為外鍵
一對多遷移主鍵	這是一對多關聯的變體，如果一對多關聯具有組合并且由一端包含多端，那么被遷移到子表的列同時又會是主鍵的一部分
多對多	會生成一個中間關聯表和兩個外鍵，其中兩端持久類的表的主鍵會遷移到關聯表中作為主鍵和外鍵，兩個外鍵由中間關聯表分別指向它們

用戶可以通過端點的度來控制外鍵是否為必需的，如果子表對應的持久類端的最小度為1，那么外鍵為必需的，即子表的外鍵列是非空的；如果為0，那么外鍵為可選的。

1.3.1.3 繼承轉換
PowerDesigner會將繼承轉換成表和關聯，用戶通過基本映射中提到的生成類型來控制轉換，生成類型表表示對于該持久類單獨的表會生成，生成類型遷移列表示該類屬性生成的列會存在于其他類生成的表中，沒有單獨的表會被生成。

映射模式	說明	設定
繼承層次到單表映射	整個繼承層次會被轉換成一張表，通過表中的分類列來區分不同的類	根類生成類型為表，其他所有子類的生成類型為遷移列，根類需要設置主標識符
每類一表映射	對于繼承層次中的每一個類，單獨的表會被生成，子類的表和父類的表通過外鍵關聯，外鍵的列同時作為子類表的主鍵	所有類的生成類型為表，根類需要設置主標識符
每具體類一表映射	只有繼承層次中的葉子節點類會被轉換成表，每一個非葉子節點類屬性生成的列會被遷移到葉子類的表	所有非葉子節點子類的生成類型為遷移列，葉子節點的生成類型為表，根類需要設置主標識符

PowerDesigner也支持混合映射模式的轉換，不過這種轉換并不常用，用戶可以參考PowerDesigner的文檔查看詳細用法。

1.3.1.4 其他映射模式的支持

PowerDesigner還可以通過嵌入來支持細粒度的轉換。比如，在員工信息類中，我們有一個屬性家庭住址，該屬性是對象類型，類型為地址類。我們不想為地址類單獨生成表，只想把它嵌入到員工信息表中。在PowerDesigner中，我們可以通過，設置屬性的類生成類型為嵌入來實現這一點。

1.3.2 自動生成面向對象模型

PDM到OOM的轉換適合于自底向上的開發過程，對于以數據為中心的應用系統或者訪問已有數據庫上的應用系統，這種轉換是非常有用的。PDM到OOM的轉換類似于OOM到PDM轉換的逆過程，PowerDesigner會把PDM中的元素轉換成OOM中對應的元素。但是其中繼承的轉換是不可逆的，因為PDM中沒有子類的概念，所以用戶需要手工更改生成后的對象模型。

1.3.3 模型和并

PowerDesigner提供了模型合并功能，支持迭代式的模型自動轉換。自動生成的目標模型并不一定完全滿足我們的需要，我們常常要對它進行修改，但是源模型也發生了改變，有時我們既想同步目標模型和源模型，又想保持我們對目標模型所作的修改，這時模型的合并顯得非常重要。通過PowerDesigner的模型合并窗口，用戶可以了解到重新生成的模型和當前的目標模型的差異，從而可以根據自己的需要，選擇是否保持或者覆蓋以前的模型。


用戶還可以通過PowerDesigner的流體模型了解源模型和目標模型間的轉換關系。

1.4 自動代碼生成

??? 從上面可以看到，通過PowerDesigner，設計人員可以方便的完成應用程序的設計、數據庫設計以及O/R映射定義，那么編程人員通過編碼實現這些設計。對于O/R映射的實現，我們可以看到，不管使用什么技術，編碼人員都需要進行大量的工作。

??? 我們知道MDA的目標就是把現有的以代碼為中心的開發模式轉換成以模型為中心的開發模式，讓模型生成代碼，把開發人員從繁瑣的編碼工作中解放出來，從而專注于系統的架構和業務邏輯上。PowerDesigner通過其可擴展性提供了對于MDA的支持。在PowerDesigner中，所有的模型都是通過元模型進行描述的，可以通過GTL（通用模板語言）和VBScript來訪問這些元模型。那么我們可以通過元模型的信息來做他想要做的事，包括自動代碼生成。

??? PowerDesigner已經提供了對于主要持久化技術的支持，Hibernate、EJB 3、NHibernate、ADO.Net等，用戶可以直接使用這些擴展模型。除了O/R映射實現代碼，這些擴展模型還可以生成測試代碼，方便用戶對生成的代碼進行測試。用戶只需要添加相應的擴展模型，并且通過擴展屬性設置特定擴展模型所需的信息，就可以實現自動代碼生成。下圖是應用Hibernate擴展模型生成映射文件的預覽窗口。


用戶也可以對這些擴展模型進行定制或者開發他自己的擴展模型，以滿足自己的需要。關于如何擴展PowerDesigner，可以參閱PowerDesigner用戶文檔和高級使用手冊。

結論

我們可以看出，通過PowerDesigner的模型映射，設計人員可以很方便的定義O/R映射，不管是手工的方式還是通過自動模型轉換。O/R映射元數據同模型保存在一起，保證了一致性，方便的和模型同步，提高了可維護性。通過自動代碼生成，編碼人員不再需要進行繁瑣、重復性的勞動，提高了開發的生產率。

轉載于:https://blog.51cto.com/jawsy/197747

總結

以上是生活随笔為你收集整理的PowerDesigner中的对象与关系映射建模的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。