一.引言

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

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

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

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

二.現狀分析

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

(表一)

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

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

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

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

1. 處理關系型數據的能力較弱，數據維護困難，查詢和統計效率低下。

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

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

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

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

三.解決問題思路和方案

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

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

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

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

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

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

最終，我們決定使用數據對象映射的方式，實現新老系統數據遷移。具體如圖一：

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

(圖一)

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

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

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

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

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

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

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

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

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

四.實踐過程描述

根據我們擬定的數據遷移方案，我們依托OA系統現有的表單設計器，自動化的進行數據遷移。具體過程如下：

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

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

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

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

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

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

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

(表二)

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

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

(圖二) 

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

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

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

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

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

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

五.結束語

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

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

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

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

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

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

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