ORACLE到DM的系统移植方案.docVIP

ORACLE数据库向DM的移植 数据库系统移植概述 不同的关系数据管理系统之间存在结构差异，Oracle、SQL Server和DM都对SQL-92标准做了许多自有的扩展。系统移植过程中面临的最重要的问题是执行SQL-92语言标准和每一个关系数据管理系统提供的语言扩展。有一些开发人员只使用标准的SQL语法，喜欢尽可能的保持他们的程序代码的普遍性。通常，这种方法把程序代码限制在SQL-92标准的入门级别（Entry-Level）上，而这个级别是被许多的数据库产品实现了的，包括Oracle和DM。 这种方法将会产生一些不必要的程序代码复杂性而且还会对程序的性能造成很大的影响。例如，Oracle、DM的DECODE函数、CASE表达式是一个非标准的SQL扩展。私有开发接口的使用带来了新的问题。用Oracle OCI（Oracle Call Interface）进行程序转换通常需要很多资源。开发一个可能用到多个关系数据管理系统的应用程序，最好是考虑使用标准数据库接口如ODBC、OLEDB、JDBC等。 从应用程序开发的观点来看，Oracle和DM是以相似的方法来管理数据的。在Oracle和DM之间有着一定的内部区别，但是如果管理得当，可以把这些区别对移植的影响减到最小。 第二章 系统移植的基本步骤 数据库系统的移植通常采用以下几个步骤进行。 1、分析系统 分析系统的目的在于了解系统，判断系统移植的工作量及确定移植工作的重点和方案，主要包括以下一些内容： (1) 后台操作系统是什么及其版本信息，Windows、Unix、Linux等。 (2) 后台数据库是什么及其版本信息，是SQL Server、Oracle、Informix还是其它。 (3) 前台开发工具是什么及其版本信息，是.NET、JBuilder、Delphi还是其它。 (4) 应用系统采用了什么开发模式，C/S还是B/S模式。 (5) 应用系统使用的接口，常用的如ODBC、OLEDB、JDBC；如果是采用通用的接口，重点将转向后台数据库的移植；如果是采用一些特别的专用接口如OCI、API或者自定义的接口标准，则需要进行相关接口的开发，这时候移植工作重点将转向接口的开发上面来。 (6) 相关的一些开发组件及其版本信息。 (7) 相关的运行环境及其版本信息，如Tomcat、.NET Framework等。 (8) 是否用到第三方的开发工具和平台，如SuperMap等。 (9) 数据库的相关信息，主要有几个库，这些库之间的关系。 (10) 涉及到的数据类型，常规的如CHAR、VARCHAR、INT等，这些各种数据库一般都支持，如果系统用到了如日期、时间、时间戳、文本、图像等类型，在移植的时候需要注意各种数据库之间的一些差异，主要是关注长度、精度、标度信息，有时候需要做些类型转换，如在Oracle中的VARCHAR(8000)，在达梦数据库中可考虑将其转换成TEXT类型或采用16KB以上的建库模式加以解决。 (11) 注意表的定义信息，主要是关注自定义的数据类型、自定义的缺省值，因SQL Server等数据库可创建自定义的数据类型和自定义的缺省值，而使用达梦的JDTS工具无法将这些信息转换出来，需要在原系统中查找。 (12) 是否使用到了视图、存储过程、存储函数、触发器、序列等；如果没有使用到这些，后台数据库的移植工作将主要是进行数据迁移；如果用到了这些，且数量较多，后台数据库的移植工作将是脚本的移植转换工作。 (13) 是否用到了后台数据库的系统字典，因各数据库的系统字典格式和内容均不一样，这时候需要分析原数据库的系统字典的涵义，只能根据使用的实际情况作相应的处理。 (14) 系统的运行规模和效率要求，如并发访问量，使用的频度，时间响应要求，主要是确定优化的方案，如果要求不高，优化的时候主要是采用创建索引的方法，如果要求较高，可考虑采用改写SQL语句的方法来进行，甚至考虑改写程序逻辑。 (15) 是否有其它的特别的要求，如安全控制、双机热备、数据同步等，如果有这些要求，移植工作的重点和难点将转向这些问题的解决。 2、确定方案 在分析了系统之后，应确定移植的重点和难点，并确定移植方案。 首先应确定系统移植工作的主承担方，即以应用软件开发商为主还是以数据库供应商为主；如以应用软件开发商为主，则数据库供应商应提供该数据库的技术支持服务，主要负责和承担数据库差异的解释工作；如以数据库供应商为主，则应用软件开发商则应提供对应用系统比较熟悉的技术人员配合移植工作。 一般来讲移植工作分为后台数据库的移植和前台应用系统的移植。 3、搭建环境 搭建环境包括搭建原系统运行环境和新系统环境，便于后续做功能和性能对比测试。 4、系统移植 数据库系统移植主要包括功能移植、功能测试和效率优化。在功能移植的过程