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等工具來修改，一個查找替換舊搞定了。當然的注意

只能修改里面的內容，否則會修改一些不應該修改的地方。

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

分享到：

2010-07-18 11:20

瀏覽 1135

評論

總結

以上是生活随笔為你收集整理的孔雀东南飞用mysql存储_PowerDesigner使用建议(完整版) 用实体关系图进行数据库建模...的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。