資料庫設計中使用設計模式

一、引言
現代的企業開發中，越來越多地引入了多層架構設計模式，即使是小型的企業資訊系統也逐漸向多層架構發展，以滿足系統的可伸縮性以及可維護性。目前企業開發的平臺占主導地位的是 J2EE 和 .NET 兩大平臺，本文並不是去對比兩大平臺的優缺點，以免引發宗教式的爭論，而是在兩大平臺的基礎上探討如何進行資料庫的設計，將設計模式引入到資料庫設計中，以期達到良好的、可管理、可伸縮的資料庫設計。

傳統的資料庫設計理論，更加關注的是資料庫設計正規化，這是資料庫設計必須要遵守的規則：

第一正規化（1NF）：在關係模式R中的每一個具體關係r中，如果每個屬性值都是不可再分的最小資料單位，則稱R是屬於第一正規化的關係。

第二正規化（2NF）：如果關係模式R（U，F）中的所有非主屬性都完全依賴於任意一個候選關鍵字，則稱 R是屬於第二正規化的。

第三正規化（3NF）：如果關係模式R（U，F）中的所有非主屬性對任何候選關鍵字都不存在傳遞信賴，則稱 R是屬於第三正規化的。

一般認為設計資料庫時能夠達到第三正規化即可，這也是大部分資料庫原理課程所要求的資料庫設計結果。但現代關聯式資料庫管理系統中，除了支 持資料庫中的資料查詢、更改、插入和刪除外，更有強大的企業級功能支援，像儲存過程、觸發器和分散式查詢處理，無疑，我們的資料庫設計如果只滿足幾個正規化 的話，充其量只是完成了資料的存取要求，而無法和企業程式良好的結合。在設計企業應用中，資料庫是企業應用中最重要的一層，是企業應用的資訊起點和終點。 如何將業務邏輯在資料庫系統設計中正確、良好的表達，不僅涉及到系統實現的不同方式，也涉及到企業應用的成功與否。

本文試圖探討在資料庫設計中如何應用設計模式理論，形成一種資料庫設計模式，以避免業務邏輯層對資料庫層的資訊耦合，達到業務邏輯在不同層之間的正確轉移與實施。



二、分散式多層應用中資料庫設計的疑問

現代的企業應用程式大多采用分散式多層應用模式。如下圖所示：




從上面的示意圖中可以看出，無論是微軟的 .NET 平臺還是 J2EE 平臺都表現出將業務邏輯單獨放置在業務邏輯層中的意圖，也即 .NET 平臺中的 Web Service，J2EE 平臺中的 Enterprise Java Bean。

J2EE 平臺發展較早，並且理論非常成熟，很多技術和架構都在 J2EE 中產生，然後才有相應的 .NET 移植與實現。在 J2EE 體系架構中，核心的是 Enterprise Java Bean 技術，而 Session Bean 更是成功的設計。在 J2EE 中，利用 Entity Bean進行了 O/R 對映的嘗試，但因為 Entity Bean 的設計複雜以及無法進行單元測試等缺點，在 J2EE 社群中頗多微詞，也導致了 Hibernate、JDO 等輕量級 O/R 框架的產生。而在微軟的 .NET 平臺中，也出現了 NHibernate 的移植框架，微軟本身也在進行 Object Spaces O/R框架的開發。

透過研究O/R 對映，讓程式設計師和設計者產生了這樣一個感覺：無論是 Entity Bean、還是 Hibernate 和 JDO，都強調 O/R 對映關係，讓程式設計師和設計者可以用物件導向的思維方式來考察系統，而不用關心資料如何在底層儲存，甚至我們只要在系統中設計好物件實體，然後利用 O/R 對映去自動實現到資料庫的對映即可，程式設計師不需要關心資料庫，不需要知道任何 SQL 的語法，只需要透過專門的 EJB-QL 或者 HQL 語言進行資料的處理即可，而無需在程式中書寫任何的設計資料庫存取的程式碼。這樣編寫的程式有利於移植，如果需要更改資料庫系統，僅僅重新改寫 EJB-QL 或者 HQL 語言既可。

雖然看起來很美，但這卻是一個美麗的謊言。

首先，在企業應用設計中，當選擇了一個關聯式資料庫系統後，在實施時企業將花費大量的資金購買資料庫系統使用許可，而且資料庫系統的實施、安裝、日常維護也需要專門的人員來完成，更換資料庫系統意味著企業的巨大損失，基本上不可能出現更換資料庫系統的情況。

其次，大型資料庫管理系統有著良好的設計和最佳化功能，而且不同的資料庫系統有著自身的特點，很多特性是獨有的，是不可移植的。採用 O/R 對映會損失資料庫系統所特有的強大的功能。

第三，無論在進行系統設計時如何最佳化效能，O/R 對映最終都要轉化為實際的資料庫連線，進行實際的資料庫操作，而這些任務是無法和資料庫系統內部的儲存過程、觸發器的效能相比較的，而且即使透過連線池，也會增加資料庫連線的負荷。

所以，良好的資料庫設計仍然是企業應用中非常重要的步驟。



三 在資料庫設計中應用 Façade 模式

當前系統設計中有大量的設計模式，Façade 設計模式更是深入人心。Façade模式描述為：“為子系統中的一套介面提供了一個統一的介面。Façade 定義了一個更高層次的介面，使子系統更容易使用。”在系統設計中，Façade 是應用最廣泛的設計模式，利用 Façade 模式的思想把構成子系統的一套業務物件“包裝”在Façade 介面中。這樣，Façade物件作為客戶端訪問業務物件的攔截器，遮蔽了業務物件。客戶端訪問Façade物件來代替訪問底層的業務物件，當一個客戶端需要呼叫多個業務物件的方法時，它只需要進行一次粗粒度的遠端方法呼叫，將請求送給Façade 物件, 再由Façade 物件透過本地方法呼叫，呼叫相應的業務物件，執行其方法。這樣就減輕了網路負載，提高了系統效能。並且當底層業務物件的方法改動時，只需要修改 Façade 物件，而客戶端可以保持不變。這就減少了客戶端和業務物件之間的耦合度，同時客戶端也不必管理事務的細節。如下圖所示：




由 Façade 設計模式我們可以看出，如果將資料庫系統認為是一個底層的業務系統，我們應該在設計資料庫系統時隱藏底層的細節，而將所有對資料庫進行的增、刪、改、查詢操作統一到一個 Façade 介面上來，這樣在系統設計的過程中，所有與資料庫系統打交道的業務元件無需關心底層的資料庫儲存方式，而是將底層的資料按照系統實體的方式展現出來，再透過 Façade 介面進行變換，將實際的實體提交給業務元件介面或者將實體持久化到真正的資料庫表當中。

比如，在設計學生選課管理系統中，底層的資料表可能包括課程表、學生表、選課表以及成績表，但對外表現出來的實體應該只有學生和課程兩 個實體。然後可以透過一個儲存過程暴露出來一個學生選課的功能，在業務元件中呼叫。同時應設計觸發器，當插入選課資訊到選課表的時候，在相應得成績表中插 入相應的記錄。而在業務元件端，僅僅看到底層資料庫系統暴露出來的一個功能，即使資料庫系統的設計發生變化，也不會影響業務元件的功能。

隨著 SQL Server 2005 的釋出，已經可以在 SQL Server 2005 中使用 .NET CLR 來進行資料庫的程式設計，這對資料業務邏輯的封裝提供了更好的支援。Oracle 已經支援 Java，並且也在進行 .NET CLR 的整合，IBM 的DB2 也有類似的功能。

採用Façade設計模式，能夠較好的隔離底層資料庫系統與業務元件之間的耦合，但物極必反，過度的使用儲存過程也可能帶來不必要的設計麻煩。在資料庫設計中，適當的暴露底層的檢視也是一種良好的設計風格。一個全面的、良好的設計才是系統成功的保證。[@more@]