1．Powerdesigner使用建議
1.1業務規則的使用(Business Rule)
對于一些業務邏輯可能出現在多個數據表中，建議封裝成Business Rule，這樣便于業務邏輯的重新使用，也便于業務邏輯的維護。
為了便于維護業務邏輯，可以考慮將Business Rule和Domains結合起來使用。將業務Business Rule應用到Domains上，然后再把Domains應用到數據表的字段上。
例如：在拆遷項目中，拆遷業務部分，管理參數業務部分，房源業務部分，拆遷合同部分的數據表中都有樓層這個字段，因此先一個Business Rule，然后定義一個Domain，這樣相應的數據表的字段就可以使用這個Domain了。
1.2.自定義數據類型(Domains)的使用
oralce提供了一些內置的數據類型，但是用戶也可以根據業務的需要，定義自定義的數據類型。
在自定義數據類型里面包裝業務邏輯。
正如上面的房屋樓層，我們可以定義一個獨立的數據類型(Domain)維護，然后在相關數據表的
字段上使用這個自定義數據類型。
一般在定義自己的數據類型時候，可以在oracle基本類型上定義，然后可以加上一些standard check或者Business Rules。
比如：在拆遷項目中，面積類別這個字段在很多數據表都出現了，可以作為一個單獨的數據類型類維護，定義一個” 面積類別” Domains（包含的種類有：0 --- 廳房面積,1 --- 使用面積,2 --- 單元面積,,3 --- 總建筑面積,4 --- 分攤面積）。而且由于Powerdesigner的提供關聯作用,這樣便于當業務邏輯發生了變動，能夠很快查詢出那些對象受到影響。
1.3序列號(Sequence)的使用
在powersigner的模型里面定義一堆了Sequence，接下來的是要把他們和數據表的相關字段關聯起來，特別是那些用于多個數據表字段的Sequence。
一個數據表原則上只允許一個字段使用Sequence，并且在數據表的字段使用Sequence前，應該把該Sequence添加到數據表的Extended Dependencies中。
如果一個數據表有2個字段或者更多字段使用了Sequence，那模型檢查時會給出提示信息。
使用的規則一般是只能應用到數據表的主鍵字段上。
主鍵字段建議是 數據表+“ID“或者 “編號“構成。
例如：“房屋整合面積“ 數據表，那它的主鍵字段=房屋整合面積編號，對應的Sequence為
SEQ_房屋整合面積。其它數據表可能也使用到了這個Sequence，那也需要在使用前設置引用關系。
（在數據表的Extended Dependencies 上設置引用關系）
1.4 Oracle Package的使用
在Oracle Package里面可以定一些procedure ，但是Oracle包引用的數據庫對象到底有哪些呢，這些信息建議手動維護起來。特別是Oracle Package使用了哪些數據表，視圖，以及Oracle Packag等信息建議維護起來。
1.5包的使用
PowerDesigner的包相當于文件夾。用戶可以把它當作一個維護業務邏輯的容器。PowerDesigner包一般建議按照業務模塊來建立。如果模塊需要細分，可以考慮建立PowerDesigner子包來完成。
建議容器里保存的是模型對象的快捷方式。原始信息建議不要放到容器里面。因為在要是把這些信息放到容器里，在PowerDesigner的模型合并或者逆向工程時，這種方式的信息可能得不到維護。
PowerDesigner的包下面的PhysicalDiagram，建議采用象ERWin的Subject Area那樣，按照某個主題或者業務角度的方式來組織PhysicalDiagram包含的對象，使得每個PhysicalDiagram的功能明確。
1.6.視圖(View)的使用
視圖一般是數據表或者視圖上建立得來的（當然也可能引用了某個存儲過程）。一般視圖的模型中應該維護視圖的數據來源的引用信息。
在我們現在的項目中數據庫模型沒有對視圖進行維護，為此需要在建立視圖的Powerdesigner
模型。
我在Powerdesigner9.5環境下通過逆向工程不能夠獲得視圖(view)的腳本，通過修改相關配
置參數，還是不能夠獲得腳本。
可以通過以下2方法獲得視圖(view)的腳本。
方法1：使用powerdesigner8.0的逆向工程獲得視圖的腳本，然后在Powerdesigner9.5中把視
圖的模型合并進來，這樣就可以對視圖進行維護了。
方法2：使用Erwin逆向工程獲得視圖的Erwin模型，然后再把模型保存為ERX類型的文件
在Powerdesigner9.5中導入該文件，然后進行合并模型就可以了
PowerDesigner的視圖模型處理能力比較差，不能構維護視圖的依賴關系(也就是建立視圖對數據源的依賴關系)，這一點明顯不如ERWin。
1.7.同義詞（synonym）的使用
同義詞相當于給數據庫對象一個別名，提供了位置和數據的獨立性。在跨數據庫用戶訪問對象時，可以考慮建立同義詞結合權限分配，簡化數據庫對象的訪問。
1.8．數據表的使用
數據表的注釋語句的更新。
業務背景：
在我們的項目中，Erwin模型中的數據表的注釋語句沒有同步到Oracle數據庫?，F在需要更數據庫中的數據表的注釋語句。
可能可以采取的實現方法：
方法1：Erwin直接正向工程，但是從Erwin直接正向工程由于注釋語句中有回車符號，更新會失敗。
方法2：如果把Erwin模型轉換成為powerdesigner模型再更新數據表的注釋語句，這樣就可以避免回車符號的問題，按正常情況是可以行得通的，但是由于Erwin模型中的邏輯模型和物理模型不一致，甚至它們出現的順序不一致，這樣獲得powerdesigner模型就不正確了，生成的修改數據庫的腳本也就不正確了。
實際采用的方法：
把Erwin模型轉換成powerdesigner模型在Erwin中保存為ERX類型，然后在PowerDesigner導入模型），并且把文件保存為PDM類型（XML格式），刪除模型中的視圖，domains,Business Rule,reference等信息，只留下相關數據表本身的信息，然后把模型文件的后綴修改XML，并且采用XMLSPY生成這個文件的DTD文件，再采用Java編寫了一個基于SAX的程序去解析XML文件，把各個數據表以及字段的注釋語句提取出來，然后更新數據庫中數據表和字段的注釋語句，這樣就可以了。
1.9．ERWin升級到PowerDesigner的相關問題
1.9.1 Domain的升級
從Erwin3.52升級到PowerDesigner9.5時，Domain信息和數據表的關聯關系會丟失，需要手動重新添加2者間的關系。當然可以通過編程修改PowerDesigner的模型文件，添加2者之間的關聯關系。一般的PowerDesigner模型文件較大，只要有個幾十張數據表肯定模型文件有1MB，建議采用SAX的方式添加信息。
注意：添加數據表字段使用的Domain時候，需要設置數據表對Domain的引用關系（也就是Extended Dependencies）。
1.9.2 Business Rule的升級
從Erwin3.52升級到Powerdesigner9.5，Business Rule的表達式(腳本)需要修改的，把所有的
Business Rule的表達式中的@column 修改成%COLUMN%
具體實現的方式，可以直接在Powerdesigner9.5里面修改；或者把模型保存為XML格式（文件類為 .pdm）,通過UltraEdit或者XMLSpy等工具來修改，一個查找替換舊搞定了。當然的注意
只能修改<c:BusinessRules> </c:BusinessRules>里面的內容，否則會修改一些不應該修改的地方。
同Domain一樣，從Erwin3.52升級到PowerDesigner9.5時，Business信息和數據表的關聯關系也會丟失。如果Business Rule 不是太多建議手動修改模型文件。
1.9.3.Sequence的升級
.Sequence的升級建議采用和Domain的方式，編程實現維護。
1.9.4.物理圖的升級
從Erwin3.52升級到Powerdesigner9.5，物理圖同樣能夠倒入Powerdesigner9.5中，但是Powerdesigner9.5的升級功能有些問題：在生成的物理圖中數據表的信息有些問題：物理圖中的數據表的字段顯示不完全，而且很多時候數據表字段的類型都不能顯示完全。我使用java采用sax的方式把升級后的模型文件進行解析，然后重新生成物理圖中數據表的位置信息（數據表的2個坐標：左上角坐標，右下角坐標）；另外根據業務需要可以生成自己的Powerdesigner9.5包并且可以創建物理圖，把數據表添加到物理圖上。
1.9.5.其他說明
從Erwin3.52升級到Powerdesigner9.5，我寫了一些java程序解決了相關問題，如果哪位同行遇到相似的問題
可以交流一下。
2．關于powerdesigner中的數據結構的變更管理
目前拆遷項目中數據結構的有些失控，在結合powerdesigner包的概念的基礎山上提出如下一些建議。
2.1．數據結構按照業務模塊進行維護
模型中所有的數據結構都在一個文件中，而且在頂層文件夾中各個業務模塊維護的是數據結構的快捷方式。
2.2．數據結構按照其生命周期進行分類管理。
在各個業務模塊的包下面建立如下的包：
2.2.1臨時測試數據結構：
是一些當前業務模塊測試時使用的數據結構，可以隨時被刪除
2.2.2討論中數據結構：
是數據結構處于討論中，還沒有確定下來。
2.2.3需要更新的數據結構：
是數據結構已經確定下來，但是還沒有更新到數據庫中。
2.2.4正式數據結構：
在數據庫中被業務正常使用的數據結構
2.2.5作廢中的數據結構：
在數據庫中以前被業務正常使用，現在已經不再使用，但是還沒有進行
被作廢的數據表中數據的遷移，沒有完全作廢的數據結構。如果要把這些數據結構進行作廢，
需要先進行數據遷移，以及其他相關處理。
2.2.6已經作廢的數據結構：
在數據庫已經不再被使用的業務數據表，相關的數據遷移已經完成，但是數據表還沒有刪除，
相關的文檔沒有更新。