一.引言

作為一個優(yōu)秀的軟件系統(tǒng)，不光要求其能夠滿足業(yè)務使用需要、穩(wěn)定運行;對系統(tǒng)的長期維護、系統(tǒng)升級也有極其苛刻的要求。我們的OA產品，在三年前主要是以Domino+ Lotus-Notes數(shù)據(jù)庫架構實現(xiàn)的;三年后的今天，這樣的架構已經越來越不能滿足數(shù)據(jù)協(xié)同的要求，而客戶對OA的功能要求也越來越多，老系統(tǒng)已經不堪重負。而根據(jù)目前市場主流OA的架構，多是基于JAVA的MVC三層架構設計實現(xiàn)的，Domino產品在推廣實施上已經逐漸開始占劣勢，而Domino也在慢慢的退出歷史舞臺。

為了解決上面的問題，提高OA產品競爭力，增強產品的推廣性，OA產品線，對產品的升級做了大量的工作和充足的準備。OA系統(tǒng)版本的更新?lián)Q代迫在眉睫。

但老系統(tǒng)數(shù)據(jù)向新版本系統(tǒng)數(shù)據(jù)庫的遷移工作，一直是實施的心病，是不能逃避但又無計可施的大麻煩。

在實施南京大學辦公自動化系統(tǒng)(以下簡稱南大OA)從Domino版本向JAVA版本的升級，為了保證將原Lotus-Notes數(shù)據(jù)庫(以下簡稱LN庫)的數(shù)據(jù)完整的遷移到新版本系統(tǒng)的Oracle數(shù)據(jù)庫，我們決定開始著手進行數(shù)據(jù)遷移的研究，解決掉這個攔路虎。

二.現(xiàn)狀分析

我們詳細了解Domino系統(tǒng)的數(shù)據(jù)庫和Oracle數(shù)據(jù)庫的差異,然后將這兩個數(shù)據(jù)庫進行簡單比較，如表一。 

(表一)

通過比對可以發(fā)現(xiàn)，LN庫是通過文件形式存放的，它的記錄、索引的存放方式和Oracle數(shù)據(jù)庫完全不同，它的所有數(shù)據(jù)是以文件方式存放在NSF文件中，元數(shù)據(jù)存放方式的不同直接導致了數(shù)據(jù)移植的難度大大增加。

LN庫的特點，就是基于文檔的數(shù)據(jù)管理模式，它使用非結構化的元數(shù)據(jù);使用視圖來代替索引進行定位數(shù)據(jù)。

在通過南大OA的LN庫目前情況分析，當數(shù)據(jù)庫文檔數(shù)據(jù)(記錄數(shù))達到一定量級的時候，已經引發(fā)查詢效率逐步降低的問題。目前已經有所感覺，但尚不非常明顯。但一旦速度再降低，就是無解的問題了。據(jù)目前所知，只有提高物理設備性能或者拆分表單(類似關系型數(shù)據(jù)庫中的拆表)的方法能夠解決 。

除了這個問題存在之外，我們還整理了LN數(shù)據(jù)庫目前存在的其他問題：

1. 處理關系型數(shù)據(jù)的能力較弱，數(shù)據(jù)維護困難，查詢和統(tǒng)計效率低下。

2. 由于LN庫是IBM本身定制開發(fā)的數(shù)據(jù)庫，與Domino之間的耦合度非常高，對B/S開發(fā)的支持功能很弱。

3. Domino不是一個開放的系統(tǒng)，無論從數(shù)據(jù)使用還是與其他系統(tǒng)接口上講，其中邏輯代碼和表單、代理、視圖耦合度非常高，使得代碼維護困難，系統(tǒng)靈活性受到很大限制。

4. 架構過時，不利推廣。如果要進行移動版本OA開發(fā)或協(xié)同功能開發(fā)，無法依托Domino框架實施。

5. Domino軟件本身也不是免費的，IBM的東西的價格一般都不便宜。

三.解決問題思路和方案

考慮LN數(shù)據(jù)庫向Oracle數(shù)據(jù)庫的移植，將在OA產品推廣實施過程中，會是一個長期且普遍的工作事項;所以，我們優(yōu)先考慮使用數(shù)據(jù)移植工具，一次實踐能夠多次復制，不需要每次移植都要二次開發(fā)，甚至完全手工操作。

在數(shù)據(jù)移植的方式選擇上，我們進行了調研。現(xiàn)在常用的方法包括Notes代理、NotesSQL以及自主開發(fā)對象轉化等幾種方式。下面進行分別表述：

1)Notes代理方式：這個方法存在以下問題：

a)要完成數(shù)據(jù)轉換任務 ，需要大量代理在服務端運行。但服務器上運行的代理較多時，會大大降低服務器的性能和代理的穩(wěn)定性，可能出現(xiàn)一些數(shù)據(jù)丟失的問題卻很難發(fā)現(xiàn)。

b)使用Lotus Script或Lotus公式所寫的代理對大文本，二進制流的處理都不理想。

2)使用NotesSQL方式，也存在對大文本和二進制流處理的問題。

最終，我們決定使用數(shù)據(jù)對象映射的方式，實現(xiàn)新老系統(tǒng)數(shù)據(jù)遷移。具體如圖一：

考慮老版本系統(tǒng)中，存在大量的附件，所以上面的兩種方式都被排除掉了。 

(圖一)

從上面出發(fā)點考慮，我們先建立自己的映射模型，整理從LN數(shù)據(jù)庫到Oracle數(shù)據(jù)庫的元數(shù)據(jù)、字段、記錄的映射關系，在轉換程序上實現(xiàn)數(shù)據(jù)庫、表、字段的映射關系配置，并通過工具最終實現(xiàn)數(shù)據(jù)遷移。

在原LN數(shù)據(jù)庫中，每個業(yè)務表單都是以一個獨立的文件存放。通俗的講，就是表之間不存在主從表關系，所有業(yè)務都是使用一張表實現(xiàn)。因此，從快速開發(fā)工具的角度考慮，我們簡略掉了數(shù)據(jù)表中多對一和多對多的映射關系，只針對單表映射進行工具開發(fā)。

考慮客戶在進行JAVA版本系統(tǒng)建設時，對原來Domino系統(tǒng)中的表單會進行較大修改和調整，我們決定將Domino版本系統(tǒng)表單以歷史文件的形式在新版JAVA系統(tǒng)中存放和展現(xiàn)，這樣也不會與JAVA版本OA的數(shù)據(jù)沖突，更利于數(shù)據(jù)的多次遷移、增量遷移。

經過和南大用戶溝通，這種方法也得到了校方的認可。因此，老版本數(shù)據(jù)遷移的物理表和新版本OA系統(tǒng)中，雖然相同的辦文辦公流程，但使用了不同物理表進行存放，也使用不同的表單模板設置展現(xiàn)。

綜上所述，本次實踐設計的重心放置在以下方面：

1)首先，大多數(shù)字段都要能夠快速匹配多數(shù)字段的映射關系，以減少數(shù)據(jù)遷移的配置工作量。我們確定在LN庫和Oracle庫中的，將需要遷移的字段名稱和Oracle數(shù)據(jù)庫字段配置成名稱一樣，當名稱一樣的字段存在時，系統(tǒng)將直接進行數(shù)據(jù)遷移。

2)其次，轉換程序需要支持將個別字段配置新老數(shù)據(jù)映射關系來實現(xiàn)數(shù)據(jù)遷移。于是，我們可以約定一種映射關系寫法，由前臺數(shù)據(jù)遷移人員編寫字段的映射關系，轉換程序解析映射關系，進行數(shù)據(jù)遷移。

3)第三，要支持原庫中多字段移植到新庫中，合并到一個字段的邏輯關系。我們可以對二點的映射關系進行擴展，到達映射規(guī)則填寫時，支持多對一的功能。

4)最后，一定要支持原系統(tǒng)中附件的遷移。在OA系統(tǒng)中，附件的存放位置是在工程文件內指定目錄下的，因此只要將原LN數(shù)據(jù)庫中的附件移植到項目部署工程下的指定目錄內。

四.實踐過程描述

根據(jù)我們擬定的數(shù)據(jù)遷移方案，我們依托OA系統(tǒng)現(xiàn)有的表單設計器，自動化的進行數(shù)據(jù)遷移。具體過程如下：

1)由對Domino系統(tǒng)數(shù)據(jù)結構熟悉的人員，整理原統(tǒng)各表單的字段;JAVA項目組根據(jù)老表單的樣式，對照系統(tǒng)使用要求，設計移植后的數(shù)據(jù)結構和表單展現(xiàn)。整理的最終結果，是為了得到LN庫表單和RDB庫物理表字段之間的映射關系。

A) 我們在實施中，依托工作流表單快速開發(fā)，對于一張LN表內的字段向Oracle轉換時，盡量保持字段名稱一樣，降低字段映射的工作量。功能內代碼邏輯如下：

I. 自動按照字段名稱移植數(shù)據(jù)。新老表內名稱相同的字段，自動移植數(shù)據(jù)。

II. 支持個別字段按照新老庫配置的映射關系來實現(xiàn)數(shù)據(jù)遷移。例如，有些特殊字段(如“來文字號：ywzh”)在新庫中的字段名稱叫做ywh_。約定的新老字段映射方式為“新表單字段代碼”+“|”+“*老的字段代碼*”(如來文字號的映射關系為“ywh_| *ywzh*”，新字段以“**”包含。多個特殊字段以“，”分隔填寫。

III. 支持老庫中多字段到新庫中合并為一個字段的設置。對于出現(xiàn)的原LN表中，是多個字段，但到Oracle庫中合并成一個字段的問題，設計了字段的映射方式。例如，LN庫中，收文的來文字號分別存在3個字段中(字段：ywzh，ywnf和ywlsh)，到了Oracle庫中，合并成ywhFld_字段。約定的映射規(guī)則，擴展了單字段名稱修改的映射規(guī)則，在映射關系編輯時填寫ywhFld_|*ywzh**[*ywnf*]*ywlsh*號，轉換程序就能識別映射關系并 可以進行轉換。

下面， 以一個南大OA某張表中映射關系的例子(如表二)。

下面， 以一個南大OA某張表中映射關系的例子（如表二）。

(表二)

2)根據(jù)設計的表單展現(xiàn)和數(shù)據(jù)結構，在OA系統(tǒng)內進行數(shù)據(jù)庫配置和表單開發(fā)。由于OA系統(tǒng)內具有表單配置器和表單設計引擎，所以直接將設計好的Oracle數(shù)據(jù)庫在OA系統(tǒng)內填寫和并生成物理表單。這都是配置的工作，不涉及任何代碼的編寫或修改。

3)設計數(shù)據(jù)轉換程序操作向導界面，用來調用據(jù)轉換核心程序，實現(xiàn)數(shù)據(jù)移植。界面最終實現(xiàn)如圖二： 

(圖二) 

4)編寫數(shù)據(jù)轉換核心程序，根據(jù)提供LN的數(shù)據(jù)信息和Oracle數(shù)據(jù)表，實現(xiàn)數(shù)據(jù)遷移和轉換。核心程序的實現(xiàn)步驟如下：

A)根據(jù)方案設計和界面提交內容，分別連接兩套數(shù)據(jù)庫。

B)檢查LN數(shù)據(jù)庫內數(shù)據(jù)表字段并進行對象組裝，通過分析特殊字段映射關系內容提取特殊字段，非特殊字段通過兩庫的字段比對直接映射。

C)將映射完成的字段，組裝成RDB庫中的對象，通過統(tǒng)一接口方法，將組裝后的對象插入到RDB庫中。

D)在解析LN庫時，將原系統(tǒng)中的附件解析，通過I/O流向文件的轉換，在服務器指定目錄中寫入歷史附件。

E)對于未辦結的辦文辦公流程，沒有建立數(shù)據(jù)遷移的模型。目前，只能通過研發(fā)人員逐個事項分析，獲取辦件步驟狀態(tài)信息，最終 在JAVA版本OA系統(tǒng)流程中進行數(shù)據(jù)同步。

五.結束語

經過數(shù)據(jù)遷移工作，我們完全實現(xiàn)了將DOMINO版OA系統(tǒng)中數(shù)據(jù)向JAVA版OA系統(tǒng)數(shù)據(jù)的遷移，數(shù)據(jù)遷移的模式也是支持復制實施的。數(shù)據(jù)遷移之后，我們形成了DOMINO版本 OA系統(tǒng)的歷史流程庫，且歷史表單與新版本流程使用表單不存在沖突。

數(shù)據(jù)遷移的速度也是可以接受的。畢竟OA的辦文辦件數(shù)量不是非常多，我們最多辦文的一個事項的數(shù)據(jù)遷移時間，也只是耗費 20-30分鐘就完成了。

在整體數(shù)據(jù)遷移方案中，也存在尚未解決的問題：

1. 由于項目資源緊張，時間倉促，我們在對移植后數(shù)據(jù)驗證方面考慮不足。

2. 對于一次性移植不成功的數(shù)據(jù)，需要支持移植數(shù)據(jù)的刪除，并達到可以多次移植的 目的。

從整體上來看，本次數(shù)據(jù)遷移的實踐，達到了老系統(tǒng)數(shù)據(jù)向新系統(tǒng)數(shù)據(jù)遷移的目標 。數(shù)據(jù)遷移工作的實施，為我們以后各院校中，從DOMINO版OA系統(tǒng) 向JAVA版OA系統(tǒng)的數(shù)據(jù)遷移提供了成功案例和合理的實施方法。

下一步，我們將針對數(shù)據(jù)遷移中的不足，繼續(xù)優(yōu)化數(shù)據(jù)遷移的方案和工具。在數(shù)據(jù)驗證方面，提供相關工具驗證數(shù)據(jù)的正確性和完整性，并設計實現(xiàn)數(shù)據(jù)的刪除，如果數(shù)據(jù)量很大的話，我們考慮后續(xù)項目中支持斷點續(xù)傳的功能。