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建模工具的鏈接和資源的清單。