介紹
Power Designer是能進行資料庫設計的強大的軟體，是一款開發人員常用的資料模組化工具。幾乎包括了資料庫模型設計的全過程。利用Power Designer可以制作資料流程圖、概念資料模型、實體資料模型，還可以為資料倉庫制作結構模型。
概念模型
概念資料模型是最終使用者對資料存儲的看法，反映了最終使用者綜合性的資訊需求，它以資料類的方式描述企業級的資料需求，資料類代表了在業務環境中自然聚內建的幾個主要類别資料。
概念資料模型的内容包括重要的實體及實體之間的關系。在概念資料模型中不包括實體的屬性，也不用定義實體的主鍵。這是概念資料模型和邏輯資料模型的主要差別。
概念資料模型的目标是統一業務概念，作為業務人員和技術人員之間溝通的橋梁，确定不同實體之間的最高層次的關系。在有些資料模型的設計過程中，概念資料模型是和邏輯資料模型合在一起進行設計的。
邏輯模型
邏輯資料模型反映的是系統分析設計人員對資料存儲的觀點，是對概念資料模型進一步的分解和細化。邏輯資料模型是根據業務規則确定的，關于業務對象、業務對象的資料項及業務對象之間關系的基本藍圖。
邏輯資料模型的内容包括所有的實體和關系，确定每個實體的屬性，定義每個實體的主鍵，指定實體的外鍵，需要進行範式化處理。
邏輯資料模型的目标是盡可能詳細的描述資料，但并不考慮資料在實體上如何來實作。
邏輯資料模組化不僅會影響資料庫設計的方向，還間接影響最終資料庫的性能和管理。如果在實作邏輯資料模型時投入得足夠多，那麼在實體資料模型設計時就可以有許多可供選擇的方法。
實體模型
實體資料模型，提供了系統初始設計所需要的基礎元素，以及相關元素之間的關系。即用于存儲結構和通路機制的更高層描述，描述資料是如何在計算機中存儲的，如何表達記錄結構、記錄順序和通路路徑等資訊。使用實體資料模型，可以在系統層實作資料庫。資料庫的實體設計階段必須在此基礎上進行詳細的背景設計，包括資料庫的存儲過程、操作、觸發、視圖和索引表等；
實體資料模型是在邏輯資料模型的基礎上，考慮各種具體的技術實作因素，進行資料庫體系結構設計，真正實作資料在資料庫中的存放。
實體資料模型的内容包括确定所有的表和列，定義外鍵用于确定表之間的關系，基于使用者的需求可能進行發範式化等内容。在實體實作上的考慮，可能會導緻實體資料模型和邏輯資料模型有較大的不同。 實體資料模型的目标是指定如何用資料庫模式來實作邏輯資料模型，以及真正的儲存資料。
1. 概念資料模型
1.1建立及設定
1.1.1 建立項目
1.1.2 建立概念資料模型
在項目的基礎上建一個概念資料模型：
修改模型的屬性資訊：
1.1.3 建立和修改模型圖
建立好了概念資料模型後，預設生成一張模型圖。我們在要在模型圖上做設計。點選或者點選前面的小圖示，會顯示模型圖。
修改模型圖的屬性：
建立一個模型圖：
1.1.4 建立實體
1.1.5 編輯實體和屬性
選中實體右擊
編輯屬性後：
1.1.6 設定實體的顯示
勾選實體顯示那些内容。設定後，實體顯示如下：
1.1.7 設定屬性的name、code可重複
powerdesinger 預設是不允許實體屬性（字段）的name和code重複。需要我們去修改配置。
設定字段能否重複使用：
設定生成邏輯模型或實體模型時，不要檢查重複實體屬性的name和code：
1.1.8 建立和使用domain（域）
概念：域是某個或某些屬性的取值範圍，定義域後可以被多個實體的屬性共享使用，域的定義在模型涉及中具有重要意義，使得不同實體中的屬性标準化更加容易。
Domain是對字段統一定義資料類型和長度等，多個字段添加這個domain，一旦變化隻需要修改domain即可。功能類似于java中的配置檔案，一旦修改了配置檔案，程式中所有引用都會變化。
建立一個domain:
建立後，在這裡顯示：
我們在設定實體的屬性（字段）的時候，在這裡選擇即可使用:
1.2 一對一雙向關聯關系
1.2.1 建立一對一關系
(1) 我們準備兩個實體。分别是使用者和護照，他們是一對一的關系。
(2) 建立一對一關系。實體之間的關系是使用主鍵來維護的。
1.2.2 編輯一對一關系
修改關系的名稱等：
設定關系的基本資訊：
建好後的效果：
1.2.3 生成邏輯模型
1.3 一對一單向關聯關系
1.3.1 單向和雙向
這個模型就是雙向關系。使用者和護照實體都有對方的引用（對方的主鍵）。
單向關系：我們從護照想知道使用者資訊，不想從使用者知道護照資訊。
1.3.2 示意圖利用已有的實體（強烈不推薦）
利用已有的實體，會導緻之前的關系和現在的關系混亂。不要這樣操作。
1.3.3 編輯一對一單向關系
主表和從表就是誰依賴誰，我依賴你，你是主表，我是從表。我依賴你，可以了解為，要先有你才有我。
1.3.4 更新邏輯模型
1.3.5 删除邏輯模型
糾錯。按照上面操作，我們發現生成的邏輯模型不是我們想要的。原因是我們兩個概念模型使用了相同的實體。工作中，我們兩個概念模型不會使用相同的實體，不會遇到這種情況。
删除邏輯模型：
1.3.6 複制實體（不推薦）
不要複制表和字段。複制品和原有的會關聯變化。
1.3.7 從概念模型删除實體
1.3.8 一對一單向和雙向邏輯模型
1.3.9 一對一關系的思考和總結
一對一關系，我們首先要弄清是單向關系還是雙向關系。
雙向關系，兩個實體表都要包含對方主鍵。
單向關系，我們要弄清，兩個實體的主從關系，從表要包含主表的主鍵，主表無需操作。
主表和從表如何定義？1. 看我們需求，一般主表不經常查詢從表，從表經常查詢主表。2. 看他們依賴關系，從表必須要有主表的存在才行。主表不需要從表的存在，也能獨立表達業務。3. 從表中有主表的主鍵。主表的主鍵是從表的外鍵。
一對一關系，我們還需要注意是一對一還是一對零。
這裡通過主鍵關聯，這裡的主鍵更像一個概念意義上的主鍵。我們可以把它了解為概念主鍵，而不是資料表主鍵。
1.4 一對多和多對一關聯關系
1.4.1 重用字段（不推薦）
1.4.2 資料類型擴充
1.4.3 準備員工表和部門表
1.4.4 建立一對多關系
1.4.5 一對多邏輯模型
1.5 多對多關聯關系
1.5.1 解決多對多圖示不能使用
PowerDesigner下面圖示都是灰色的，不能點選。
解決PowerDesigner的association按鈕不能使用的問題：
1.5.2 建立多對多關系
(1) 建立一個association
(2) 輕按兩下association或右擊--properties，編輯
(3) 建立關系
1.5.3 多對多的邏輯模型
注意：關聯表沒有自己的主鍵。他們還存在依賴關系。多對多就是兩個一對多。
1.5.4 多對多關聯實體包含其他屬性
我們先準備2個實體：
學生實體存儲每個學生的資訊，如：張三、李四、王五。
考試實體存儲考試資訊，如：數學考試、英語四級、計算機二級。
需求1：我們想知道每個學生每科考試的總成績。
解決思路：多對多的中間關聯表不僅要包含兩個實體的主鍵，還要包含其他屬性。多對多本質就是兩個一對多。我們建立一個中間表，不僅包含兩個實體的主鍵，還包含其他屬性，然後兩個實體和中間表建立兩個一對多關系，即可。
概念模型圖：
生成的邏輯模型圖：
1.6 依賴關系
1.6.1 依賴關系--聯合主鍵
需求：我們要求建一個答題卡實體，答題卡存儲每個學生每個考試每個題目的資訊。如：題目編号、題目得分。我們想知道每個學生每個考試每個題目的得分。
這個需求我們有兩個方案。
第一個方案，答題卡實體不建獨立主鍵，以學生ID、考試ID、題号作為聯合主鍵。
總結：沒勾選“dependent”，主表的主鍵會變成從表的外鍵。勾選“dependent”，主表的主鍵會變成從表中的主鍵。勾選“dependent”，主鍵能夠繼續傳遞下去，而關聯關系都是靠主鍵來實作的。
1.6.2 依賴關系--獨立主鍵
(1) 答題卡實體建獨立主鍵
(2) 取消答題卡和關聯表的依賴
(3) 最終的概念模型
(4) 最終的邏輯模型
總結：這部分内容，還是展現了上部分總結的内容。
其實這部分模型，不太優化，應該把答題卡和關聯表建立一個一對一的關系，我随便畫一下模型圖，沒有學習價值。
概念模型：
邏輯模型：
1.7 繼承關系
1.7.1 繼承關系的資料庫設計
這裡的繼承關系和java中的繼承是一個意思。這種關系我們在資料庫中該如何表達呢？
列舉一些應用場景：
1. 程式有很多異常類，這些異常類有共同屬性，也有各自的特性。
2. 一個物聯網系統，它有很多裝置種類，如：錄影機、顯示屏、傳感器。他們有一些裝置共同屬性，但是每種裝置還有各自的特性。
我們現在有個案例，有一個老師實體：他有name、age、學科。有一個學生實體，他有name、age、專業。如何設計？
第一種，老師和學生各自建資料表，資料表包含各自全部屬性，不建父級表。缺點：字段備援。
第二種，老師和學生都建在一張資料表，用字段區分實體。缺點：字段數量太多，資料為null的情況多。
第三種，如上圖所述。
總結：第三種更優化。如果業務比較簡單，第二種和第二種比較适合。如何選擇看具體情況。
1.7.2 繼承關系第一種設計
(1) 準備3個實體
(2) 建立繼承關系
(3) 編輯繼承關系。兩個繼承關系都要編輯
(4) 生成邏輯模型
1.7.3 繼承關系第二種設計
(1) 前面的步驟和上面一樣。隻有關系設定不同。
(2) 生成的實體模型
1.7.4 繼承關系第三種設計
(1) 前面的步驟和上上面一樣。隻有關系設定不同。
(2) 生成的邏輯模型
2. 實體資料模型（PDM）
2.1 生成實體資料模型
2.2 表與字段
2.3 實體模型中建立視圖
在實體資料模型中建立視圖，注意先切換到實體資料模型圖。
2.4 實體模型中建立索引
實體模型中建立索引：
2.5 實體模型中建立存儲過程
2.6 實體模型中建立觸發器
2.7 PDM生成SQL腳本檔案
老師在課程中還有用power designer連接配接資料庫，執行SQL語句。這個不實用，就不贅述了。我們一般在navicat中操作。
3. 項目實戰
3.1 建立實體和屬性
1. 分析需求中的實體。有如下實體：客戶、部門、員工、開發團隊、項目、項目的任務。
2. 确定實體屬性。實體和實體屬性如下：
3.2 部門、員工、開發團隊和一對多、多對多關系
一個部門有多個員工，一個員工隻屬于一個部門。
一個開發團隊有多個員工，一個員工屬于多個開發團隊。
設定部門和員工一對多關系：
建好的關系：
3.3 客戶、項目、項目任務和一對多、依賴關系
一個客戶有多個項目，一個項目隻屬于一個客戶。
一個項目有多個任務，一個任務隻屬于一個項目。任務可以依賴項目。
一個員工參與多個任務，一個任務屬于多個員工。
設定客戶和項目之間一對多關系：
設定項目和項目任務之間的一對多和依賴關系：
設定好他們之間的關系：
3.4 項目、項目任務、父表和繼承關系
他們之間繼承關系設定：
設定好的繼承關系：
3.5 員工、項目任務、員工參與任務和多對多包含其他屬性、依賴關系
員工和員工參與任務之間依賴和多對多關系：
任務和員工參與任務之間依賴和多對多關系：
建好的關系：
3.6 建好的概念模型、邏輯模型、實體模型
概念模型：
邏輯模型：
實體模型: