面向對象的關系數據庫設計,北京市公路局系統使用的是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只是給用戶為已采用的數據庫提供一個舞臺,而是否使用這個舞臺上的道具以及唱什么戲,則完全取決于用戶的戲劇腳本和導演(開發者)的安排。例如,公路局系統所使用的數據庫治理系統,是以二維表為基本治理單元、支持所有關系代數操作、支持實體完整性與實體間參照完整性的全關系型RDB MS,而我們要在這個舞臺上利用上述"道具"設計一個面向對象的關系數據庫。四、應用對象模型與RDBMS模型的映射
數據庫設計(模式)是否支持應用系統的對象模型,這是判定是否是面向對象數據庫系統的基本出發點。由于應用系統設計在前,數據庫設計隨后,所以應用系統對象模型向數據庫模式的映射是面向對象數據庫設計的要害。
1. 三層數據庫模式面向對象模型的擴展
一般數據庫設計多參照ANSL/SPARC關于數據庫模式的3層標準結構提案。最接近物理數據庫的內部模式由DBMS提供的SQL來描述。概念模式可以由若干個內部模式聚集而成 ,它是由數據庫用戶規范的一些表的集合。例如,公路局計劃處數據庫模式、機務處數據 庫模式等,它們是邏輯數據庫,經常通過庫表ID來界定庫邊界。一般的概念模式是數據庫 物理模式作用域的邊界,它能實現數據庫的物理意義、特定DBMS 的非凡操作對外部應用 程序的信息隱蔽。外部模式是從特定用戶應用角度看待的數據庫模式,從不同的應用出發對同一概念模式可以給出多種不同的外部模式。例如:公路綠化情況查詢應用看到的數據 庫是公路上的樹木種類、數量、分布比率等, 梁隧道狀況查詢應用看到的是公路上的橋 梁、隧道長度、個數、路段等,但是它們可能訪問的是同一個庫表的不同子集。 當外部應用系統以對象模型進行抽象時,從各個應用出發抽象出的對象模型可以映射 到外部模型上,對此我們不妨稱之為外部對象模型。但是,外部模型只是概念模型的子集 ,所以面向對象的數據庫設計核心在于系統對象模型(不妨稱之為概念對象模型) 向數據庫概念模型的映射。
2. 對象模型向數據庫表的映射規則
由于RDBMS是以二維表為基本治理單元的,所以對象模型最終是由二維表及表間關系來描述的。換言之,對象模型向數據庫概念模型的映射就是向數據庫表的變換過程。有關的變換規則簡單歸納如下:
(1) 一個對象類可以映射為一個以上的庫表,當類間有一對多的關系時,一個表也可 以對應多個類。
(2) 關系(一對一、一對多、多對多以及三項關系)的映射可能有多種情況,但一般映 射為一個表,也可以在對象類表間定義相應的外鍵。對于條件關系的映射,一個表至少應 有 3個屬性。
(3) 單一繼續的泛化關系可以對超類、子類分別映射表,也可以不定義父類表而讓子 類表擁有父類屬性;反之,也可以不定義子類表而讓父類表擁有全部子類屬性。
(4) 對多重繼續的超類和子類分別映射表,對多次多重繼續的泛化關系也映射一個表 。
(5) 對映射后的庫表進行冗余控制調整,使其達到合理的關系范式。3. 數據庫模式要面向應用系統
我們選擇面向對象的系統設計也好,面向對象的數據庫設計也好,根本目的是服務于應用系統的需要。 以公路局計劃處子系統為例。計劃處的最大工作量就是處理成堆的報表,因此如何有 效地存取這些報表是計劃處數據庫設計的要害?？紤]到每月上交的報表是同構的,我們可 以創建一張庫表去存儲同一種報表,例如公路工程月報表。但是又產生另一個問題,當用戶想查詢某個月的公路工程月報表時,如何從庫表中取出數據呢?按照數據庫的思想應該 有一個主鍵來標識這張報表。在公路局的報表里,區別月報表靠上報時間和上報單位,但 假如為每條記錄都加上這兩個字段,無疑會加大庫表冗余,增加查詢時間,降低效率。更何 況每張報表都有單位負責人、填表人的屬性,那么怎樣解決這個問題呢?我們設計了超類 對象 X3 表和流水號表。將它們加入由應用對象模型映射出的數據庫概念模型后,得到新的結構。每一個應用模塊對象對應建立一張流水號表,同一類的報表屬同一流水號表,由流水號表統一治理。流水號表對各分局、處室提交和建立的每一張報表分配一個流水號,該流 水號在整個數據庫中是唯一的,因此在庫中存放任何一張報表都是明確的。流水號的數據類型為 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 的觸發器、存儲過程、函數等 ,把數據庫中無法簡化的復雜表關系封裝到黑盒子里,隱藏起來,非凡是放到服務器端 ,其 優越性更是多方面的。
