物件資料管理.doc

此文檔收集于網(wǎng)絡，如有侵權(quán)，請聯(lián)系網(wǎng)站刪除物件導向資料庫管理 Part I 物件資料庫管理概論1第一章 前言1第二章 物件(Objects)32.1物件(Objects)32.2 物件識別碼(Object identifiers)32.3物件鍵值(Object keys)42.4物件屬性(Object attributes)52.5參考屬性(Reference attributes)52.6群集屬性(Collection attributes)62.7衍生屬性(Derived attributes)62.8程序(Procedures)7第三章 關係(Relationships)93.1子類別和父類別的關係(ISA)93.2二元關係(Binary relationships)93.3非二元關係(Nonbinary relationships)103.4 相反屬性(Inverse attributes)123.5 關係的實作(Relationship implementation)123.6 參考完整性(Reference integrity)13Part II Control Concept of OODMS15第四章 綱要演進(Schema evolution)154.1 綱要(Schema)154.2 綱要改變的分類164.3 綱要修改四個主要方法18第五章 物件版本管理(Object versions)205.1 版本管理205.2 物件導向資料庫版本管理21第六章 交易控制(Transactions control)256.1同步和復原概念256.2 典型的交易特性266.3 交易的鎖定276.3.1 鎖定模式276.3.2 兩階段式鎖定286.3.3 死結(jié)(Deadlocks)286.4 樂觀的同步控制296.5 復原30第七章 授權(quán)(Authorization)327.1 概念327.1.1 明示性正向授權(quán)(explicit positive authorization)327.1.2 暗示性授權(quán)(implicit authorization)327.1.3 正向/負向授權(quán)(Positive/negative authorization)337.2暗示授權(quán)(Implicit authorization)347.2.1授權(quán)使用者(Authorization Subjects)347.2.2授權(quán)操作(Authorization Operations)357.2.3授權(quán)物件(Authorization Objects)36第八章 資料庫的效能表現(xiàn)408.1 前言408.2 OODB的效能考量(Performance consideration)408.3 物件導向資料庫之績效評估方面41Part III C. J. Date對OO-Model觀點43第九章 Mr. DATE對於物件導向模式的評論439.1 簡介439.2 物件導向模式的回顧439.3 定義域=物件類別469.3.1 定義域469.3.2 型態(tài)繼承（Type Inheritance）509.3.3 結(jié)論539.4 關連物件類別559.5 物件導向關連式的共存模式64Part IV 其他補充66第十章 Introduction of Object Data Management SystemObjectStore6610.1 ObjectStore的特色：6610.2 ObjectStore Development tools6810.3 ObjectStore Database Management Highlights6910.4 結(jié)語70參考資料71精品文檔Part I 物件資料庫管理概論第一章 前言物件導向資料庫系統(tǒng)（Object-Oriented Database）的發(fā)展動機來自物件導向程式語言，物件在物件導向語言中的生命週期只有在程式執(zhí)行期間而已。由於使用者需要儲存已處理完畢物件的需求，促成儲存物件的物件導向資料庫的發(fā)展，透過物件導向資料庫，物件可以永久存在，同時達成共享的目的。其次，隨著其他領域如工程、專家系統(tǒng)及多媒體的發(fā)展，多樣且複雜的資料儲存型態(tài)的需求，也帶動了物件導向資料庫的蓬勃發(fā)展，因此物件導向資料庫的應用也變得更加廣泛。物件導向資料庫主要架構(gòu)：1.資料模式：此類資料庫之資料模式根源於物件導向程式語言。物件導向程式語言主要包含抽象資料型態(tài)的概念，此型態(tài)清楚地定義一個資料結(jié)構(gòu)(或物件)之公有與私有的部分。抽象資料型態(tài)在物件導向程式語言中，稱為類別(Class)，封裝了物件之私有的資料部分與公有的程序部分(稱為Method)。封裝 (Encapsulation)的理由，主要是想透過模組化來簡化程式的建立與維護工作。物件是一個黑箱(black box)，能被系統(tǒng)獨立地建立與修改，只要其公有的介面 (Method)沒有被改變。2.資料庫結(jié)構(gòu)：此類資料庫之資料庫結(jié)構(gòu)是，擴大目前的程式語言(如C+)，使其提供永續(xù)(Persistence)、同時存取控制(Concurrency Control)、與其他資料庫能力。此類資料庫管理系統(tǒng)傳統(tǒng)上提供一個查詢語言，但查詢語言與程式語言都在應用系統(tǒng)程式環(huán)境裡執(zhí)行，分享相同的型態(tài)系統(tǒng)和資料工作空間。亦即此結(jié)構(gòu)對資料提供一個單一的環(huán)境。物件導向資料庫的特色：物件導向資料庫為一個支持以物件導向為基礎模式的資料庫管理系統(tǒng)，利用綱要（Schema）提供對物件的描述，持續(xù)儲存物件的能力以及定義與處理的語言。它包含了一般資料庫所有的查詢語言（Query Language）、索引（Indexing）、叢集（Clustering）、同步控制（Concurrency Control）、多使用者存取（Multi-user access）及復原（Recovery）等技術(shù)，亦必須提供版本管理（Version management）及綱要演進（Schema evolution）的管理能力。因此，物件導向資料庫可視為物件導向技術(shù)與資料庫管理功能的結(jié)合體，結(jié)合了資料庫的管理功能及物件導向的物件認證（Object Identity）抽象資料型態(tài)（Abstract Data Typing）及繼承（Inheritance）特色。在本部份中，探討有關連式模型及一些進階資料庫技術(shù)。在ODMS的主要功能是在支援工程上、科學上、及辦公室應用程式和一些較複雜的傳統(tǒng)商業(yè)應用程式。我們將把焦點放在ODMS所提供的功能和一些在實務上已經(jīng)被用來建構(gòu)這些功能的方法。物件資料庫管理的工作仍然處於初期發(fā)展階段，沒有像關連式系統(tǒng)一樣的單一資料模型，現(xiàn)在仍存在許多開放性的研究議題於物件資料庫管理方面。因為這麼多的方法已經(jīng)被使用，因此要提供一個單一的，整合性的物件資料管理描述是不太可能的。第二章 物件(Objects)2.1物件(Objects)“物件” 在物件導向的觀念裡，所有的東西都是以物件表示，物件之間則透過訊息(message)做相互的溝通，一個物件包含一個唯一的物件識別編號(Object Identity，簡稱OID)、一個狀態(tài)(state)與一組物件運作行為(behavior)，物件的組成是來描述物件的屬性與其處理程序；在資料庫系統(tǒng)中，物件又有著許多的意義，然而一般在物件資料管理系統(tǒng)(ODMS)中則具體呈現(xiàn)兩個物件最基本的特性。1.物件群集(Object grouping)：物件本身可以用來代表附屬於真實世界實體中的群組資料，也就可以說是由一組物件所組合而成的物件，例如：一份文件或一個人。與此相關的說法，稱之為複合物件(Complex Objects)。OO系統(tǒng)通常都提供Complex Objects的概念，讓使用者能夠?qū)⒄鎸嵤澜绲膫€體表示出來。在一個Complex Objects中，可以有許多不同個數(shù)的欄位，每一個欄位的值可以是atomic data value或者指示參考到其他的物件。2.物件識別碼(Object identify，OID)：物件導向資料庫給予每一個物件本身包含一個唯一且獨立的識別值，以顯示物件的認證具有唯一性及不可改變性。由於關連式模型(Relational model)是以值為基礎的(value-based)：一個實體或物件是經(jīng)由主鍵來識別。而在一個以識別為基礎(identity-based)的物件導向資料庫系統(tǒng)中允許一個物件可以經(jīng)由內(nèi)部產(chǎn)生的唯一識別碼來被其他的物件所參考，我們稱為物件識別碼。2.2 物件識別碼(Object identifiers)首先要注意，OID是位址或指標，而且是使用者所看不到的。OID的優(yōu)點是方便控制物件的儲存以及和其他物件之間的聯(lián)繫。OID的長度會大大的影響資料庫的大小。主要的原因是因為物件之間的參考，在OO應用程式之間是經(jīng)常發(fā)生的。OID在實作上有幾種方法，可能是實體(Physical)或邏輯(Logical)的位址表示方法，以下列出四種方式：1. 位址(Address)：利用物件中，儲存的實體位址來識別。位址長度約為32bit或更少，以這種方式來讀取物件資料是最快、最有效率的方式。然而在資料庫系統(tǒng)中很少使用實體位址，因為若要將物件移動或刪除，得先將現(xiàn)存所有物件之間的參考關係都被全部找到，才能夠被允許將該物件移動或刪除，因為被刪除錯物件，造成參考不完整性出現(xiàn)。2. 結(jié)構(gòu)化位址(Structured address)：此種方式是關連式系統(tǒng)中最常使用的一種方式。位址中包含了實體和邏輯資料兩個部份，在左邊的位數(shù)放物件所儲存的實體segment和page號碼，便於快速找到物件所在的磁區(qū)；在其他的位數(shù)則存放一個邏輯的偏移量，用來精確的找到物件存放放置。此種方式下我們可以輕易移動或修改物件資料。3. 代替性編號(Surrogates)：這是一種純粹邏輯表示的方法，利用演算來保証產(chǎn)生一個唯一的OID。再根據(jù)這個邏輯OID對應到實體位址來讀取物件資料。此種方式在執(zhí)行時的效率最差。4. 型態(tài)代替性編號(Typed Surrogates)：這種方式是上述第三種方式的修正，包含型態(tài)編號和物件編號兩個部份。物件編號部份是由每一個型態(tài)藉由不同的計數(shù)器所產(chǎn)生。2.3物件鍵值(Object keys)一些ODMS允許物件可以取一個有意義的名稱及物件識別碼。例如，下列所展示的Document資料庫中，我們可能會使用標題名稱來查詢Document物件及其所包含的Chapter物件。這些名稱就好比在關連式系統(tǒng)中的主鍵的功能一樣；在物件導向系統(tǒng)中我們叫它物件鍵值。事實上，假如一個資料庫系統(tǒng)提供唯一的物件識別碼但是在處理的過程中放棄了物件鍵值，可以說是遺失了在原有關連式系統(tǒng)中的一些功能。當然，任何一個物件屬性值都可以被視為一個鍵值，只要DBMS允許聯(lián)合物件查閱。定義鍵值的好處是什麼呢？主要是為了方便性：一個簡單的語法就可以藉由鍵值來參考到物件，而且DBMS也可以自動的利用鍵值是否唯一來確認完整性限制(integrity constraint)。另外，OO的應用程式一般被應用在視為可以在互相聯(lián)結(jié)的物件網(wǎng)路上使用。所以一個程式一開始，需要存取某些已知的物件，然後再透過此物件關聯(lián)存取其他物件。因此，資料庫也必須提供某些機制能夠識別一個到多個物件，所以可以透過替物件命名(Naming)的方式達成。Document: title: STRING;revision: DATE;keywords: SETSTRING;chaps: LISTChapter Chapter: title: STRING;number: INTEGER;doc: Document 在大部份的ODMS中，物件間的參考不是利用OID就是使用物件鍵值。在ODMS中物件鍵值的實作方式和傳統(tǒng)的關連式系統(tǒng)建立主鍵的方式不太一樣。物件鍵值可以利用hash或B-tree索引對應到OID。例如在ObjectStore系統(tǒng)中允許執(zhí)行如下的敘述：Document:title=”O(jiān)bject Data Management”:查詢物件2.4物件屬性(Object attributes)物件是使用者定義的，用來表示真實世界或抽象的一個實體，例如；文件、人等。在關連式系統(tǒng)中，利用記錄(records)來表示物件，在表格中的值則以好比記錄的屬性值方式來儲值。而在物件導向資料庫中，1. 物件屬性值可以是複雜值(complex value)，如群集或是參考到其他物件的屬性值。2. 使用者可以自行定義所需的資料型態(tài)，彌補內(nèi)建資料型態(tài)的不足。3. 物件屬性也可以是影音資料，通常這些資料型態(tài)稱之為binary large objects(BLOBS，二進位大型物件：用來儲存包含如影音、聲音、視訊等大量二進位資料的物件)。好比關連式系統(tǒng)中記錄的屬性值一樣，在ODMS中物件的屬性有屬性名稱且一般都以“.”的表示方式來參考到某物件的屬性值。例如：在文件類別中物件d的revision屬性值可以表示如下：d.revision無論型態(tài)或大小為何，只要屬性包含文字值(literal values)則稱為簡單屬性。也就是說屬性值屬於文字值，就稱為簡單屬性。2.5參考屬性(Reference attributes)在上節(jié)中我們介紹了簡單屬性的表示方式。在本節(jié)中將介紹三種複雜的屬性：參考(reference)、群集(collections)、和衍生屬性。參考屬性是用來表示物件間的關係(relationships)。參考屬性類似程式語言中的指標功能，或是關連式系統(tǒng)中外來鍵(foreign key)的功能。然而，還是有一些重要的差異：1. 參考屬性不可以被塗改的(corrupted)，但是指標可以被塗改。當被參考到的物件被殺掉時，則參考屬性將自動失效。2. 參考屬性不像外來鍵使用一個使用者看得見的(user-visible)值來建立聯(lián)結(jié)關係。所有在被參考物件中的值可以被改變，但是參考屬性值仍將指到同一個物件。相對於在關連式系統(tǒng)中使用外來鍵，我們可以定義一個Chapter物件的參考屬性Doc來建立和Document物件間的參考關係如下：Chapter: Title: String;Number: Integer;Doc: Document 2.6群集屬性(Collection attributes)第二種複雜的屬性，群集屬性，通常被使用來表示串列值(LIST)、集合值(SET)、或是陣列值(Array)。群集可以包含簡單屬性值或是參考屬性值。如下面的例子所示，我們可以定義二個Document物件的集合值屬性：Document: Title: String;Revision: Date;Keyword: SETString;Chaps: LISTChapter 第一個群集屬性，Keyword，是Document物件中關鍵字字串的集合，可以利用主題的方式來查閱文件。第二個群集屬性，Chaps，代表Document物件所包含的Chapter物件串列。2.7衍生屬性(Derived attributes)屬性值可以被定義成程序的方式而不僅是值的方式，程序可以指定於當值被查詢或指派時執(zhí)行。衍生屬性最大的特色是，此屬性值並沒有明顯的儲存著，而是在需要時計算出來。另外，衍生屬性也可以增加資料的獨立性。所謂的資料獨立性，是指當資料庫的綱要改變時，不會影響外部對此綱要的景觀。不過一般程式語言不容易支援此功能。(In C+ for example, a function call is syntactically different than an attribute reference, so providing transparent derived attributes is not possible.)例如，假設我們採用一個新的機制來追蹤Document物件的修正版本，定義一個Document的屬性叫creation其型態(tài)為integer，用來產(chǎn)生日期資料。然後，我可以以程序的方式，也就是衍生屬性的方式，來重新定義舊的revision屬性如下所示：Document: creation: Integer; /* seconds since 1950 */revision: DATE PROC () =secsToDate(creation + secsTo1950);2.8程序(Procedures)到目前為止，前面所提到均屬於處理結(jié)構(gòu)的物件導向(structural object-oriented)物件內(nèi)部的資料結(jié)構(gòu)。在本節(jié)中，我們將介紹操作物件的程序。相較於傳統(tǒng)的DBMS，ODMS提供一個完全計算性(computationally complete)的資料庫存取語言，就是資料庫語言可以執(zhí)行程式語言所能作的相同運算。除此之外，ODMS也提供連結(jié)資料庫物件和程序的功能。在行為物件導向系統(tǒng)(behaviornally object-oriented systems)所使用的程序稱為方法(method)，用來封裝或隱藏物件所包含的屬性。一個物件所包含的屬性是私有性的(private)，唯有透過物件所提供的方法才能存取或修改這些私有性的資料。ODMS的應用程式必須要有將程序和資料一樣的儲存在資料庫中的能力。事實上，在物件導向系統(tǒng)中，物件中所包含的程序是唯一使用者可以直接存取的。一般ODMS有兩種方法來儲存程序的內(nèi)容：1. 程序的儲存和執(zhí)行都在現(xiàn)存程式語言的環(huán)境之中，以一個程式檔的方式；程序並未和物件型態(tài)定義一起儲放在資料庫中。許多的物件導向ODMS產(chǎn)品大都採用此種方式。2. 程序的原始碼和部份己編譯過的二進位碼都儲存在資料庫之中，這種方式通常被用於關連式系統(tǒng)所延伸的物件導向系統(tǒng)如；POSTGRES、ORION。第一種方式在執(zhí)行較有效率因為不須要再作動態(tài)繫結(jié)(dynamic binding)，但是第二種方式使得新的程序可以藉由網(wǎng)路分享給眾多使用者。第三章 關係(Relationships)物件導向的產(chǎn)品及物件導向的術(shù)語裡的relationship一般來說是指關連式資料庫中的外部鍵(foreign key)關係。不過它還可以再區(qū)分為三類：3.1子類別和父類別的關係(ISA)以類階層來代表，例如：ECTANGLE ISA (PLOYGON) 四邊形是屬於多邊形的3.2二元關係(Binary relationships)在物件導向資料系統(tǒng)中關係的表示是利用前面章節(jié)所提到的複雜屬性來完成：參考(reference)和參考群集(collections of references)屬性。二元關係可以利用如下的方式來建立：1. 我們藉由分別新增一個參考屬性到抽象資料型態(tài)A和B中，來表示A和B二者之間的一對一關係。2. 我們藉由新增一個參考屬性（reference attribute）到A和一個參考群集屬性（reference-set attribute）到B，來表示A和B兩者之間的多對一關係。3. 我們藉由分別新增一個參考群集屬性到A和B中，來表示A和B之間的多對多關係。圖1圖1提供上述三種情況下的二元關係例子。在圖的左邊是一些定義物件型態(tài)的語法，在圖的右邊則是利用圖形來表示物件實例和根據(jù)定義所產(chǎn)生的關係。例如：Document D1有一個Index I1；三個Chapters C1、C2、C3和一個唯一的Author P2。Document D2有二個Authors P1、P2；唯一的Chapter C和Index I2。3.3非二元關係(Nonbinary relationships)之前介紹過了二元關係在物件導向系統(tǒng)中的表示方式，現(xiàn)在讓我們進一步的介紹非二元關係，也就是多元關係的表示方式。請注意，要表示一個多元的關係必須建立一個新的物件型態(tài)來表示，該物件型態(tài)的名稱就代表該多維關係的名稱。從使用者的觀點來看，利用中介物件(intermediate object)來表示多元關係使得整個資料庫的結(jié)構(gòu)顯得更為複雜。然而，在關連式系統(tǒng)中也是同樣的方式，須要一個額外的關連來表示。下圖為多元關係的例子：圖2.3.4 相反屬性(Inverse attributes)在3.2節(jié)二元關係的圖1中，文件（document）和章節(jié)（chapter）之間的關係是以如下的方式來處理：在文件(document)物件中我們用chaps屬性來代表它的章節(jié)，而在章節(jié)(Chapter)物件中我們用doc屬性來代表它屬於那個文件。注意，這不只是單單加入屬性而已。相反地，我們使用雙向箭頭來代表相反屬性（inverse attributes），所以doc: Document chaps; chaps: LIST Chapter doc;表示doc的相反屬性是chaps，而chaps的相反屬性是doc。我們稱這個兩屬性互相相反，也就是它們代表同一件事情的不同的兩個面。在3.2節(jié)的圖1中，還有另外兩對相反屬性，第一個是文件和目錄之間的一對一關係，它們被表達成一組相反屬性for及index，第二個是文件和作者之間的多對多關係，它們也被表達成一組相反屬性pubs及authors。注意，每一組的相反屬性間的彼此關係必須不斷的保持正確且一致。例如說，我們?yōu)橐涯骋徽鹿?jié)新增至某一文件中，我們設定了該章節(jié)物件的doc屬性，那麼，資料庫系統(tǒng)就必須自動地修改該文件物件的chaps屬性。同理，如果某一章節(jié)被移轉(zhuǎn)屬於另一文件，則這兩個相反屬性都必須同時被更動。所謂參考完整性的問題即是如何維持相反屬性間一致的問題，之後將討論此一問題。3.5 關係的實作(Relationship implementation)在不同的OODBMS對於關係的實作有不同的方法。在磁碟上，關係一般而言是使用OID來儲存。但是，一但放到記憶體中，關係可以用OID來表示，或者將OID轉(zhuǎn)換成(Swizzled)虛擬記憶體的指標(ADDRESS)來表示，此種方式稱為pointer Swizzling。Swizzling是一種將以磁碟為主的關係表示，轉(zhuǎn)成物件在記憶體位置的程序。當物件有需要時被載入時，這個程序就會被執(zhí)行。Pointer Swizzling 的好處可以加速物件在記憶體存取物件的速度。（Swizzling原理在此不贅述）3.6 參考完整性(Reference integrity)假如我們想在物件識別基礎(object-identify-based)表示方式下提供參考完整性，好比在關連式系統(tǒng)下利用鍵值來達成，我們沒有辦法很簡單的確認參考屬性是否參考到適當型態(tài)的合法物件。所以現(xiàn)在我們只能列出幾種不同層次的參考完整性來討論：1. 沒有完整性檢查(No integrity checks)：一個系統(tǒng)可能在參考完整性方面不提供任何的檢查。在這種方式之下，可能會發(fā)生參考到錯誤型態(tài)的物件，甚至是不存在的物件，只有靠使用者自行在應用程式中撰寫方法來實現(xiàn)參考完整性。也就說，假如一個物件已經(jīng)被刪除了，使用者必須先確定所有參考到這個物件的參考屬性都已經(jīng)事先被移除了或是設為NIL。所以使用這個方法具有危險，因為使用者會有所疏忽的狀況存在。2. 參考確認(Reference validation)：系統(tǒng)可以確認被參考到的物件存在且是正確的型態(tài)。不過，物件刪除是不被允許的。以下介紹二種方式達到此一水準n 當物件不再被使用者存取時，系統(tǒng)必須可以自動的將物件刪除，例如GemStone的作法。一般採用此種方式的系統(tǒng)，當物件應該被自動刪除時，並不允許讓使用者直接刪除或執(zhí)行參考計數(shù)(reference counting)等演算法。n 當物件不再被使用時，系統(tǒng)允許物件直接被刪除掉，但是相關的參考將自動的被刪除掉。這種方法可藉由許多的方式來達成。假設OIDs不被再利用，則參考到已經(jīng)刪除物件的參考隨即將被刪除。假設一個有效率的機制被設計來發(fā)現(xiàn)所有跟某個物件有關的參考，則參考到已經(jīng)被刪除物件的參考將可以全部設成NIL，例如，IRIS就是採取這種方式。3. 關係完整性(Relationship integrity)：系統(tǒng)允許直接對物件或關係進行刪除或修改，並自動地保持物件間關係的正確性。前面所提到利用相反屬性(inverse attribute)來表示二維關係的方式即提供如關連式系統(tǒng)下的參考完整性限制，但是1和2並未提供。4. 自訂參考語意(Custom reference semantic)：大部份較複雜的系統(tǒng)允許資料庫設計者對每一個型態(tài)、物件、或關係指定自訂適合(custom-tailored)的參考完整性語意。例如，當一個Document被刪除時，使用者可能希望把相關的Chapter都刪除，然而在上面第3點說明的處理方式下只能將參考到Document的關係刪除或設為NIL來維持參考完整性限制。這種刪除操作在物件導向的系統(tǒng)裡面是沒有提供的，使用者必須自行撰寫方法來執(zhí)行。Part II Control Concept of OODMS物件導向資料庫中變動是常態(tài)而非異常，物件導向資料庫管理綱要演進的特色，與其他資料庫管理系統(tǒng)比較較具優(yōu)勢。Smith 與 Joshi Smith and Joshi, 1995 以物件導向模組化能力的角度進行研究，認為物件導向資料庫提供豐富的模式化能力，再加上物件導向技術(shù)可將複雜的製造環(huán)境切割為小的模組的能力，透過可以擴充的特性讓未來系統(tǒng)的修改更簡單。其他有關物件導向的優(yōu)點，例如在於處理複雜的資料型態(tài)及複雜的資料操作時具有優(yōu)異的表現(xiàn)，因此物件導向資料庫在製造環(huán)境的適用性明顯優(yōu)於目前現(xiàn)有資料庫管理系統(tǒng)。物件資料管理產(chǎn)生了資料庫同步控制(concurrency control)和復原(recovery)上的新問題，因為ODMS提供使用者在執(zhí)行交易時的新同步需求：物件資料可以被長時間的讀取，同一物件的不同版本(version)可以同時儲存在一個資料庫之中，進而產(chǎn)生Version control的議題。在關連式系統(tǒng)中，提供同步控制和復原兩種機制來控制商業(yè)應用程式的交易處理。同樣地，ODMS也使用新的技巧如：版本控制來控制交易處理。第四章 綱要演進(Schema evolution)4.1 綱要(Schema)綱要演進（Schema evolution ）是物件導向資料庫非常有用的功能之一，如果物件導向資料庫沒有綱要演進，對於物件導向資料庫的綱要（Schema），我們只能加入新的類別（Class），而不能重新定義已存在綱要裡的類別；假如使用綱要演進，我們可以重新修改資料庫裡的類別。例如：我們設計顧客資料庫時，顧客姓名的物件欄位設六位字元，後來卻發(fā)現(xiàn)需要輸入八位字元的字，我們就可以使用綱要演進將六位字元改成八位字元（如圖 3）。圖3 Schema是型態(tài)定義的集合，包括所定義的架構(gòu)及行為(A schema is a set of type definitions-including their definitions of the structure and the behavior.)傳統(tǒng)的資料庫產(chǎn)品對於現(xiàn)有的綱要（schema）改變只提供相當簡單的功能。如對現(xiàn)有的關聯(lián)(relation)加上一個新的屬性（欄位）等等。不過，有一些應用需要複雜的綱要(Schema)來改變功能的支援，一些物件導向的雛形系統(tǒng)對這個問題已有相當深度的研究。這個問題在物件導向的環(huán)境裡比在關聯(lián)式資料庫的環(huán)境裡更加複雜，原因是物件導向資料庫的綱要比關聯(lián)式資料庫更為複雜。大部份的ODMS並不提供對現(xiàn)存綱要程式的修改。在某些狀況下，綱要的改變會自動的反應到相關的物件。藉由綱要定義架構(gòu)(schema definition frame)可以來說明綱要(Schema)是由它自己的subschema所組成，如下幾何學的schema表示法：schema Geometry issubschema CSG;subschema BoundaryRep;end schema Geometry;schema BoundaryRep istype Cuboid is ;type Surface is ;type Edge is ;type Vertex is ;var exampleCuboid: Cuboid;end schema BoundaryRep;一般schema也為包含actual type definitions，且上面這個例子使用schema BoundaryRep來定義變數(shù)exampleCuboid。4.2 綱要改變的分類ODBMS會自動維護你在綱要中所指定關聯(lián)的參考完整性，如刪除屬性以及superclass，ODMS會自動反應。另外，新增一個屬性欄位和Superclass，只要當default value屬性值可以接受，ODMS也會自動反應。舉例來說，你刪除一個Student物件，ODMS將自動消除該Student物件到所有Course物件的link，也會自動消除所有Course物件到該Student物件的link。Banerjee在1987年定義了一些綱要改變的分類，以下我們將針對這些分類作一說明：1. 改變類別中型態(tài)的元件(修改類別中的屬性定義)1.1 改變屬性1.1.1 新增一個屬性1.1.2 刪除一個屬性1.1.3 改變屬性名稱1.1.4 改變屬性型態(tài)1.1.5 繼承一個不同的屬性定義1.2 改變方法1.2.1 新增一個方法1.2.2 刪除一個方法1.2.3 改變方法名稱1.2.4 改變方法的實作1.2.5 繼承一個不同的方法之定義1.3 改變關係2. 改變類別階層(修改類別間的繼承關係)2.1 新增一個父類別/子類別關係2.2 刪除一個父類別/子類別關係2.3 改變繼承順序(在多元繼承系統(tǒng)才存在)3. 改變類別本身(修改與刪除資料庫中的類別)3.1新增一個類別3.2刪除一個類別3.3改變類別名稱l 修改類別中的屬性定義：該改變的屬性也會改變到所有下屬的子類別當中，改變方法就是指改變類別的運算方法；但是要注意到修改屬性預設值，只能在原宣告類別中做，不可以在任何其他子類別中對此繼承所得的屬性做預設值的修改；改變類別屬性的預設值，相當於對該屬性做更新的動作一般。l 修改類別間的繼承關係：新增類別關係就是在現(xiàn)有類別之上宣告另一個類別為其父類別，這樣該class及其底下所有子類別就會繼承所有superclass(父類別)上的屬性與運算方法。l 修改與刪除資料庫中的類別：新增類別時，與關聯(lián)式資料庫最大不同點在於OODB可以放置集合式的資料，以便讓使用者可以一次將集合式的資料(SET)加到集合型態(tài)的屬性中。4.3 綱要修改四個主要方法在很多情況下，綱要演進是很重要的問題且相當複雜，因為會遇到父/子類別關係上的衝突，以下是當綱要修改時維護資料實例(data instance)正確的四個主要方法：l Write-once types：這是最簡單的一種方法，當型態(tài)(type)已經(jīng)建立實例(instances)則不允許再修改綱要內(nèi)容。假如使用者希望新增一個屬性到綱要內(nèi)容，則系統(tǒng)將建立一個新的型態(tài)並將舊有資料複製到新型態(tài)去。l Immediate update：在這個方法下，當綱要的內(nèi)容修改後將立即影響到原有型態(tài)下的現(xiàn)存資料(existing data)。例如：假設新增一個屬性到某一物件型態(tài)中，則原有型態(tài)下現(xiàn)存的所有物件都將自動地新增此一屬性並將其設為null值。這種方式是目前大部份ODMS產(chǎn)品所使用的方式。l Lazy update：這種方法的處理方式是，當綱要的內(nèi)容修改時，將延緩對原有型態(tài)下現(xiàn)存物件的修改，直到物件下一次被使用時一併修改。當物件被抓到主記憶時，一個物件的標籤將指示系統(tǒng)該物件是否已修改過，若否，則同時進行修改。在這種方式下，系統(tǒng)必須儲存舊有的綱要資訊及程序內(nèi)容直到所有的物件都修改完成。l Schema mapping：這是一種最極端的作法，當綱要的內(nèi)容修改時，將無限期地延緩對原有型態(tài)下，現(xiàn)存物件的修改或直到要求重新組織(reorganization)時為止。系統(tǒng)必須維護新舊型態(tài)間的對應(mapping)。和Lazy update的作法一樣，系統(tǒng)必須同時維護多個版本的綱要。綱要對應(schema mapping)是很困難的，所以目前尚未有系統(tǒng)採用此一方式。第五章 物件版本管理(Object versions)5.1 版本管理在任何資料庫系統(tǒng)於多人同時使用資料資料庫的情況下，資料處理（Transaction）必須具有支援單元性（Atomicity）、一致性（Consistency Preservation）、隔絕性（Isolation）及持久性（Durability）四項特性才能夠保證在任何情況下，維持資料被多人共用時的正確性。這樣的非獨立性的資料處理方式在執(zhí)行過程中須相互等待，因此資料庫系統(tǒng)在資料的存取處理不能持續(xù)太長的時間，否則整體效率將降低。許多應用軟體都需要物件的多版本管理概念，來進行軟體開發(fā)。例如，軟體發(fā)展，硬體設計，文件建立等等。目前有一些物件導向系統(tǒng)已有支援，這些支援通常包括：建立某物件之新版本能力。設立某一物件版本成為目前資料庫的版本。刪除過時老舊的版本。查詢某物件的版本歷史。注意，物件版本的歷史並不一定是直線式的，下圖為一般版本管理的歷史圖，其中版本V.2分裂為兩個不同的版本V.3a及V.3b，然後再合併成為版本V.4。圖4當我們有許多物件的不同版本及版本歷史時，一個明顯的問題便是我們到底該使用那一個版本？例如說，當一個物件有了更新版本時，以前指向該物件的參考（reference）是該仍指向舊版本還是指向新版本？使用者查詢時，是把那一個版本的物件給他？要回答這些問題，便要談接下來會講到的組態(tài)（configuration）。5.2 物件導向資料庫版本管理物件導向資料庫應用版本管理（Version Management ）的方式，藉由版本的產(chǎn)生，讓使用者取得不同資料版本，以獲得對資料存取的獨立控制權(quán)，而展現(xiàn)出物件導向資料庫在長時間的資料處理的優(yōu)勢。長時間資料處理具有兩個優(yōu)點：允許多人可針對共用資料同時進行不同的存取作業(yè)，及資料可以被長時間鎖定而不影響整體效率。因此，最能夠發(fā)揮版本管理優(yōu)點的環(huán)境，即是對多項作業(yè)並行且必須長時間對資料進行存取鎖定的環(huán)境。在版本管理的過程尚需要三項重要的概念組態(tài)（Configuration）、工作空間（Workspace）和版本管理之運作。以下將對這三項概念分別詳述l 組態(tài)（Configuration）：物件導向資料庫中所儲存的資料置於物件之內(nèi)，所以產(chǎn)生新舊的版本乃是對物件而言。物件產(chǎn)生了新舊版本時，同時衍生了物件間新舊版本的對應問題，新版本與舊版本之間的差異在於物件內(nèi)的屬性值更動。所謂的組態(tài)（configuration）是由資料庫中，各個物件的某一版本所形成的組合體（當然這些版本間的關係必須協(xié)調(diào)一致），換句話說，組態(tài)即整體資料庫的版本。組態(tài)具有兩個功能：版本管理的基本單位及自動紀錄各物件間版本之間的對應問題。如下：1. 版本管理的基本單位：也就是說系統(tǒng)提供一些基本的組態(tài)管理機制，讓使用者根據(jù)這些機制，而建構(gòu)自己的組態(tài)管理策略。例如說，在物件導向資料庫Objectivity/DB中，它提供了三種機制：l MOVE：若物件有一個新的版本產(chǎn)生時，組態(tài)便會使用新版本的物件，而不再使用舊版本。l DROP：若物件有一個新的版本產(chǎn)生時，組態(tài)仍會使用舊版本的物件，而不使用新版本。l COPY：若物件有一個新的版本產(chǎn)生時，組態(tài)便會同時使用新舊版本的物件。2. 自動紀錄各物件間版本之間的對應：系統(tǒng)自動提供一整套的組態(tài)管理策略。例如說，在物件導向資料庫ObjectStore中，它把組態(tài)視為資料庫的快照Snapshot，只是這個快照的內(nèi)容可以讓使用者修改，我們把它的做法歸納如下：l 我們用一種特別的組態(tài)物件代表資料庫的組態(tài)。l 使用者在每次操作時，可開啟任何一個現(xiàn)存的或新的組態(tài)物件以作為資料庫的現(xiàn)在組態(tài)。l 當有新的物件版本產(chǎn)生時，我們會加上標記以記錄該物件是在那一個組態(tài)被產(chǎn)生。當使用者讀取物件時，我們會根據(jù)現(xiàn)在組態(tài)而決定該讀入那一個版本的物件。組態(tài)可視為容器，將一群相關物件放入組態(tài)成為群體，作為版本管理時的基本單位，而取用物件即是以組態(tài)為基本單位，而不再是一個個分散的物件。使用組態(tài)的概念不僅在物件版本在更新的過程中能夠自動產(chǎn)生對應的紀錄，使得未來在物件新舊版本的取用在對應上不會發(fā)生對應錯誤的問題，同時也提供了將物件依其相關程度做分類而形成存取單位，使使用者輕鬆的取用到所有相關的物件。使用組態(tài)必須先對該組態(tài)定義其功能及包含範圍，而組態(tài)的定義則必須依據(jù)設計物件（Design Object）的概念。階層式的類別關係中，上階層的類別即為所謂的設計物件。以汽車引擎為例，汽車的引擎部分由許多零件所構(gòu)成，引擎屬於上階層，因此引擎這個設計物件即可用來當成組態(tài)，成為版本管理運作時的基本單位。l 工作空間（Workspace）：要讓使用者取得個別資料卻不相互干擾，這種使用者各自具有個別作業(yè)空間的概念，稱為“工作空間”（Workspace ）。工作空間主要的功能，在於能夠提供使用者在進行資料修改時獨自運作的空間，其正在進行修改組態(tài)的物件內(nèi)容並不會讓別人看見，提供了隱密性，並提供對所需專案資料適當且具有完整版本進化連貫性的能見度（Visibility）避免不必要的資料相互交錯干擾。工作空間之間具有階層的關係，一個工作空間之下可以有數(shù)個子工作空間，上面的工作空間稱為父工作空間（Parent Workspace），相對於上方的工作空間，下方的工作空間則稱為子空間（Child Workspace），而工作空間所構(gòu)成的階層數(shù)則可視情況而定，可以只有兩層，亦能多達數(shù)層。l 版本管理之運作：使用者必須先取得相關物件才能進一步修改更新。在資料存取的過程中，所有資料庫內(nèi)的物件必存放於一個具父親的角色的整體工作空間（Global Workspace）的位置，其下有數(shù)個子工作空間(見圖 4)。使用者欲取得與其相關之組態(tài)進行設計修改，則必須向父工作空間提出要求，以取出組態(tài)至本身所在的子工作空間，方便下一步階段修改的進行，這種從父工作空間取出資料的動作稱為登記取出（Check-out）。此外，一個工作空間可以包含數(shù)個組態(tài)，也就是說子工作空間可以向父工作空間同時取用多個不同組態(tài)。登記取出（Check-out）動作允許由多位於不同工作空間的成員同時進行，且各成員所取出組態(tài)可以不相同。由於使用者使用資料時，往往會遇到多個使用者同時對一個組態(tài)進行物件屬性值修改動作的狀況，需要紀錄不同的修改過程，而版本管理亦能夠滿足此項需求，由多位使用者針對某一特定組態(tài)登記取出，以進行多方同步修改資料。綜合上述，這樣的版本管理的運作架構(gòu)，在組態(tài)取用方面可分為兩種狀況一是使用者各自取用各自所需組態(tài)，另一則是取用同一組態(tài)，同步地進行資料修改，這種多方取用同一組態(tài)的方式，稱為版本分支（Version Branching）。資料登記取出（Check-out）的動作，代表此組態(tài)的物件內(nèi)容將被進行修改，而為了保留之前的物件內(nèi)容，不希望在修改之後，失去原有物件內(nèi)容，應用版本（Version）概念，以版本歷史圖（Version History Graph）記載該項組態(tài)版本的發(fā)展紀錄，因此在組態(tài)取出的同時，也一併進行版本歷史圖的版本登記工作。完成組態(tài)中物件內(nèi)容的更新後，必須將發(fā)展出來的新版本登記放回（Check-in）父工作空間以表示完成作業(yè)，這個動作也會一併將這個新版本公佈，讓其他子空間的使用者看到。由於登記取出（Check-out）可分為兩種方式，所以在登記放回（Check-in）的方式也有兩種。若是以單一使用者取用的方式，則完成的修改以登記放回的方式處理，可是若採用多個使用者同時取用之版本分支方式，則在修改的過程除了用登記放回的方式，也可以在修改至最後的結(jié)果與原先的版本進行版本合併（Version Merging）的動作選取進行合併兩個版本中的資料，合併成為新的版本方案（如下圖 5：版本管理運作圖）。圖 5：版本管理運作圖第六章 交易控制(Transactions control)物件資料管理產(chǎn)生了資料庫同步控制(concurrency control)和復原(recovery)上的新問題，因為ODMS提供使用者在執(zhí)行交易時新的同步需求：物件資料可以被長時間的讀取，同一物件的不同版本可以同時儲存在一個資料庫之中。在關連式系統(tǒng)中，提供同步控制和復原兩種機制來控制商業(yè)應用程式的交易處理。同樣地，ODMS也使用新的技巧如：版本，來控制交易處理。6.1同步和復原概念物件導向系統(tǒng)的交易管理控制通常比傳統(tǒng)的交易管理控制來的更為複雜。通常物件資料庫是應用在工程開發(fā)上，其複雜交易可能延續(xù)數(shù)小時或數(shù)天，而傳統(tǒng)的交易僅需幾個百分之一或千分之一秒即可完成。所以：l 交易的rolling back：如果每次都是從交易開始的那一點為起始點的話，可能會產(chǎn)生對使用者無法接受的大量工作的損失。l 傳統(tǒng)鎖定的使用可能會引起無法接受的延遲（為了等待鎖定結(jié)束）。第一點指出了物件導向的交易管理需要partial rollbacks，而第二點指出了物件導向的交易管理需要非鎖定(nonlocking)的並行處理控制機能。在長時間交易(long transaction)以及巢狀交易(nested transaction)的處理上我們都需要應用這兩點的概念。以下我們針對這兩種交易形態(tài)進行解說：1.長時間交易（Long transaction）：由於教一時間越長，越容易發(fā)生存取衝突與中斷。因此在這裡，儲存點（savepoint）概念提供了partial rollback的功能。所謂的儲存點是說：對於一個長時間的交易，我們可以在中間設