PowerDesigner是一款非常優秀的數據庫建模工具，熟練的使用該工具進行數據庫建模，對軟件系統的分析和設計有很大的幫助。
PowerDesigner中有幾種模型可以創建，不過最常見的是概念模型CDM（Conceptual Data Model）和物理模型PDM(Physical Data Model)。畢竟PowerDesigner在數據庫建模方面有很強大的功能。
概念模型不針對任何具體的數據庫語法，而以一種抽象的數據庫爲模型進行設計，物理模型則通常需要指定某一種具體的數據庫，在物理模型的設計中，數據庫語法將根據該具體的數據庫進行設計和定義。當然這帶來的一個不好的地方是，如果你想你的數據庫設計支持多種不同種類的數據庫時，不方便。所以通常情況下你應該優先考慮概念模型進行數據庫建模設計。而PowerDesigner支持將概念模型轉換爲不同的物理模型。所以只要我們在概念模型中把相關的設計做好，則剩下的事情就交給PowerDesigner來幫你解決，當然因爲概念模型轉換爲物理模型時，因物理模型中使用的數據庫類型不一致，所以在概念模型中定義的數據類型在物理模型中會有所改變，關係也一樣會有所改變，不過這個我們也不用去擔心，因爲PowerDesigner仍會幫我們做好，只是需要注意的是二者在處理上有些區別，所以在使用概念模型時，需要考慮好實際的物理模型的表現情況。
所以在這裏，我也只講解關於概念模型的使用方面，當然其中會涉及到如何轉換爲物理模型以及關於物理模型中與數據庫進行實際的關聯的方法。我的使用版本是PD12，且使用的是英文版，網上似乎有中文補丁，但是我建議不要使用中文的，因爲使用英文版能提高你對英文的敏感程度，畢竟做軟件這一行，我覺得很多時候你所面對的問題，中文網站是無法提供的，你不得不去英文網站中尋找，請對應該版本。
下面說說具體在使用PowerDesigner時需要我們留意的地方：
1.建議所有數據表中應該含有一個主鍵ID，這個ID沒有特別的意義，只是用來唯一區別於每一條記錄的，且它也應該只能有這種作用，不應該含有其他作用。雖然在有些表中，表中的某一字段我們能保證其是唯一的，但是我認爲還是應該加上這樣一個主鍵ID。這樣做的好處是可以使我們在做表與表之間的關係時，比較明顯易懂（在做數據庫系統的設計中，單獨的表容易處理，而難點在表與表的關係處理上）。這個ID應該設爲這個表的主鍵，且該字段名可以命名爲：“表名_ID”這樣的名字，這樣在做關係時，是非常明顯的區別於不同的表的主鍵，另一方面這樣做的好處是在用PD從概念模型轉化爲物理模型時，一些關聯關係之間命名產生衝突（如果你將所有表的主鍵命名相同的話）。當然，你的表中可以存在多個主鍵的，但仍建議以表名加上該字段名的方式進行命名，如一個表dept中的用戶ID也是一個主鍵，則其命名規則爲dept_UserId命名之。另外再說一點，這個與PD無關，就是在做數據庫表設計時，主鍵建議都採用同一種數據類型和長度，這樣有好處。
2.每個表的主鍵的存在會在表（實體）屬性的Identifiers中產生對應的記錄，該記錄會與表的主鍵進行關聯，但我們需要改變一下該記錄的默認Name和Code，建議以表名加字段名加_PK命名之。比如表名爲dept，則該值中name與Code值爲dept_ID_PK，從這個意思上可以看出來，該PK指的是dept表中的ID字段爲主鍵。當然如果一個表中有多個主鍵，仍可以按上述方式進行命名，這樣做的好處主要體現在物理模型中，如果你需要改變表與表之間的關係（表與表之間的關係在物理模型中的通常體現是本表是否擁有關係表中的某一主鍵）的時候，就很容易根據該Identifiers中的變量名來進行更換了，意思明瞭。而如果用默認的，則看不出意思來，容易出錯。
3.兩個實體之間存在關係時，在CDM中，是不需要在實體的表中創建單獨的字段來存儲對方的主鍵的。在概念模型轉化爲物理模型時，PowerDesigner會自動添加對應的對方的主鍵字段名作爲本表中的外鍵字段。這也是在前面的第一條中，爲何在實體的主鍵上建議命名方式爲表名加字段名的原因。
4.繼承關係中，在CDM轉化爲PDM時，子表和父表都會生成對應的表，且父表中的所有字段都會在子表中存在，且你表的主鍵會同時成爲子表的主鍵之一。個人覺得實體之間的繼承關係目前在數據庫設計上的使用意義不大，而PD在做這樣的關係，主要是出於基於面向對象方面的因素的考慮。建議少用或者不使用該關係。
5.Association（注意不是Association Link）主要用於描述兩個及以上的實體間關聯關係的。和relationship最大的區別在於Association會單獨生成一張表，且會存儲相關實體的所有主鍵，從某種角度來說，它更（象）是一個關聯關係表。所以我們也可以通過relationship來實現，只需要新添加一個實體來進行多個實體之間的關聯即可。Association Link是用來進行Association與其他實體Entity之間的關聯的，類似於RelationShip的功能，只是這個用於Association與Entity之間的聯繫，而RelationShip應用於Entity之間。
6.從CDM轉化爲PDM很簡單，在tools中，選擇Generate physical Data Model…，選擇你需要轉化的數據庫類型即可。此時PD會將對應的關係以及數據類型轉化爲特定的物理模型中使用的數據庫類型，建議你改變一下你轉換的物理模型的名字，不要用默認的。
7.當我們添加或者修改字體中的字段屬性時，默認情況下name與code是同步的，也就是說修改name的時候，code也跟着變化，這個令人很煩，可以通過下面的步驟將其去掉：Tools->General Options->Dialog->Name to Code Mirroring 。將Name to Code Mirroring默認的選中去掉，使其不選中，即可。
8.在生成某一具體的物理模型下對應的數據庫腳本時，我們可以插入自己的數據庫腳本，這樣可以一併生成，這通常在初始化數據庫和加入較詳細的註釋時很有用。這個操作只能在物理模型中進行，因爲概念模型不針對某一具體數據庫，而物理模型中加入腳本是針對具體數據庫進行的。添加自己的腳本的方法是：雙擊選中物理模型中的你需要添加自已腳本的表，在左下角中點擊more>>，選中其中的Script，然後在裏面的Begin和End中就可以輸入你要加入的腳本了。
9.當所有的表設計好之後，通過CDM轉化爲PDM之後，若要生成腳本文件，則在物理模型中，選擇DataBase->Generate DataBase…在File name中選擇你所要保存的sql腳本文件名。確定之後，就可以生成對應的腳本文件了，包括第8點中提到你自已添加的腳本也是可以同時生成在腳本文件中的。你可以在preview屬性框中，可以在查看當前所有表的腳本內容。
10．生成報表很簡單，只需要在物理模型中（實際有意義的是在物理模型中生成報表，因爲你需要生成的數據字段類型和關係與具體的數據庫類型有關）。選中左邊工程欄中的物理模型，右鍵點擊該物理模型，然後選擇new，再選中report即可，此時就可以在工程欄中新建一個包，裏面即含有report項。在生成report中，建議report template中採用none，即不使用任何模板，因爲我們需要自行定義模板的顯示內容。
具體到上面的顯示，生成過程中右鍵點擊上面的物理模型，在彈出來的對話框中選擇new，然後再選擇report即可，這樣就會生成reports包，在裏面有一個report1的報表。點擊Report1報表，因爲我們之前是不選擇任何模板，所以顯示的樣子如下：
左邊則表示可以顯示的項，而右邊則是你要生成的報表的項，你可以通過雙擊左邊的某些選項，就可以把這些選項添加到右邊，這樣就可以在報表中生成出來，通常你應該將左邊的Table下的List of Table Columns加入至右邊。然後在右邊的你加入的List of Table Columns中右鍵選擇該選項，選擇Layout…，然後在彈出來的對話框中選擇你要顯示的內容，默認情況下只顯示了兩個，就是name和code，你可以將Data type以及Primary以及Foreign,以及Length也可以加上，再調整一下距離就可以了。要在報表顯示的情況下，你可以點擊在上面的面板，生成html文件或者rtf文件。實際情況中，可能顯示doc更好，你可以在生成的rtf中文件中另存爲doc的方式，就可以保存爲doc了。在實際的使用中，你要生成的報表到底需要哪些內容，得根據實際的需求而定，這個報表的作用通常是可以指導開發人員在上面進行進一步的設計開發用的。爲了滿足實際的顯示內容的需求，你可以不斷的進行可顯示內容的嘗試，直到滿足你的需求爲止。
在使用PD的過程中，如果你有時不是很把握CDM轉化成PDM在有些屬性的設置上的改變，可以先做一個簡單的CDM表及關係，然後轉化爲PDM看一下實際的表現，不要在CDM所有的表都建立好了之後，再來看，那樣的話，如果出錯，修改是非常麻煩的。這是我的實際使用時經常用到的方法。尤其是在做CDM的表關係時，有些屬性的修改，選擇等在PDM上到底是什麼表現，我通常就是在CDM中做一個簡單的表和關係，如部門員工表以及關係，然後再轉換到PDM中，看看是否是我需要的，我覺得這個方法很有用，後面我會詳細說明CDM中的實體對象之間的關係選項對PDM的形成表現進行說明，我也是通過這種方法來確定的。