Lotus-Notes数据库向ORACLE数据迁移

一.引言

作为一个优秀的软件系统，不光要求其能够满足业务使用需要、稳定运行;对系统的长期维护、系统升级也有极其苛刻的要求。我们的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系统的数据迁移提供了成功案例和合理的实施方法。

下一步，我们将针对数据迁移中的不足，继续优化数据迁移的方案和工具。在数据验证方面，提供相关工具验证数据的正确性和完整性，并设计实现数据的删除，如果数据量很大的话，我们考虑后续项目中支持断点续传的功能。