지난 40여년 동안 끊임없이 진화를 거듭해 온 데이터베이스 기술은 이제 정보시스템의 필수불가결한 핵심요소로 자리 잡았다. 데이터베이스 기술은 한 기업의 단순 OLTP 업무에서부터 OLAP 분석, 데이터 마이닝 업무영역까지 포괄하며, CEO로부터 보험 영업사원까지 사용자가 확대되고 있다. 그리고 기존의 유통, 금융, 생산 분야에서 이제는 우주공학, 생명공학 분야로까지 그 지평을 넓혀가고 있다.

90년대 초반부터 국내에 활발히 도입되기 시작한 데이터베이스는 90년대 중반 이후 정보 시스템의 근간으로 자리잡고 있다. 특히 ERP(Enterprise Resource Planning), CRM(Customer Relationship Management), 데이터 웨어하우스와 같은 기업의 전략적 정보시스템이 국내에도 활발히 도입됐는데, 이들 정보시스템의 핵심에는 데이터베이스가 자리잡고 있다.

이 분야 외에도 웹 로그 분석, 데이터 마이닝, GIS(공간지리 정보시스템), 모바일, 전자상거래 분야 등 거의 모든 정보 시스템들이 데이터베이스를 중심으로 정보를 저장, 검색, 분석하고 있다.

물론 요즈음 정보 시스템의 도입에 있어 적어도 표면적으로 DBMS 자체는 큰 이슈가 아닌 것처럼 보인다. 그러나 어떤 DBMS를 사용하고, 데이터베이스에서 제공하는 기술을 어떻게 효과적으로 사용하느냐가 그 정보 시스템의 성패를 좌우할 만큼 자리를 차지하고 있다. 왜냐하면 데이터베이스 기술이 정보 시스템의 처리 속도, 가용성, 무결성 등에 영향을 미치기 때문이다.

새로운 응용 분야의 출현과 DB의 ‘진화’

현재의 응용 분야 외에도 새로운 정보시스템 응용분야가 출현하더라도 DBMS는 기능 추가/개선 등의 진화를 통해 끊임없이 생명력을 가질 것이다. 예를 들어, XML 데이터, 데이터 마이닝, 생명 공학(Bio-informatics) 등의 새로운 분야에서도 향후 DBMS는 중요한 역할을 할 것이다. 이 시점에서 DBMS가 어떻게 탄생하였고, 어떤 과정을 거쳐서 발전해왔으며, 앞으로 어떤 식으로 진화할 것인가에 대해 살펴보고자 한다.

데이터베이스 기술의 발달은 크게 성능과 기능의 향상으로 구분할 수 있다. 성능 향상은 말 그대로 똑같은 기능에 대해 처리 속도를 높이는 기술을 가리킨다. 예를 들어, 특정 조건에 만족하는 레코드를 빨리 찾기 위한 인덱싱 기능이 성능 향상을 위한 대표적인 기술이라 할 수 있다.

기능 향상은 기존 데이터베이스의 기능만으로 어떤 분야를 지원하기 위해서는 응용프로그램이나 SQL의 작성과 유지가 복잡할 때, DBMS에서 새로운 기능을 추가하고 제공함으로써 생산성을 높일 수 있는 경우를 말한다. 대표적인 예를 들면, 비즈니스 규칙을 DBMS에서 표현할 수 있게 해준 트리거 기능이나 복잡한 분석 기능을 가능하게 해주는 SQL/OLAP 기능을 들 수 있다.

새로운 데이터베이스 응용 분야가 생겨나면, 한두 개의 DBMS에서 선구자적으로 해당 분야를 위한 기능을 도입하게 되고, 그 분야가 주요 응용분야로 자리잡으면서 대다수의 DBMS에서 필요한 기능을 지원하는 과정을 거친다.

이 과정에서 해당 응용분야 지원을 위한 기술의 성능 비교를 목적으로 하는 표준 벤치마크(TPC-C, TPC-H/R, TPC-W 등)를 제정해 DBMS 벤더들 이 성능 개선을 위한 경쟁을 치열하게 펼치게 된다. 이 과정에서 성능 향상을 위한 혁신적인 기능들이 도입되곤 한다.

DBMS의 정의

데이터베이스는 간단히 말해 데이터의 집합이다. 이때 데이터는 크게 데이터베이스에서 모델링하는 실세계의 개체(entity)와 관계(relationship)로 나눌 수 있다. 예를 들어, 대학교의 학사 데이터베이스에서는 학생, 교수, 과목, 강의실 등의 개체와 학생의 과목 등록, 과목별 강의실 사용 등의 관계를 표현한다.

DBMS는 쉽게 이야기해서 대량의 데이터 유지관리를 담당하는 소프트웨어 모듈을 일컫는다. 좀더 구체적으로 질의 처리와 최적화, 디스크, 메모리, 트랜잭션, 백업과 복구 등의 기능을 제공한다. 또한 지원하는 데이터 모델에 따라 네트워크/계층형, 관계형, 객체지향, 객체관계 DBMS 등으로 분류할 수 있다.

일반적으로 데이터 모델은 크게 세 가지 구성요소, 즉 데이터의 저장 구조(structure), 구조를 대상으로 허용하는 연산(operations), 그리고 데이터가 만족해야 하는 무결성 제약조건(constraints)으로 이뤄진다.

예를 들어, 관계형 DBMS는 관계형 데이터 모델을 지원하는 DBMS를 일컫는데, 관계형 데이터 모델은 테이블을 기본 구조로 갖는다. 테이블에 대한 select, project, join, union, minus라는 다섯 가지의 기본 연산을 바탕으로 한 SQL 언어가 연산이며, 무결성 제약조건으로 주키(primary key), 외래 키(foreign key) 제약조건 등을 갖는다.

DBMS의 역사

60～70년대는 DBMS의 개념이 등장해서 시장에서 자리잡기 시작할 무렵이었고, 80년대에는 관계형 DBMS를 중심으로 단순 OLTP(On-Line Transaction Processing) 업무에 널리 사용되기 시작했다.

90년대 초반부터 데이터 웨어하우스와 같은 대용량 데이터 처리와 인터넷 전자상거래와 관련한 하이엔드 OLTP 업무에 DBMS 기술이 적용됐다. 90년대 중반부터는 ERP와 CRM 등 솔루션 레벨의 소프트웨어가 DBMS의 주요 응용분야가 되고 있다. 이제부터 네 가지 주요 DBMS를 등장과 발전과정을 중심으로 알아보자.

네트워크·계층형 DBMS

최초의 DBMS의 개념은 바크만 다이어그램으로 잘 알려진 찰스 바크만(Charles Bachman) 박사가 GE에 근무하면서 개발한 IDS(Integrated Data Store)라 할 수 있다.

바크만 박사는 이 공로로 1973년에 전산학 분야의 노벨상에 해당하는 튜링상을 데이터베이스 분야로는 최초로 받았다. 이는 네트워크 데이터 모델의 시초가 됐고, CODASYL에 의해 표준화 작업이 이뤄졌으며, 1960년에 개발된 많은 DBMS(IBM의 IMS(Information Management System) 등)에 영향을 미쳤다. 물론 IMS는 좀더 단순화시켜 계층 데이터 모델을 기반으로 했고, 아직까지도 많은 기업에서 사용되고 있는 제품이다.

그런데 이들 네트워크 계층 데이터 모델에 기반한 제품들은 그 구조가 복잡하고, 사용자가 데이터를 저장, 검색하기 위해서는 복잡한 그래프 또는 트리 구조의 정보를 항해(navigation)하면서 사용해야 하기 때문에 응용 프로그램의 작성이 복잡하고 고도의 기술을 필요로 했다.

더구나 데이터베이스의 구조가 바뀌게 되는 경우 그에 따라 응용 프로그램도 같이 수정해야 하는 어려움 즉, 응용 프로그램의 데이터 독립성(data independence)의 문제가 있었다.

관계형 DBMS

이와 같은 문제점을 극복하기 위해 1970년도에 IBM 새너제이 연구소에 근무하는 코드(E. F. Codd) 박사가 관계형 데이터 모델을 제안했다. 앞서 설명한 것처럼 테이블이라는 간단한 자료구조와 다섯 가지의 기본 연산만으로 데이터의 표현, 저장, 검색을 모두 수행할 수 있다는 것을 보였다.

이 관계형 데이터 모델의 가장 큰 특징은 원하는 데이터를 검색하기 위해, 절차적인(procedural) 언어 대신에 선언적인(declarative) 언어를 사용하기 때문에 초보 사용자도 원하는 질의를 쉽게 작성할 수 있게 됐다.

즉, 사용자는 자신이 원하는 조건의 데이터를 찾는 방법을 일일이 프로그래밍하지 않고, 자신이 원하는 데이터의 조건만 지정하면 DBMS에서 해당 조건에 맞는 데이터를 알아서 찾아주게 됐다.

따라서 관계형 DBMS의 등장으로 말미암아 응용프로그램 개발의 생산성에 일대 획기적인 개선(데이터베이스를 접근하는 프로그램의 개발과 유지보수 측면)을 가져왔다. 물론 관계형 모델을 발표할 당시에 기존의 네트워크 계층 DBMS 옹호자들이 관계형 데이터 모델에 기반한 제품이 과연 성능을 제대로 낼 수 있을 지에 대한 많은 의구심을 보였으며, 이에 관한 열띤 논쟁이 있었다.

그럼에도 불구하고 관계형 데이터 모델의 단순함에 매력을 느낀 많은 IBM, 버클리 대학 등의 연구자들이 관계형 DBMS 개발에 뛰어들었다. 그 결과로 IBM에서 System/R이라는 최초의 상업용 프로토타입 DBMS를 만들었고, 버클리 대학의 스톤브레이커(Stonebraker) 박사팀에서 잉그레스(Ingres)라는 최초의 연구용 DBMS를 완성했다. 후에 System/R은 IBM SQL/DS, DB2의 원형이 되었고, 잉그레스라는 제품도 상용으로 나왔다.

그리고 이때 System/R의 발표를 보고 현재 오라클 회장인 래리 엘리슨이 최초의 상용 관계형 DBMS인 ‘오라클'을 1978년에 출시했다. System/R 개발에 포함된 중요한 내용 중 하나가 Sequel이라는 언어인데, 이 언어가 현재 데이터베이스의 대표적인 표준 언어인 SQL(Structured Query Language)의 시초이다.

SQL을 발음할 때, ‘S-Q-L’이라 발음하기 보다는 ‘Sequel’로 발음하는 경우가 많은데, 이러한 역사적인 배경이 있는 걸로 추측된다. 이 SQL은 1986년도에 처음으로 표준이 제정돼 SQL-92, SQL-2000 등으로 계속 발전하고 있다. 이와 같이 DBMS 분야에서 혁신적인 변화를 가능하게 한 코드 박사는 이 공로로 1981년에 튜링상을 받았다.

관계형 DBMS와 관련해 빼놓을 수 없는 중요한 업적 중 하나가 동시성 제어(concurrency control)라는 트랜잭션 관리 기능이 System/R과 잉그레스와 같은 DBMS을 개발하면서 본격적으로 발전했다는 점이다.

즉, DBMS는 여러 명의 사용자가 동시에 같은 데이터를 접근해 값을 읽고 변경하기 때문에 이때 발생할 수 있는 무결성 문제를 해결하는 것이 중요한 과제 중 하나였다.

트랜잭션은 한 마디로 논리적인 일의 단위라고 할 수 있는데, 가장 쉽게 생각할 수 있는 것이 은행에서 한 구좌에서 다른 구좌로 돈을 이체하는 작업을 들 수 있다. 이 트랜잭션은 A라는 구좌에서 이체 금액만큼 감하고, B라는 구좌에 해당 금액만큼 더해주어야 한다.

그런데 실제 데이터베이스에서는 이 두 작업이 모두 성공적으로 발생하든지, 아니면 아예 어떤 일도 발생하지 않은 것처럼 결과가 반영돼야 한다. 만일 어떤 사용자가 송금하는 도중에 하드웨어적인 이유로 데이터베이스가 다운됐을 때, A구좌에서 돈이 빠져나가고, B구좌에는 입금되지 않으면 사용자는 돈을 잃게 된다.

이와 같은 트랜잭션 관리문제를 정의하고, 기술적으로 발전시켜 가장 큰 공헌을 한 사람인 Jim Gray는 이 분야에 대한 공헌으로 1999년에 튜링상을 수상했다. 즉, IBM DB2, MS SQL 서버를 포함한 많은 상용 제품에서 채택하고 있는 2단계 잠금(two-phase lock) 프로토콜 및 복구를 위한 WAL(write-ahead-log) 기법 등이 이 당시에 개발됐다.

이외에도 관계형 DBMS와 관련해 이 무렵에 이루어진 주요한 기술 발전으로는 비용기반의 질의 최적화 방법(cost-based query optimization), 정규화(normalization) 이론에 기반한 데이터베이스 설계 기법, 데이터 접근 패턴에 따라 한정된 크기의 버퍼를 활용하는 버퍼 관리 기술, 특정 조건을 만족하는 레코드를 빨리 검색가능 하게 하는 인덱스 기술 등을 들 수 있다.

특히 이중에서 질의 최적화에 관한 연구는 최근까지도 끊임없이 연구가 계속되고 있는 핵심 분야이다. 앞에서 설명한 것처럼, 사용자는 원하는 데이터의 조건만 지정하면(what), 이 질의 최적화가 결과 데이터를 어떻게 가장 효율적으로 구할 것인가(how)를 자동적으로 결정한다.

순수 객체지향과 객체관계형 DBMS

관계형 DBMS가 80년대 들어서 성공적으로 기존의 비즈니스 업무에 도입되면서 CAD, CAM, 인공지능의 지식표현, 멀티미디어, 통신회사의 교환기 등에서도 DBMS 기술을 사용하려는 요구가 서서히 일기 시작했다. 그러나 관계형 DBMS의 장점인 테이블에 기반한 단순 구조나 연산으로는 더 이상 이러한 응용분야들의 요구사항을 효과적으로(특히, 모델링 측면과 성능면에서) 지원할 수 없다는 지적이 나오고, 이에 데이터베이스 연구자들은 데이터 모델링과 기능적인 측면에서 새로운 연구를 수행하게 됐다.

순수 객체지향 DBMS

이러한 노력으로 가장 먼저 탄생하게 된 분야가 순수 객체지향(object oriented) DBMS 분야이다. 이들 순수 객체지향 DBMS 분야는 기존의 객체지향 프로그래밍 언어(980년대 중반의 스몰토크, C++) 환경에 데이터베이스 기능, 즉 데이터의 지속성(persistency)을 추가하는 측면에서 주로 이뤄졌다.

이를 통해 모델링 측면에서는 객체, 클래스, 메쏘드, 상속 등의 객체지향 개념을 지원하고 성능 측면에서는 관계형 DBMS의 조인 대신에 객체 식별자(object identifier)를 통해 빠르게 관련 정보를 접근할 수 있는 장점이 있었다.

초기의 대표적인 연구용 순수 객체지향 DBMS로는 오라이온(Orion), 엑소더스(Exodus), 포스트그레서(PostGres), 앙코어(Encore) 등을 들 수 있고, 이들의 경험을 바탕으로 상업용 객체지향 DBMS들이 80년대 후반, 90년대 초반 무렵에 나오기 시작했다.

대표적인 상업용 객체지향 DBMS로는 O2, 버선트(Versant), 온투스(Ontos), 오브젝트스토어(ObjectStore), 오브젝티비티(Objectivity), 포잇(Poet) 등을 들 수 있다. 이러한 추세에 발맞춰 관계형 데이터베이스 언어의 표준인 SQL에 해당하는, ODMG(Object Database Management Group)라는 단체가 객체지향 DBMS의 표준을 탄생시켰다.

그러나 80년대 객체지향 DBMS가 등장할 당시의 예상과는 달리 객체지향 DBMS는 시장에서 주류기술로 자리잡지 못하고 현재는 통신업종의 교환기 시스템, XML 리파지토리 등의 틈새시장에서 주로 사용되고 있다.

객체관계형 DBMS

90년대 초반 미국 MCC 연구소에서 오라이온이라는 순수 객체지향 DBMS 개발을 주도했던 김원 박사는 이미 시장에서 주류로 자리잡고 있는 관계형 DBMS에 객체 개념을 추가한 객체관계형(object relational) DBMS를 주창했다.

아마도 김원 박사는 순수 객체지향 DBMS로는 시장 점유가 쉽지 않을 것을 예상한 것 같다. 그리고 김원 박사는 직접 UniSQL(관계형과 객체지향 개념을 동시에 지원한다는 의미에서 Uni라는 접두어를 사용)이라는 객체관계형 DBMS 회사를 차렸다(현재 UniSQL은 한국컴퓨터통신이라는 국내 회사에서 인수해서 개발, 판매하고 있다).

비슷한 시기에 버클리 대학의 스톤브레이커 교수도 PostGres(관계형 DBMS인 잉그레스의 다음 버전이라는 의미에서 Post라는 접두어를 사용한 것 같다)라는 연구용 객체지향 DBMS에 대한 경험을 바탕으로 객체관계형 DBMS인 일러스트라(Illustra)를 시장에 내놓게 된다.

80년대, 90년대 초반에 소프트웨어 분야를 휩쓸던 객체지향 패러다임을 지켜보던 기존의 주요 관계형 DBMS 벤더인 IBM, 인포믹스, 오라클 등도 이 무렵부터 자사의 제품에 객체지향 개념을 서서히 도입하기 시작했다.

IBM은 80년대 중반부터 새로운 응용분야에 관계형 DBMS를 적용하기 위한 노력의 일환으로 스타버스트(Starburst)라는 프로젝트를 통해 객체지향 개념을 지원하는 연구의 결실로 DB2 UDB 5.0부터 객체지향 개념을 지원하기 시작했다. 인포믹스의 경우도 90년대 중반 무렵 일러스트라를 흡수합병하면서 자사 제품에 객체지향 개념을 추가했다.

오라클은 오라클 8부터 한정적인 객체지향 기능을 추가하기 시작해 최근 발표한 오라클9i부터는 완전한 의미의 객체지향 DBMS로 자리잡게 됐다. 현재 이 빅3 제품은 SQL3라는 표준에 맞는 객체관계형 DBMS로 완전히 자리잡았다.

그러나 객체관계형 DBMS도 기능면에서 토대를 갖췄지만 아직까지 순수 관계형 DBMS에 비해 객체관계형 DBMS의 장점을 인식하고 활용하는 개발자들의 현실적인 노하우가 아주 미흡하다. 진정한 의미에서 객체관계형 DBMS가 주류 기술로 자리잡기 위해서는 이 부분에 대한 노력이 필요하다.

DBMS 기능과 성능 향상을 위한 다양한 노력

앞서 소개한 것처럼 데이터 모델적인 측면에서 주류 DBMS의 발전과 병행해서 80년대 후반부터 90년대 중반까지 DBMS 기능과 성능면에서 개선을 위한 다양한 시도가 있었다. 독자가 주목할 만한 몇 가지 대표적인 예로서는 능동 데이터베이스(active database), 연역 데이터베이스(deductive database), 공간 데이터베이스(spatial database), 멀티미디어 데이터베이스(multimedia database), 시간 데이터베이스(temporal database), 병렬 데이터베이스(parallel database) 등이 있다.

능동·연역 데이터베이스는 DBMS에 지능을 추가하려는 노력의 일환이었고, 공간·멀티미디어·시간 데이터베이스는 DBMS가 공간·멀티미디어·시간 데이터의 개념을 이해하고 처리할 수 있도록 기능을 확장하려는 시도였다.

마지막으로 병렬 데이터베이스는 하드웨어 가격, 그 중에서도 특히 CPU 가격의 하락으로 데이터베이스 성능 향상을 위한 시도였다. 이들 기능에 대해 간단히 소개하고, 이들 기능이 현재 상용 DBMS에서는 어떻게 지원하고 있는지 알아보자.

DBMS에 지능의 부여

먼저 능동 데이터베이스의 경우를 살펴보자. 기존의 DBMS는 사용자가 지정한 DML문을 수행한다는 점에서 수동적(passive)이었다. 즉, 사용자가 명령을 통해 시키는 일만 수행하는 것이었다. 그러나 사용자가 명령한 작업 이외에 데이터베이스에서 인텔리전트하게 어떤 일을 능동적으로 수행할 필요가 있다.

이와 같은 능동 데이터베이스는 ECA(Event-Condition-Action) 규칙(데이터베이스에 어떤 이벤트가 발생하면, 특정 조건을 검사해 조건이 맞는 경우 어떤 행동(action)을 자동적으로 수행)을 지원한다. 이와 같은 능동 데이터베이스 기능을 상용 DBMS들은 트리거 형태로 지원하고 있다.

지원 기능의 정도 차이는 있지만 IBM, 사이베이스, 오라클, 인포믹스, 마이크로소프트 등 거의 대부분의 상용 DBMS가 트리거 기능을 지원한다. 다음은 오라클 8i를 이용해 Log_salary_increase라는 트리거를 정의한 예이다.

CREATE OR REPLACE TRIGGER Log_salary_increase

AFTER UPDATE ON Emp_tab // Event: Emp_tab에 update 발생

FOR EACH ROW // 각 row 단위로

WHEN (new.Sal > 1000) // Condition: update된 값이 1000이상

BEGIN // Action: Emp_log에 관련 정보 기록

INSERT INTO Emp_log (Emp_id, Log_date, New_salary, Action)

VALUES (:new.Empno, SYSDATE, :new.SAL, ’NEW SAL’);

END;

위와 같이 트리거를 정의하고 난 후, 다음과 같이 Emp_tab 테이블의 sal 값을 수정하면, Emp_log에 수정된 employee 각각에 대해 로그(log) 레코드가 자동 추가된다.

UPDATE Emp_tab SET Sal = Sal + 1000.0

WHERE Deptno = 20;

그런데 현실적으로 많은 실무자들이 이 트리거 기능을 사용하기를 꺼려하고 있다. 필자의 생각으로는 크게 두 가지 이유가 있는 것 같다. 첫째는 막연하게 트리거를 사용하면 성능이 급속도로 저하된다는 인식이다. 두번째는 하나의 이벤트에 영향을 받는 여러 개의 트리거가 동시에 수행될 때 이들의 수행 순서가 일정하지 않기 때문에 데이터베이스의 무결성을 보장하지 못할 것 같은 두려움인 것 같다. 이 능동 데이터베이스 기능의 사용이 좀더 활성화되기 위해서는 국내 DBMS 벤더들에서 자사의 트리거의 기능과 한계에 대해 시장에 알릴 필요가 있다.

다음으로 연역 데이터베이스에 대해 알아보자. 연역(deduce)이란 어떤 사실에서 새로운 사실을 추론하는 과정을 말한다. 예를 들어, A의 조상이 B이고, B의 조상이 C라면, C도 A의 조상이 된다. 이 연역 규칙을 다음과 같이 표현할 수 있다.

Ancestor(A,B) :- Parent(A,B) // A의 부모가 B이면, B는 A의 조상

Ancestor(A,C) :- Parent(A,B) & Ancestor(B,C) // A의 부모가 B & B의 조상이 C -> C는 A의 조상

위와 같은 규칙이 성립할 때, 자식과 부모간의 관계를 표현하는 Parent(Child, Parent)라는 테이블이 존재할 경우는 다음과 같이 특정 사람 p1의 모든 조상을 구하고자 하는 경우를 생각해보자.

Ancestor(p1,?) // 이와 같은 질의를 재귀적 질의(recursive query)라 한다.

DBMS에서 이와 같은 추론 기능을 직접 제공하지 않는 경우, 사용자자 직접 응용프로그램에서 루프를 사용해 더 이상 p1의 새로운 조상이 나타나지 않을 때까지 계속적으로 셀프 조인을 수행해야 한다. 이 때 사용자가 원하는 질의를 표현하기도 힘들고, DBMS 내부에서 이 결과를 계산하는 속도도 엄청나게 느려진다.

이와 같은 문제점을 없애기 위해서 DBMS에서 추론 규칙을 직접 표현하고, 이 추론 규칙을 만족하는 결과를 빨리 찾아낼 수 있도록 효과적으로 계산할 수 있는 데이터베이스를 연역 데이터베이스(보다 일반적인 표현으로는 Datalog)라 한다.

이 연역 데이터베이스 분야는 80년대 중, 후반 무렵에 객체지향 DBMS 분야만큼이나 활발하게 연구됐지만, 많은 사람들이 이 분야가 주류 기술로 자리 잡는 데에 실패했다고 생각한다.

실패 이유는 크게 두 가지가 있다. 첫째 이유는 일반적인 데이터베이스 응용 개발자들이 이 기술을 이해하고 사용하기에 어려웠다는 점이고, 두번째는 이 기능을 절실히 필요로 하는 응용분야가 그 당시에 그리 많지 않았다는 점이다.

그럼에도 불구하고 현재 SQL3 표준에서는 재귀적 질의 기능을 포함하고 있으며, IBM DB2는 이 연역 데이터베이스 기능을 지원하고 있다. 오라클도 connect by라는 키워드를 이용해 부분적으로 이와 같은 기능을 제공하고 있다. 다음은 IBM DB2에서 위의 추론 규칙에 해당하는 재귀적 질의를 표현하는 예이다.

WITH RECURSIVE Ancestor(Descendent, Forefather) AS

(SELECT P1.Child, P1.Parent FROM Parent P1)

UNION

(SELECT P2.Child, A1.Forefather FROM Parent P2, Ancestor A1

WHERE P2.Parent = A1.Descendent)

SELECT * FROM Ancestor;

향후에 이 연역 데이터베이스의 사용이 활성화되기 위해서는 연역기능이 필요한 새로운 응용 분야를 개척하고, 사용자가 쉽게 사용할 수 있는 개발환경이 필요하다.

새로운 데이터 타입을 지원

GIS, CAD/CAM과 같은 응용분야에서는 점(point), 선(line), 도형(polygon)과 같은 2, 3차원의 공간 데이터를 표현하고 이들 객체를 질의(어떤 지점에서 가장 가까운 거리에 있는 몇 개의 건물을 검색하거나 공간 객체간의 조인)할 필요가 있다.

이같이 공간 데이터를 표현·저장·검색을 지원하는 데이터베이스를 공간 데이터베이스라 한다. 특히 이 분야에서는 다차원 공간에서 객체를 빨리 검색하기 위한 다차원 인덱스 기법, 공간 질의 최적화 방법 등에 관한 연구가 여럿 진행됐다.

대표적인 다차원 인덱스 기법으로는 Grid 파일, K-D-B 트리, R 트리 등을 들 수 있으며, 질의 최적화 부분에서는 특정 지점에서 가장 가까운 다른 공간 데이터를 빨리 검색하는 근접이웃(nearest neighbor)에 관한 방법을 들 수 있다. 대부분의 상용 DBMS에서는 객체관계형 DBMS의 확장성 기능을 이용해 공간 데이터베이스 기능을 제공한다. 공간 데이터 모델링을 위해서는 사용자 정의 타입(user defined type)을 이용해 표현하고, 초보 수준의 다차원 인덱스와 질의 최적화를 제공하고 있다.

현재의 상용 객체관계형 DBMS가 효과적으로 GIS 응용분야 등을 지원해 진정한 공간 데이터베이스 플랫폼으로 사용되기 위해서는 개선해야 할 것이 많다.

공간 데이터 외에 많은 DBMS 응용분야에서는 문자, 숫자와 같은 단순한 데이터 타입뿐만 아니라 텍스트, 이미지, 비디오, 오디오 등과 같은 멀티미디어 데이터 처리를 요구한다. 특히 이와 같은 응용분야에서는 이들 데이터 타입을 새로 정의해 데이터베이스에 표현·저장 뿐만 아니라 내용기반 검색을 지원해야 한다.

예를 들어 특정 이미지와 유사한 모든 이미지를 검색하든지, 비행기를 포함하고 있는 모든 그림을 찾는 식의 질의를 처리할 수 있어야 한다. 현재 상용 DBMS들은 공간 데이터베이스 분야와 비슷하게 확장성 기능을 이용해 멀티미디어 데이터 처리를 위한 패키지를 개발·제공하고 있다. 오라클은 카트리지(catridge), IBM은 익스텐더(extender), 인포믹스는 블레이드(blade)라는 이름으로 멀티미디어 데이터를 지원한다.

다음으로 시간 데이터베이스에 대해 알아보자. 일반적인 데이터베이스에서는 어떤 애트리뷰트의 정보를 갱신하는 경우 갱신된 시점을 기준으로 이전의 값은 데이터베이스에서 사라져버리고, 항상 최신의 애트리뷰트 값만을 갖는다.

사람의 신상 정보를 표현하는 테이블인 Person(Name, Address)이라는 테이블이 있다고 가정하자. 어떤 사람의 주소가 변경된 경우 이전 전화번호는 사라져버리게 된다(물론, 이와 같은 주소 변경의 이력을 모델링하기 위해 테이블을 Person(Name, Address, Start-Time)으로 표현해서 응용프로그램에서 주소 변경시 새로운 주소와 변경된 시간을 기록함으로써 해결할 수는 있다).

어떤 응용분야에서는 이와 같이 어떤 애트리뷰트의 값의 변화를 기록해뒀다가 과거 특정 시점의 상태로 질의를 수행할 필요가 있다. 이처럼 DBMS에서 시간을 주요개념으로 지원하는 경우를 시간 데이터베이스라 한다. 현재 SQL3 표준에 시간 개념을 포함한 SQL/Temporal 표준안이 추가될 예정이다.

대용량 데이터 처리를 위한 성능 개선

CPU, 디스크, 메모리를 포함한 하드웨어 가격의 하락에 따라 데이터 적재, 인덱스 생성, 질의 처리 등의 데이터베이스 연산을 병렬화함으로써 성능 향상과 가용성을 추구하는 것이 병렬 데이터베이스이다.

80년대 후반 위스콘신 대학에서 Gamma 프로젝트로부터 시작된 병렬 데이터베이스에 대한 본격적인 연구는 현재 SMP, MPP, NUMA와 같은 다양한 병렬 하드웨어 아키텍쳐에서 동작하는 다양한 종류의 병렬 DBMS를 중심으로 펼쳐지고 있다. 거의 모든 DBMS들이 특정 방식의 병렬 데이터베이스 아키텍쳐를 채택해, 지원하고 있다.

병렬 데이터베이스의 경우 크게 두 가지 이슈, 즉 speed-up과 scale-up이 있다. Speed-up의 경우는 CPU와 디스크 개수의 증가에 비례해 트랜잭션의 처리 속도가 어느 정도 빨라지느냐 하는 것이고, scale-up은 데이터량의 증가에 비례해서 CPU와 디스크의 개수를 늘릴 때, 처리 시간이 일정하게 유지되느냐 하는 것이다.

병렬 데이터베이스 분야의 연구는 대량의 데이터 적재, 스캐닝, 정렬, 조인 연산을 효과적으로 병렬 처리하는 알고리즘에 관한 연구가 주를 이뤘다. 병렬 데이터베이스의 경우 궁극적인 목적은 선형적인(linear) speed-up과 scale-up의 목적을 달성하는 것이다.

그렇지만 현실적으로 선형적인 성능향상을 이루기는 쉽지 않고 얼마만큼 선형에 근접하느냐의 문제이다. 최근에 오라클9i에서는 과거의 OPS(Oracle Parallel Server) 아키텍쳐를 개선한 리얼 애플리케이션 클러스터(Real Application Cluster, RAC)라는 기술을 이용해 speed-up과 scale-up에 많은 향상을 가져왔다.

최근 5년간의 DBMS 기술 발달

1990년대 중반 이후 IT의 주요 투자 영역은 인터넷의 활성화에 따라 B2C를 중심으로 한 전자상거래, 기업에서 보유한 데이터를 활용하기 위한 데이터 웨어하우스/OLAP, 기업 프로세스 혁신을 위해 신규로 도입하게 된 ERP(전사적 자원 관리)가 있다.

특히 요즘은 B2C, ERP를 B2B로 확장하고 데이터 웨어하우스 개념을 e비즈니스로 확장하고, 이들 영역을 결합한 CRM 등의 분야로 IT 범위를 넓혀가고 있는 단계이다. 특히 이중에서도 DBMS 수요를 가장 많이 창출한 분야가 ERP 분야이다. 그런데 재미있는 사실은 SAP라는 독일계 ERP 업체가 엄청나게 빠른 속도로 성장하면서 DBMS 시장에 대한 영향력이 커졌고, 이에 위기감을 느낀 오라클은 자신들의 DBMS 시장을 지키기 위해 오라클 애플리케이션(Oracle Application)이라는 ERP 패키지를 자체 개발했다. 물론 오라클이 ERP 시장에 뛰어든 데는 ERP 시장자체의 매력도 한 몫을 했을 것이다.

그렇지만 ERP 분야가 DBMS 수요 창출에 기여했다는 것 외에는 DBMS 기술 발달에 미친 영향은 그리 높지 않다. 또한 많은 데이터베이스 학자들은 1990년대 중반 이후 객체관계형 DBMS 분야가 큰 연구 줄기라고 예상했지만, 실제로 업계 현장에서는 이 분야가 그리 활발하지 못했던 것 같다.

대신에 최근 5년간의 DBMS의 기술적인 진화에 가장 많은 영향을 미친 부분은 데이터 웨어하우스와 인터넷 분야이다. 실제로 SIGMOD, VLDB, ICDE 등 데이터베이스 관련한 유명 국제 학술대회 논문집 등에서 최근 5년 동안 가장 많은 논문이 게재된 분야 중 하나가 데이터 웨어하우스이고, 이들 논문의 아이디어를 응용한 기술들은 단기간 내에 상용 DBMS에 반영됐다.

필자가 박사 학위를 마칠 무렵인 지난 96~98년에 연구가 한창 실체화 뷰(materialized view) 기술이 있었는데, 학위를 받고 99년도에 오라클에 입사했을 때 이미 오라클8i에 이 기능이 포함된 것을 보고 놀란 적이 있다. 여기서는 데이터 웨어하우스와 인터넷 분야가 DBMS 기술에 미친 영향을 알아보도록 하자.

데이터 웨어하우스 분야

데이터 웨어하우스는 기업 내외부의 데이터를 한 곳에 모아 OLAP(On Line Analytical Processing) 분석을 하는 전체적인 프로세스를 일컫는다. OLAP은 기존의 OLTP(On-Line Transaction Proccesing)와 구분하기 위해 1993년에 E.F. Codd 박사가 처음으로 사용한 용어다. 일반적으로 데이터 웨어하우스 아키텍처는 크게 운영계 시스템으로부터 데이터 추출 업무를 담당하는 ETT 서버, 수집한 데이터를 저장하는 데이터 웨어하우스용 데이터베이스, OLAP 분석을 위한 OLAP 서버, 메타데이터 저장소, 그리고 사용자가 분석·리포팅·마이닝을 수행하는 클라이언트 모듈로 구성된다.

그런데 OLAP 분석업무는 지금까지 관계형 DBMS가 주로 지원했던 OLTP 분야와는 달리 아주 복잡한 분석 질의를 필요로 했다. 기존 관계형 DBMS의 SQL 언어로는 이 질의를 쉽게 표현하기가 힘들었고, 데이터베이스에서 효과적으로 처리하기가 힘들었다. 따라서 90년대 중반부터 현재까지는 주로 OLAP 분석용 서버가 DBMS와는 별도로 존재해 분석용 업무를 담당했다.

시장에서는ROLAP(Relational OLAP), MOLAP(Multidimensional OLAP) 등의 제품이 주로 사용됐다. 즉, 실질적인 OLAP 분석을 주로 이들 OLAP 서버가 담당했고, 관계형 DBMS들은 이들 OLAP 서버에 필요한 데이터를 저장했다가 필요한 경우 제공해주는 보조 역할을 주로 했다.

그런데 1995년 무렵에 데이터 웨어하우스 분야의 선구자인 Ralph Kimball 박사가 OLAP 분야에서 기존 SQL의 한계가 무엇이고, OLAP 분석에 직접 데이터베이스를 사용할 수 있는 방안을 제시하면서부터 관계형 DBMS를 이용해 OLAP 분야를 직접 지원하기 위한 연구가 진행됐다.

가장 주목할 만한 연구로는 기존의 group by 개념을 확장한 cube 연산자와 비교와 리포팅 기능을 SQL에서 효과적으로 표현할 수 있는 SQL/OLAP 표준화를 들 수 있다. 이 두 기능은 모두 SQL3에 포함됐다. 이와 같이 SQL 언어가 OLAP 분석 기능을 포함하게 됨에 따라 OLAP 서버에서 대량의 데이터를 DBMS로부터 전송받아 OLAP 서버에서 복잡한 계산을 수행하는 대신, DBMS에서 처리할 수 있는 분석 질의는 데이터베이스 쪽에서 직접 처리할 수 있다.

따라서 대량의 데이터가 DBMS에서 OLAP 서버쪽으로 이동할 필요도 없고, DBMS가 OLAP 서버들에 비해 대량의 데이터에 대한 확장성 측면에서도 뛰어나기 때문에 OLAP 분야의 데이터 처리의 효율성이 훨씬 높아지게 될 것이다.

이와 같이 OLAP 분석 질의를 SQL에서 직접 표현할 수 있는 기능적인 발전 이외에, 대용량의 데이터 웨어하우스에 대한 복잡한 질의 처리의 성능을 높이기 위한 현실적인 방안들이 이 무렵에 상용 DBMS에 속속 반영되기 시작했다.

실체화 뷰(materialized views: MV), 비트맵/조인 인덱스(bitmap/join index), 파티션닝(partitioning)을 대표적인 예로 들 수 있다. MV는 실체 뷰의 정의에 맞도록 뷰의 내용을 미리 계산해 결과를 저장해두고, 기본 테이블을 대상으로 한 질의가 들어올 때 이미 계산/저장된 뷰를 이용해 해당 질의 결과를 계산함으로써 성능을 높이는 것이 목적이다.

데이터 웨어하우스의 분야의 경우 남녀 성별과 같이 테이블 전체 레코드 수에 비해 카디널리티(cardinality)가 작은 애트리뷰트를 대상으로 한 분석용 질의가 많기 때문에, 기존의 B 트리 인덱스 이외에 비트맵(bitmap)과 같은 새로운 유형의 인덱스가 유용하게 사용될 수 있다.

또한 데이터베이스의 연산 중에서 가장 시간이 많이 걸리는 조인의 결과를 미리 계산해 인덱스를 생성하고 이를 질의처리에 이용함으로써 복잡한 질의에 대한 처리시간을 단축하는 조인 인덱스 기술도 유용하다. 최근에는 이 두 가지 개념을 결합한 비트맵 조인 인덱스도 상용화되고 있다.

즉, 데이터 웨어하우스에서 스타 스키마와 같은 스키마 구조에서 차원 테이블의 애트리뷰트 값을 이용해 미리 조인되는 사실 테이블의 레코드에 대한 비트맵 인덱스를 생성해두는 것이다.

MV, 비트맵/조인 인덱스와 더불어, 데이터 웨어하우스 질의처리 속도 향상을 위해 도입된 또 다른 대표적인 기능이 파티션 개념이다. 이는 매출 테이블과 같은 대량의 사실 테이블을 연/월, 지역 등의 차원으로 물리적으로 서로 다른 파티션으로 생성, 관리함으로써 특정 연/월, 지역에 대한 질의가 발생하는 경우 해당 테이블의 모든 테이블을 검색할 필요 없이 질의 조건에 해당되는 파티션들만 검색해서 결과를 계산할 수 있다.

현재 상용 DBMS에서 제공하는 파티션닝 기술로는 범위(range), 해시(hash), 복합(composite), 리스트(list) 파티션닝 등 다양한 기술이 있고, 지원하는 정도의 차이는 있지만, 대부분의 상용 DBMS에서 파티셔닝 개념을 지원하고 있다.

마지막으로 데이터 웨어하우스 분야와 관련해 주목할 만한 DBMS 기술 발전분야가 바로 ETT 기능이다. 일반적으로 ETT 과정에 필요한 여러 요소 기술은 별도의 ETT 서버를 활용해야만 하는 것으로 인식돼 왔다. 그러나 최근에 ETT 서버의 주요 기능도 관계형 DBMS의 SQL을 이용하고 확장성 기능을 이용해 대체하려 한다. 오라클9i의 ETT 관련 기능을 예로 들 수 있다.

한마디로, 최근 데이터 웨어하우스 관련 DBMS 기술은 DBMS 엔진 속으로 OLAP 서버와 ETT 서버 기능을 흡수하려는 방향으로 발전했다. 그리고 초보적이지만 데이터 마이닝과 메타데이터 저장소 기능도 조금씩 흡수하고 있다. 이와 같은 기술 발전의 결과 향후의 데이터 웨어하우스 아키텍처는 단순한 구조가 될 것이다.

인터넷 분야

자바는 인터넷 시대의 기업 응용 프로그램 개발의 표준 언어라 할 수 있다. 특히 한 군데에서 개발된 응용 프로그램이 자바 VM(Virtual Machine)을 지원하는 어떤 플랫폼에서도 동작할 수 있는(Development Once, Deployment Anywhere) 플랫폼 독립성은 인터넷 컴퓨팅을 가능하게 한 자바의 거장 큰 특징이다.

자바 지원과 관련해 DBMS 측면에서 추가된 기능은 크게 두 가지로 이해할 수 있다. 하나는 자바 VM을 DBMS 내에 통합해 지원하는 일이고, 두 번째는 JDBC와 SQLJ로 대변되는 자바와 데이터베이스의 표준 인터페이스의 정의이다.

자바 VM을 DBMS에서 강력하게 통합해서 지원함으로써 자바에서 데이터베이스 내의 데이터를 많이 다루는(data centric) 로직을 구현해 DBMS에서 직접 수행할 수 있게 됐다. 이 방법은 효율성 측면에서 유리하다.

JDBC(Java Database Connection)는 자바 환경에서 SQL을 이용해 데이터베이스를 접근할 때 사용하는 표준 API로서, 썬마이크로시스템즈의 자회사인 자바소프트(JavaSoft)에서 ODBC(Open Database Connection)를 참조해 개발했다. SQLJ는 JDBC에 기반해 자바 프로그램에서 데이터베이스 접근을 훨씬 용이하도록 제정한 표준이다.

JDBC에 비해 SQLJ를 이용하면, 훨씬 더 간단하게 프로그램을 작성할 수 있고, 컴파일할 때 SQL 문장을 컴파일해 타입 오류를 검사할 수 있는 등 유지보수하기 쉬운 프로그래밍이 가능하다.

현재 JDBC는 여러 상용 DBMS에서 지원하고 있다. SQLJ는 표준이 SQLJ 0, 1, 2로 나눠져 작성 중이다. SQLJ 0은 자바 프로그래밍 내에서 SQL 문장을 직접 이용할 수 있도록 해주며, SQLJ 1은 자바를 사용해 SQL 저장 프로시쥬어(stored procedure)나 사용자 정의 함수(user defined function: UDF)를 정의할 수 있도록 해주며, SQLJ 2는 순수 자바 언어의 클래스를 데이터베이스내의 타입으로 정의할 수 있도록 한다.

향후 5년간 예상되는 DBMS 기술 발달

마지막으로 향후 DBMS가 많이 활용될 것으로 예상되는 분야가 무엇이고, 이들 분야를 효과적으로 지원하기 위해 DBMS에서 추가해야 할 기술이 어떤 것인지에 필자의 개인적인 견해를 담아 알아본다.

데이터 마이닝

데이터 마이닝(data mining)이란 기업에서 생성하는 엄청나게 많은 양의 데이터로부터 아직까지 알려지지 않은 숨은 지식이나 패턴을 찾아내는 기술이다. 자세한 내용은 본지 지난 5월호 데이터 마이닝 특집을 참고하기 바란다. 향후 ERP 이상으로 그 시장 규모가 늘어나게 될 CRM 분야는 고객 데이터를 활용한 활발한 데이터 마이닝 작업이 예상된다.

그런데 지금까지의 데이터 마이닝 기술과 도구는 주로 파일 시스템에 존재하는 데이터를 대상으로 마이닝을 수행하든지 데이터베이스에서 데이터를 추출해서 데이터베이스와는 별도로 작업을 수행했다.

하지만 OLAP 기능을 DBMS에서 흡수해 발전한 것과 비슷하게 데이터베이스 내에서 마이닝 작업을 수행할 수 있도록 기본적인 데이터 마이닝 기술을 DBMS에서 직접 지원하는 방안에 대한 연구와 상용화가 진행될 것이다.

아무리 데이터 마이닝 기술이 알고리즘이나 응용 가능성 측면에서 발달했더라도 미래에 주류기술로 자리잡기 위해서는 데이터베이스 프로그램 개발자들이 쉽게 이해하고 사용할 수 있는 프레임워크를 제공하는 것이 필수적이기 때문이다. MS OLE DB for OLAP이나 Oracle JDMAPI 등 표준 인터페이스를 통해 데이터베이스와 데이터 마이닝의 결합이 가속화될 것이다.

즉, 어떤 표준 인터페이스를 통해 데이터 마이닝 응용 프로그램이 데이터베이스 응용 프로그램 개발 프레임워크를 확장한 환경에서 지원할 수 있을 지, 그리고 이런 인터페이스를 SQL 언어를 확장해 마이닝을 지원할 지 아니면 SQL/OLAP 기능을 충분히 활용해 마이닝 알고리즘을 구현할 지, 저장 프로시져나 사용자 정의 함수(UDF)를 이용해 데이터베이스 기술과 마이닝을 결합할 지 등에 관한 다양한 시도와 기술 발전이 있을 것이다.

생명공학

생명공학(bio-informatics) 분야는 전에 없이 컴퓨터 기술에 의존하고 있으며, 생명 공학자들은 점점 더 많은 데이터를 분석하고, 더 상세한 레벨에서 데이터를 분석, 조작하려고 한다.

게놈 프로젝트에서 다루는 인체의 경우, 인체는 60 ～ 100조의 세포로 구성돼 있고, 한 개의 세포는 두 개의 게놈으로, 다시 각 게놈은 46개의 염색체로, 그리고 각 염색체는 수천 개의 유전자로 구성됐다고 한다.

이렇게 엄청난 데이터를 갖는 인간 유전자에서 각종 희귀 질병 또는 복잡한 질병과 그 원인을 규명하기 위해서는 유전자 배열의 차이를 정보만 하더라도 18 Peta(10**15) 엔트리가 필요하다고 한다. 생명공학과 같이 특수한 개별 응용분야(vertical applications)의 지원을 위해 객체관계형 DBMS의 확장성 기능을 효과적을 활용하는 방안과 이들 분야에 필요한 특수 패키지를 상용 DBMS 벤더에서 제공할 것이다.

XML

XML 데이터를 데이터베이스 기술을 이용해 저장하고, 검색하는 방안에 관한 연구가 90년대 중반 이후 활발하게 연구됐고, 최근에는 IBM, 오라클, 마이크로소프트 등의 상용 DBMS 제품에서도 XML 지원 솔루션들이 나오고 있다.

학계에서 주로 수행한 연구는 주로 XML 데이터가 반구조적(semi-structured)인 점에 중점을 둬 기존의 순수 객체지향 DBMS나 XML을 위한 또 다른 특수한 DBMS를 이용해 XML을 지원하는 방안에 관한 것들이다.

그러나 향후에는 관계형 DBMS가 상대적으로 새로운 유형의 DBMS들에 비해 갖는 여러 장점과 주요 DBMS 벤더가 이 분야에 투자를 많이 할 것이므로 분명히 많은 양의 XML 데이터가 객체관계형 DBMS에 저장되고, SQL을 이용해 검색하고, 검색된 결과를 XML 데이터로 변환해 보여주게 될 것이다.

최근에는 관계형 DBMS를 XML 저장장치로 활용하기 위해, XML 스키마를 관계형 스키마로 변환하고, XML 질의를 SQL 질의로 변환하고, 질의 결과를 XML로 보여주는 방안에 관한 연구가 활발하다.

또한, 기존의 SQL 질의 유형에서 잘 발견되지 않았으나, 최근에 확정된 XQuery 표준에서 많이 사용되는 집합 포함 조인(Set Containment Join)을 관계형 DBMS를 이용해 빨리 처리하는 조인 기법들과 질의 최적화에 관한 연구도 활발히 진행중이다.

기타 분야

위의 세 분야를 위한 지원 기술들 이외에, DBMS에서 흡수 또는 개선하게 될 주요 기능은 다음과 같은 것들을 들 수 있다.

워크플로우/큐잉/TP 모니터 기능

B2B, EAI(Enterprise Application Integration), ERP 등의 영역에서 필요한 워크플로우, 큐잉, TP 모니터 기능은 현재 미들웨어에서 주로 지원하고 있는데, 이들 기능을 DBMS에서 직접 지원하게 될 것이다. 이 기능들은 주로 기업내 부서간 또는 기업간의 여러 DBMS나 ERP 시스템에 걸쳐서 발생하는 트랜잭션의 흐름을 제어하고, 작업 흐름간의 메시지 내용을 바꿔서 전달하고, 무결성을 보장하는 역할을 한다.

확장성

90년대 등장한 객체관계형 DBMS가 본격적으로 멀티미디어, 인터넷, 전자상거래, 데이터 웨어하우스, 생명공학 영역에 활용됨에 따라 사용자 정의 타입을 쉽게 등록하고, 이들을 위한 새로운 타입의 인덱스를 쉽게 정의할 수 있게 됐다. 이들 사용자 정의 타입과 인덱스의 특성을 활용해 질의 최적화기(query optimizer)가 효율적으로 처리할 수 있는 프레임워크에 대한 상용 DBMS의 활발한 지원이 있을 것이다.

관리의 편의성

DBMS의 기능이 복잡해지고 관리하는 데이터의 양이 증대함에 따라 데이터베이스를 관리하는 작업이 이전에 비해 훨씬 복잡해지고 있다. 현재 지원하고 있는 응용분야에 따라 DBMS에서 제공하는 수백 개 이상의 인자(parameter)를 제대로 지정하기가 쉽지 않고, 여러 개의 다중 데이터베이스가 연동하는 상황에서 어떤 데이터베이스가 문제를 야기하고 있는지 또는 ERP, DW과 같은 환경처럼 미리 패키지화된 도구에서 직접 SQL을 생성, 수행하는 환경에서 어떤 SQL문이 성능을 저하시켰는지 등을 파악한 후 조치하는 작업을 지금처럼 수작업으로 진행하는 것은 불가능해 질 것이다.

이를 위해 많은 상용 DBMS가 자동적으로 DBMS를 튜닝하는 기능, 데이터베이스 관리 도구, 서드 파티 벤더에서 주로 제공하는 데이터베이스 성능 모니터링, 튜닝 도구들의 기능이 점점 다양하고 정교하게 발전할 것이다.

데이터베이스 기술 활용에서 경쟁력을

DBMS는 그 지원 영역을 확대해오면서 엄청나게 다양하고 복잡한 기술을 갖춘 소프트웨어로 성장했다. 바야흐로 21세기의 기업 핵심 IT 기술로 거의 모든 정보 시스템을 도입할 때 DBMS를 포함한다.

새로운 응용분야가 나타남에 따라 초창기에는 과연 DBMS가 그 분야를 잘 지원할 수 있을까라는 의심을 받았지만, 데이터베이스 연구자들과 DBMS 벤더의 적극적인 노력으로 그 분야를 효과적으로 지원할 수 있겠 됐다. 핵심 기능을 DBMS에 추가해 다른 대안 기술을 틈새시장으로 한정시키면서, DBMS는 전세계적으로 연간 100억달러 이상의 거대 시장을 형성하고 있다.

전세계 데이터베이스 시장의 60% 이상 비중을 차지하고 있는 미국의 경우, GDP 대비 데이터베이스 산업이 차지하고 있는 비중이 2.5%대에 이르고 있다. 일본의 경우도 GDP 대비 데이터베이스 산업의 비중이 비슷한 실정이다. 한국의 경우는 GDP 대비 데이터베이스 산업이 0.7% 정도에 머무르고 있다.

아마도 90년도 후반부터 국내에 불기 시작했던 데이터 웨어하우스, 전자상거래, ERP, CRM 등의 초기 경험을 바탕으로 기업에 본격적인 e비즈니스가 자리 잡을 향후 몇 년 내에 국내 데이터베이스 산업의 비중도 선진국 수준에 이르리라 본다.

비록 한국이 데이터베이스 원천 기술 개발의 상용화에는 성공하지 못했더라도 데이터베이스 산업과 기술에 정통한 인력의 양성을 서둘러야 할 것이다.

참고 자료

이상원 (마이크로소프트웨어)

2001/08/09

http://www.zdnet.co.kr/develop/backend/db/article.jsp?id=40285