數(shù)據(jù)庫及其接口設計

數(shù)據(jù)庫及其接口設計第一頁，共一百零五頁，編輯于2023年，星期三數(shù)據(jù)管理系統(tǒng)，包括文件系統(tǒng)和數(shù)據(jù)庫管理系統(tǒng)兩大類。采用關系模型的數(shù)據(jù)庫稱做關系數(shù)據(jù)庫（relationaldatabase）。與層次和網(wǎng)狀的DBMS相比，RDBMS所采用的數(shù)據(jù)模型以二維表的形式而不是人為地設置指針（或導航鏈）來實現(xiàn)實體數(shù)據(jù)之間的聯(lián)系，從而使用戶可以直接從數(shù)據(jù)庫中獲取表示事物之間聯(lián)系的信息，而不必借助軟件專家的幫助。第二頁，共一百零五頁，編輯于2023年，星期三15.1數(shù)據(jù)管理系統(tǒng)及其選擇

有效地實現(xiàn)數(shù)據(jù)在永久性存儲空間的存儲與管理需要特定的軟件系統(tǒng)支持。這些實現(xiàn)數(shù)據(jù)存儲、檢索、管理、維護的系統(tǒng)稱做數(shù)據(jù)管理系統(tǒng)，包括文件系統(tǒng)和數(shù)據(jù)庫管理系統(tǒng)兩大類。第三頁，共一百零五頁，編輯于2023年，星期三文件系統(tǒng)文件系統(tǒng)（filesystem）通常被作為操作系統(tǒng)的一部分。它采用統(tǒng)一、標準的方法對輔助存儲器上的用戶文件和系統(tǒng)文件的數(shù)據(jù)進行管理，提供存儲、檢索、更新、共享和保護等功能。它有如下的局限性：

第四頁，共一百零五頁，編輯于2023年，星期三

（1）各個文件中的數(shù)據(jù)是相互分離和獨立的，不易直接體現(xiàn)數(shù)據(jù)之間的關系。（2）容易產(chǎn)生數(shù)據(jù)冗余，并因此給數(shù)據(jù)完整性的維護帶來很大困難。（3）應用程序依賴于文件結構，當文件結構發(fā)生變化時，應用程序也必須變化.第五頁，共一百零五頁，編輯于2023年，星期三

（4）不同的編程語言（或其他軟件產(chǎn)品）產(chǎn)生的文件格式互異，互不兼容。（5）難以按用戶視圖表示數(shù)據(jù)。第六頁，共一百零五頁，編輯于2023年，星期三數(shù)據(jù)庫管理系統(tǒng)數(shù)據(jù)庫的建立、使用和維護必須有DBMS的支持，DBMS提供的功能包括：（1）模式翻譯（2）應用程序的編譯第七頁，共一百零五頁，編輯于2023年，星期三

（3）交互式查詢（4）數(shù)據(jù)的組織與存取（5）事物運行管理（6）數(shù)據(jù)庫的維護第八頁，共一百零五頁，編輯于2023年，星期三數(shù)據(jù)庫管理系統(tǒng)克服了文件系統(tǒng)的許多局限性，它使數(shù)據(jù)庫中的數(shù)據(jù)具有如下特點：（1）數(shù)據(jù)是集成的，數(shù)據(jù)庫不但保存各種數(shù)據(jù)，也保存它們之間的關系，并由DBMS提供方便、高效的檢索功能。

第九頁，共一百零五頁，編輯于2023年，星期三（2）數(shù)據(jù)冗余度較小，并由DBMS保證數(shù)據(jù)的完整性。（3）程序與數(shù)據(jù)相互獨立。（4）易于按用戶視圖表示數(shù)據(jù)。第十頁，共一百零五頁，編輯于2023年，星期三關系數(shù)據(jù)庫和關系數(shù)據(jù)庫管理系統(tǒng)（1）采用關系模型的數(shù)據(jù)庫稱做關系數(shù)據(jù)庫。關系模型用二維表來表示各類數(shù)據(jù)，二維表中有行，有列。第十一頁，共一百零五頁，編輯于2023年，星期三（2）基于關系模型的數(shù)據(jù)庫管理系統(tǒng)叫做關系數(shù)據(jù)庫管理系統(tǒng)。RDBMS所采用的數(shù)據(jù)模型以二維表的形式而不是人為地設置指針（或曰導航鏈）來實現(xiàn)實體數(shù)據(jù)之間的聯(lián)系，從而使用戶可以直接從數(shù)據(jù)庫中獲取表示事物之間聯(lián)系的信息，而不必借助軟件專家的幫助。第十二頁，共一百零五頁，編輯于2023年，星期三面向對象數(shù)據(jù)庫和面向對象數(shù)據(jù)庫管理系統(tǒng)

（1）采用面向對象數(shù)據(jù)模型的數(shù)據(jù)庫稱做面向對象數(shù)據(jù)庫（OODB）；相應的數(shù)據(jù)庫管理系統(tǒng)稱做面向對象數(shù)據(jù)庫管理系統(tǒng)（OODBMS），有時稱做對象數(shù)據(jù)庫管理系統(tǒng)（ODBMS）。第十三頁，共一百零五頁，編輯于2023年，星期三

（2）面向對象數(shù)據(jù)管理系統(tǒng)應具備兩方面的特征：一方面它是面向對象的，另一方面它又具有數(shù)據(jù)庫管理系統(tǒng)應有的特點和功能。第十四頁，共一百零五頁，編輯于2023年，星期三數(shù)據(jù)管理系統(tǒng)的選擇對許多項目而言，關系數(shù)據(jù)庫管理系統(tǒng)和文件系統(tǒng)都可能成為最合適的選擇。決定采用何種數(shù)據(jù)管理系統(tǒng)，要綜合考慮技術和非技術兩方面的因素：第十五頁，共一百零五頁，編輯于2023年，星期三1）非技術因素（1）數(shù)據(jù)管理系統(tǒng)的成熟程度和先進性。（2）價格。（3）開發(fā)隊伍的技術背景。（4）與其他系統(tǒng)的關系。第十六頁，共一百零五頁，編輯于2023年，星期三2）技術因素（1）文件系統(tǒng)。（2）關系數(shù)據(jù)庫管理系統(tǒng)。（3）面向對象數(shù)據(jù)庫管理系統(tǒng)。第十七頁，共一百零五頁，編輯于2023年，星期三15.2數(shù)據(jù)庫系統(tǒng)數(shù)據(jù)庫管理在應用上扮演了集中的角色。它使大量持續(xù)性集合的數(shù)據(jù)被組織和維持，并且由以計算機為基礎的數(shù)據(jù)系統(tǒng)來支持，數(shù)據(jù)庫應用在許多不同的領域，已經(jīng)被開發(fā)。第十八頁，共一百零五頁，編輯于2023年，星期三數(shù)據(jù)庫系統(tǒng)包括軟件、數(shù)據(jù)庫管理系統(tǒng)和一個或多個數(shù)據(jù)庫。數(shù)據(jù)庫管理系統(tǒng)是在計算機主存儲器中執(zhí)行，并且由個別的操作所控制的程序系統(tǒng)。數(shù)據(jù)庫是一群數(shù)據(jù)的集合，它是有關真實世界應用的代表信息。第十九頁，共一百零五頁，編輯于2023年，星期三數(shù)據(jù)庫與數(shù)據(jù)庫管理系統(tǒng)之間的區(qū)別是兩種對數(shù)據(jù)庫系統(tǒng)的觀點與方式：（1）由用戶的觀點（2）由開發(fā)者的觀點第二十頁，共一百零五頁，編輯于2023年，星期三對概觀數(shù)據(jù)庫的一般性描述，有四個主要的領域：（1）數(shù)據(jù)模型（2）數(shù)據(jù)庫語言（3）交易與并行控制（4）數(shù)據(jù)結構第二十一頁，共一百零五頁，編輯于2023年，星期三以下針對各數(shù)據(jù)庫結構簡要地說明其特點：（1）文件管理系統(tǒng)。一般而言，文件管理系統(tǒng)的程序結構在處理導向的模型上，并依分類順序或是以邏輯上的關鍵值來作索引。文件管理系統(tǒng)的缺點主要包括有數(shù)據(jù)重復、矛盾、缺乏彈性、不易分享、沒有標準、程序產(chǎn)量低，以及需要大量的程序維護工作等。第二十二頁，共一百零五頁，編輯于2023年，星期三

（2）層次式數(shù)據(jù)庫管理系統(tǒng)。由于“單一雙親法則”的特性，使得該數(shù)據(jù)模型會產(chǎn)生重復且過量的數(shù)據(jù)和結構。因此，浪費保存空間是其最大的缺點。但在薪資系統(tǒng)上仍適合使用。第二十三頁，共一百零五頁，編輯于2023年，星期三

（3）網(wǎng)絡式數(shù)據(jù)庫管理系統(tǒng)。雖然網(wǎng)狀式數(shù)據(jù)庫結構可將相鄰或共同的要素加以結合，以節(jié)省保存空間，但因其采用“環(huán)式指示碼結構”來表示復雜現(xiàn)象的拓撲結構，所以當有數(shù)據(jù)需編輯或更新時，則必須改變原有相連的數(shù)據(jù)結構，此為其最大缺點。第二十四頁，共一百零五頁，編輯于2023年，星期三

（4）關系型數(shù)據(jù)庫管理系統(tǒng)。關系型數(shù)據(jù)模型在某方面有其使用限制，這是為了使數(shù)據(jù)模型簡單化所加的限制。雖然如此，但與其前身比較，該數(shù)據(jù)模型則具備了一些非常重要的特點。例如，數(shù)據(jù)獨立、聲明式處理、去除重復、簡單及以表單作為表達形式，以上優(yōu)點不僅使程序開發(fā)更為快速，也使得程序的維護更加容易。第二十五頁，共一百零五頁，編輯于2023年，星期三

（5）面向對象數(shù)據(jù)庫管理系統(tǒng)。面向對象數(shù)據(jù)庫將數(shù)據(jù)與操作方法集合成為對象的概念，并且也支持復合對象及一般化關系的直接表示，這是傳統(tǒng)數(shù)據(jù)庫所不能達到的。面向對象數(shù)據(jù)庫在傳統(tǒng)數(shù)據(jù)庫中加入了抽象，擴充類型定義、用戶定義操作與數(shù)據(jù)類型、繼承機制、數(shù)據(jù)定義語言與數(shù)據(jù)操作語言的集成，以及支持版本與模型演變等概念與功能，消除了傳統(tǒng)數(shù)據(jù)對數(shù)據(jù)定義的一致性限制。第二十六頁，共一百零五頁，編輯于2023年，星期三15.2.1面向對象技術

面向對象技術的特點：（1）面向對象的思考方式比結構化分析及設計的技術，對人類更自然。（2）系統(tǒng)通常由已存在的對象所構成。（3）對象的復雜度可以一直成長，因為對象是由別的對象所組成，以此類推。第二十七頁，共一百零五頁，編輯于2023年，星期三（4）計算機輔助軟件工程（CASE）保存庫應該包含有持續(xù)成長的對象類別鏈接庫，某些是購買的，某些是建立的。（5）用面向對象技術來生成功能良好的系統(tǒng)比較容易，原因是由于類又包含著類。（6）面向對象技術與CASE工具很自然地結合。第二十八頁，共一百零五頁，編輯于2023年，星期三面向對象分析與設計。面向對象分析是利用系統(tǒng)結構及操作概念，以對象來反映系統(tǒng)連續(xù)的處理過程，其主要特點歸納如下：（1）面向對象模型與真實世界的差距很小。（2）以對象為基礎，可做局部的修改。（3）有助于理解問題空間。第二十九頁，共一百零五頁，編輯于2023年，星期三

（4）改進分析人員與用戶間的交互方式。（5）增加分析結果內部的一致性。（6）共同性質明顯表示。（7）分析結果可重復使用。第三十頁，共一百零五頁，編輯于2023年，星期三面向對象設計是將分析模型所得轉換成解答模型的過程，其主要特性有：（1）模塊化（2）信息隱藏（3）弱耦合力第三十一頁，共一百零五頁，編輯于2023年，星期三

（4）強內聚力（5）抽象（6）可擴充性（7）整合性第三十二頁，共一百零五頁，編輯于2023年，星期三面向對象分析與設計的主要目標如下；（1）確定企業(yè)運作過程中的各項重要角色，然后確定各角色的責任。（2）定義軟件對象來表達各項角色。（3）進行面向對象分解，即將對象分類或分解更小的對象。第三十三頁，共一百零五頁，編輯于2023年，星期三15.2.2面向對象數(shù)據(jù)庫的應用

面向對象技術被視為能夠帶來更可靠和較高品質的軟件，因為它能夠借助使用定義好的接口與隱藏實現(xiàn)細節(jié)，建立更模塊化的軟件。第三十四頁，共一百零五頁，編輯于2023年，星期三對象數(shù)據(jù)庫技術在其他工業(yè)部門也變得很受歡迎，對象數(shù)據(jù)庫技術已明顯地移向非工業(yè)方面的應用。第三十五頁，共一百零五頁，編輯于2023年，星期三由于面向對象技術在觀察、分析問題時更接近人類的思維方式，所以模型中的對象與真實世界的實體或概念有自然的對應，并可隨環(huán)境的變動，修正系統(tǒng)中的對象屬性或方法，以適應復雜多變的產(chǎn)品開發(fā)類型。第三十六頁，共一百零五頁，編輯于2023年，星期三15.2.3應用程序設計程序

越來越強調流程的整合是迫使采用面向對象數(shù)據(jù)庫的原由。面向對象數(shù)據(jù)庫的應用領域非常廣泛，而它的特質就是具有非常復雜而有效的信息，面向對象能以更自然及更易了解的方法來呈現(xiàn)問題的解決。第三十七頁，共一百零五頁，編輯于2023年，星期三面向對象數(shù)據(jù)庫引入面向對象的新概念于數(shù)據(jù)庫中，同樣使用面向對象的方法仿真?zhèn)鹘y(tǒng)數(shù)據(jù)庫的功能。因此，其優(yōu)點為比傳統(tǒng)數(shù)據(jù)庫多了“面向對象”的功能。面向對象的功能是在對象與對象之間擁有多樣化的關系。第三十八頁，共一百零五頁，編輯于2023年，星期三通常面向對象數(shù)據(jù)庫下列的優(yōu)點勝過關系型數(shù)據(jù)庫：

（1）一個更真實，更有力的數(shù)據(jù)模型。（2）處理更復雜的對象。（3）在實體之間的繼承關聯(lián)。第三十九頁，共一百零五頁，編輯于2023年，星期三

（4）在模式層之內結合對象的行為與對象的定義。（5）在集合繼承之間的內隱連接以對象識別碼為基礎。（6）版本的機制。第四十頁，共一百零五頁，編輯于2023年，星期三

（7）較好的交易與并行管理。（8）表達更佳的查詢語言。（9）對合作的工作有較好的支持。第四十一頁，共一百零五頁，編輯于2023年，星期三15.2.4面向對象數(shù)據(jù)庫的最佳化面向對象數(shù)據(jù)庫管理系統(tǒng)將保證大部分的最佳化責任，允許用戶規(guī)范高層以外的陳述，指引什么樣的最佳化需被執(zhí)行。面向對象數(shù)據(jù)庫的演進，如圖15-1所示。

第四十二頁，共一百零五頁，編輯于2023年，星期三圖15-1

第四十三頁，共一百零五頁，編輯于2023年，星期三15.3技術整合在整合面向對象和數(shù)據(jù)庫的技術時，首先要考慮的問題是：對象在什么時候該被保存起來，未來將如何取用這些對象。第四十四頁，共一百零五頁，編輯于2023年，星期三解決了保存對象的問題之后，接下來要處理的是對象共享時所產(chǎn)生的管理問題。在一般的數(shù)據(jù)文件中，并無法做到對象保密及安全性的控制，數(shù)據(jù)文件中的對象可隨意讓人使用。第四十五頁，共一百零五頁，編輯于2023年，星期三通過數(shù)據(jù)庫管理系統(tǒng)的使用，程序設計者可以將應用程序產(chǎn)生的數(shù)據(jù)放到數(shù)據(jù)庫里，而不需要操心如何將這些數(shù)據(jù)存放在存儲器中。當需要任何數(shù)據(jù)時，只要跟數(shù)據(jù)庫系統(tǒng)說明，系統(tǒng)便能快速地把你所需要的數(shù)據(jù)取出來。第四十六頁，共一百零五頁，編輯于2023年，星期三面向對象數(shù)據(jù)庫管理系統(tǒng)，最大的特點之一就是：能直接記錄復雜的數(shù)據(jù)結構，而不需將之拆成一個個的片段。使用面向對象數(shù)據(jù)庫系統(tǒng)，可以讓應用程序直接、緊密地與數(shù)據(jù)庫結合，使得應用程序無需花太多額外的力氣在數(shù)據(jù)庫系統(tǒng)的溝通及數(shù)據(jù)轉換的工作上。第四十七頁，共一百零五頁，編輯于2023年，星期三基于以上的因素，一個要求具備下列條件的數(shù)據(jù)庫便應運而生：（1）能提供豐富的數(shù)據(jù)類型。（2）能直接處理復雜對象而沒有數(shù)據(jù)格式轉換的問題。（3）能提供與傳統(tǒng)數(shù)據(jù)庫相同的管理及服務。（4）能兼顧系統(tǒng)的彈性。第四十八頁，共一百零五頁，編輯于2023年，星期三15.4數(shù)據(jù)接口

數(shù)據(jù)接口部分是OOD模型中負責與具體的數(shù)據(jù)管理系統(tǒng)銜接的外圍組成部分，它為系統(tǒng)中需要長久存儲的對象提供了在選定的數(shù)據(jù)管理系統(tǒng)中進行數(shù)據(jù)存儲與恢復的功能。第四十九頁，共一百零五頁，編輯于2023年，星期三OOD模型中的數(shù)據(jù)接口部分就是這樣一個組成部分：它負責將應用系統(tǒng)中的對象在選定的數(shù)據(jù)管理系統(tǒng)中進行存儲，并將存儲結果恢復到應用系統(tǒng)。它所要解決的問題，可以通過以下的討論而明確范圍。第五十頁，共一百零五頁，編輯于2023年，星期三

（1）對象在內存空間的存儲是由編程語言自動解決的，不需要設計者做什么事。（2）只需考慮對象屬性值的存儲。（3）并非所有的對象都需要長期保存。（4）如果使用的面向對象編程語言能夠支持永久對象的表示和存儲管理，不需要設計者做更多的工作。第五十一頁，共一百零五頁，編輯于2023年，星期三數(shù)據(jù)接口部分的設計所瞄準的問題可以歸結為：在選用的編程語言和數(shù)據(jù)管理系統(tǒng)不能直接支持對象永久存儲的情況下，通過一個專門設計的模型組成部分，實現(xiàn)應用系統(tǒng)與數(shù)據(jù)管理系統(tǒng)的接口，以解決應用系統(tǒng)中需要長期保存的對象的屬性值在外存空間的保存問題。第五十二頁，共一百零五頁，編輯于2023年，星期三15.5對象存儲方案和數(shù)據(jù)接口的設計策略本節(jié)針對文件系統(tǒng)、RDBMS和OODBMS三種不同的數(shù)據(jù)管理系統(tǒng)，分別討論相應的對象存儲方案和數(shù)據(jù)接口部分的設計策略。第五十三頁，共一百零五頁，編輯于2023年，星期三15.5.1針對文件系統(tǒng)的設計

對象在內存空間和文件空間的映像。由于應用系統(tǒng)的具體要求和實現(xiàn)策略不同，對象實例在內存空間和文件空間的存儲映像也有不同的映射方式：第五十四頁，共一百零五頁，編輯于2023年，星期三

（1）每個需要永久存儲的對象，都在內存空間建立一個對象實例，同時又在文件中保存一個記錄。（2）一個類的每個對象都在文件中對應著一個記錄，但是在內存空間卻只根據(jù)算法的需要創(chuàng)建一個或少量幾個對象實例。第五十五頁，共一百零五頁，編輯于2023年，星期三對象存放策略。用文件系統(tǒng)存放對象的基本策略是：把由每個類直接定義，并需要永久存儲的全部對象實例，存放在一個文件中；其中每個對象實例的全部屬性作為一個存儲單元，占用該文件的一個記錄。第五十六頁，共一百零五頁，編輯于2023年，星期三為了在文件中高效地存儲和檢索數(shù)據(jù)，一個重要的問題是努力在對象實例和文件記錄之間建立一種有規(guī)律的映射關系。在以下情況下，這種努力將取得明顯的效果：第五十七頁，共一百零五頁，編輯于2023年，星期三

（1）對象名稱呈線性規(guī)律的情況（2）對象關鍵字呈線性規(guī)律的情況（3）對象名稱或關鍵字可以比較和排序的情況第五十八頁，共一百零五頁，編輯于2023年，星期三一個類使用一個文件，一個對象對應文件中的一個記錄是基本策略。進一步的決策要根據(jù)應用系統(tǒng)的具體特點與要求，考慮以下問題：第五十九頁，共一百零五頁，編輯于2023年，星期三

（1）一個類是否有大批量的對象實例需要永久存儲？（2）對象名稱或關鍵字是否呈現(xiàn)某種規(guī)律？（3）應用系統(tǒng)經(jīng)常需要按照什么條件進行檢索？（4）是否需要經(jīng)常地插入或刪除對象？

第六十頁，共一百零五頁，編輯于2023年，星期三設計數(shù)據(jù)接口部分的對象類。一個最主要的對象類是為所有（需要在文件中存儲數(shù)據(jù)的）其他對象提供基本保存與恢復功能的對象類，可將它命名為“對象存取器”。應用系統(tǒng)中各個類的對象是按關鍵字存取，還是按對象名稱存取，還是二者兼而有之，這將對“對象存取器”類的設計提出不同的要求。第六十一頁，共一百零五頁，編輯于2023年，星期三圖15-2中的三個特殊類照原樣繼承了“對象存取器”的屬性，但繼承來的服務是多態(tài)的，算法各不相同。第六十二頁，共一百零五頁，編輯于2023年，星期三圖15-2第六十三頁，共一百零五頁，編輯于2023年，星期三問題域部分的修改。由于每個需要長久保存其對象實例的類都需要上述屬性和服務，因此可以增加一個一般類來定義它們，作為共同協(xié)議，供所有這樣的類繼承。第六十四頁，共一百零五頁，編輯于2023年，星期三以上策略可能使問題域部分的某些類由原先的單繼承變?yōu)槎嗬^承，所以對不支持多繼承的編程語言可能不適應。解決辦法是：第六十五頁，共一百零五頁，編輯于2023年，星期三

（1）在較高的層次繼承“存儲協(xié)議”。（2）在出現(xiàn)問題的類中自己定義所需的屬性與服務。（3）采用化解多繼承的策略。第六十六頁，共一百零五頁，編輯于2023年，星期三系統(tǒng)至少在以下幾種時刻需要保存或恢復對象：（1）系統(tǒng)每次啟動時要恢復所有需要預先恢復的永久對象。（2）系統(tǒng)停止運行之前要保存在本次運行期間曾經(jīng)使用而未曾保存過的永久對象。

第六十七頁，共一百零五頁，編輯于2023年，星期三（3）自系統(tǒng)啟動以來首次使用一個未曾恢復過的永對象時要首先恢復。（4）在與其他應用系統(tǒng)共享對象數(shù)據(jù)的情況下，要根據(jù)共享機制的數(shù)據(jù)一致性保證策略所要求的時刻保存或恢復對象。第六十八頁，共一百零五頁，編輯于2023年，星期三15.5.2針對RDBMS的設計

對象及其對數(shù)據(jù)庫的使用。使用RDBMS和使用文件系統(tǒng)相比，有以下幾點不同：（1）對象可能非映射式地使用庫中的數(shù)據(jù)（2）可能需要數(shù)據(jù)格式轉換第六十九頁，共一百零五頁，編輯于2023年，星期三對象在數(shù)據(jù)庫中的存放策略。用關系數(shù)據(jù)庫存放對象的基本策略是：把由每個類直接定義并需要永久存儲的全部對象實例存放在一個數(shù)據(jù)庫表中。第七十頁，共一百零五頁，編輯于2023年，星期三1）對象數(shù)據(jù)的規(guī)范化關系數(shù)據(jù)庫要求存入其中的數(shù)據(jù)符合一定的規(guī)范，并且用范式來衡量規(guī)范化程度的高低。

第七十一頁，共一百零五頁，編輯于2023年，星期三

（1）第一范式（1NF）：關系（表）的每個屬性都必須是原子的。就是說，關系的每個屬性都是單值的，它不包含內部的數(shù)據(jù)結構。（2）第二范式（2NF）：如果一個關系的所有非關鍵字屬性都只能依靠整個關鍵字（而不是依賴關鍵字的一部分屬性），則該關系在第二范式中。第七十二頁，共一百零五頁，編輯于2023年，星期三

（3）第三范式（3NF）：如果一個關系在第二范式中，而且沒有傳遞依賴，則該關系在第三范式中。（4）Boyce-Godd范式（BCNF）：如果一個關系的每個決定因素都是候選關鍵字，則該關系在BCNF中。（5）第四范式（4NF）：如果一個關系在BCNF中，而且沒有多值依賴，則該關系在第四范式中。第七十三頁，共一百零五頁，編輯于2023年，星期三為了表示某種事實已經(jīng)不存在而刪除一個元組，可能導致體現(xiàn)另一種事實的信息被同時刪除（這是刪除異常）；或者，由于一種事實尚未發(fā)生，導致體現(xiàn)另一種事實的數(shù)據(jù)無法插入到表中（這是插入異常）。如圖15-3所示的例子。第七十四頁，共一百零五頁，編輯于2023年，星期三圖15-3（a）

第七十五頁，共一百零五頁，編輯于2023年，星期三圖15-3（b）

第七十六頁，共一百零五頁，編輯于2023年，星期三圖15-3（a）是一個數(shù)據(jù)庫表（關系）。該表符合2NF，但是它不符合3NF，因為有傳遞依賴，即Fee依賴Building，而Building又依賴SID。這種傳遞依賴所帶來的更新異常問題是：當一座建筑物中的最后一位房客（例如表中的150號學生）退房時，刪除相應的元組將導致反映這座建筑物收費多少的信息從表中消失；反之，在一座建筑物無人入住之前，關于它收費多少的數(shù)據(jù)也無法插入到表中。第七十七頁，共一百零五頁，編輯于2023年，星期三這個表進行規(guī)范化的辦法是把它分解成如圖15-3（b）所示的兩個表，一個反映每學生住在哪座建筑物，另一個反映每座建筑物的收費標準。這樣一來，以上兩種信息的插入和刪除不再相互制約了。第七十八頁，共一百零五頁，編輯于2023年，星期三總結以上的討論，可得到以下幾點認識：（1）OOA得到的類其屬性很可能是非原子的。（2）運用面向對象技術，可以在很大程度上解決2NF、3NF、BCNF以及4NF所要解決的更新異常和數(shù)據(jù)冗余問題，但是不能保證在任何情況下都能解決上述問題。（3）遺留的問題可通過常規(guī)的規(guī)范化策略解決，但是未必規(guī)范程度越高越好。

第七十九頁，共一百零五頁，編輯于2023年，星期三2）修改類圖。規(guī)范化意味著，從類圖中原有的類到數(shù)據(jù)庫表，數(shù)據(jù)格式發(fā)生了變化。現(xiàn)在的問題是如何在設計中體現(xiàn)這種變化。有以下兩種策略：第八十頁，共一百零五頁，編輯于2023年，星期三

（1）保持原先的類圖不變，只是按規(guī)范化的結果定義數(shù)據(jù)庫表。（2）按照規(guī)范化的要求修改類圖，無論是各個類內部的屬性變化，還是把一個類分解成兩個類，都體現(xiàn)為對類圖的修改。第八十一頁，共一百零五頁，編輯于2023年，星期三3）確定關鍵字。對每個需要在數(shù)據(jù)庫中存儲其對象實例的類都要確定一個關鍵字。第八十二頁，共一百零五頁，編輯于2023年，星期三4）從類圖到數(shù)據(jù)庫的映射。以下通過幾個例圖討論幾種典型情況的處理：第八十三頁，共一百零五頁，編輯于2023年，星期三

（1）對一般-特殊結構的處理。如圖15-4所示的一般-特殊結構中，假定A是一個不用于創(chuàng)建對象實例的類（稱做抽象類），B、C和D都要創(chuàng)建對象實例。第八十四頁，共一百零五頁，編輯于2023年，星期三圖15-4第八十五頁，共一百零五頁，編輯于2023年，星期三（2）對關聯(lián)的處理。對關聯(lián)的一般實現(xiàn)策略是，在連接線一端的類中定義一個（或一組）屬性，它的值表明另一端類的哪個對象實例與本端的對象實例相關聯(lián)。第八十六頁，共一百零五頁，編輯于2023年，星期三

對于一對一的關聯(lián)，無論在哪一端的類（以及它所對應的表）中設置這樣的屬性均無不可。但是在哪一端設置更好些還值得進一步考慮。如圖15-5所示的情況，設置在A端比設置在B端更便于實現(xiàn)。第八十七頁，共一百零五頁，編輯于2023年，星期三圖15-5第八十八頁，共一百零五頁，編輯于2023年，星期三

對于一對多的關聯(lián)，沒有別的選擇，只能從多重性約束為“*”的一端指向多重性約束為“1”的一端。例如在圖15-6中，應該在A類定義指向B類對象的屬性。第八十九頁，共一百零五頁，編輯于2023年，星期三圖15-6第九十頁，共一百零五頁，編輯于2023年，星期三多對多的關聯(lián)可化為兩個一對多的關聯(lián)，例如圖15-7（a）可以化為圖15-7（b）。這種轉化應該在類圖中完成。第九十一頁，共一百零五頁，編輯于2023年，星期三圖15-7（a）第九十二頁，共一百零五頁，編輯于2023年，星期三圖15-7（b）

第九十三頁，共一百零五頁，編輯于2023年，星期三

（3）對整體-部分結構的處理。當應用系統(tǒng)永遠不可能把整體對象和它的部分對象分開并進行重新組合時，通常可以采用緊密、固定的實現(xiàn)方式。但是在實踐中即使對這種情況也可以采用松散、靈活的實現(xiàn)方式。第九十四頁，共一百零五頁，編輯于2023年，星期三數(shù)據(jù)接口部分對象類的設計和問題域部分的修改。在采用RDBMS的情況下，系統(tǒng)