APP
論分布式數(shù)據(jù)庫的集成
[摘要]
本文討論了某公司發(fā)貨系統(tǒng)的分布式數(shù)據(jù)庫集成解決方案。該公司由于業(yè)務的發(fā)展，要在另三個城市設立貨倉進行發(fā)貨。為此，需要増加原先的MIS系統(tǒng)實現(xiàn)這一功能。公司委任我作為項目經理完成系統(tǒng)的設計和開發(fā)的工作。我經過分析，使用了 Sybase的分布式數(shù)據(jù)庫技術。我設計的這個系統(tǒng)是采用典型的C/S結構，但客戶端連接服務器的網(wǎng)絡采用電話線撥號，速度有限，傳統(tǒng)Windows界面的客戶端應用程序相應速度比較慢。于是我采用了優(yōu)化數(shù)
據(jù)庫結構的方法，把數(shù)據(jù)分兩部份存放，基礎數(shù)據(jù)放客戶機，銷售資料主要采用鍵碼放服務器，應用程序再現(xiàn)數(shù)據(jù)時從服務器取鍵碼，到客戶機取対應的解釋。由于鍵碼的數(shù)據(jù)量少，網(wǎng)絡傳輸便快。在構建這個公布式數(shù)據(jù)庫系統(tǒng)的過程中，我著重研究并解決了數(shù)據(jù)同歩和事務協(xié)調的問題，到得了良好的應用效果。
[正文]
2004年3月，由于公司業(yè)務的發(fā)展，要求在其它三個城市設立貨倉，處理發(fā)貨業(yè)務。公司本部運行用Sybase數(shù)據(jù)庫的MIS系統(tǒng)可以實現(xiàn)發(fā)貨，該系統(tǒng)用的是C/S結構。由于客戶端連接服務器的網(wǎng)絡采用電話撥導，所以直接把客戶端軟件直接安裝在外地訪問本部數(shù)據(jù)庫,速度很慢。于是，公司成立了一個項目，專門解決這個問題。在這個項目中，我擔任項目經理。經過対現(xiàn)有系統(tǒng)的分析，我們決定利用Sybase提供的技術，采用分布式數(shù)據(jù)庫集成的方
法來改造目前的系統(tǒng)使之能適應新的需要。項目分三個階段進行，一是進行需求分析，確定要増加的功能。二是進行系統(tǒng)設計，改變后數(shù)據(jù)分布如何，系統(tǒng)架構如何。最后是實現(xiàn)和測試，上線。整個項目歷時從分析到實現(xiàn)歷時三個月，最后于2004年6月份系統(tǒng)成功上線。
在分析階段時我發(fā)現(xiàn)由于客戶端地域的分散，遍及三個省境內，連接服務器數(shù)據(jù)庫的網(wǎng)絡采用電話撥導方式，速度有限，在使用客戶端應用程序時感覺界面速度很慢。我經過分析,認識到許多操作都要從服務器中取數(shù)據(jù)，速度慢就慢在數(shù)據(jù)訪問上。服務器是沒有瓶頸的，問題出在網(wǎng)絡速度上。出于成本和業(yè)務重方面的考慮，公司不會用專線連接，只能是電話撥號。這時只能改變目前軟件的實現(xiàn)方法，來適應這種低速網(wǎng)絡的使用模式。
經和項目組的人員一起探討，結合關系數(shù)據(jù)庫的知識，我認識到，應用程序的每一次數(shù)據(jù)庫操作，都要訪問多個相聯(lián)的表，其中，有銷售訂單表和物料基礎數(shù)據(jù)表唇戶資料表/貨倉的基礎數(shù)據(jù)等。銷售訂單表中存放著出銷售的訂單編號，成品編號等，數(shù)據(jù)量少。而基礎數(shù)據(jù)表就則放著成品的相關信息，有大量的數(shù)據(jù)。如果考慮把銷售訂單放在服務器，基礎數(shù)據(jù)放在客戶端，當應用程序中訪問數(shù)據(jù)時，總是從服務器上存取銷售訂單，從客戶端提取成
品/訂單的詳細信息。由于訂單的數(shù)據(jù)量少，便減少了網(wǎng)絡上傳送的數(shù)據(jù)量，從而提高了界面的響應速度。
把數(shù)據(jù)分散存放只是工作的第一歩，接下來要考慮應用程序怎樣訪問這種分布式數(shù)據(jù)。開發(fā)應用時，如果每一功能都針対兩個數(shù)據(jù)庫進行，就帶來了很多麻煩。所以，我通過研究Sybase的分布式數(shù)據(jù)庫技術，決定采用CIS （組件集成服務）部件，來合并兩個數(shù)據(jù)庫成一個統(tǒng)一的分布式數(shù)據(jù)庫。應用程序只要連接一個數(shù)據(jù)庫，就可以透明統(tǒng)一訪問到兩個數(shù)據(jù)庫中的數(shù)據(jù)。
該技術具體實施方法是：在客戶端數(shù)據(jù)庫中建立一個対服務器數(shù)據(jù)庫的遠程訪問服務名，包含訪問地址，登錄用戶名，登錄密碼等關鍵的連接信息；前且対服務器中銷售訂單建立一個本地代理表。結構和服務器中遠程表完全一樣，它是訪問服務器中會員資料的中轉和代理?？蛻舳藨贸绦蛟L問本地代理銷售資料表時，實際上是通過預先定義的遠程訪問服務名中包含的連接信息到服務器中対應的實際銷售資料表中訪問數(shù)據(jù)。這種訪問対于客戶端完全透明，感覺不到是從物理上獨立的兩個服務器中存服數(shù)據(jù)。所以，這種數(shù)據(jù)庫結構是典型的分布式數(shù)據(jù)庫。部署這種分布式數(shù)據(jù)庫不是難事，只要在客戶端和服務器上安裝12.0版本以上的數(shù)據(jù)庫服務器，在客戶端服務器上建立遠程服務名和代理表即可。由于Sybase數(shù)據(jù)庫的安裝支持腳本方式，在客戶端應用程序的標準安裝過程中，嵌入Sybase數(shù)據(jù)庫的安裝和配置腳本，就自動化地完成了所有工作。
在實際使用該分布式數(shù)據(jù)庫系統(tǒng)的過程中，遇到了幾個問題，第一，數(shù)據(jù)同歩?？蛻舳嘶A數(shù)據(jù)不是絕対靜態(tài)的，也有變化，因此在服務器要設貫一個統(tǒng)一的基準，稱為主點數(shù)據(jù)?？蛻舳丝偸且獜椭剖褂茫Q為復制點數(shù)據(jù)。如何及時感知到服務器端主點數(shù)據(jù)的變化，有效率地復制到客戶端，是個難題。Sybase針対這種應用場合，提供了復制服務器技術，但為了避免過于復雜，我們采用實際應用程序來管理同歩。當服務器端主點數(shù)據(jù)有了更改時，保存一個相應的標識和時間戳，客戶端應用在登錄服務器時，檢資這些標識，一檢測到了數(shù)據(jù)有更新，就首先下載,然后再進入系統(tǒng)正常使用。這種方法實現(xiàn)起來，増加了額外的開發(fā)量，且不能判別繞過應用程序対數(shù)據(jù)的直接修改，但是，是最簡單和有效的方法。
第二個問題是事務協(xié)調問題。物理上獨立的兩個數(shù)據(jù)庫，在協(xié)同操作時，如果服務器正好停機或者網(wǎng)絡故障，完整的一個事務沒能完成，就會事務崩潰,雖然Sybase CIS內嵌了兩階段提交技術，能夠自動恢復。但是應用程序在這種情況下，敏感性不夠，操作界面會無端凝固，影響了使用的方便性。我針対PB対勁于連接的判斷和感知，用了一個小小編程技巧，使應用程序能夠及時感知到數(shù)據(jù)庫連接故障，及時停止和恢復事務，使操作界面表現(xiàn)友好靈活。
在具體的應用中,我們在三個城市安裝了増強的客戶端應用程序，同時安裝了 Sybase數(shù)據(jù)庫。初始化時，把基礎數(shù)據(jù)放從公司本部的數(shù)據(jù)庫導入客戶端的數(shù)據(jù)庫中。用戶在外地進行發(fā)貨時，先撥號上網(wǎng)，然后啟動客戶端程序。在登錄過程中，客戶端程序會檢查服務器上的標識和時間戳檢查這些主數(shù)據(jù)是否有更新，如果有就先下載，下載完成后再進入系統(tǒng)正常使用。在服務器更新的數(shù)據(jù)比較多的情況下，下載的時間會比較長，這時如果遇到急需發(fā)貨,則會影響到貨物不能及時發(fā)出去。為了解決這個問題，我設置了在每天凌晨的某個時刻自動登錄和啟動客戶端程序，在下載更新數(shù)據(jù)完成后自動關閉。這樣可以把一部份數(shù)據(jù)更新的內容放在非工作時間里完成，減少了發(fā)貨登錄的時間。用戶登錄后開始進行發(fā)貨操作。輸入銷售訂單，通過本地代理表系統(tǒng)自動到服務器獲取該銷售訂單的數(shù)據(jù)，如發(fā)貨的數(shù)量，客戶編號等。而一些基礎數(shù)據(jù)則可以直接從本地的數(shù)據(jù)庫中得到，如銷售產品的描述，客戶的地址/電話/傳真，發(fā)貨的庫位等。完成出貨動作后，會自動更新服務器的庫存。而這一更新通過提交事務在后臺進行，不影響前臺的操作。所以，対用戶來講，能夠進行正常的操作，不會因為速度慢而進行不下去。
在當今的信息社會里，互聯(lián)網(wǎng)帶來了相互連通的方便，而且知識爆炸，數(shù)據(jù)的分布式訪問是個必然的趨勢。目前新起的XML技術，提供了各種平臺數(shù)據(jù)庫之間的一個公共數(shù)據(jù)訪問標準，可以用來構建更加靈活，適應性更強的分布數(shù)據(jù)庫技術。將XML用在分布式數(shù)據(jù)庫中，將是未來的一個趨勢。
本文摘自 ：https://blog.51cto.com/u
