來自 http://www.uml.org.cn/sjjm/sjjm05.htm
|
一、概述
很可能你現在正在規划一個數據庫驅動的網站；而且幾乎可以肯定的是，你一定已經瀏覽過數據庫驅動的網站。過去，一些網站依賴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的界面 轉向數據建模工具的主要挑戰在於：
一些入門級數據建模工具（參見本文后面的參考資源）只有少量的高級特性。這有好處，但也有弊端——它們很容易學習使用，但當你積累了更多的經驗時，它們可能不再滿足你日益增長的需要。然而，升級工具或更換工具一般不存在大的問題，特別是當新的工具能夠對現有數據模式進行精確、完整的反向工程時，升級或更換工具的過程尤其簡單。 三、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 關系 如果我們只定義數據模式中的表，數據建模工具就不那么重要了。各個表之間的關系、依賴情況往往很復雜，有一個管理和顯示這些關系的工具將帶來很大的幫助。對於一個給定的關系，必須收集的重要信息包括：
大多數建模工具通過在兩個或者更多表之間畫出連線的方式定義關系。默認情況下，關系往往被定義成為一對多關系，而且它對於關系中的任何一方都是可選的。要修改關系，你必須打開關系的屬性窗口，更新實體關系的特征信息。圖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，看看自己是否可以信任和認可建模工具對數據模型的解釋。一段時間之后，你就會熟悉建模工具對各種關系和表細節的解釋。 【結束語】數據建模是一種很好的軟件工程實踐。它能夠幫助你在正式編寫程序代碼之前規划數據需求。在維護和改進系統的數據布局的過程中，數據建模同樣很有用。一些工具能夠讓這個過程變得非常簡單，能夠在你管理和設計數據庫系統的時候帶來極大的幫助。然而，根據你所需功能的不同，建模工具的價格也有着極大的差異。在不出現預算赤字的情況下，輕松掌握和運用數據建模技術的最好方法是，從小型的工具開始，然后逐漸深入和提高。 六、參考和資源 ■ 工具
|
