複製鏈接
請複製以下鏈接發送給好友

面向對象數據庫

鎖定
面向對象數據庫系統(OODBS)支持定義和操作OODB,應滿足兩個標準:首先它是數據庫系統,其次它也是面向對象系統。第一個標準即作為數據庫系統應具備的能力(持久性、事務管理、併發控制、恢復、查詢、版本管理、完整性、安全性)。第二個標準就是要求面向對象數據庫充分支持完整的面向對象(OO)概念和控制機制。 [1] 
中文名
面向對象數據庫
外文名
object-oriented database(OODB)
類    型
認識方法學
其他稱呼
新的程序設計方法學
優    點
易維護

面向對象數據庫簡介

面向對象數據庫系統(OODBS)支持定義和操作OODB,應滿足兩個標準:首先它是數據庫系統,其次它也是面向對象系統。第一個標準即作為數據庫系統應具備的能力(持久性、事務管理、併發控制、恢復、查詢、版本管理、完整性、安全性)。第二個標準就是要求面向對象數據庫充分支持完整的面向對象(OO)概念和控制機制。綜上所述,我們將面向對象數據庫簡寫為:面向對象數據庫=面向對象系統+數據庫能力。
面向對象是一種認識方法學,也是一種新的程序設計方法學。把面向對象的方法和數據庫技術結合起來可以使數據庫系統的分析、設計最大程度地與人們對客觀世界的認識相一致。面向對象數據庫系統是為了滿足新的數據庫應用需要而產生的新一代數據庫系統。

面向對象數據庫基本技術

面向對象數據庫數據庫轉換技術

異構數據庫系統中各數據庫模式和操作之間轉換是一個關鍵研究課題。由於關係數據庫系統主宰當今數據庫應用領域,而面向對象數據庫能滿足更高一級數據庫要求,所以有必要在這兩種數據庫模型中建立一種映射關係,實現模式和操作相互轉換 [1] 
轉換一般有兩種途徑:從關係DB到面向對象DB(RDBtoOODB)和從面向對象DB到關係DB(OODBtoRDB)。OODBtoRDB轉換技術轉換時要保證一致性(對象語義和動作信息在轉換過程中不丟失)。轉換包括數據模式和數據操作轉換。
數據模式轉換
對象標識符是對象存在的唯一標誌,兩個對象相同等價於其標識符相同。與關係模式不同的是面向對象中類屬性分為原子屬性、組合屬性和集合屬性。數據模式轉換指從OODB到RDB數據描述語言(DML)的轉換,基本思路是把父類屬性擴展到所有子類中,每個類映射為一個關係;類的每個屬性映射為它對應的關係屬性。類中不同類型屬性作不同處理。默認對象標識符屬性映射為RDB關鍵字屬性,原子屬性映射為固定屬性,組合屬性映射為與主屬性對應關係關鍵字相關的外關鍵字,集合屬性映射為原子屬性加上具有兩個屬性的關係,其中一個屬性是設置與對應的集合屬性的聯繫;另一個屬性是處理集合元素。方法轉換是數據模式轉換的重要轉換,方法有定義和調用。標準RDB無支持用户自定義函數和過程的機制,近年來一些商業化RDBMS提供這方面的功能,稱為PSM子程序(包含用户自定義函數和過程)。標準PSM子程序至少支持以下兩種功能:
①創建用户自定義函數,並從標量表達式中調用此函數;
②創建用户自定義過程,並通過一個新的SQL語句(典型的是CALL)調用這些過程。
繼承性是OODBMS典型特性,M.Blaha提出四種藉助關係表處理繼承性的方法,其核心是把分層結構中的每個類轉換為一張表。
數據操作轉換
數據模式轉換是指從OODB到RDB數據操縱語言(DCL)的轉換。本文從OODB to RDB角度講述。數據庫常用操作有數據查詢、插入、刪除和修改,它們都離不開限制條件,所以先講述限制條件轉換。
我們用
分別表示類限制條件和關係限制條件。相比之下,
多兩個機制:路徑表達式操作數機制和集合操作數及運算符。通過直接設置類C某些屬性及以類C為根類組合層次結構中的限定謂詞得到
。根據
我們得到一個類限定圖GC,同樣每一個
也對應一個關係限定圖GR。實施限制條件轉換時,通常是先根據
構造
,然後把GC轉換成GR,最後由GR產生
。數據查詢轉換是把對象查詢運算轉換為關係查詢運算。其過程是從指定的類和(或)它的所有子類映射關係中選出與
限定對象對應的元組(由關係限定條件
所限定)。
數據修改轉換是把對象修改運算轉換為關係修改運算。該操作受QR(由
映射得到)限定,過程是刪除所有舊元組後再插人新元組。數據插入轉換與此相似。數據刪除轉換是把對象刪除運算轉換為關係刪除運算,該操作受
(由QC映射得到)限定,此時必須把與這些組合對象對應的元組中那些外關鍵字屬性設置為NULL。

面向對象數據庫模式演進技術

面向對象數據庫中的類為適應需求變化而隨時間變化稱為模式演進,包括創建新類、刪除舊類、修改類屬性和操作等。模式演進必須保持模式一致性(模式自身內部不能出現矛盾),這通過模式一致性約束來描述。模式一致性約束可分為唯一性約束(同一模式中名字唯一)、存在性約束(顯示引用的成分須存在)和子類型約束(子類和父類的聯繫不可有環,不能有從多繼承帶來的任何衝突等)等,滿足所有這些一致性約束的模式稱為一致模式。模式演化歷來是面向對象數據庫研究的重點與難點。其解決途徑一般有以下兩種:
①模式改變考慮現有應用程序,使兩者相互集成和適應。
②開發新的高級數據庫編程語言。
常用演化方法有TSE(透明模式演化)、等價模式演化和基於數據字典的模式演化等。

面向對象數據庫索引技術

面向對象數據庫數據龐大而複雜,若無好的索引處理,則數據處理效率十分低下。索引化過程就是對數據進行主體和特徵分析,賦予標誌的過程。數據索引技術分為三種:繼承索引、集聚索引和集成索引。具體技術特點見文獻。

面向對象數據庫事務管理技術

傳統數據庫事務管理特點及不足
傳統數據庫事務管理由兩部分組成:併發控制和恢復。通常用鎖協議實現併發控制,用日誌協議實現恢復。在工程設計等應用領域需要長事務和協作事務。但事務原子性使得若長事務不能完成,則所有已做的工作均要放棄;而串行性則使得若長事務不結束,其他事務必須等待,造成傳統併發控制方法效率極低。
OODBS事務管理技術特點
圖1 圖1
OODBS事務管理子系統如圖1所示。其中,鎖管理器管理鎖表,存放單個活動事務管理鎖和等待鎖。存儲子系統與鎖管理器實施對象上鎖操作,事務結束時釋放此鎖。死鎖管理器檢測和解除死鎖。系統採用時間溢出技術,即每個申請均有一時間限制,時間溢出則死鎖管理器將事務放棄。日誌管理記錄對象修改日誌。相比傳統RDBS,OODBS加鎖技術的特點有:加鎖邏輯單位是對象而不是類;給一個類對象加鎖比給一個關係對象加鎖需更多信息;當一個類實例被加鎖時,其超類也被加鎖。數據庫中被加鎖項大小稱為粒度。採用粗粒度鎖機制時併發程序開鎖代價低,但系統併發行差;採用細粒度鎖機制則保證高度併發性,但系統開鎖代價大。OODB採用粗粒度加鎖機制同樣能達到很高的並行性,加鎖的一般是對象,但是如果某一事務要訪問同一個類的大多數實例,則對整個類加鎖,既保證可靠性,又降低系統開鎖代價。
OODBS恢復機制
RDBS支持軟故障和硬故障恢復。OODBS採用來自軟件故障和用户激活事務夭折的事務恢復,不採用來自磁盤故障的恢復。OODBS採用UNDO日誌(更新的對象頁事務結束時存入磁盤)。恢復內容主要有以下兩種:
(1)多媒體日誌恢復。通常OODBS把多媒體數據和其描述部分分開,描述部分通過對象標識符引用相應多媒體數據。存儲子系統管理一個能動態變化的空閒塊鏈表,裏面存儲多媒體數據,系統把它作為多媒體數據日誌。如果創建多媒體數據事務夭折,則只需置空描述部分引用並將己分配給多媒體數據的空閒塊鏈重新復位。同樣如果刪除多媒體數據事務夭折,則描述部分根據日誌可恢復到原來狀態。
(2)索引頁日誌恢復。方法有兩種:①分裂索引頁的插入操作。系統把當前索引頁的一半表項分給新頁,除了拷貝到新頁的表項外,其他表項都記錄在日誌中。發生故障時,去掉整個新頁即可。②合併索引頁的刪除操作。系統把當前索引頁的表項拷貝到新頁,除了從當前頁刪除的表項外,其他表項都記錄在日誌中。發生故障時,重新使用當前頁即可。
虛擬事務
OODBS支持兩類事務:常規事務和虛擬事務。前者提交時,所有更新結果都永久地記錄到數據庫中;它夭折時,所有修改相當於沒做。後者總是夭折的,即不論此事務以什麼方式結束,對對象的改動不會記錄到數據庫中,用户能通過此類事務對數據庫進行復雜變化並觀察結果,不必擔心不一致性。虛擬事務對象採用兩個副本:影子副本(原始對象,不被更新)和當前副本(被更新對象)。
長事務管理
傳統事務模式處理長事務時存在衝突事務間長期等待和系統故障時數據庫更新全部撤銷兩個缺點。OODB中一個長事務可看作一些短事務集合。一個短事務看作併發控制和恢復的基本單位,這樣用户能減少鎖粒度(把長事務鎖變成短事務鎖),實現不同長事務併發操作和長事務部分撤銷。

面向對象數據庫視圖類實現技術

面向對象數據庫視圖
傳統數據庫視圖從某個特定角度反映數據庫,不存儲數據,也不佔用空間,但可當作實表操作,也稱為虛表。OODBS中的視圖具備傳統數據庫中的功能,每個視圖是一個“虛類”,由一個或多個類產生,雖不能產生對象實例,但可當作對象實例操作。面向對象數據庫中所有視圖構成一個有向無環圖,其基本元素是對象視圖類。對象視圖類從模式中源類的某個查詢推導產生,它由屬性和方法構成,存在繼承和合成關係。
面向對象數據庫視圖實現技術
面向對象數據庫中很多操作(如統計、連接查詢和視圖操作)都能自由訪問數據庫數據,利用這些操作實現OODBS視圖操作,能降低複雜度並提高效率,但容易破壞對象封裝性。為了不破壞對象封裝性,我們在對象中設計一組接口,系統通過這組接口完成視圖操作,這樣會增加對象複雜性和OODBS設計難度。為了克服這個缺點,我們對這些接口實行標準化,把它們與數據庫中其他對象的服務結合。基於上述條件,我們設計相應類數據結構和操作實現OODBS視圖。
面向對象數據庫視圖集成技術視圖類定義好後,我們把它們集成在一起構成有向無環圖,其基本元素是對象視圖類。

面向對象數據庫版本管理技術

工程類應用中設計工作隨時間逐漸演進,本身就是一個不斷反覆、試探、選擇和完善的過程,其間會產生同一被設計對象的多個版本,它們必須妥善管理。為了降低設計複雜性,常常採用分層逐步細化的方法。這樣,一個被設計對象由多個子對象構成,每一個子對象同樣產生多個版本。子對象某些版本合起來就構成了上層對象某個特定版本,並且如果某個子對象創建一個新版本,上層對象可能派生一個對應的新版本,等等。此外,在模式演化過程中,常用版本管理控制對象演化過程。版本管理有兩個方面:
圖2 圖2
①集合管理。對所有版本管理,其關係有兩種,即時間先後關係,是最基本的關係,一般用版本號表示,以及派生關係,如圖2所示,這種圖叫做版本圖。版本集合管理常用版本圖進行管理。
②引用管理。多版本系統中的對象只是邏輯上虛擬的概念,實際存在的是該對象的各個版本,所以,使用對象就是引用它的某一版本。
一般有兩種引用方法:靜態引用(直接引用某個對象的特定版本)和動態引用(引用關係指向某個對象,不一定是哪個版本)。相比之下,動態引用更有效,更貼近實際。根據版本是否已“凍結”,版本分為發行版本(已經定型和“凍結”,不可更改)和臨時版本(可修改)兩種。

面向對象數據庫安全建模技術

隨着Internet技術不斷髮展,安全性已成為不可忽視的問題,利用安全模型能精確地描述系統安全策略。安全模型和數據庫系統的結合就是數據庫安全建模技術。OODB通常結合RDB安全技術描述OODB安全技術。常用OODB安全模型有支持單級和多級對象的兩種模型。相比之下,多級對象模型能更好地描述現實世界實體,是實現OODB安全性的主流。
安全建模基本框架安全建模本質是利用面向對象建模技術,對現實世界各種安全性引入若干種安全性約束分類,進行安全性分等,將現實系統中的安全性語義表達成數據庫系統支持的安全性模型。在此過程中可能會產生衝突,引起數據庫安全性語義的不一致性,因此,進行一致性檢測和解決衝突是必要的。安全建模主要有兩個任務:安全性分等和一致性檢查與衝突解決。其中的一致性檢查與衝突解決任務由機器完成。安全性分等是由OODB提供方法,由應用系統設計者(建模者)完成。

面向對象數據庫優點

OODBS賦予數據庫設計和應用開發人員很強的面向對象能力,從而大大擴展了數據庫系統的應用領域,提高了開發人員的工作效率和應用系統的質量。面向對象數據模型與傳統數據模型相比"在以下方面具有優勢 [2] 
1、易維護
採用面向對象思想設計的結構,可讀性高,由於繼承的存在,即使改變需求,那麼維護也只是在局部模塊,所以維護起來是非常方便和較低成本的。
2、質量高
在設計時,可重用現有的,在以前的項目的領域中已被測試過的類使系統滿足業務需求並具有較高的質量。
3、效率高
在軟件開發時,根據設計的需要對現實世界的事物進行抽象,產生類。使用這樣的方法解決問題,接近於日常生活和自然的思考方式,勢必提高軟件開發的效率和質量。
4、易擴展
由於繼承、封裝、多態的特性,自然設計出高內聚、低耦合的系統結構,使得系統更靈活、更容易擴展,而且成本較低。

面向對象數據庫問題

面向對象數據庫技術可望成為繼關係數據庫技術之後的新一代數據管理技術。儘管目前已有大量的研究開發工作,有一些可支持的面向對象數據庫系統,但面向對象數據庫的成熟仍有賴於許多關鍵問題的解決。另一方面,由於面向對象數據庫的發展經歷了從研究到商用的過程,因而,開發者面對的是涉及各方面的技術問題。對於面向對象數據庫來説,最大的挑戰是建立一個在性能、一致性、完整性、可靠性和靈活性上優良的數據庫。其中一些問題是面向對象數據庫所特有的,如 [2] 
  1. 性能方面:由於面向對象數據庫中數據被存放在許多地方,因此,有效對象聚集是性能好壞的關鍵因素。這種數據集聚可以以類層次或對象的其它關係為依據。而面向對象數據庫的性能提高也需要優良的高速緩衝方案,其目標是根據使用要求使各對象儘可能地放在一起。同時,面向對象數據庫技術要想能取代傳統的數據庫技術,性能改善是必不可少的。提高面向對象數據庫的性能尤其是在分佈式環境中的性能的一種方法是把訪問數據庫的應用程序也看作是對象,以使它們在數據庫中可象數據對象那樣到處移動。在進行查詢時,數據庫可以選擇將數據移至程序還是將程序移至數據。
  2. 模式修改:當需要面向對象數據庫的升級或新版本時數據庫的模式修改或重構將是個問題。面向對象數據模型有豐富的建模能力,這一方面使用户建模容易。另一方面也使面向對象數據庫模式複雜,需要有工具支持。視圖、演繹能力、語義建模和長事務也是未來面向對象數據庫系統應該具備的數據庫特徵。可擴充體系結構也是一個重要方向。
  3. 標準化:標準化和形式化是面向對象數據庫系統研究和發展的一個重要方向。幾年來,人們在核心面向對象概念方面基本達成了共識,但在面向對象數據模型的其它方面,如&體系結構、編程接口語言上的理解尚未達到一致。有待於在系統研製和應用過程中進行標準化。
參考資料