多數據庫中間件中分布異構數據緩沖區系統的實現
2008-01-01 00:00:00趙潔張鵬齊德昱
計算機應用研究 2008年1期
摘要：實現了多數據庫中間件中分布異構數據緩沖區，該模型能夠實現分布異構數據對象的數據雙向同步/異步更新機制；采用的全局數據對象存儲模型和緩存管理使數據在緩沖區存儲并被用戶高效快捷地訪問；實現了全局事務管理策略，包括局部代理的設計、全局事務的并發控制、全局事務提交協議等。
關鍵詞：多數據庫中間件； 分布異構數據緩沖區； 對象緩存管理； 全局數據對象模型； 雙向同步/異步更新
中圖分類號：TP311.138文獻標志碼：A
文章編號：1001－3695(2008)01－0215－05
多數據庫中間件項目主要研究如何構建新型意義上的多數據庫中間件。其實質是構造“DBMS over DBMS”，是多數據庫的一種兼容與普通DBMS的模式化解決方案，從而解決異構數據庫集成問題。多數據庫中間件架構如圖1所示。
數據上推規則：使用數據上推描述語言（data push description language，DPDL），對欲上推出去供第三方訪問的數據進行描述。
上推機（中間件）：為中間件形式，負責接收集成機發來的數據訪問消息，根據上推規則訪問數據源，并將結果回送到相應的集成機。
數據緩沖區系統（中間件）：又稱為集成機，為中間件形式，負責將上層應用的訪問請求（形式為SQL或ODBC/JDBC等）轉換為上推機消息，發送到上推機，或接收上推機的響應消息，轉換為應用程序兼容的數據形式。這一層又分為兩大層：最上面一層作用類似于ODBC/JDBC等數據庫編程接口；下面一層是分布數據鏈接集。
分布數據鏈接集：該集合相當于多數據庫的各應用視圖。
1分布異構數據緩沖區系統
1．1分布異構數據緩沖區模型
根據對多數據庫中間件的緩沖區的需求分析，設計了分布異構數據緩沖區系統邏輯模型。緩沖區管理層中的主要組件包括應用訪問接口(APIs)、全局數據對象模型管理器、元數據管理器、數據緩存區、事件動作觸發管理器、全局事務管理器、XML轉換器、數據收發器（server端）。多數據庫中間件中的分布異構數據緩沖區模型[1]如圖2所示。
1．2分布異構數據緩沖區中的關鍵技術
分布異構數據緩沖區模型中的幾個關鍵技術，包括數據的一致性管理方法的分析與改進、數據的復制策略、局部數據源的即插即用研究、緩沖區系統中的數據名空間、系統的安全管理技術等。此處不再詳述。
2分布異構數據緩沖區系統的實現
本文重點論述分布異構數據緩沖區的實現平臺及主要的實現策略，如緩沖區系統中的對象管理、對象粒度的選擇、緩沖區與各局部代理間的數據交互以及緩沖區系統中的全局事務管理等。其中包括局部代理的設計、全局事務的并發控制、全局事務提交協議等。最后給出全局數據對象模型和基于此對象模型的應用程序接口APIs的實現細節。
2．1分布異構數據緩沖區（DHDB）的實現平臺
首先說明系統的實現平臺。本系統采用Java語言實現，因此運行在虛擬機（JVM）之上，可以跨平臺，不受不同操作系統的影響。系統框架基于廣域網，并對傳統C/S架構進行擴展。廣域網的復雜性對系統的實現提出了許多新的問題，如局域網上的多數據庫事務處理如何遷移到廣域網上，不可保證的網絡通信質量如何使系統正常執行等。
系統的實現分為客戶端和服務器端兩部分。客戶端主要提供客戶端用戶接口。客戶端以局部代理的形式實現，負責監聽本地數據庫的數據變化，并把相應的改變即時通知服務端的緩沖區，保證源數據與副本數據的一致性；另外，客戶端負責監聽來自緩沖區發來的數據操作請求，并響應請求作出適當的操作，同時為多數據庫事務處理提供有力支持，并模擬事務處理功能。關于事務處理功能將在下面詳細論述。
實現系統時，主要考慮如何高效實現客戶端與服務器端的通信，使其具有良好的可擴展性。在本模型的通信過程中，傳輸的數據中既有規則的結構化數據，又有大容量的非結構數據。若采用傳統的socket通信方法，在傳輸非結構化數據時不但傳送報文格式難以定義，而且通信程序也難以擴展，所以在實現的原型系統中利用Java提供的串行化功能，較好地解決了非結構化數據的傳輸問題。考慮到客戶端編程語言的多樣性，為實現平臺的無關性，采用Java語言作為系統實現語言。
服務器端的實現較為復雜，要同時考慮通信效率、并發控制與數據庫的操作。服務器端通信的解決辦法與客戶端是一致的。同樣利用Java的串行化功能實現數據的收發，使其具有較好的擴展性。在全局數據模型管理中，存在著大量的并發性操作，如多個客戶同時訪問全局數據模型，平臺的多線程機制實現了客戶端的并發訪問。
2．2分布異構數據緩沖區的主要實現策略
2．2．1緩沖區中的對象緩存管理技術
在緩沖區系統中數據操作存儲的格式都是對象。如何設置對象的緩存大小才能保證對象訪問的命中率，以及如何高效地訪問數據對象呢？下面主要講述緩沖區系統中數據對象的緩存管理技術[2]。
1）對象緩存
比較恰當的對象緩存的定義可以在object caching service for Java (OCS4J)[3]的功能規范文檔中找到。定義如下：服務器必須將信息和可執行對象分為三種基本類別來管理，即永遠不會改變的對象、每次請求都會發生改變的對象、介于兩者之間的對象。Java對前兩種對象的處理提供了很好的支持，但是對第三種類別的支持非常有限。如果對象永遠不改變，在服務器初始化時創建靜態對象。如果對每個請求對象都是不同的，每次都創建新的對象。對于介于兩者之間的對象或信息，它們的狀態可能會發生變化，但又需要提供跨越請求、跨越用戶或跨越進程的共享，就要采用對象緩存服務了。
基本上，對象緩存就是通過在使用對象后不立即釋放，而是存儲在內存中并被后來的客戶端請求重用，避免重新獲得對象的昂貴成本。當數據第一次從數據源被檢索出來后，在名為cache的內存緩沖中臨時存放。 同樣的數據再次被訪問時，對象從緩存中取出來，而不是從數據源重新獲取。當被緩存的數據不再需要，就從內存中釋放出來。
2）緩存的優點
對象緩存最主要的益處是對應用性能的重大提升。在一個多層應用中，與其他工作相比，數據訪問是一種代價非常高的操作。通過將頻繁被訪問的數據并在第一次使用后不釋放，可以避免重新獲取與釋放對象的開銷和時間。這將會大規模提升多數據庫應用的性能。因為不必在每次獲取數據時訪問局部數據庫。在緩沖區中，保存的都是正在被多數據庫用戶訪問來自于各個局部數據庫的“熱”數據。這樣用戶每次訪問都會很快得到響應，而不是每次都去訪問局部的數據庫系統獲得所需數據。
3）使用緩存所需考慮的問題
在多數據庫應用中使用對象緩存也帶來了一些不利因素。這些問題將在緩沖區系統中一一解決。
a)同步復雜性。復雜性的增長依賴于數據的種類。因為緩沖存儲區保存熱點數據和正在被執行寫操作的數據，需要保證被緩存數據與數據源中原始數據的一致性；否則，被緩存的數據與實際數據不一致，將會導致應用中的數據錯誤。緩沖區系統的數據同步/異步更新機制解決了此問題。
b)持久性。當服務器崩潰時，被緩存數據的修改會丟失。可以采用同步緩存來避免該問題。
c)對象的替換算法。當考慮使用緩存時，需要考慮對象的預定執行時間和刷新率或者叫做對象的生存時間。緩存不能容納所有想要存儲的數據，因此緩存使用的內存及時得到釋放，既可以通過定義合理的生存時間實現，也可以在數據不再需要時顯式地釋放被緩存的對象。可以指定緩存算法如最近被訪問算法（LRU）或最少被使用算法（LFU），以便緩存基于訪問頻率來釋放對象。
d)內存大小。如果有大量沒有用處的數據存放在緩存中，并且這些數據沒有在正常的時間間隔內被釋放，內存大小就會變得無法接收地龐大。緩沖區系統中采用虛擬內存技術來解決內存大小不足的問題。
一個典型的數據庫系統由存儲在磁盤上的永久性數據構成。要處理這些數據，必須首先將它讀到主存，也就是通常所說的數據緩沖區。但是在多數據庫中間件系統中，緩沖區中的數據不是來自本地磁盤上的永久性數據，而是來自于各個分布異構的局部數據庫。因此緩沖區對象的替換都是對遠程對象的訪問。典型的DBMS通常通過調用底層操作系統的塊I/O 來實現。數據庫管理系統需要組織好這些讀到內存緩沖區的數據頁面，以備將來使用。以后，假如服務器在內存能找到所需頁面，就不必作物理I/O，只是進行邏輯I/O，稱之為命中緩沖區。多數據庫中間件系統中，物理I/O不是調用底層操作系統的塊I/O來實現的，而是與局部代理建立通信連接進行數據訪問。緩沖區管理程序的效率是用緩沖區命中率來衡量。它是申請訪問的對象在內存緩沖區中的比例。
在緩沖區系統實現中，采用OpenSymphony提供的免費OSCache[4]作為緩存主要實現載體，還使用了另外的幾個支持cache服務的著名Java開源項目如JCS[5]、SwarmCache[6]來作為OSCache的補充。OSCache不僅支持各種粒度對象的緩存，而且包含一些提高可伸縮性的高級特性，如緩沖到磁盤、可編程的緩沖刷新、異常控制等。OSCache提供了幾種屬性的設置來使用它的各種特性：cache.memory設置是否采用內存緩沖支持；cache.capacity設置緩存的容量大小，缺省值代表容量無限大，從來不刪除其中的任何對象；cache.algorithm設置OSCache采用哪種對象替換算法（OSCache提供三種算法：LRU、FIFO、Unlimited。當緩存容量沒有設置時，OSCache就采用Unlimited算法）；cache.unlimited.disk設置是否采用磁盤作為無限緩存支持。
2．2．2緩沖區中的對象粒度
在緩沖區系統中，數據緩存區要存儲大量的數據對象。前面已提到，數據緩存區中的數據結構采用面向對象的數據結構。從理論上說，可以在緩沖區中定義任意大小的對象。在注冊一個DBMS數據到緩沖區的情況中，一個對象可以是關系的一行記錄、一個數據庫表、一個關于數據表結構的元數據，也可以是整個數據庫本身。
當過于小的對象（如數據庫表）被注冊為緩沖區對象時，所有處理這些表的DBMS函數，如查詢、事務控制等，必須由緩沖區系統本身來實現，還需有一個強大的對象倉庫以便存儲及高效地訪問對象。如果是一個DBMS被注冊為一個緩沖區對象時，所有需要處理這些表的DBMS函數都留給DBMS來做。這樣問題就可大大簡化，也有利于保持成員系統的自治性。另外，緩沖區系統只是作為上層DBMS的數據緩存，要提高數據的訪問速度及方便性，大的數據對象粒度恰好能滿足這點。
注冊小對象到緩沖區的另一個缺點是：每當插入和刪除這些對象時，就需要重新頻繁地查找對象緩沖區，降低了系統的綜合性能；如果對象的粒度小，對象的存儲空間分配回收管理也相對復雜。基于上面分析，將每個DBMS數據定義為一個緩沖區對象。
2．2．3緩沖區系統和局部數據代理之間的數據交互
前面提到由數據收發器來完成緩沖區系統和各個局部數據代理之間的數據通信。要保證兩者通信有條不紊地進行，必須在兩者之間設計一個交互協議。
1)多線程通信服務
為提高訪問的響應時間和訪問的并發度，采用多線程技術實現緩沖區端的數據收發器。在實現時，采用Java socket通信套接字來實現服務器和局部代理LA之間的通信。工作流程如下：
緩沖區系統啟動后，進行網絡的初始化工作，并建立網絡監聽。接收局部代理LA的連接請求后，服務器給LA分配一個端口（port）并發送給LA。此端口用于區分指定某個LA和服務器的通信服務。緩沖區系統服務器與LA建立連接后，首先進行注冊檢查，檢查LA端傳來的注冊信息是否正確。若注冊成功，服務器將再產生一個新的線程，與LA再建立另一條連接通路。原線程繼續等待新的LA交互的連接請求。將先建立的連接稱為握手連接，后建立的稱為數據連接。至此，緩沖區端的服務器與LA間的連接完全建立。
服務器能夠同時支持很多LA提出的連接請求。多個LA與服務器之間的通信互不干擾。服務器收到多個LA發來的數據包并把它們排成隊列，然后由XML轉換器從隊列中讀取數據包，再接著將它們遞交給元數據管理器或數據緩存區。所以服務器能夠并發地與多個LA同時進行數據通信交互，如圖3所示。
2)數據傳輸對象
它是指在服務器與局部代理LA之間的數據傳送對象。在設計數據傳輸對象時，要考慮到對象的粒度問題。粒度大的數據對象在傳送時要占用大量的網絡帶寬，造成網絡中的通信流量較大，通信負荷過重。此時就考慮選擇盡可能小的數據傳輸對象，減少網絡之間的通信流量。例如，局部數據庫系統中某張表的幾條數據記錄發生改變。此時在緩沖區中恰好有此表的數據快照，那么必須把此次的數據變化反映到緩沖區中，可采用一個基于XML格式的數據傳輸對象DiffGram，而不是把整張表的數據全都傳給緩沖區系統。被傳輸的數據對象不僅僅是數據記錄集，有時也用于緩沖區端的數據請求命令。有時緩沖區要向局部代理發送數據查詢請求命令，因此要設計出命令的格式。針對上述需求，給出了四種數據傳輸對象的格式：DBMetaData、SQLCommand、DiffGram、ResultSet。它們具體的模式DTD形式略。
a)數據庫元數據DBMetaData對象。用于向緩沖區系統發送各個局部數據的某個數據庫元數據信息，同時也可以包括相關的業務數據等。
b)SQLCommand命令對象。緩沖區系統中數據更新操作的變化結果以此格式發送給各個局部代理；局部代理從該對象中解析出SQL命令；然后將它發送給局部DBMS完成數據的操作（如select、insert、update和delete等操作）。
c)DiffGram數據對象。DiffGram格式是用于標志數據記錄的當前和初始版本的XML 格式。它會為DiffGram 填充精確地重新創建某個數據庫的內容（但不包括其元數據）所必需的全部信息。其中包括original和current行版本的列值、行錯誤信息以及行順序。此格式可以在緩沖區與LA間雙向傳輸使用。DiffGram 格式分為三個節：當前數據、初始（即before）數據和錯誤節。
d)ResultSet對象。當緩沖區系統向局部代理（LA）發送數據查詢請求，LA根據請求命令從局部數據庫取出數據，繼而LA把查詢數據打包成result對象格式發送給緩沖區系統。
2．2．4緩沖區系統中的全局事務管理實現策略
1)局部代理（local agent）的設計
局部代理[6，7]負責維護局部數據庫提供的輸出模式；將從緩沖區接收到的命令翻譯成對應局部數據庫的查詢語言或操作語言；提供一個訪問局部數據庫（LDBMS）的接口；將查詢結果返回給查詢結果處理器；文件或Web局部代理需要對半結構化數據進行包裝，并模擬事務處理功能。
局部代理作為全局事務管理器與局部數據庫系統的接口，為多數據庫事務處理提供了有力的支持。DHDB系統主要采用專用接口的方法來實現局部代理，如使用Oracle的OCI、Sybase的Open client DB Library等。這樣可以充分體現各局部系統在數據模型、存取方法、事務協議、并發控制、用戶接口等方面的私有特性，以提高整個MDBS的效率。對于不宜用專用接口實現的局部系統，如FoxPro文件、Excel文件、Access、SQL server數據庫等，采用ODBC通用接口來實現局部代理。它只支持各數據庫所共有的數據類型，無須深入了解各數據庫的專有特性，實現難度可以大大降低。對那些并不支持兩階段提交協議的數據庫系統及文件系統，局部代理還需保證全局子事務執行的正確性。
在DHDB系統中，為每個LDBMS定義了一個Java類，如對Oracle、Sybase和DB2數據庫分別定義了OraServiceImpl、SybServiceImpl和DB2ServiceImpl類。此外又定義了DBServiceImpl類作為這些Java類的基類。所有為LDBMS定義的類都繼承該類，其成員函數用于實現局部代理的接口。DHDB系統通過公共的成員函數來屏蔽多種異構數據庫接口的差異性。與事務處理相關的函數描述如下：
a)BeginTrans。該函數在相關LDBMS上啟動一個新事務。如果該LDBMS的調用層接口提供了該項功能，則返回一個有效的事務標志符（TID）。
b)PrepareToCom。向支持兩階段提交（2PC）協議的相關DBMS發送一個準備提交（PrepareToCommit）的消息。
c)CommitTrans。負責在相關的LDBMS中提交事務，并根據LDBMS的需要獲取即將提交事務的標志符作為輸入參數。
d)AbortTrans。負責取消相關LDBMS中的事務。與CommitTrans方法中類似，它也需要獲取即將提交事務的標志符。
e)CheckTicket。負責檢查全局事務的票值，并與局部代理中的票值進行比較，以保證全局事務的串行化執行。
f)ConnectToDB。將用戶名、口令、數據源作為輸入參數，建立起一條到LDBMS的連接。這些參數從全局模式管理器中獲得。
g)SendQuery。將待執行的查詢（或事務）語句作為輸入參數，在相應的LDBMS上執行該語句，并返回一個狀態值以指明執行成功與否。
h)GetNext。取得由SendQuery執行的查詢語句的結果。由兩部分組成：描述部分，包括結果列的數目、各列的類型、各列的最大顯示長度、返回的行數等信息；數據部分，包含查詢語句返回的記錄行，其結構為緩沖區的系列（sequence）類型。GetNext方法的每次調用所能返回的最大行數在該接口中以常量方式定義。對于結果量較大的情況，需要多次調用GetNext方法才能取回查詢的所有結果行。
不同數據庫的局部代理均從DBServiceImpl類繼承相關接口，并使用各自數據庫提供的接口進行實現，如OraServiceImpl類繼承DBServiceImpl類，并使用Oracle提供的OCI接口來實現BeginTrans、PrepareToCom、CommitTrans等相關函數。
2）全局事務的并發控制
在DHDB系統中，組成多數據庫系統的Oracle、Sybase和DB2等局部數據庫對于全局而言是完全自治的。全局對局部的附加信息和執行情況一無所知。針對最常見的LDBMSs產生可串行化調度的情況，開發了一種保守的樂觀票（COT）方法來保證全局事務的可串行化執行。
該方法的實質是，事先給全局事務分配一個全局可串行化的先后順序（用票值的大小標志）。它們所應讀的票值事先確定。若一個事務的操作沒有按照局部站點票值大小順序執行，就夭折它所在的全局事務或者延遲等待。
在每個LDBMS上放置了一個TicketTable表。該表只包含一個ticket數據項，記錄緊接的前次已執行的全局事務的全局票值（GlobalTicket），這里記為L_Ticket。每次局部庫代理初始化時，ticket數據項的缺省值為0。
在每個全局事務GTi初始化時，票據（ticket）管理器就為其分配一個全局惟一且單調遞增的全局票值，這里記為G_Ticket(GTi)。顯然每個新的全局事務所獲得的GlobalTicket大于前面任一全局事務的GlobalTicket。這樣自動產生了一個全局事務的串行執行順序，即若G_Ticket(GTj)>G_Ticket(GTi)，則全局事務GTj必須在全局事務GTi之后執行，并將這種順序帶入局部DBMSs上全局子事務的
執行。對于每一個GTi和GTj執行所在的LDBMS中，屬于GTj的所有操作均在屬于GTi的所有操作之后執行。這通過在局部代理上進行票值檢查來完成。每當全局事務GTi的一個操作發給LDBMS執行之前，都必須讀相關LDBMS中的L_Ticket。如果G_Ticket(GTi)>L_Ticket，則將當前L_Ticket的值替換成G_Ticket(GTi)，并將該操作發給局部LDBMS執行；否則，夭折GTi。當GTi的所有操作都成功執行，則GTi執行成功。
2．3緩沖區系統的數據模型及數據訪問接口API
2．3．1全局數據對象模型
全局數據對象模型是緩沖區中一個基本數據操作對象，緩沖區系統對上層用戶提供的一些API操作都是根據此全局對象數據模型衍生的，如圖4所示。
圖4全局數據對象模型——數據集（DataSet）
數據集是一種數據關系視圖。數據集的結構（表、列、關系和約束）與關系數據庫系統的結構是一致的。DataSet 中的操作方法與關系數據庫模型中的操作方法也是一致的。數據集DataSet是一個數據容器，所以數據集不需要或不支持當前記錄的概念。相反，數據集中的所有記錄都可用。由于沒有當前記錄，就沒有指向當前記錄的特定屬性，也沒有從一個記錄移動到另一個記錄的方法或屬性。可以訪問數據集中以對象形式出現的各個表；每個表公開一個行集合。可以像處理任何集合那樣處理行集合，通過集合的索引訪問行，或者用編程語言通過集合特定的語句來訪問行。
如果數據集中有多個表(DataTable)，這些表中的信息可能是相關的。數據集沒有這些關系的繼承知識，因此為了使用相關表中的數據，可以創建 DataRelation對象來描述數據集中表之間的關系；可使用DataRelation 對象以編程方式獲取父記錄的相關子記錄和從子記錄獲取父記錄。
與大多數數據庫一樣，數據集也支持約束，作為一種確保數據完整性的方法。約束是在表中插入、更新或刪除行時應用的規則。可以定義兩種類型的約束：惟一約束，檢查列中的新值在表中是否是惟一的；外鍵約束，定義當主表中的記錄被更新或刪除時相關子記錄應如何更新的規則。
DataSet也可以按XML 的形式來保持和重新加載其內容。可以使用數據集的 ReadXML 方法將 XML 文檔或流讀入數據集，使用數據集的 WriteXML 方法將數據集以 XML 格式寫出。因為 XML 是不同應用程序之間的標準數據交換格式。這意味著可以加載其他應用程序發送的包含 XML 格式信息的數據集。同樣，數據集可以將其數據集寫出為 XML 流或文檔，以與其他應用程序共享或只是將其存儲為標準格式。在緩沖區系統中，XML轉換器從數據收發器獲得數據，并通過API調用將它寫入DataSet中。緩沖區用戶也可以通過調用API向DataSet寫入數據。
2．3．2基于全局數據對象模型的應用程序接口APIs
根據圖4，設計實現了全局數據對象模型中的各個主要構造對象及相應的成員操作方法。通過調用這些對象的成員方法（即APIs）就可以操作緩沖區的各種數據。
DataSet對象：DataSet 由一組 DataTable 對象組成，可使這些對象與DataRelation 對象互相關聯。還可通過使用 UniqueConstraint 和 ForeignKeyConstraint 對象在 DataSet 中實施數據完整性。盡管 DataTable 對象中包含數據，但DataRelationCollection 允許遍覽表的層次結構。這些表包含在通過 Tables 屬性訪問的DataTableCollection 中。其成員方法的具體定義略。
DataTableCollection對象：DataTableCollection 包含 DataSet 中的所有 DataTable 對象。其成員方法的具體定義略。
DataTable對象：在緩沖區系統的命名空間中定義，Data￣Table表示內存駐留數據表。與局部數據庫的數據表相對應，它可以是單個物理表的映像或多個分布的物理表的集成。它包含 DataColumnCollection 所表示的列和 ConstraintCollection 所表示的約束的集合，列和約束一起定義了該表的架構。Data￣Table還包含DataRowCollection 所表示的行的集合，而 DataRowCollection 則包含表中的數據。其成員方法的具體定義略。
DataColumnCollection對象：表示 DataTable 的DataColumn 對象的集合。DataColumnCollection定義DataTable的架構，并確定每個DataColumn 可以包含什么種類的數據。DataColumnCollection使用add和remove方法插入和刪除DataColumn對象。其成員方法的具體定義略。
DataColumn對象：DataColumn是用于創建 DataTable 的架構的基本構造塊。通過向 DataColumnCollection 中添加一個或多個 DataColumn 對象來生成這個架構。每個 DataColumn 都有 DataType 屬性。該屬性確定 DataColumn 所包含的數據的種類。例如可將數據類型限制為整數、字符串或小數。由于 DataTable 所包含的數據通常合并回其原始數據源，必須使數據類型與數據源中的數據類型匹配。其成員方法的具體定義略。
DataRowCollection對象：DataRowCollection表示 DataTable 的行的集合，包含表的實際數據。在該表中，DataRowCollection中的每個DataRow表示單行。可通過調用add和remove方法，從DataRowCollection中插入和刪除DataRow對象。還可通過調用find方法搜索在主鍵列中包含特定值的DataRow對象。也可通過調用contains方法在基于字符的數據中搜索單個單詞或詞組。其成員方法的具體定義略。
DataRow對象：DataRow 和 DataColumn 對象是 DataTable 的主要組件。使用DataRow 對象及其屬性和方法檢索、評估、插入、刪除、更新 DataTable中的值。DataRowCollection 表示DataTable中的實際DataRow 對象，DataColumnCollection中包含用于描述DataTable架構的 DataColumn對象。其成員方法的具體定義略。
DataRelationCollection對象：DataSet 在其DataRelationCollection 對象中包含關系。關系由 DataRelation 對象來表示，它使一個 DataTable 中的行與另一個 DataTable 中的行相關聯。關系類似于可能存在于關系數據庫中的主鍵列與外鍵列之間的連接路徑。DataRelation 標志 DataSet 中兩個表的匹配列。關系能使在 DataSet 中從一個表導航至另一個表。DataRelation 的基本元素為關系的名稱、相關表的名稱以及每個表中的相關列。關系可以通過一個表的多個列來生成，方法是將一組 DataColumn 對象指定為鍵列。當關系被添加到 DataRelationCollection 中時，如果已對相關列值作出更改，它可能會選擇添加一個 UniqueKeyConstraint 和一個 ForeignKeyConstraint 來強制完整性約束。其成員方法的具體定義略。
DataRelation 對象：表示兩個 DataTable 對象之間的父/子關系。使用 DataRelation 通過 DataColumn 對象將兩個 Data￣Table對象相互關聯。例如在客戶/訂單關系中，客戶表是關系的父表，訂單表是子表。此關系類似于主鍵/外鍵關系。關系是在父表與子表中匹配的列之間創建的，即兩個列的DataType 值必須相同。其成員方法的具體定義略。
DataView對象：表示用于排序、篩選、搜索、編輯和導航的 DataTable 的可綁定數據的自定義視圖。可自定義 DataView 來表示 DataTable 中數據的子集。其成員方法的具體定義略。
Constraint對象：約束是用于維護 DataTable 中數據的完整性的規則。例如，當刪除在一個或多個相關表中使用的值時，ForeignKeyConstraint 確定如何處理相關表中的值：同樣刪除、設置為空值、設置為默認值或者不執行任何操作。另一方面，UniqueConstraint 只是確保特定表內的所有值都是惟一的。不使用基本的 Constraint 構造函數。使用 UniqueConstraint 構造函數創建主鍵約束或惟一鍵約束；使用 ForeignKeyConstraint 構造函數創建外鍵約束。其成員方法的具體定義略。
3結束語
分布異構數據緩沖系統是多數據庫中的重要組成部分，該系統的實現需要綜合使用多種技術。本文論述分布異構數據緩沖區的實現平臺及主要的實現策略。該緩沖區系統實現了源數據與目的數據之間的雙向同步/異步更新；支持局部數據庫系統能夠動態地加入或撤出多數據庫中間件系統，即局部數據源的即插即用；緩沖區實現了一種數據命名空間來解決各個局部數據庫中的數據名字沖突、數據映射等問題；也設計實現了該緩沖區系統的安全管理機制。
分布異構數據緩沖系統的實現是一項復雜的工作，很多問題還有待深入研究。
參考文獻：
[1]張鵬. 多數據庫中間件中的分布異構數據緩沖區系統的研究與實現[D].廣州：華南理工大學 2004：49－72.
[2]PENCHIKALA S.Object caching in a Web portal application using JCS[EB/OL].(2003－12－23).http：//www.onjava.com/pub/a/onjava/2003/12/23/caching.html.
[3]Object caching service for Java[EB/OL]. (2004－01－22).http：//www.jcp.org/aboutJava/.communityprocess/jsr/cacheFS.pdf.
[4]OSCache technical documentation[EB/OL].(2004－01－25).http://www.opensymphony.com/.oscache.
[5]Java caching syste（JCS）[EB/OL].(2004－01－30).http://jakarta.apache.org/turbine/jcs/.
[6]盧正鼎，李瑞軒，肖衛軍.多數據庫事務處理模型中局部代理的設計與實現［J］.計算機研究與發展，1998，35（12）:1130 1134.
[7]盧正鼎，肖衛軍，李瑞軒，等.多數據庫事務處理原型系統的設計與實現［J］.計算機工程與科學，1997，17（4）:1－4.
[8]SwarmCache： cluster aware caching for Java[EB/OL].(2004－02－02).http://swarmcache.sourceforge.net/index.html.
“本文中所涉及到的圖表、注解、公式等內容請以PDF格式閱讀原文”
