面向對象的關系數(shù)據(jù)庫設計

1、面向對象的關系數(shù)據(jù)庫設計一、概念的區(qū)分有些人把面向對象的數(shù)據(jù)庫設計（即數(shù)據(jù)庫模式思想與面向對象數(shù)據(jù)庫管理系統(tǒng)（OODBMS論混為一談。其實前者是數(shù)據(jù)庫用戶定義數(shù)據(jù)庫模式的思路,后者是數(shù)據(jù)庫管理程序的思路。用戶使用面向對象方法學可以定義任何一種DBM頷據(jù)庫，即網(wǎng)絡型、層次型、關系型、面向對象型均可，甚至文件系統(tǒng)設計也照樣可以遵循面向對象的思路。面向對象的思路或稱規(guī)范可以用于系統(tǒng)分析、系統(tǒng)設計、程序設計，也可以用于數(shù)據(jù)結構設計、數(shù)據(jù)庫設計。OOSI6上至下、自始至終地貫徹面向對象思路，是一個一氣呵成的統(tǒng)一體。面向對象的數(shù)據(jù)庫設計只是OOSE的一個環(huán)節(jié)。二、數(shù)據(jù)庫設計的重要性一般數(shù)據(jù)庫設計方法有兩種

2、，即屬性主導型和實體主導型。屬性主導型從歸納數(shù)據(jù)庫應用的屬性出發(fā),在歸并屬性集合（實體時維持屬性間的函數(shù)依賴關系。實體主導型則先從尋找對數(shù)據(jù)庫應用有意義的實體入手，然后通過定義屬性來定義實體。一般現(xiàn)實世界的實體數(shù)在屬性數(shù)1/10以下時，宜使用實體主導型設計方法。面向對象的數(shù)據(jù)庫設計是從對象模型出發(fā)的，屬于實體主導型設計。一般數(shù)據(jù)庫應用系統(tǒng)都遵循以下相關開發(fā)步驟：1設計應用系統(tǒng)結構；2選擇便于將應用程序與DBMS吉合的DBM外系結構,如RDBMS;3根據(jù)應用程序使用的環(huán)境平臺，選擇適宜的DBMS（口Oracle和開發(fā)工具（如PB;4設計數(shù)據(jù)庫，編寫定義數(shù)據(jù)庫模式的SQL程序；5編寫確保數(shù)據(jù)正確錄

3、入數(shù)據(jù)庫的用戶接口應用程序6錄入數(shù)據(jù)庫數(shù)據(jù);7運行各種與數(shù)據(jù)庫相關的應用程序,以確認和修正數(shù)據(jù)庫的內容。對以上各步驟，有幾點需要說明：(1這不是瀑布模型，每一步都可以有反饋。在公路局系統(tǒng)中，以上各步不僅有反饋、有反復，還有并行處理。比如一些庫表在數(shù)據(jù)錄入時，另一些庫表設計還在修改。這與我們的遞增式開發(fā)方法有關，也與面向對象的特征有關。(2上述順序不是絕對的，大多數(shù)場合是從第三步開始的。(3對大多數(shù)數(shù)據(jù)庫應用系統(tǒng)來說，上述各步中最重要、最困難的不是應用系統(tǒng)設計而是數(shù)據(jù)庫設計。三、DBMS勺支持和數(shù)據(jù)庫設計多數(shù)據(jù)庫應用系統(tǒng)開發(fā)者不重視數(shù)據(jù)庫設計的原因是：他們太迷信DBMS人為購入一個功能強大的DB

4、MS5數(shù)據(jù)庫設計就不困難、不重要了。一些國內外的數(shù)據(jù)庫教材常常是在為DBMS勺開發(fā)廠商做宣傳，而很少站在數(shù)據(jù)庫用戶角度，從數(shù)據(jù)庫應用系統(tǒng)出發(fā)介紹數(shù)據(jù)庫設計方法。結果往往使讀者搞不清書中介紹的是數(shù)據(jù)庫管理程序的設計思想，還是應用這種DBMS進行數(shù)據(jù)庫設計的思想。其實,DBMSR是給用戶為已采用的數(shù)據(jù)庫提供一個舞臺，而是否使用這個舞臺上的道具以及唱什么戲，則完全取決于用戶的戲劇腳本和導演(開發(fā)者的安排。例如,公路局系統(tǒng)所使用的數(shù)據(jù)庫管理系統(tǒng)，是以二維表為基本管理單元、支持所有關系代數(shù)操作、支持實體完整性與實體間參照完整性的全關系型RDBMSJ我們要在這個舞臺上利用上述“道具”設計一個面向對象的關系

5、數(shù)據(jù)庫。四、應用對象模型與RDBMSI型的映射數(shù)據(jù)庫設計(模式是否支持應用系統(tǒng)的對象模型，這是判斷是否是面向對象數(shù)據(jù)庫系統(tǒng)的基本出發(fā)點。由于應用系統(tǒng)設計在前，數(shù)據(jù)庫設計隨后，所以應用系統(tǒng)對象模型向數(shù)據(jù)庫模式的映射是面向對象數(shù)據(jù)庫設計的關鍵。1 .三層數(shù)據(jù)庫模式面向對象模型的擴展一般數(shù)據(jù)庫設計多參照ANSL/SPAR供于數(shù)據(jù)庫模式的3層標準結構提案。最接近物理數(shù)據(jù)庫的內部模式由DBMS1供的SQL#描述。概念模式可以由若干個內部模式聚集而成，它是由數(shù)據(jù)庫用戶規(guī)范的一些表的集合。例如，公路局計劃處數(shù)據(jù)庫模式、機務處數(shù)據(jù)庫模式等，它們是邏輯數(shù)據(jù)庫，常常通過庫表ID來界定庫邊界。一般的概念模式是數(shù)據(jù)庫

6、物理模式作用域的邊界，它能實現(xiàn)數(shù)據(jù)庫的物理意義、特定DBMS的特殊操作對外部應用程序的信息隱蔽。外部模式是從特定用戶應用角度看待的數(shù)據(jù)庫模式，從不同的應用出發(fā)對同一概念模式可以給出多種不同的外部模式。例如：公路綠化情況查詢應用看到的數(shù)據(jù)庫是公路上的樹木種類、數(shù)量、分布比率等，梁隧道狀況查詢應用看到的是公路上的橋梁、隧道長度、個數(shù)、路段等，但是它們可能訪問的是同一個庫表的不同子集。當外部應用系統(tǒng)以對象模型進行抽象時，從各個應用出發(fā)抽象出的對象模型可以映射到外部模型上，對此我們不妨稱之為外部對象模型。但是，外部模型只是概念模型的子集，所以面向對象的數(shù)據(jù)庫設計核心在于系統(tǒng)對象模型(不妨稱之為概念對象

7、模型向數(shù)據(jù)庫概念模型的映射2 .對象模型向數(shù)據(jù)庫表的映射規(guī)則由于RDBMSI以二維表為基本管理單元的，所以對象模型最終是由二維表及表間關系來描述的。換言之，對象模型向數(shù)據(jù)庫概念模型的映射就是向數(shù)據(jù)庫表的變換過程。有關的變換規(guī)則簡單歸納如下：(1一個對象類可以映射為一個以上的庫表，當類間有一對多的關系時，一個表也可以對應多個類(2關系(一對一、一對多、多對多以及三項關系的映射可能有多種情況，但一般映射為一個表，也可以在對象類表間定義相應的外鍵。對于條件關系的映射，一個表至少應有3個屬性。(3單一繼承的泛化關系可以對超類、子類分別映射表，也可以不定義父類表而讓子類表擁有父類屬性；反之，也可以不定義

8、子類表而讓父類表擁有全部子類屬性。(4對多重繼承的超類和子類分別映射表，對多次多重繼承的泛化關系也映射一個表。(5對映射后的庫表進行冗余控制調整，使其達到合理的關系范式。3.數(shù)據(jù)庫模式要面向應用系統(tǒng)我們選擇面向對象的系統(tǒng)設計也好，面向對象的數(shù)據(jù)庫設計也好，根本目的是服務于應用系統(tǒng)的需要。以公路局計劃處子系統(tǒng)為例。計劃處的最大工作量就是處理成堆的報表，因此如何有效地存取這些報表是計劃處數(shù)據(jù)庫設計的關鍵?？紤]到每月上交的報表是同構的，我們可以創(chuàng)建一張庫表去存儲同一種報表，例如公路工程月報表。但是又產生另一個問題，當用戶想查詢某個月的公路工程月報表時，如何從庫表中取出數(shù)據(jù)呢？按照數(shù)據(jù)庫的思想應該有一

9、個主鍵來標識這張報表。在公路局的報表里，區(qū)別月報表靠上報時間和上報單位，但如果為每條記錄都加上這兩個字段，無疑會加大庫表冗余，增加查詢時間，降低效率。更何況每張報表都有單位負責人、填表人的屬性，那么怎樣解決這個問題呢？我們設計了超類對象X3表和流水號表。將它們加入由應用對象模型映射出的數(shù)據(jù)庫概念模型后，得到圖2所示的結構。每一個應用模塊對象對應建立一張流水號表，同一類的報表屬同一流水號表，由流水號表統(tǒng)一管理。流水號表對各分局、處室提交和建立的每一張報表分配一個流水號，該流水號在整個數(shù)據(jù)庫中是唯一的，因此在庫中存放任何一張報表都是明確的。流水號的數(shù)據(jù)類型為Char(10,前4位為表號,后6位為序

10、列號,其中序列號取自X3表中最大序列號。也就是說，流水號就是對象標識符，報表是一個對象，一個對象標識符唯一決定一個對象。流水號一旦被分配出去后，在這張報表的生存期內就具有了永久不變性。無論報表的內容及結構怎么變化，它都不變，直到報表被刪除，流水號才會消失。流水號表是父類，報表是子類，流水號表之間的聯(lián)系只能通過X3表。5個應用模塊對象完全映射到數(shù)據(jù)庫概念模型中，形成應用對象與數(shù)據(jù)庫對象的一一對應，保持了5個應用對象在目標系統(tǒng)設計中原有的獨立性，具有很好的封裝性和信息隱蔽性。盡管流水號表會有一些冗余，但它是值得的。五、面向對象關系數(shù)據(jù)庫設計效果在公路局系統(tǒng)設計中，從某種意義上講，是數(shù)據(jù)庫設計的面向

11、對象特征最終奠定了整個系統(tǒng)的面向對象性，才使面向對象方法在程序開發(fā)階段全面開花。具效果歸納如下：1 .數(shù)據(jù)庫結構清晰便于實現(xiàn)OO的于實現(xiàn)了應用模塊對象對數(shù)據(jù)庫對象的完全映射，數(shù)據(jù)庫邏輯模型可以自然且直接地模擬現(xiàn)實世界的實體關系。公路局用戶所處的當前物理世界、系統(tǒng)開發(fā)者所抽象的系統(tǒng)外部功能，與支持系統(tǒng)功能的內部數(shù)據(jù)庫(數(shù)據(jù)結構一一對應，所以用戶、開發(fā)者和數(shù)據(jù)庫維護人員可以用一致的語言進行溝通。特別是對多數(shù)不了解公路局業(yè)務的程序開發(fā)人員來說，這種將應用對象與相應的數(shù)據(jù)對象封裝在對象統(tǒng)一體中的設計方法，大大減輕了程序實現(xiàn)的難度，使他們只要知道加工的數(shù)據(jù)及所需的操作即可，而且應用程序大多雷同，可以多處

12、繼承由設計人員抽象出來的、預先開發(fā)好的各種物理級超類。2 .數(shù)據(jù)庫對象具有獨立性，便于維護除了數(shù)據(jù)庫表對象與應用模塊對象一一對應外，在邏輯對象模型中我們沒有設計多重繼承的泛化關系，所以這樣得到的數(shù)據(jù)庫結構基本上是由父表類和子表類構成的樹型層次結構,表類間很少有繼承以外的復雜關系，是一個符合局部化原則的結構，從而使數(shù)據(jù)庫表數(shù)據(jù)破壞的影響控制在局部范圍且便于修復,給公路局系統(tǒng)開通后的數(shù)據(jù)庫日常維護工作帶來便利。3 .需求變更時程序與數(shù)據(jù)庫重用率高，修改少在映射應用對象時，除關系映射規(guī)范化后可能出現(xiàn)一對多的表映射外，大多數(shù)應用對象與表對象是一一對應的。我們可以把規(guī)范化處理后的、由一個應用對象映射出來

13、的多個表看成一個數(shù)據(jù)庫對象。因此當部分應用需求變更時，首先，系統(tǒng)修改可以不涉及需求不變更的部分。其次，變更部分的修改可以基本上只限于追加或刪除程序模塊或追加新庫表,而基本上不必修改原有程序代碼或原有庫表定義，從而大大減少了工作量，降低了工作難度。六、最簡單的就是最好的客觀世界是錯綜復雜的，計算機科學理論的發(fā)展也越來越高深、復雜。然而，人類探索理論和技術的最終目的是：讓客觀世界的復雜變簡單，最簡單的就是最好的。為此我們給出以下幾點忠告：1 .慎用外鍵RDBM斂持復雜關系的能力很強，無論用戶怎么在邏輯上設定外鍵，它基本上都能從物理上幫用戶實現(xiàn)。但是外鍵把許多獨立的實體牽連在一起，不僅使RDBMS隹

14、持數(shù)據(jù)一致性負擔沉重,也使數(shù)據(jù)庫應用復雜化,加重了程序開發(fā)負擔,這樣的數(shù)據(jù)庫很難理解，很難實現(xiàn)信息Bt蔽性設計，往往把簡單問題復雜化。2 .適當冗余減少數(shù)據(jù)庫冗余的設計思路產生于70年代，它是促使DBMS進步的重要動力之一。然而，猶如為了節(jié)省2個字節(jié)的存儲空間而釀成了如今全球為之頭痛的2000年問題一樣，它是計算機硬件主導時代的產物。以今天國內計算機市場價格為例,6G服務器硬盤的價格不過2000元，而上海物價局1996年頒發(fā)的一個人月軟件開發(fā)的指導價約8000元，即一個人月的軟件價格就可以購買20G左右的硬盤。即使有5萬行數(shù)據(jù)的庫表，每個記錄壓縮40字符的冗余，單純計算合計也不足2M,即節(jié)省0.6元錢的磁盤空間。今天的世界已進入軟件主導的計算機時代。因此，最容易理解、應用開發(fā)工作量最少、維護最簡單的數(shù)據(jù)庫結構才是最好的