三、傳統的資料庫於分散式資料庫的區別<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />

傳統的資料庫應用程式經常採用客戶機/伺服器結構（即C/S結構，如圖2），這種結構在技術上已經很成熟了並且應用也很廣泛，但這種結構的應用系統有其不足之處。比如當客戶數量很多，資料量又都很大的情況下，伺服器的負載就會很重，而且重複性工作很多，因為很多客戶發出的查詢可能完全相同，而查詢結果無法共享，即使兩個客戶發出的請求完全相同也要在伺服器上執行兩次查詢；在客戶端儲存了具有商業價值的查詢演算法；資料庫伺服器負擔過重導致效率低下等。

而當在伺服器和客戶機之間再加一個伺服器，專門用於儲存查詢演算法和臨時查詢結果，則問題就得到了很好的解決：一方面不同的客戶可以共用臨時的查詢結果而無須再訪問資料庫伺服器，減輕了伺服器的負擔；同時在客戶端也看不到作為商業機密的查詢演算法。這也就是分散式系統的工作原理。

分散式系統的出現源於傳統的C/S結構的若干弊病，如效率低，安全性差等，結合到資料庫方面來說，全球的DNS（域名解析系統Domain Name System）系統是一個很典型的例子，試想如果把全世界所有的域名都集中到一臺伺服器中來進行管理，那伺服器肯定會因負載過重而無法正常工作，整個網際網路也就癱瘓了。（可以畫一個定址DNS伺服器的圖）

與傳統式資料庫中避免資料冗餘不同，資料冗餘在分散式系統中被看作是所需要的特性，其原因在於：

首先，如果在需要的節點複製資料，則可以提高區域性的應用性。

其次，當某節點發生故障時，可以操作其它節點上的複製資料，因此這可以增加系統的有效性。

但在分散式系統中對最佳冗餘度的評價是很複雜的。

四、分散式資料庫技術設計

資料庫設計的原則

從全域性應用的角度出發，將這些資料庫自下而上構成分散式資料庫系統，實現全域性資料的完整性和一致性，各場地仍然存放本場地的資料，通過網路對共享池進行操作，對資料進行完整性和一致性的檢查，這種做法雖然有一定的資料冗餘，但在不同場地儲存同一資料的多個副本，能提高系統的可靠性和可用性，也提高了區域性應用的效率，減少了通訊代價。該分散式資料庫系統可以在對當前機構影響最小的情況下進行擴充，增加新的場地時只需增加一個節點就可以了，同時也使得各處理機之間的相互干擾降到最低。

資料儲存

在分散式資料庫中，資料儲存通過以下三種途徑實現：

①複製：系統維護關係的幾個完全相同的副本，這些副本儲存在不同的結點上。

②分片：關係被劃分為幾個片段，各個片段儲存在不同的結點上。

③複製+分片：關係被劃分為幾個片段，系統為每個片段維護幾個副本。

因為各資料庫之間存在一定的資料冗餘，又存在著差異，我們使用了複製+分片的方式進行資料儲存。

資料分片

在分散式資料庫系統中，將關係分片，有利於按使用者需求組織資料的分佈，目前的分片方式有水平分片、垂直分片、匯出分片、混合分片等四種。我們可以根據不同的資料關係採用了不同的分片方式。

資料同步

資料同步方式則根據系統需求使用事務複製（transaction replication）和合併複製(merge replication)兩種，由於場地只存放本場地的資料，資料管理和分析功能是由網路共享池的資料庫伺服器來實現的，各場地只需將更新的資料儲存到共享池的資料庫即可，我們使用事務複製進行業務資料的同步，把場地的資料庫作為出版者和分發者，共享池的資料庫作為訂閱者，對各場地的資料建立快照代理，並在分發資料庫中記錄同步狀態的資訊。每一個使用事務複製的場地資料庫均有自己的日誌讀取代理，執行在分發者上並連接出版者。分發代理的任務是將分發資料庫中保持的事務任務直接推動到訂閱者。當推訂閱被建立時，每個為立即同步而建立的事務出版物通過自己的分佈代理執行在分發者上並與訂閱者相連。

事務複製可以支援兩種型別的物件複製：表和儲存過程。在出版者中定義資料庫中的部分或全部的資料，選擇多個儲存過程作為複製。當場地的資料發生更新時，日誌讀取代理將即時的把更新資訊推到共享池的資料庫中。基於儲存過程的複製使應用具有更好的效能，可以大大減少網路的通訊量。事務性日誌使用事務日誌來監視文章中的資料改變。

合併複製作為一種從出版者向訂購者分發資料方法允許出版者和訂購者對出版資料進行修改，而不管訂購者與出版者是相互連線或是斷開，然後當所有（或部分）節點相連時便合併發生在各個節點的變化。在合併複製中，每個節點都獨立完成屬於自己的任務，不像事務複製和快照複製那樣訂購者與出版者之間要相互連線，完全不必要連線到其他節點，也不必使用MS DTC來實現兩階段提交就可以在多個節點進行修改，只是在某一時刻才將該節點與其他節點相連（此時的其他節點並不一定指所有其他節點）。

然後將所發生的資料變化複製到這些相連線節點的資料庫中。

以下即為該系統的設計框圖：

<?xml:namespace prefix = v ns = "urn:schemas-microsoft-com:vml" />圖 4

■分散式事務處理利用分散式技術實現事務處理和查詢

分散式資料庫系統中資料的分佈導致事務具有了分佈性。一個全域性事務的執行被劃分為在許多場地上子事務的執行。

分散式事務要能夠在多個伺服器上執行，我們使用MS DTC作為事務管理器來協調各個伺服器對事務的處理操作，為了減少網路故障對分散式事務處理的影響，避免分散式事務造成不同伺服器間資料的不一致，X/Open XA規範將分散式事務的處理過程規定為兩個階段，即準備階段和提交階段，就是常說的兩階段提交。

在進行分散式事務處理時，我們首先在伺服器端用Transact SQL指令碼程式BEGIN DISTRIBUTED TRANSACTION語句啟動一個分散式事務，將該伺服器作為分散式事務管理伺服器，然後指令碼程式對連線伺服器執行分散式查詢或遠端伺服器上的儲存過程，分散式事務管理伺服器會自動呼叫MS DTC，使遠端伺服器參加分散式事務處理。當指令碼程式執行COMMIT TRANSACTION、COMMIT WORK、ROLLBACK TRANSACTION或ROLLBACK WORK語句時，分散式事務管理伺服器將再次呼叫MS DTC，用它來管理兩階段提交程序，使連線伺服器和遠端伺服器提交或回滾事務。例如在保險業務系統中，如果總公司資料庫管理系統發現該客戶是交叉投保，則需將該保單插入拒保記錄表中，同時在對應的營業分支機構的資料庫中將該保單的狀態設為無效。我們在營業分支機構的資料庫（DBServer1）中建立儲存過程update_policy更新保單狀態，在總公司資料庫伺服器（DBServer）上執行以下指令碼程式，啟動一個分散式事務insert_reject：
USE business
GO
BEGIN DISTRIBUTED TRANSACTION
INSERT reject
VALUES(policy_id, insurance_no,business_date,customer_id,customer_name…)
EXECUTE DBServer1.business.dbo.update_policy
COMMIT TRANSACTION
GO
　　系統執行insert_reject事務向DBServer中的reject表插入一條記錄，同時更新對應的分支機構資料庫中的保單表status欄位，該事務使系統資料的完整性得到了保證。

■分散式查詢

分散式資料庫系統中資料的分佈導致查詢也具有了分佈性，分散式查詢可能針對異類的OLE DB 或 ODBC 資料來源。SQL Server 支援分散式查詢，即包括來自兩個或更多伺服器資料的查詢，支援伺服器間的檢索、更新和遊標，並使用 Microsoft Distributed Transaction Coordinator (MS DTC) 保證節點間事務語義，維護伺服器間的安全。

在系統設計的過程中，為了減少網路通訊量，我們根據應用的功能已將資料關係進行分片存放在各資料庫中，因此大部分的應用是面向區域性資料庫的操作，但全域性性的查詢仍需要多個數據庫的資料支援。在業務人員的管理模組中，由於各分支機構對其業務人員進行直接管理，且管理制度都有差異，我們將業務人員資訊存放在分支機構的資料庫中，通過聯合分散式查詢對公司所屬的所有業務員進行登記；在客戶管理模組中，我們根據來源將客戶資訊分別存放在業務資料庫伺服器的傳統客戶表和Web資料庫伺服器的網路客戶表中，通過聯合分散式查詢才能對公司所屬的所有業務員和客戶進行登記，下面以年度的業務員查詢為例介紹聯合分散式查詢的方法：