시소당

SQL 서버가 오라클을 만났을 때 오라클

복잡해진 시스템 환경, '통합'으로 돌파하라

분야별 통합 키워드 1 | 이기종 DBMS 통합
SQL 서버가 오라클을 만났을 때

유경용

KAIST 에서 데이터베이스를 전공했으며, 검색엔진 회사인 스피드베이스 대표로 재직하면서 YES24, 모닝365, 북스포유, 서점백화점 등에 검색엔진을 공급한 바 있다. 현재는 삼성전자 디지털솔루션센터에서 책임연구원으로 근무하고 있다.
인터넷 서비스를 하는 A사에 근무하는 개발팀장 홍길동 씨는 마이크로소프트의 SQL 서버 전문가이자 A사의 모든 시스템 개발을 주도하고 있는 핵심인력이다. 따라서 A사의 모든 시스템은 SQL 서버로 구축됐고 시스템도 잘 운영되고 있었다. 이러한 안정된 시스템의 뒷받침 하에 A사 역시 치열한 경쟁을 뚫고 업계에서 1위를 달리고 있었다. 어느 정도 시간이 지나자, A사는 사업 범위를 확장하게 되었고 다른 기업 B사를 합병하게 되었다. 이로 인해 홍길동 씨는 양사의 시스템 통합 프로젝트를 진행하게 되었다. 홍길동 씨에게 주어진 임무는 이미 개발되어 잘 수행되고 있는 B사의 애플리케이션은 그대로 사용하면서 구매 정보 등과 같이 재정에 관련된 부분만 A사의 시스템에 통합시키는 것이었다. 이를 위해 B사의 시스템을 조사하던 홍길동 씨는 문제에 부딪히게 되었다. 왜냐하면 새로 합병된 B사의 DBMS는 SQL 서버가 아닌 오라클이었기 때문이다. SQL 서버라면 누구 못지않게 자신이 있는 홍길동 씨였으나 오라클은 별로 경험이 없었다. 홍길동 씨는 오라클의 모든 데이터를 SQL 서버로 이관하기 위한 방대한 프로젝트를 계획하고, B사의 애플리케이션도 모두 SQL 서버에 맞춰 수정하는 대대적인 개편 프로젝트를 계획하게 된다.

이기종 DBMS 통합시 알아야 할 사항

앞 에서 설명한 시나리오는 기업간의 합병시 흔히 개발자들이 경험하게 되는 어려움이다. 왜냐하면 기업간의 합병이 사업성을 중심으로 이뤄지는 것이지 동종의 시스템 구성을 중심으로 일어나는 것이 아니기 때문이다(예를 들면 SQL 서버로 구축된 회사들끼리 합병하고 오라클로 구축된 회사들끼리 합병하지는 않는다).
기업간 합병의 예가 아니더라도 100여명이 넘는 규모의 IT 회사라면 여러 개발팀이 존재하고 각 개발팀마다 서로 다른 DBMS를 사용해 개발하는 경우도 흔히 발생한다. 특히 처음에는 연계되지 않을 것이라고 생각됐던 이러한 각 시스템들을 어느 시점에 통합해야 하는 경우, 개발자들은 이기종 DBMS간의 통합 문제에 부딪히게 된다. 이번 특집 2-1부에서는 이와 같이 이기종 DBMS간의 통합시 필요한 사항들에 대해 고려해 보고, 각 개발자가 처한 상황에 따라 DBMS 통합 문제에 대한 해결책을 찾아보고자 한다. DBMS에는 앞에서 언급한 SQL 서버나 오라클 이외에도 다양한 DBMS가 존재하지만, 본 기사에는 SQL 서버 2000(이하 SQL 서버)과 오라클 9i R2(이하 오라클 9i)를 대상으로 설명하겠다. 이는 SQL 서버 2000 또는 오라클 9i가 많이 사용되고 있을 것이라는 필자의 주관적인 판단에 따른 것으로, 본 기사에서 작성한 부분을 조금만 응용하면 다른 DBMS 연동으로 확장할 수 있을 것이다.

데이터베이스 이관

먼 저 앞서 홍길동 씨의 생각처럼 단순하게 오라클의 테이블이나 색인 등을 모두 SQL 서버로 옮겨 놓고 SQL 서버만 사용하는 방안을 생각해 보자. 이러한 방법을 ‘데이터베이스 이관(Database Migration)’이라고 하는데, ‘데이터베이스 이관’의 정확한 의미는 데이터베이스 객체(테이블, 색인, 뷰, 제약사항 등)를 한쪽 DBMS 형식에서 다른 한쪽의 DBMS 형식으로 변환해 모두 옮기는 과정을 말한다.
이 방법을 이용해 통합을 하게 되는 경우에는 거의 재개발에 가까운 작업이 일어나게 된다. 왜냐하면 단순히 DBMS를 한쪽 DBMS에 변경해 이관하는 것으로 끝나는 것이 아니라, 두 DBMS를 완전히 하나의 DBMS로 통합하기 위해 데이터베이스 설계까지 변경하는 경우가 많기 때문이다(이는 관리자들이 이왕 하는 김에 이것저것 다 하자고 하는 경우에서 비롯된다). 또한 DBMS가 변경되면 애플리케이션이 JDBC나 ODBC 등의 표준화된 DBMS 인터페이스를 이용한다고 할지라도 애플리케이션이 각 DBMS에 의존적인 SQL문을 사용한 경우에는 애플리케이션의 SQL문을 수정해야 하기 때문이다. 그러나 이러한 고통스런 작업을 통해 일단 통합이 완료되면 SQL 서버이든 오라클이든 하나의 DBMS만을 관리해 주면 된다는 장점이 있다.
하나의 DBMS로 모두 모아서 사용한다는 단순하고 쉬운 개념 때문에 데이터 통합의 요구가 있을 때마다 가장 먼저 고려하게 되는 방법이다. 여기서는 두 DBMS 사이의 차이점을 비교함으로써 데이터베이스 이관시 어떤 점을 유의하고 변경해야 하는지를 알아보도록 하겠다.

데이터베이스 객체 이관

기 본적으로 SQL문에 대한 표준이 존재하고 있으나, 대부분의 DBMS 회사들은 이러한 표준을 기반으로 하여 자신들만의 독자적인 형태로 확장함으로써 사실상 100% 호환이 되지 않고 있다. 또한 SQL 표준에도 제정된 시점에 따라 SQL-92, SQL 1999, SQL 2003 등이 있는데, DBMS가 출시된 시기에 따라 서로 지원하는 표준이 다르다. 예를 들면 SQL 서버 2000은 SQL-92에 기반하고 있으며, 오라클9i는 SQL 1999, 그리고 최근 출시된 오라클 10g는 SQL 2003에 기반하고 있다. 그러나 기본적으로 SQL 1999, SQL 2003은 모두 SQL-92를 포함하고 있으므로, SQL 서버든 오라클이든 SQL-92를 기초로 하고 있다고 볼 수 있다(여기서 주의할 점은 SQL 1999 이후부터는 객체-관계형(Object-Relational) 개념이 포함됐는데, 이러한 객체-관계형 기능을 이용한 부분은 SQL 서버에서는 지원하지 않으므로 이를 오라클에서 SQL 서버로 이관하기는 곤란하다. 이를 위해서는 객체-관계형 데이터베이스 개념을 관계형 데이터베이스로 구현하는 방법에 대한 학습이 필요하나 내용이 방대해 여기서는 다루지 않을 것이다).

데이터 이관을 위한 사전 준비

설명을 시작하기 전에 두 DBMS를 실제로 비교하기 위해서 미리 샘플용 테이블을 준비한 뒤에 이를 활용해 설명하고자 한다. 설명을 쉽게 하기 위해 SQL 서버와 오라클 모두 하나의 윈도우 서버 2000에 설치된 것으로 가정한다.

명명법
가장 먼저 SQL 서버와 오라클에 있어서 테이블을 명명하는 방법부터 차이가 난다. SQL 서버의 경우에는 테이블 명은 네 부분으로 구성된다.

보 통은 server_name은 로컬 서버명으로, database_name은 현재 설정된 데이터베이스로, owner_name은 현재 로그인한 사용자를 디폴트로 설정하기 때문에 디폴트 값을 사용하고자 하는 경우에는 앞의 세 부분은 생략하고 테이블명만 쓰면 된다. 테이블명은 디폴트 값이 없으므로 반드시 써야 한다. 오라클의 경우에는 다음과 같이 두 부분으로 나눠진다.

여기서 schema_name은 테이블을 생성한 사용자 계정이라고 생각하면 되며, 역시 이를 생략할 수 있다. schema_name을 생략하면 디폴트로, 현재 로그인한 사용자로 간주한다.

데이터 타입
DBMS 에서 표준이 가장 무시되는 영역이 이 데이터 타입이라고 생각된다. 왜냐하면 SQL 서버이든 오라클이든 ANSI SQL 데이터 타입 표준을 구현했음에도 불구하고 이를 권고하지 않고 자신들의 독자적인 데이터 타입을 권고하고 있기 때문이다. <표 1>은 SQL 서버와 오라클 사이에 데이터 타입 변경을 도와주기 위한 대응표이다.
기본적으로 오라클에는 SQL 서버의 bit 데이터 타입이 없으나, 이를 <표 1>과 같이 NUMBER(3)나 CHAR(1)으로 대신해 오라클에서 사용할 수 있다. 그 밖에 SQL 서버의 text, ntext, image 데이터 타입에 대해서 오라클에서는 각각 CLOB, NCLOB, BLOB 데이터 타입을 사용하는 정도만 알고 있다면 대부분 변경하는데 큰 무리는 없다. 마지막으로 DBMS의 이관을 고려하고 데이터베이스를 설계하고 있다면 숫자에 대해서는 표준에서 권고하는 DECIMAL(p, s) 형식을 사용하기를 권한다. 이는 모든 DBMS가 DECIMAL이라는 표준 데이터 타입을 지원하기 때문에 모든 DBMS에서 동일하게 작동되기 때문이다.

오라클 시퀀스와 SQL 서버 2000의 아이덴티티 컬럼
유 일(unique)한 숫자를 생성하는 기능을 오라클에서는 시퀀스(sequence)라는 것으로, SQL 서버는 아이덴티티(identity) 컬럼으로 제공하고 있다. 차이점은 오라클의 경우 시퀀스라는 객체를 이용해 유일한 숫자를 생성한 뒤 이 값을 읽어서 테이블의 컬럼에 입력하는 형식이며, SQL 서버의 경우에는 테이블을 정의할 때 특정 컬럼을 아이덴티티 컬럼으로 정의해 레코드가 입력될 때 해당 아이덴티티 컬럼이 자동으로 유일한 숫자를 생성하도록 한다는 점이다. <리스트 1>을 보면 SQL 서버에서는 col1 컬럼에 특별히 값을 입력하지 않아도 자동으로 유일한 숫자가 생성되도록 되어 있고, 오라클에서는 col1 컬럼에 시퀀스로부터 읽은 숫자를 입력하도록 되어 있다 데이터를 확인해보면 자동으로 TEST 테이블의 col1 컬럼에 유일한 값이 들어가 있는 것을 확인할 수 있을 것이다.

무결성 제약 조건
무 결성 제약 조건에는 주 키(Primary key), 유일 키(Unique Key), 외부 키(Foreign Key) 등이 있으며, 그 밖의 CHECK, DEFAULT 제약사항 등이 있는데 문장 형식 등은 대부분 유사하다. 단 주 키를 생성할 때 SQL 서버에서는 디폴트로 군집(clustered) 색인이라는 것을 생성한다. 이는 색인을 키 값의 순서에 맞추어 물리적으로도 저장하는 것으로 오라클에는 이러한 색인이 없다. 군집 색인이 범위를 검색할 때 성능이 우수할 것으로는 판단되지만, 약간의 성능의 차이를 빼고는 크게 외부적으로 차이가 나지 않으므로 군집 색인을 오라클로 옮기고자 할 때 일반 비군집(non-clustered) 색인으로 대체해도 무방하다(특별한 성능 차이 역시 DBMS 제품에 따라 차이가 나므로, 군집 색인과 비군집 색인의 성능 차이는 SQL 서버 내에서의 문제이지 오라클 내에서의 문제는 아니다).
또한 유일 키의 경우 SQL 서버는 NULL 값에 대해 다른 값과 동일하게 취급해 유일 키로 정의된 컬럼에는 단 한 개의 NULL 값 외에는 중복해서 들어갈 수 없으나 오라클의 경우에는 NULL 값을 특별하게 처리해 유일 키 컬럼에 여러 개의 NULL 값이 중복해서 들어갈 수 있도록 허용해 준다.

그 외의 고려할 점으로 뷰 및 보안 관련 사항이 있다. 뷰의 경우에는 일반적으로 이관하는데 큰 불편은 없으나 오라클에는 CREATE FORCE 옵션이 있어서 뷰가 사용하는 테이블이 없는 상태에서 뷰를 만들 수 있는 유용한 기능이 있다(일반적으로 뷰가 기초로 하는 테이블이 존재해야만 이를 기반으로 뷰를 생성할 수 있다). 보안 관련해서는 두 DBMS 모두 테이블에 대한 SELECT, INSERT, UPDATE, DELETE 권한과 저장 프로시저에 대한 EXECUTE 권한을 GRANT하고 REVOKE할 수 있으며, SQL 서버에는 DENY라고 해서 특정 사용자만 접근을 막을 수 있는 기능도 존재한다.

데이터베이스 애플리케이션 코드 이관

지 금까지 DBMS 내에 존재하는 데이터 타입, 테이블, 색인 등과 같이 DBMS 내의 객체에 대해서 전체적으로 차이점을 알아봤다. 이제부터는 이러한 객체를 사용하는 SQL문, 저장 프로시저, 시스템 함수, 트리거 등의 차이점에 대해서 살펴보도록 하겠다.

SQL문
데이터베이스를 사용하기 위한 언어인 SQL문의 대부분은 표준을 따르고 있으므로 대부분 유사하지만, SQL 서버와 오라클이 각각 독자적으로 확장한 부분에 대해서는 다음의 <표 2>와 같은 차이점이 존재한다.

Transact-SQL 및 PL/SQL, 저장 프로시저
SQL 문만으로는 비즈니스 로직을 구현하기에 부족하기 때문에 SQL 서버와 오라클은 각각 독자적인 프로그래밍 언어를 갖고 있는데, 이것이 Transact-SQL과 PL/SQL이다. 이러한 언어들은 주로 저장 프로시저나 함수를 작성하는데 유용하게 사용된다. 각 언어별 내용은 방대해 여기서 모두 설명하기 곤란하므로 동일한 로직에 대해 Transact-SQL과 PL/SQL로 작성한 저장 프로시저를 비교함으로써 설명을 대신하고자 한다.

시스템 함수
SQL 서버와 오라클은 수학적인 계산이나 데이터 변환 등에 필요한 다양한 시스템 함수를 제공하고 있다. 이들에 대한 대응표는 <표 3>과 같다. 이를 활용해 이관시 해당 시스템 함수를 대응하는 상대방 DBMS 함수로 변경하도록 하자.

트리거
기 본적으로 SQL 서버와 오라클 모두 특정 테이블에 INSERT, UPDATE, DELETE와 같은 SQL문이 적용된 후에 트리거가 수행되는 사후(After) 트리거를 제공하고 있으나, 오라클의 경우에는 SQL문이 수행되기 전에 미리 수행되는 사전(Before) 트리거도 제공하고 있다. 이러한 사전 트리거는 SQL 서버에 없기 때문에 트리거가 시작되기 전에 수행되는 INSTEAD OF 트리거를 응용해 사전 트리거를 흉내내야 한다.

데이터 이관 툴

지금까지 DBMS의 객체 및 이를 사용하는 언어, 함수, 트리거 등의 차이점에 대해서 알아봤다. 이제 실제로 데이터를 옮겨보도록 하자.
SQL 서버와 오라클은 각각 DTS(Data Transformation Services : 데이터 변환 서비스)와 OMWB(Oracle Migration Workbench : 오라클 이관 워크벤치)라는 툴을 제공하고 있다. DTS는 주로 한 데이터 소스로부터 다른 데이터 소스로 데이터를 이관하고 데이터 타입을 변환해 주는 역할을 하며, 그 밖에도 이메일을 보내거나 액티브X 스크립트 및 FTP 등도 수행하도록 지정할 수 있다.
OMWB의 경우에는 오라클이 모든 데이터를 오라클에 저장하고자 하는 철학과 맞물려 이관을 위해 정성들여 만들어진 도구로써 심지어 Transact-SQL까지도 PL/SQL로 변환해 주기까지 한다. 여기서는 DTS를 갖고 데이터 이관의 예를 보이도록 하겠다.

DTS
그 럼 DTS를 이용해 데이터를 이관하는데 가장 쉬운 방법인 ‘DTS 가져오기/내보내기 마법사’를 사용해 보도록 하자. 그 전에 먼저 ODBC 데이터 원본 관리자를 이용해 데이터를 가져올 오라클에 대해 <화면 1>과 같이 Oracle9i라는 시스템 DSN을 생성해 준다. <화면 1>에서 Data Source Name 항목은 생성하는 시스템 DSN에 이름을 붙여주는 것이며, TNS Service Name은 접속할 오라클 데이터베이스를 구분하기 위한 네트워크 이름 정도로 생각하면 된다. TNS Service Name 항목은 ‘오라클 설치 폴더\ora92\network\admin\tnsname. ora’에 가면 현재 서버에서 접속할 수 있는 오라클 TNS Service Name이 나열되어 있다. 여기서 원하는 TNS Service Name을 선택하도록 한다.

<화면 1> ODBC 시스템 DSN 생성


이제 시작 메뉴에서 『프로그램(P) | Microsoft SQL 서버 | 데이터 가져오기 및 내보내기』를 선택하면 <화면 2>처럼 ‘DTS 가져오기/내보내기 마법사’가 시작된다.

<화면 2> DTS 가져오기/내보내기 마법사의 데이터 원본 설정 화면

이 렇게 데이터 원본을 선정하고 나면 그 다음에는 데이터를 저장할 대상을 선택한 뒤, ‘원본 데이터베이스에서 테이블 및 뷰 복사’를 선택하면 그 다음 화면에서 복사하기 원하는 테이블을 선택하게 된다(여기서는 TEST 테이블을 선택한다). 주의할 점은 이미 SQL 서버의 Northwind 데이터베이스에 TEST 테이블이 있으므로, 대상 컬럼에 나타난 [Northwind].[dbo].[TEST]에서 [TEST]를 [TEST2]로 변경해 이미 Northwind에 존재하는 TEST 테이블과 충돌이 나지 않도록 해야 한다. 이렇게 수행하면 오라클의 TEST 테이블이 SQL 서버로 이관된다.

이기종 분산 데이터베이스의 통합

최 근에 모 회사에서 IBM DB2와 오라클의 두 개의 이기종 데이터베이스에 나눠져 저장되어 있는 데이터를 연동하는 데이터 통합 프로젝트를 완료했다는 기사를 읽은 적이 있다. 이 회사에서는 단일 데이터베이스 기준으로 전체를 재구축할 수 있었지만, 기존의 환경을 유지한 채 마치 하나의 데이터베이스처럼 관리할 수 있도록 하는 것이 비용 면에서 경쟁력이 있다는 판단에서 DB2와 오라클을 그대로 유지한 채 통합 작업을 했다고 한다(“단일 데이터베이스 기준으로 전체를 재구축한다”는 의미는 ‘데이터베이스 이관’을 의미한다). 여기서는 이렇게 기존의 DBMS를 그대로 유지하면서 하나의 DBMS를 사용하는 것처럼, 이기종 분산 데이터베이스에서 데이터베이스를 통합하는 방법에 대해 알아보자.

연결된 서버, 오라클을 SQL 서버처럼 사용하기

오 라클의 몇몇 일부 테이블만 접속해서 조회만 해도 되는데, 그 많은 데이터 타입이며 SQL문 등을 수정해야만 하는 것일까? 당연히 아니다. 이러한 경우를 위해서 SQL 서버에서는 ‘연결된 서버’라는 것을 제공해 오라클을 마치 SQL 서버처럼 접근할 수 있도록 해준다.

연결된 서버 설정
<화면 3>처럼 SQL 서버 엔터프라이즈 매니저를 수행한 뒤, 사용하고자 하는 SQL 서버 인스턴스 아래의 『보안 | 연결된 서버』 폴더를 마우스 오른쪽 버튼으로 클릭해 ‘새 연결된 서버(s)’를 선택한다.

<화면 3> 연결된 서버 설정 화면


< 화면 3>의 연결된 서버 속성 화면의 [일반] 탭에서 기본적으로 설정해줘야 하는 부분은 연결된 서버의 이름을 지어주는 ‘연결된 서버(N):’ 부분과 오라클을 연결할 때 사용할 적절한 OLE DB ‘공급자 이름(P):’를 선택하는 부분, 그리고 연결할 오라클을 지정해 주는 ‘데이터 원본(D):’를 선택하는 부분이다. 여기서는 연결된 서버 이름을 ORACLE9i로 지어 주었고, 공급자 이름은 ‘Microsoft OLE DB Provider for Oracle’, 데이터 원본으로는 앞에서 ODBC 설정시 TNS Service Name으로 사용했던 ‘DEV9i’를 지정해줬다.
그 다음에는 <화면 4>와 같이 [보안] 탭으로 가서 다음과 같이 SQL 서버에 sa 계정으로 접속하게 되면, 오라클에는 어떤 계정과 암호로 접속할 것인지 적어준 뒤 확인을 누르면, SQL 서버 엔터프라이즈 매니저의 『보안 | 연결된 서버』 폴더 아래 Oracle9i라는 이름의 연결된 서버가 생성된다.

<화면 4> 연결된 서버 속성 [보안] 탭 설정 화면


 

오라클 테이블 접근
이제 SQL 서버의 쿼리 분석기에 sa 계정으로 접속해 다음과 같은 SQL문을 수행해 본다.

은폐 게이트웨이, SQL 서버를 오라클처럼 사용하기

은폐 게이트웨이 설치 및 설정
은 폐 게이트웨이(Transparent Gateway)는 오라클 DBMS에 기본으로 설치되는 부분은 아니므로 은폐 게이트웨이가 설치되지 않았다면 Oracle Universal Installer에서 지정해 설치하도록 한다(Oracle Universal Installer에서 ‘Oracle9i Database 9.2.0.1.0 > Oracle Transparent Gateway 9.2.0.1.0’을 설치하면 된다). 설치시 <화면 5>와 같이 SQL 서버 및 데이터베이스를 입력하라고 나오는데, 본 예제에서는 SQL 서버에는 127.0.0.1, 데이터베이스는 Northwind로 설정했다(여기서는 SQL 서버가 은폐 게이트웨이와 같은 서버에 있다고 가정한다). 여기서 지정하는 데이터베이스가 은폐 게이트웨이로 접속했을 때, 사용할 수 있는 데이터베이스가 된다.

<화면 5> 은폐 게이트웨이 설치 화면


이렇게 은폐 게이트웨이의 설치를 마치면 『오라클 설치 폴더 | ora92 | tg4msql | admin』에 은폐 게이트웨이 설정 파일 및 수정에 필요한 샘플 파일이 생성된다.

이 제 오라클에서 SQL 서버를 사용하기 위한 은폐 게이트웨이에 필요한 설정은 모두 끝이 났다. 이제 오라클에 system 계정으로 로그인해 SQL 서버에 연결할 수 있도록 데이터베이스 링크를 만들어 주도록 하자(scott 계정에서 데이터베이스 링크를 만드는 것도 가능하지만 다른 데이터베이스를 접속하도록 인가하는 것은 DBA가 하는 것이 바람직하다).

그리고 scott 계정으로 접속해 데이터베이스 링크를 이용해 SQL 서버의 Northwind 데이터베이스를 오라클처럼 사용해 보도록 하자.

◆ SQL 서버 테이블 접근

점점 커져가는 이기종 DBMS의 통합 요구

지 금까지 SQL 서버와 오라클 사이의 통합과 관련해 어느 한쪽 DBMS로만 모든 데이터 및 객체를 옮기는 데이터베이스 이관 방법과 기존의 DBMS의 존재를 인정하면서 필요한 경우 하나의 DBMS를 사용하는 것과 같은 효과를 가져오는 이기종 분산 데이터베이스에 대해 알아봤다. 얼핏 듣기에는 이기종 분산 데이터베이스가 무조건 좋아 보일 수도 있으나 반드시 그렇지는 않다. 예를 들면, 회사의 정책상 데이터를 하나의 대형 시스템에 통합시키고자 하는 경우나 혹은 이기종 DBMS간의 네트워크 연결 속도가 느려 상당한 부담으로 작용할 때에는 부득이하게 데이터베이스 이관이라는 방대한 작업을 선택해야만 할 것이다.
네트워크 연결 속도가 양호하고 단기간에 통합 작업을 마쳐야 하며 동일한 방화벽 내에 보안이 염려가 없는 경우 이기종 분산 데이터베이스가 적절한 방법이 될 것이다. 물론 이기종 DBMS를 잘 관리해야 한다는 점이 부담으로 작용할 수도 있다.
그 밖에 이 두 가지 방법의 타협점으로써 일부 자주 사용되거나 빠른 접근을 요하는 테이블을 이기종 DBMS에서 정기적으로 복사해 로컬 DBMS에 저장하는 형태인 리플리케이션 방법이 있는데, 정확하게 두 DBMS가 동기화되는 것은 아니며 복제 간격에 따라 시간차가 존재한다. 이 방법은 앞에서 설명한 이기종 분산 데이터베이스 기법과 트리거 등을 응용하면 구현할 수 있다.
최근까지의 통합은 애플리케이션 수준에서 이뤄져 왔다. 애플리케이션 수준에서의 통합은 그 개념의 타당성을 제쳐 두고라도 애플리케이션이 제공하지 못하는 인터페이스에 대해서는 결국 통합이 어렵고 유연성이 떨어지기 때문에 정적이고 그다지 큰 효과를 기대하기는 어렵다. 그러나 DBMS 수준에서의 통합은 더 유연성이 있고 다양한 조합이 가능해 통합으로 인한 이점이 애플리케이션 수준의 통합에 비해 크기 때문에 기존 이기종 DBMS간의 통합시의 문제점 등이 보완된다면 현재보다 더 많은 주목을 받게 될 것으로 생각된다.

제공 : DB포탈사이트 DBguide.net