物件導向的關聯式資料庫設計(轉)

物件導向的關聯式資料庫設計(轉)[@more@]

　　北京市公路局系統使用的是Oracle 7.3關聯式資料庫,即RDBMS。由於我們對整個工程用了物件導向的軟體工程(OOSE)開發方法學,所以資料庫設計也是物件導向的。

　　一、概念的區分

　　有些人把物件導向的資料庫設計(即資料庫模式)思想與物件導向資料庫管理系統(OODBMS)理論混為一談。其實前者是資料庫使用者定義資料庫模式的思路,後者是資料庫管理程式的思路。使用者使用物件導向方法學可以定義任何一種DBMS資料庫,即網路型、層次型、關係型、物件導向型均可,甚至檔案系統設計也照樣可以遵循物件導向的思路。 物件導向的思路或稱規範可以用於系統分析、系統設計、程式設計,也可以用於資料結構設計、資料庫設計。OOSE自上至下、自始至終地貫徹物件導向思路,是一個一氣呵成 的統一體。物件導向的資料庫設計只是 OOSE 的一個環節。

　　二、資料庫設計的重要性

　　一般資料庫設計方法有兩種,即屬性主導型和實體主導型。屬性主導型從歸納資料庫應用的屬性出發,在歸併屬性集合(實體)時維持屬性間的函式依賴關係。實體主導型則先 從尋找對資料庫應用有意義的實體入手,然後透過定義屬性來定義實體。一般現實世界的 實體數在屬性數 1/10 以下時,宜使用實體主導型設計方法。物件導向的資料庫設計是從物件模型出發的,屬於實體主導型設計。 一般資料庫應用系統都遵循以下相關開發步驟:

1設計應用系統結構;

2 選擇便於將應

　　 用程式與DBMS結合的DBMS體系結構,如RDBMS;

3 根據應用程式使用的環境平臺,選擇適宜的DBMS(如Oracle)和開發工具(如PB);

4 設計資料庫,編寫定義資料庫模式的SQL程式;

5 編寫確保資料正確錄入資料庫的使用者介面應用程式;

6 錄入資料庫資料;

7 執行各種與 資料庫相關的應用程式,以確認和修正資料庫的內容。

　　對以上各步驟,有幾點需要說明:

(1) 這不是瀑布模型,每一步都可以有反饋。

　　在公路局系統中,以上各步不僅有反饋、有反覆,還有並行處理。比如一些庫表在數 據錄入時,另一些庫表設計還在修改。這與我們的遞增式開發方法有關,也與物件導向的 特徵有關。

(2) 上述順序不是絕對的,大多數場合是從第三步開始的。

(3) 對大多數資料庫應用系統來說,上述各步中最重要、最困難的不是應用系統設計而是資料庫設計。

　　三、DBMS的支援和資料庫設計

　　多資料庫應用系統開發者不重視資料庫設計的原因是:他們太迷信DBMS,認為購入一個功能強大的DBMS後資料庫設計就不困難、不重要了。一些國內外的資料庫教材常常是在為DBMS的開發廠商做宣傳,而很少站在資料庫使用者角度,從資料庫應用系統出發介紹資料庫設計方法。結果往往使讀者搞不清書中介紹的是資料庫管理程式的設計思想,還是 應用這種 DBMS 進行資料庫設計的思想。其實,DBMS只是給使用者為已採用的資料庫提供一個舞臺,而是否使用這個舞臺上的道具以及唱什麼戲,則完全取決於使用者的戲劇指令碼和導演(開發者)的安排。例如,公路局系統所使用的資料庫管理系統,是以二維表為基本管理單元、支援所有關係代數操作、支援實體完整性與實體間參照完整性的全關係型RDBMS,而我們要在這個舞臺上利用上述"道具"設計一個物件導向的關聯式資料庫。

　　四、應用物件模型與RDBMS模型的對映

　　資料庫設計(模式)是否支援應用系統的物件模型,這是判斷是否是物件導向資料庫系統的基本出發點。由於應用系統設計在前,資料庫設計隨後,所以應用系統物件模型向 資料庫模式的對映是物件導向資料庫設計的關鍵。

　　1. 三層資料庫模式物件導向模型的擴充套件

　　一般資料庫設計多參照ANSL/SPARC關於資料庫模式的3層標準結構提案。最接近物理資料庫的內部模式由DBMS提供的SQL來描述。概念模式可以由若干個內部模式聚集而成 ,它是由資料庫使用者規範的一些表的集合。例如,公路局計劃處資料庫模式、機務處資料 庫模式等,它們是邏輯資料庫,常常透過庫表ID來界定庫邊界。一般的概念模式是資料庫 物理模式作用域的邊界,它能實現資料庫的物理意義、特定DBMS 的特殊操作對外部應用 程式的資訊隱蔽。外部模式是從特定使用者應用角度看待的資料庫模式,從不同的應用出發對同一概念模式可以給出多種不同的外部模式。例如:公路綠化情況查詢應用看到的資料 庫是公路上的樹木種類、數量、分佈比率等, 梁隧道狀況查詢應用看到的是公路上的橋 梁、隧道長度、個數、路段等,但是它們可能訪問的是同一個庫表的不同子集。 當外部應用系統以物件模型進行抽象時,從各個應用出發抽象出的物件模型可以對映 到外部模型上,對此我們不妨稱之為外部物件模型。但是,外部模型只是概念模型的子集 ,所以物件導向的資料庫設計核心在於系統物件模型(不妨稱之為概念物件模型) 向資料 庫概念模型的對映(參見圖1) 。

　　2. 物件模型向資料庫表的對映規則

　　由於RDBMS是以二維表為基本管理單元的,所以物件模型最終是由二維表及表間關係來描述的。換言之,物件模型向資料庫概念模型的對映就是向資料庫表的變換過程。有關的變換規則簡單歸納如下:

(1) 一個物件類可以對映為一個以上的庫表,當類間有一對多的關係時,一個表也可 以對應多個類。

(2) 關係(一對一、一對多、多對多以及三項關係)的對映可能有多種情況,但一般映 射為一個表,也可以在物件類表間定義相應的外來鍵。對於條件關係的對映,一個表至少應 有3個屬性。

(3) 單一繼承的泛化關係可以對超類、子類分別對映表,也可以不定義父類表而讓子 類表擁有父類屬性;反之,也可以不定義子類表而讓父類表擁有全部子類屬性。

(4) 對多重繼承的超類和子類分別對映表,對多次多重繼承的泛化關係也對映一個表 。 (5) 對對映後的庫表進行冗餘控制調整,使其達到合理的關係正規化。

　　3. 資料庫模式要面向應用系統

　　我們選擇物件導向的系統設計也好,物件導向的資料庫設計也好,根本目的是服務於應用系統的需要。 以公路局計劃處子系統為例。計劃處的最大工作量就是處理成堆的報表,因此如何有 效地存取這些報表是計劃處資料庫設計的關鍵。考慮到每月上交的報表是同構的,我們可 以建立一張庫表去儲存同一種報表,例如公路工程月報表。但是又產生另一個問題,當使用者想查詢某個月的公路工程月報表時,如何從庫表中取出資料呢?按照資料庫的思想應該 有一個主鍵來標識這張報表。在公路局的報表裡,區別月報表靠上報時間和上報單位,但 如果為每條記錄都加上這兩個欄位,無疑會加大庫表冗餘,增加查詢時間,降低效率。更何 況每張報表都有單位負責人、填表人的屬性,那麼怎樣解決這個問題呢?我們設計了超類 物件 X3 表和流水號表。

　　將它們加入由應用物件模型對映出的資料庫概念模型後,得到圖2所示的結構。

　　每一個應用模組物件對應建立一張流水號表,同一類的報表屬同一流水號表,由流水號表統一管理。流水號表對各分局、處室提交和建立的每一張報表分配一個流水號,該流 水號在整個資料庫中是唯一的,因此在庫中存放任何一張報表都是明確的。流水號的資料型別為 Char(10),前4位為表號,後6位為序列號,其中序列號取自X3表中最大序列號。也 就是說,流水號就是物件識別符號,報表是一個物件,一個物件識別符號唯一決定一個物件。流 水號一旦被分配出去後,在這張報表的生存期內就具有了永久不變性。無論報表的內容及 結構怎麼變化,它都不變,直到報表被刪除,流水號才會消失。流水號表是父類,報表是子類,流水號表之間的聯絡只能透過 X3 表。5個應用模組物件完全對映到資料庫概念模型中,形成應用物件與資料庫物件的一一對應,保持了5個應用物件在目標系統設計中原有的 獨立性,具有很好的封裝性和資訊隱蔽性。儘管流水號表會有一些冗餘,但它是值得的。

　　五、物件導向關聯式資料庫設計效果

　　在公路局系統設計中,從某種意義上講,是資料庫設計的物件導向特徵最終奠定了整個系統的物件導向性,才使物件導向方法在程式開發階段全面開花。其效果歸納如下:

　　1. 資料庫結構清晰

　　便於實現OOP由於實現了應用模組物件對資料庫物件的完全對映,資料庫邏輯模型可以自然且直接 地模擬現實世界的實體關係。公路局使用者所處的當前物理世界、系統開發者所抽象的系 統外部功能,與支援系統功能的內部資料庫 (資料結構)一一對應,所以使用者、開發者和數 據庫維護人員可以用一致的語言進行溝通。 特別是對多數不瞭解公路局業務的程式開發人員來說,這種將應用物件與相應的資料 物件封裝在物件統一體中的設計方法,大大減輕了程式實現的難度,使他們只要知道加工的資料及所需的操作即可,而且應用程式大多雷同,可以多處繼承由設計人員抽象出來的 、預先開發好的各種物理級超類。

　　2. 資料庫物件具有獨立性,便於維護

　　除了資料庫表物件與應用模組物件一一對應外,在邏輯物件模型中我們沒有設計多重 繼承的泛化關係,所以這樣得到的資料庫結構基本上是由父表類和子表類構成的樹型層次 結構,表類間很少有繼承以外的複雜關係,是一個符合區域性化原則的結構,從而使資料庫表 資料破壞的影響控制在區域性範圍且便於修復,給公路局系統開通後的資料庫日常維護工作帶來便利。

　　3. 需求變更時程式與資料庫重用率高,修改少

　　在對映應用物件時,除關係對映規範化後可能出現一對多的表對映外,大多數應用對 象與表物件是一一對應的。我們可以把規範化處理後的、由一個應用物件對映出來的多個表看成一個資料庫物件。因此當部分應用需求變更時,首先,系統修改可以不涉及需求 不變更的部分。其次,變更部分的修改可以基本上只限於追加或刪除程式模組或追加新庫 表,而基本上不必修改原有程式程式碼或原有庫表定義,從而大大減少了工作量,降低了工作難度。

　　六、最簡單的就是最好的

　　客觀世界是錯綜複雜的,電腦科學理論的發展也越來越高深、複雜。然而,人類探索理論和技術的最終目的是:讓客觀世界的複雜變簡單,最簡單的就是最好的。

　　為此我們 給出以下幾點忠告:

　　1. 慎用外來鍵

　　RDBMS 支援複雜關係的能力很強,無論使用者怎麼在邏輯上設定外來鍵,它基本上都能從 物理上幫使用者實現。但是外來鍵把許多獨立的實體牽連在一起,不僅使 RDBMS 維持資料一 致性負擔沉重,也使資料庫應用複雜化,加重了程式開發負擔。這樣的資料庫很難理解,很 難實現資訊隱蔽性設計,往往把簡單問題複雜化。

　　2. 適當冗餘

　　減少資料庫冗餘的設計思路產生於70年代,它是促使 DBMS 進步的重要動力之一。然 而,猶如為了節省2個位元組的儲存空間而釀成了如今全球為之頭痛的2000年問題一樣,它是 計算機硬體主導時代的產物。以今天國內計算機市場價格為例,6G伺服器硬碟的價格不過 2000元,而上海物價局 1996 年頒發的一個人月軟體開發的指導價約8000元,即一個人月 的軟體價格就可以購買20G左右的硬碟。即使有5萬行資料的庫表,每個記錄壓縮40字元的 冗餘,單純計算合計也不足2M,即節省0.6元錢的磁碟空間。 今天的世界已進入軟體主導的計算機時代。因此,最容易理解、應用開發工作量最少 、維護最簡單的資料庫結構才是最好的。只要資料完整性、一致性不受威脅,有些冗餘,不足為慮。換言之,最節省軟體成本 (而不是硬體成本) 的是最好的。

　　3. 資訊隱蔽

　　這是軟體工程最重要的基本原則之一。簡言之即資訊的作用域越小越好,資料庫的透 明度越大越好,因為應用程式需要知道得越多就越複雜。使資料庫黑盒化 (透明度高) 的方法很多,除了設計上的區域性化處理外,還可以利用 DBMS 的觸發器、儲存過程、函式等 ,把資料庫中無法簡化的複雜表關係封裝到黑盒子裡,隱藏起來,特別是放到伺服器端,其 優越性更是多方面的