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資料庫。現在需要更資料庫中的資料表的注釋語句。
可能可以采取的實作方法：
方法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已經廢棄的資料結構：
在資料庫已經不再被使用的業務資料表，相關的資料遷移已經完成，但是資料表還沒有删除，相關的文檔沒有更新。
用實體關系圖進行資料庫模組化 一、概述 很可能你現在正在規劃一個資料庫驅動的網站；而且幾乎可以肯定的是，你一定已經浏覽過資料庫驅動的網站。過去，一些網站依賴CGI腳本和文本檔案存儲實作資料持久化，但現在我們能夠通路大量不同的關系型、對象-關系型、面向對象型資料庫。 對于Web應用來說，關系資料庫是一種強大的支援工具，這得感謝它們的高可用性、性能，而且相對來說，關系資料庫比較容易使用。要找出一個功能完善、源代碼開放、能夠在多種平台上運作的資料庫系統并不困難。你可以用Perl、Java、PHP以及其他伺服器端腳本語言把關系資料庫和Web網站連結到一起。 随着網站規模的發展，它對資料庫——通常是關系資料庫——的依賴程度也日益增加。大量頁面和服務需要向資料庫表寫入資訊，或者從資料庫提取資訊。對于大多數網站，資料庫表很快成為網站體系結構中的關鍵部分，成為網站運作的生命中樞。為了友善和輕松地管理大容量資料，使用者帳戶、新聞動态、内容、統計資料都可以儲存到關系資料庫管理系統（Relational Database Management System，RDBMS）。 用圖（Diagram）管理資料模型具有高效、友善的優點。對于RDBMS，描述資料模型的圖通常稱為實體關系圖（Entity Relationship Diagram，ERD）。用ERD描述資料模型能夠幫助你預先精确定義資料需求，使你能夠對以後的改動作出有效的規劃，能夠随着網站的發展友善地改進規劃。 本文将介紹ERD模組化工具和概念。文章提供了一些圖的執行個體，但它們的目的不是提供精确的或者是全面的資料設計範例。它們的目的是以兩個模組化工具為例，介紹資料模組化符号。在不同的工具之間，圖的符号有着重大的差别，但它們的基本概念一樣。本文的圖例從PowerDesigner和Visio 2000 Professional的試用版得到，你可以從本文末尾找到這些工具和其他類似産品的連結。 二、是否使用模組化工具？ 許多規模較小的網站用ASCII形式的SQL（Structured Query Language）腳本檔案進行資料模組化。當開發小組人員較少，或者最理想的情況下僅由一個人構成時，這種方法最有效。然而，資料模型将很快發展成為一個複雜的結構——在這種情況下，CASE（Computer Aided Software Engineering，計算機輔助軟體設計）工具、有關所有資料資訊的圖、集中式知識庫能夠極大地幫助你管理Web網站的資料層。 2.1 何時使用SQL？ 即使當你準備用SQL直接管理資料模式（實體資料庫）時，圖也能有效地幫助你了解和改進系統。然而，如果你的預算或者時間非常有限，采用複雜的新式模組化工具可能得不償失。相反，在這種情況下，你應該使用一個簡單的圖形工具把資料模式的基本情況記錄下來，然後逐漸轉換到複雜的資料模組化工具。 如果你正在設計的資料庫類型不常見（或者是非标準的），避免使用某些複雜CASE工具可能是明智的，因為這些工具的“反向工程”能力和某些自動功能可能無法在你的環境下發揮作用。這裡所謂的自動功能，是指模組化工具根據輸入模型的圖形和屬性資訊，自動為目标資料庫生成合适SQL指令的能力。反向工程是這樣一種能力，模組化工具根據已經部署的實體資料模式，從現有的表提取出實體和關系資訊。 2.2 轉入模組化工具 從簡單繪圖工具轉換到資料模組化工具并不是一個很複雜的過程。大多數資料模組化工具的工作方式就象是一個标準的繪圖工具，參見圖1a和圖1b，這是兩個資料模組化工具的界面執行個體。你可以在這裡建立和排清單，定義關系，以及指定其它資訊（列的類型、長度，鍵等）。
圖1a：PowerDesigner的界面
圖1b：Visio的界面
轉向資料模組化工具的主要挑戰在于：
- 學習使用模組化符号。
- 在不丢失任何關鍵資訊的前提下，用資料模組化工具描述現有資料模型。
- 尋找一個對你的資料庫提供全面支援的工具，例如在生成SQL、從現有資料模式通過反向工程建立資料模型時。
一些入門級資料模組化工具（參見本文後面的參考資源）隻有少量的進階特性。這有好處，但也有弊端——它們很容易學習使用，但當你積累了更多的經驗時，它們可能不再滿足你日益增長的需要。然而，更新工具或更換工具一般不存在大的問題，特别是當新的工具能夠對現有資料模式進行精确、完整的反向工程時，更新或更換工具的過程尤其簡單。 三、ERD模組化符号 本文使用Martin的Information Engineering符号。PowerDesigner采用的就是這種符号， Oracle的Designer産品所使用的符号也和它很相似。你可以在 AIS Modeling Summary檢視各種ERD符号的說明。基本的ERD繪圖規範很直覺易懂。你可以定義實體（表），描述各個實體之間的關系。在填寫表和關系的細節資訊時，每一種工具的做法都有所不同；但就我所遇到的工具來看，基本概念在大多數軟體包之間是相通的。接下來的内容将介紹你必須了解的主要圖形元素和設定方法。 3.1 表 所有構造合理的資料模組化工具都允許為表指定豐富的關聯資訊。這些資訊包括（但不局限于）：
- 表的描述、注解，以及實體（表）的标題。
- 列，列的類型、長度、預設值和強制條件。
- 主鍵，索引，唯一性限制。
要指定這些資訊，一般你需要進入表的屬性視窗，如圖2a和圖2b所示。
| |
2a：PowerDesigner中表的屬性視窗
| |
圖2b：Visio中表的屬性視窗 一旦輸入了新表的屬性資訊，圖将被更新，顯示出你所提供的新的或更改後的表資訊。下面的圖形顯示了一個表的執行個體，這個表的屬性資訊見圖2a和圖2b。在圖2a和圖2b中，許多列被定義成了（m）andatory（強制的）、（p）rimary（主鍵）和（d）isplayed（被顯示的）列。下面的圖顯示了為該表輸入的部分屬性資訊。
| |
圖3a：PowerDesigner的表
| |
圖3b：Visio的表 在圖3a中可以看到一些非标準的資料類型，如PHONENUMBER和PK。許多資料模組化工具允許定義域或定制資料類型，它們可供一個以上的列使用。域不僅代表着資料類型——通常，它們還包含檢查限制、預設值、值清單等資訊。如果你想要更新一個域（例如定義一種新的電話号碼格式），所有該模型中引用該域的列都将自動更新。 3.2 關系 如果我們隻定義資料模式中的表，資料模組化工具就不那麼重要了。各個表之間的關系、依賴情況往往很複雜，有一個管理和顯示這些關系的工具将帶來很大的幫助。對于一個給定的關系，必須收集的重要資訊包括：
- 父表和子表。
- 兩個表之間的強制關系。例如，父表可能有一個子表，但子表必須有一個父表。
- 關系基數（Cardinality）。即，一個父表可以有零個或者多個子表，但一個子表有且隻能有一個父表。
- 關于關系的注釋、意見和角色說明。
大多數模組化工具通過在兩個或者更多表之間畫出連線的方式定義關系。預設情況下，關系往往被定義成為一對多關系，而且它對于關系中的任何一方都是可選的。要修改關系，你必須打開關系的屬性視窗，更新實體關系的特征資訊。圖4a和圖4b顯示了兩個不同的工具允許為關系定義的部分屬性：
| |
圖4a：PowerDesigner的關系屬性設定界面
| |
圖4b：Visio的關系屬性設定界面 該圖顯示了一個一對多關系——一個典型的父-子關聯關系。部門（Branch）和雇員（Emplyee）的關系是強制的。它意味着一個部門必須至少有一個雇員（1-N強制關系）；另一方面，它意味着一個雇員必須屬于且隻能屬于一個部門（1-1強制關系）。圖5a和圖5b反映了修改後的關系。
| |
圖5a：PowerDesigner中兩個表之間的關系
| |
圖5b：Visio中兩個表之間的關系 這個圖顯示了如何把資訊轉換成符号。強制的關系由一條實心垂直線（而不是橢圓）表示。某些工具用虛線表示可選的關系。關系中屬于“多”的這一邊用一個類似鳥爪的圖形表示，關系的基數在靠近它所描述的那一端顯示。 你可能已經注意到，Employee表沒有定義外鍵列。這個圖仍舊處于“概念設計”階段——此後，從概念圖到實體資料模型之間的轉換是必不可少的。大多數工具區分概念和實體資料模型——概念資料模型描述資訊的需求，但不關注細節問題，例如索引和強制性的引用完整性。 有些時候，你可能要定義自我引用的表。自我引用的表一般用來描述層次型關系。如下面的圖形所示，大多數資料模組化工具能夠處理這類關系。注意在這個例子中，雇員可以有零個或者一個上級——它使你能夠處理一些特殊的情況，比如總統沒有直接的上級。
| |
圖6a：PowerDesigner中自我引用的表
| |
圖6b：Visio中自我引用的表 四、圖的規劃 定義表和關系隻是挑戰的一部分，圖的清楚明白同樣很重要。雖然一些工具提供自動布局能力，我還沒有看到過一個完善的實作。相反，你的目标應該是遵從“孔雀東南飛”這一規則（這裡的“孔雀”是關系中代表“多”這一方的符号，它是連接配接到表的三條分叉線，象個鳥爪）。換句話說，子表應該位于父表的右方和下方。這種安排使得從邏輯上組織和了解資料模型更加友善。最重要、最進階别的表應該出現在左上角，讓級别較低的表出現在頁面的右下角。為了清楚起見，減少圖中交叉線的數量也是很重要的。正如Eberhardt Rechtin在 The Art of Systems Architecting中強調的，“一個好的設計往往看起來很舒服”。如果無論怎樣安排，你的資料模型看起來都很混亂，那麼，它可能正在告訴你資料模型本身有一些值得注意的問題。
| |
圖7a：完整的ER圖（PowerDesigner）
圖7b：完整的ER圖（Visio）
五、從圖到資料庫 依賴于你所選擇的用來建立資料模型的軟體包，模組化工具可能會根據模型生成SQL指令或直接修改資料庫模式。這種功能帶來了極大的便利；和使用ASCII格式的SQL腳本相比，這種方式有着許多優點。一些模組化工具的功能适合于大量的資料庫類型，例如PostgreSQL、MySQL、 Oracle、DB2，等等。對于簡單的資料庫修改，改動操作可以從模組化工具通過ODBC直接完成。資料庫改動還允許以增量方式進行（例如，ALTER指令或建立指令，以及對特定表的更新指令）。當你第一次使用模組化工具時，你可以檢視模組化工具生成的SQL，看看自己是否可以信任和認可模組化工具對資料模型的解釋。一段時間之後，你就會熟悉模組化工具對各種關系和表細節的解釋。 【結束語】資料模組化是一種很好的軟體工程實踐。它能夠幫助你在正式編寫程式代碼之前規劃資料需求。在維護和改進系統的資料布局的過程中，資料模組化同樣很有用。一些工具能夠讓這個過程變得非常簡單，能夠在你管理和設計資料庫系統的時候帶來極大的幫助。然而，根據你所需功能的不同，模組化工具的價格也有着極大的差異。在不出現預算赤字的情況下，輕松掌握和運用資料模組化技術的最好方法是，從小型的工具開始，然後逐漸深入和提高。 六、參考和資源 ■ 工具
- Sybase PowerDesigner - 一個高端資料模組化工具。你可以下載下傳一個45天試用版。
- ERWin - 一個高端資料模組化工具。可下載下傳試用版。
- Rational Rose Enterprise - 一個高端UML工具，恰如其分的資料庫模組化支援。可下載下傳試用版。
- Visio Professional - 一個價格低廉的繪圖工具，可用來生成資料模型、UML圖等。企業版還支援針對各種資料庫的雙向工程能力。你可以訂購60天試用版的CD。
- Dezign - 一個價格極其低廉的ERD模組化工具。你可以下載下傳一個有限制的試用版本。
- ERD Tool List - 一個關于各種資料庫和UML模組化工具的連結和資源的清單。