데이타베이스 역사 및 발전 방향

글 ||장성우| 한국오라클 BD본부 | sungwoo.chang@oracle.com

데이타베이스의 발전 과정을 데이타베이스 모델의 변화 과정에서 고찰해 보고, 컴퓨팅 환경이 인터넷으로 변화됨에 따라 데이타베이스의 어떤 특성이 중요시되고 있는가에 대해서 살펴본다. 또, 최근 새롭게 각광 받고 있는 XML 정보를 데이타베이스가 어떻게 관리하는가와 향후 어떤 방향으로 XML 정보 검색을 지원할 지에 대해 전망한다.

정보의 효율적 관리를 지원하는 데이타베이스

정보 시스템에서 데이타베이스가 차지하는 중요성은 새삼 강조할 필요가 없을 것이다. 많은 기업들이 회사의 가장 중요한 정보를 데이타베이스를 통해 관리하고 있다. 데이타베이스는 기업 정보의 정확한 모델링 및 효율적인 관리를 위해 네트워크 모델로부터 출발하여 관계형, 객체지향형, 객체관계 등으로 내부적인 모델 변화를 겪어 왔으며, 현재는 객체관계형 모델이 대세를 이루고 있다. 그리고, 최근에는 인터넷 기반의 컴퓨팅 환경 및 e-business가 부각되면서 데이타베이스 모델에 대한 논쟁은 사라지고 전산시스템의 핵심 요소로서 데이타베이스의 성능 및 가용성, 확장성이 더욱 더 중요한 의미를 가지게 되었다.

이 글에서는 우선 데이타베이스가 초창기부터 현재까지 지나온 발전 과정을 데이타베이스 모델의 변화 관점에서 고찰해 보고, 컴퓨팅 환경이 인터넷으로 변화됨에 따라 데이타베이스가 어떻게 새롭게 변화되고 있는가에 대해서 살펴보기로 한다. 마지막으로, 최근 새롭게 각광 받고 있는 XML 정보를 데이타베이스가 어떻게 관리하기 시작했는지와 향후 어떤 방향으로 XML 정보 검색을 지원해 나갈 것인가에 대해서도 전망한다.

데이타베이스 발전 과정 개요

컴퓨터의 등장 이후 초창기에는 정보의 저장과 검색은 운영체제가 제공하는 파일 시스템을 이용하였다. 즉, 파일에 데이타를 단순히 저장하고 읽기만 했으며, 이러한 데이타를 보다 효율적으로 관리하거나 사용하기 위해서는 프로그래머가 직접 파일 시스템상에서 필요한 애플리케이션을 개발해야 했다. 또한, 사용자의 요구가 바뀔 때마다 애플리케이션은 변경되거나 심지어는 다시 개발되어야 했으며, 그 기능 또한 동시에 많은 사용자가 사용하기에는 극히 제한적이었다.

정보 관리의 중요성이 부각되면서 1960년대 말에 이르러 처음으로 '데이타베이스'란 용어가 '한 조직의 응용 시스템들이 공용(shared)하기 위해 통합(integrated), 저장(stored)한 운영(operational) 데이타의 집합'이란 개념으로 정의되고, 곧 이어 데이타베이스를 관리하기 위한 시스템인 DBMS(Database Management System)가 소개되었다.

초창기의 데이타베이스는 계층적 데이타 모델과 네트워크 데이타 모델에 기반을 두었는데, 이는 기존의 애플리케이션에서 사용하던 데이타 구조를 확장한 것이었다. 이 때, IMS, Total 등의 DBMS들이 개발되어 영업망 정보, 부서 조직 정보 등 계층적 구조를 갖는 비즈니스 영역에서 우수한 성능을 발휘하였다. 하지만, 이러한 DBMS들은 결정적인 단점을 가지고 있었는데, 그것은 바로 데이타들이 포인터로 연결되어 있고 그러한 포인터들을 최대한 효율적으로 이용하도록 애플이케이션들을 개발했기 때문에 데이타베이스를 변경해야 할 때 애플리케이션의 성능에 큰 영향을 미친다는 것이었다. 더구나 그러한 데이타베이스의 일관성을 유지하기란 여간 어려운 것이 아니었다.

이러한 문제점들을 해결할 방안으로서 관계형 데이타 모델이 1970년대 중반에 E.F. Codd에 의해 제안되었다. 관계형 데이타 모델을 개념적으로 SELECT, Project, Join의 세 가지 대표적인 관계 대수(relational algebra) 연산을 사용하였는데, 이러한 연산들을 기반으로 구축된 관계형 데이타베이스는 모델이 단순하여 모델링이 쉬웠으며, 이전 데이타 모델들에서의 단점이었던 특정 애플리케이션에 종속적인 최적화 문제, 데이타 저장 구조 노출 문제, 포인터를 일일이 따라가야 하는 코드 작성 문제 등의 복잡성과 비효율성을 해소할 수 있었다.

그 결과로 데이타베이스 설계를 애플리케이션과 독립적으로 작성 및 유지할 수 있게 되었으며, 또한 SQL(Structured Query Language) 덕분에 간단한 조작만으로도 쉽게 정보를 검색 및 활용할 수 있게 되었다. 따라서, 관계형 모델은 그 후 90년대 초까지 명실상부한 데이타베이스의 대표 모델로서 위상을 유지하게 된다.

그러나, 90년대에 들어서면서 보다 복잡한 데이타, 즉, 사용자 정의 데이타 및 멀티미디어 데이타의 저장 및 관리가 필요하게 되었다. 하지만, 기존의 간단한 관계형 모델은 이러한 복잡한 데이타를 처리할 수 없었는데, 이를 해결할 수 있는 한 방안으로서 1980년대 중반 이후부터 주목 받기 시작한 객체지향 기술을 데이타베이스에 접목하는 연구가 시작되어 프로토타입 시스템들이 발표되기 시작하였다.

1990년대에 들어서 객체지향 기술은 소프트웨어 산업에서 가장 중요한 개념들 중의 하나로 자리잡았으며, 데이타베이스 분야에서도 상용 제품들이 하나 둘씩 발표되기에 이르렀다. 하지만, 객체지향 데이타베이스는 이러한 장점들에도 불구하고 치명적인 단점을 가지고 있었는데, 그것은 바로 객체지향 데이타베이스가 가지는 짧은 연륜으로 인하여 기본적인 데이타베이스 기능(트랜잭션 처리, 동시 처리 가능한 사용자 수, 에러 복구와 백업 기능 등)에서 기존에 시장을 장악하고 있던 관게형 데이타베이스에 훨씬 미치지 못 했다는 점이다. 바로 이 점이 객체지향 데이타베이스가 그 모델링상의 탁월한 장점에도 불구하고 시장에서 점유율을 높이지 못한 채 최근 거의 유명무실해진 중요한 이유이다. 현재 대부분의 객체지향 데이타베이스는 내장 시스템(embedded system)으로 다른 소프트웨어에 내장되어 해당 소프트웨어의 정보 저장소(repository)의 역할을 수행하거나 SML 정보 처리를 위한 특화된 솔루션으로 방향 전환을 시도하고 있다.

앞서 언급한 바와 같이 관계형 데이타베이스가 가지는 단점들(단순한 타입 및 확장성 미비, 복잡한 정보 모델링의 어려움 등)을 해결하여 차세대 데이타베이스로 자리잡을 것으로 생각되었던 객체지향 데이타베이스가 데이타베이스 기본 기능의 미비라는 치명적인 제약 때문에 안정성 있고 쓸 만한 상품이라는 이미지를 심어 주지 못 한 채 시장에서 고전하는 사이에 기존의 관계형 데이타베이스 시스템들이 객체지향 데이타베이스가 제공하는 기능들 중에서 장점들만을 모아 기존의 관계형 모델에 통합함으로써 새로운 개념의 객체 관계형 데이타베이스(또는 확장된 관계형 데이타베이스라고도 함)로 발전하게 되었다. 즉, 기존의 관계형 데이타베이스의 등장으로 데이타 모델에 대한 오랜 논란은 마무리되게 되었다.

최근에는 인터넷 기반의 컴퓨팅 환경이 대두되면서 기존의 데이타베이스를 바라보는 관점이 변화하기 시작하였다. 즉, 인터넷 컴퓨팅 환경에서는 데이타베이스의 모델이 중요한 것이 아니라 인터넷을 통해 접속을 시도하는 엄청난 수의 사용자 관리와 대규모의 트렌잭션을 서비스의 중단 없이 안정적으로 지원할 수 있는 능력이 데이타베이스의 선택을 좌우하는 중요한 요소가 되었다. 따라서, 지금까지 많은 논의의 대상이었던 데이타 모델을 기반으로 한 데이타베이스의 분류는 점점 의미를 잃고 퇴색되기 시작하였다. 반면에 다양한 인터넷 기반 애플리케이션을 구축하고 운용하는 데 있어 어느 데이타베이스가 앞서 언급한 처리 능력을 얼마나 성능 좋게 제공할 수 있느냐의 여부가 데이타베이스를 바라보는 중요한 기준이 되었다. 앞으로 인터넷 컴퓨팅이 비즈니스영역으로 확장되어 e-business가 더욱 더 활성화되고. 또한 기업의 전산 시스템이 광범위하게 연결되면서 전산 시스템 그 자체가 기존의 회사 업무를 다른 회사의 전산 시스템과 협업하는 B2B 환경으로 변모하게 되면, 데이타베이스가 그 회사를 대표하는 중요한 시스템이 될 것이므로 다양한 성능 요구(높은 효율, 가용성, 안정성, 안전성, 관리 용이성 등)가 데이타베이스 판단에 더욱 더 중요한 지표가 될 것이다.

마지막으로, 가장 최근의 핫 이슈는 바로 데이타베이스에서의 XML(extensible Markup Language) 정보의 저장, 검색 및 관리의 지원 방안에 대한 활발한 연구 및 개발이다. XML은 인터넷 상에서의 데이타 교환을 위한 표준 포맷으로서, W3C(World-Wide Web Consortium)에 의해 표준으로 정의되었으며, 정보의 구조를 나타내는 태그를 자유로이 정의할 수 있는 확장성과 내부 구조와 표현의 분리를 통한 다양한 활용 가능성을 제공함으로써 전자상거래 및 EDI 애플리케이션의 내부 정보 표현 및 저장 방안으로서 빠르게 자리를 잡아가고 있다.

이러한 XML 문서의 광범위한 확산은 필연적으로 XML 정보의 효과적인 저장 관리 및 검색의 문제를 야기하게 되었고, 따라서 현재 데이타베이스 학계 및 업계에서는 XML 정보를 데이타베이스에서 어떻게 원활하게 관리할 수 있는가에 대해 활발한 연구와 개발 작업이 진행 중에 있으며 이러한 결과로 다양한 표준들이 개발되고 있다.

이러한 추세에 발맞추어 오라클은 최근 Oracle9i 데이타베이스 안에 XML DB라는 이름으로 데이타베이스 상에서 XML 정보를 효율적으로 저장/관리 및 검색하기 위한 기능을 탑재하였다. XML DB는 XML 정보를 효과적으로 데이타베이스 상에서 관리하는 데에 필요한 많은 기능을 사용자에게 제공함으로써 향후에 XML 기반의 정보 처리 환경에서 커다란 역할을 수행할 것으로 기대되고 있다.

데이타베이스 모델의 발전 역사

앞에서 언급한 대로 불과 몇 년 전까지만 해도 데이타베이스 모델이 데이타베이스 선택의 중요한 지표였다. 또 실제로 데이타베이스 모델의 우위를 놓고 학계와 산업계에서 다양한 논의가 있었다. 이는 관계형 데이타베이스가 워낙 오랜 기간 동안 산업계에서 거의 표준 데이타베이스처럼 인식되었지만, 객체지향 기술의 급속한 파급으로 인해 기존의 관계형뿐만 아니라 객체지향 데이타베이스 관리 시스템의 상용 제품들이 시장에 나왔고, 또, 얼마 되지 않아 최근에는 관계형 데이타베이스가 발전한 객체관계형 데이타베이스 관리 시스템 제품들이 나오면서 모델 측면에서의 데이타베이스 선택 기준에 대한 관심이 고조되었기 때문이다.

그러면, 사용자들의 이해를 돕기 위해 데이타 모델을 기준으로 데이타베이스 발전의 역사 및 각 데이타 모델별 특징을 좀 더 자세히 알아보도록 하자.

현존하는 데이타베이스를 그 지원 데이타 모델에 따라 분류하면, 크게 다음과 같은 세 가지로 나누어 볼 수 있다.

▶관계형 데이타베이스(Relational Database)
▶객체지향형 데이타베이스(Object-oriented Database)
▶객체관계형 데이타베이스(Object-relational Database)

관계형 데이타베이스

관계형 데이타베이스의 성공 요인

관계형 데이타베이스 시스템은 가장 대표적인 데이타베이스 시스템인데, 관계형 데이타베이스가 초반에 거의 표준 모델로서 성공적으로 자리잡게 된 요인을 꼽는다면, 크게 다음과 같은 네 가지 요인을 들 수 있다.

• 먼저 모델 자체가 간단하다는 점이다. 관계형 데이타베이스는 한 마디로 문자, 숫자, 날짜 타입의 정보를 이차원 구조의 테이블 형태로 저장한다. 이것은 우리가 많이 사용하는 스프레드시트를 연상하면 된다. 즉, 관계형 모델은 주변에서 가장 쉽게 접할 수 있는 정보들을 아주 쉬운 형태의 구조에 저장할 수 있도록 지원한다. 이것은 데이타베이스 설계자나 사용자 모두에게 정보 구조를 쉽게 설계 및 이해하고 활용할 수 있는 장점을 제공한다.
  
  
• 다음으로는 관계형 모델 자체가 수학적인 이론의 바탕 위에서 성립되었다는 점이다. 기본적으로 '관계형'이라고 하는 용어 자체가 수학의 집합론(set theory)의 '관계형 이론(relational theory)'으로부터 유래되었다. 이 관계형 이론은 이차원의 행렬(matrix) 구조의 정보에 가해지는 다양한 연산들의 특성을 수학적으로 정의하고 있다. 이와 같이 기반 모델이 수학적인 바탕을 가진다는 것은 개발자들에게는 엄청난 도움이 된다. 즉, 개발할 시스템의 성능을 수학적으로 미리 예측 및 검증할 수 있으며, 여러 연산을 수학적으로 최적화할 수 있기 때문이다. 따라서, 현재 관계형 데이타베이스가 제공하는 많은 장점들, 예를 들면, 질의 기능, 질의 최적화 기능, 인덱싱 기능 등은 모두 이러한 수학적 기반을 통해 제공되는 것이다.
  
  
• 특히 관계형 모델이 이전의 데이타베이스 초기 모델들(네트워크 모델과 계층적 모델)을 물리치고 산업계의 데이타베이스 표준으로 자리잡게 된 데에 결정적으로 도움을 준 것이 바로 질의어(query language)의 존재이다. 이전 모델들은 사용자가 특정 정보를 검색하기 위해서는 해당 정보를 찾아가는 방법까지도 명시해야만 했다. 즉, 이는 정보 검색을 위해 사용자가 거의 검색을 위한 프로그램을 작성해야만 했음을 의미한다. 하지만, 질의어는 일정한 패턴을 가지는 질의문을 통해 내가 원하는 조건들만을 나열하면 해당 정보를 검색해 준다. 이것은 '내부에서 정보를 찾아오는 방법은 나는 알지 못하겠으니 아무튼 내가 원하는 조건을 만족하는 것들을 가져오라'는 식이다. 즉, 철저히 고객을 중시하는 사상이 들어간 언어인 것이다. 그러니, 간단한 질의어만 익히면 누구나 정보 검색을 할 수 있으므로 데이타베이스의 대중화에 이보다 중요한 요소는 없었던 것이다.
  
  
• 마지막으로 관계형 데이타베이스는 시대의 흐름에 따라서 그 시대가 요구하던 기술들을 지속적으로 지원하여 왔다. 대표적인 것으로 클라이언트/서버 구조. 대규모 병렬 처리 기능 등을 들 수 있다. 이러한 기능들은 실제의 대규모 정보를 다루어야만 하는 산업계에서 꼭 필요했던 기능들로 관계형 모델의 기반 위에서 이와 같은 기능을 지원할 수 있게 됨으로써 명실공히 관계형 데이타베이스는 전산업계로 퍼지게 되었던 것이다.

관계형 데이타베이스의 표준화

일반적으로 관계형 데이타베이스의 표준화는 그 기반이 되는 질의어인 SQL의 표준화로 설명할 수 있는데, 이는 SQL 자체가 관계형 데이타베이스에 대해서 사용 가능한 여러 기능들을 모두 포함하기 때문이다. SQL에 대한 표준화 작업은 1982년에 미국 표준화 기구인 ANSI(American National Standard Institute)의 데이타베이스 위원회(X3H2)에 의해 시작되어 1986년에 최초의 표준안이 작성되었다. 이 표준안은 이듬해에 국제 표준화 기구인 ISO(International Standards Organization)에 의해 국제 표준으로 채택되었다.

그 후 SQL의 기능이 확장될 필요성이 높아져 1989년에 기존의 표준안에 보다 많은 기능이 포함된 표준이 만들어졌는데, 이것을 흔히 SQL1 또는 SQL/89라 부른다. 그 후에 더욱 더 많은 기능들(예를 들면, ESQL에 관한 개념 포함, SQL에 대한 X/OPEN 표준안, IBM의 SAA 표준안, 그리고 미국 연방 표준인 FIPS 표준안을 반영하고, 서로 다른 시스템들간의 상호운용성 등을 포함)을 포함하는 표준을 1992년 말에 제정하였는데, 이것을 흔히 SQL2 또는 SQL/92라 부르며 오늘날 관계형 데이타베이스의 표준으로 사용하고 있다.
SQL2 이후로도 표준화 작업이 진행되었는데, 관계형 기술을 기반으로 객체지향 기술을 포함할 수 있는 표준화 작업이 1999년 완료되었으며, 이 결과 SQL-1999라는 객체관계형 데이타베이스 표준안이 제정되었다.

관계형 데이타베이스로서의 오라클 데이타베이스

오라클은 1977년에 설립되었으며 1978년에 첫 상용 관계형 데이타베이스 제품인 Oracle Version1을 내놓았다. 이후로 계속적으로 향상된 버전의 제품을 발표하였으며, 특히, 1992년에는 Oracle Version7과 병렬 처리를 지원하는 OPS(Oracle Parallel Server)를 발표하여 대규모 업무 처리를 지원하는 고성능 서버로서 자리매김을 하게 되었다.

객체지향 데이타베이스

멀티미디어 정보 시대의 도래 및 관계형 데이타베이스의 문제점

앞서 언급한 대로 관계형 데이타베이스는 문자, 숫자 등의 기본 타입을 갖는 비즈니스 분야에서 많은 고객을 확보하게 되었다. 또, 1980년에 들어서서 많은 기술적 발전을 이루어 데이타베이스 분야에 일대 변혁을 일으키며 대용량의 데이타 관리에 뛰어난 성능과 우수한 안정성을 보였다.

그러나, 90년대에 들어서서 하드웨어와 소프트웨어 기술의 발달로 기존의 문자, 숫자뿐만이 아닌 보다 복잡한 데이타, 즉, 이미지, 오디오, 비디오, 그리고, 이러한 정보들이 대규모로 생성되면서 사용자들은 이러한 멀티미디어 정보에 대한 데이타베이스 기능의 지원을 요구했다. 이러한 이유로 관계형 데이타베이스에 대한 다음과 같은 문제점들이 나타나기 시작하였다.

• 관계형 데이타베이스에서의 데이타 타입은 몇몇 타입으로 제한되어 있으며, 새로운 타입의 생성 및 기존 타임의 확장이 불가능하다.
  
  
• 모든 정보 구조는 테이블의 형태만으로 한정되므로, 고정된 포맷이 없고 여러 정보들이 연관되어진 비정형 복합 정보를 표현하기가 몹시 어렵다.
  
  
• SQL에서는 값에 의해 데이타의 관계가 표현되기 때문에 설령 복합 객체를 표현한다고 하더라도 상호 관련된 객체들을 찾아내어 처리하기가 어렵다.
  
  
• Impedence Mismatch 문제(프로그래밍 언어에서 지원하는 정보 타입과 데이타베이스가 지원하는 정보 타입이 서로 상이해서 데이타베이스에 검색된 정보를 프로그램상에서 처리하기 위해서 정보 타입을 임의로 변환시켜 주어야만 하는 문제)로 인해서 응용 개발 및 유지가 어렵다.
  
  

객체지향 데이타베이스의 탄생

이와 같은 문제점들을 해결할 수 있는 한 방안으로서 1980년대 중반 이후부터 주목 받기 시작한 객체지향 기술을 데이타베이스에 접목하는 연구가 시작되어 프로토타입 시스템들이 발표되기 시작하였다. 1990년대에 들어서는 객체지향 기술은 소프트웨어 산업에 가장 중요한 개념들 중의 하나로 자리잡았으며, 데이타베이스 분야에 대해서도 상용 제품들이 하나 둘씩 발표되기에 이르렀다. 이 당시의 유명한 제품으로 ObejctStore.02.Objectivity.Verant 등을 들 수 있다.

객체지향 데이타베이스의 특징 및 장점

객체지향 데이타베이스는 객체 모델에 기반하여 정보의 저장 및 검색을 지원하여 주는 정보 관리 시스템이라고 볼 수 있다. 객체지향 데이타베이스는 C++나 smalltalk 같은 객체지향 언어를 사용하여 시스템을 개발하던 객체 사용자들이 데이타베이스에 대한 요구사항을 가지게 되면서 만들어지게 되었다. 따라서, 객체지향 데이타베이스는 객체지향 언어와 객체지향 데이타베이스가 단일 스키마를 공유하는 장점을 가지게 된다. 객체지향 데이타베이스가 가지는 특징들로는 다음과 같은 것들이 있다.

• 사용자가 임의의 형태로 정의한 사용자 정의 타입을 지원하며, 이 타입 정보의 저장 및 검색 가능. 또, 사용자 정의 타입들 사이의 상속성(inheritance) 명세 가능.
  
• 비정형 복합 정보의 모델링 가능.
  
• 객체들 사이의 참조(reference)구조를 이용한 네비게이션 기반 정보 접근 가능.
  
• 프로그래밍 언어와 데이타베이스 언어 사이의 긴밀한 연결 관계로 인한 프로그램 내의 정보 구조와 데이타베이스 스키마 구조가 거의 유사.

이러한 특징들은 객체지향적으로 시스템을 분석/설계하고 또 프로그램을 작성하는 사람들에게는 다음과 같은 장점들을 제공하게 된다.

• 먼저, 객체지향 분석/ 설계자들의 입장이다. 관계형 데이타베이스를 사용하면 그들이 설계한 클래스 다이어그램을 테이블 기반의 관계형 스키마로 매핑시켜줘야 한다. 반면에, 객체지향 데이타베이스를 사용하면 그들이 설계한 방법론을 데이타베이스 상에서 그대로 지원할 수 있다.
  
• 다음으로, 객체지향 언어를 사용하는 개발자들의 입장에서 데이타베이스를 이용할 때 다음과 같은 두 가지 측면이 있을 수 있다. 먼저 관계형 데이타베이스를 사용하는 경우이다. 이 경우 개발자들은 자신들이 정의한 객체들을 평평한 형태의 관계형 테이블상의 레코드로 변환시켜야 한다. 물론 객체가 가지는 메소드는 별도로 표현해야 한다. 또, 데이타베이스에서 정보를 가져올 때에도 거꾸로 변환 작업을 수행해야 한다. 이러한 일들은 개발자들의 작업 능률과 시스템의 전체적인 성능을 떨어뜨리게 되는 단점이 있다. 하지만, 객체지향 데이타베이스를 사용하면 이러한 변환 작업을 수행할 필요 없이 객체지향 언어상에서 정의하였던 모든 클래스 정보를 데이타베이스 상에 그대로 스키마로서 표현할 수 있게 되어, 프로그래밍 언어와 데이타베이스가 단일의 스키마를 공유하게 되는 장점을 가지게 된다. 따라서, 객체들을 있는 그대로 저장하거나 검색할 수 있게 된다.
  

객체지향 데이타베이스의 단점

하지만, 객체지향 데이타베이스는 이러한 장점들에도 불구하고 치명적인 단점을 가지고 있는데, 그것은 바로 객체지향 데이타베이스가 가지는 짧은 연륜으로 인하여 기본적인 데이타베이스 기능(트랜잭션 처리, 동시 처리 가능한 사용자 수, 에러 복구와 백업 기능 등)에서 기존에 시장을 장악하고 있던 관계형 데이타베이스에 훨씬 미치지 못 한다는 점이다. 바로 이 점이 객체지향 데이타베이스가 그 모델링상의 탁월한 장점에도 불구하고, 시장에서 점유율을 높이지 못하고 있는 중요한 이유이다.

객체지향 데이타베이스는 그 이론이 80년대 중반에 나왔으며, 초기 프로토타입들이 80년대 말에, 그리고, 실제 상용화된 제품들이 모습을 나타내기 시작한 것은 90년대 초이다. 즉, 객체지향 데이타베이스는 실제 제품으로서 세상에 모습을 드러낸 것이 불과 몇 년 되지 않는다. 더 중요한 것은 대부분의 객체지향 데이타베이스는 객체지향 개념을 연구하던 학자 및 연구원들이 연구 수행시 만들었던 프로토타입들을 벤처 기업 형태로 만들어서 제품화한 것들이 대부분이라는 사실이다. 즉, 대부분의 회사들이 직원 규모가 수백 명에 불과한 중소 기업이라는 것이다.

이러한 사람들이 처음에 모든 노력을 기울인 부분은 객체지향 모델을 지원하는 시스템을 만드는 것이었다. 하지만, 데이타베이스 상품으로서 발전하기 위해서 필요한 기본적인 기능들을 코딩하기에는 개발자 수나 연륜면에서 기존의 수십 년의 역사와 대규모 개발 인력을 가진 관계형 데이타베이스 회사들이 개발해서 내놓은 관계형 데이타베이스를 따라가기에는 애초부터 한계가 너무도 자명했던 것이다. 물론, 이러한 기본 기능들 역시 시간이 지나면서 많이 개선되기는 했지만 규모의 경제 측면에서 볼 때 단시간 내에 기존의 관계형 데이타베이스 시스템 정도의 기능을 내기에는 무리였다고 보는 것이 올바른 판단일 것이다.
따라서, 현재로서는 객체지향 데이타베이스는 빠른 성능과 대규모 사용자를 지원하는 환경보다는 복잡한 정보 모델링 측면의 지원이 더 우선되는 연구소나 학교 등의 분야에 우선적으로 적용되고 있는 상황이다.

객체지향 데이타베이스의 표준화 동향

관계형 데이타베이스로부터 객체지향 데이타베이스로의 이전이 문제가 되는 주요 이유들 중의 하나가 바로 표준의 부족이다. 현재 관계형 데이타베이스 환경은 국제 표준화 기구에 의해 표준이 작성되어 있는 반면에, 객체지향 데이타베이스 환경은 아직까지 표준이 존재하지 않는다. 다만 객체지향 데이타베이스 벤더들에 의한 표준안만이 존재할 뿐이다. 더욱 중요한 것은 단순히 모델링 및 프로그래밍 분야뿐만 아니라 모델링 도구 및 백업 유틸리티 등 데이타베이스 관리에 필요한 다양한 분야에 대한 명확한 방안이 제시되어 있지 않다. 관계형 데이타베이스는 성숙의 단계를 이미 오래 전에 넘어 10년 이상의 산업계 경험을 쌓았지만, 객체지향 데이타베이스는 아직도 유아기에 머물러 있다는 것이 가장 큰 문제가 되는 것이다.

객체지향 데이타베이스 업계에서 거의 표준으로 받아들여지고 있는 것으로 ODMG(Object Database Management Group)의 ODMG-93 표준안을 들 수 있다. ODMG는 객체지향 데이타베이스 상용 제품 업체들의 컨소시엄으로서, 1993년에 처음 만들어진 ODMG-93 표준안은 객체지향 데이타베이스들 사이에 공통적으로 사용될 수 있는 객체 모델과 이 위에서 수행될 수 있는 데이타 정의 및 검색, 처리 언어, 그리고, 기존의 객체지향 언어인 C++및 Smalltalk과의 연결 관계를 기술하고 있다. 이를 통해 이 표준안을 만족하는 데이타베이스들 사이에서 애플리케이션이 호환성을 가지도록 지원하며, 더 나아가 이들 데이타베이스들이 상호 연동될 수 있도록 하는 것을 목표로 하고 있다. 차후에 발표될 2.0 버전은 보다 개선된 객체 모델과 새로운 객체지향 언어로 각광을 받고 있는 Java와의 연결 관계 기술을 포함하게 된다.

객체관계형 데이타베이스

객체관계형 데이타베이스의 도래

앞서 언급한 것처럼 관계형 데이타베이스가 가지는 단점들을 해결하여 차세대 데이타베이스로 자리잡을 것으로 생각되었던 객체지향 데이타베이스가 데이타베이스 기본 기능의 미비라는 치명적인 제약 때문에 실제 시장에서 그다지 큰 호응을 받지 못했다. 이러한 반응은 오히려 기존의 관계형 데이타베이스 시스템들이 객체지향 데이타베이스가 제공하는 기증들 중에서 장점들만을 모아 기존의 관계형 모델에 통합한 새로운 개념의 객체관계형 데이타베이스가 탄생하는 계기를 제공하게 되었다. 즉, 기존의 관계형 데이타베이스로서의 안정된 성능에 기반하면서 동시에 객체지향 모델의 모델링 파워를 가미하는 특징을 제공할 수 잇게 된 것이다. 이러한 객체관계형 데이타베이스의 등장으로 객체지향 데이타베이스의 입지는 더욱 더 줄어들게 되었다.

이러한 객체관계형 데이타베이스는 또 하나의 다른 관점에서도 중요한 의미를 가지는데, 그것이 바로 또 하나의 잠재적 어려움인 관계형 데이타베이스로부터 객체지향 데이타베이스로의 데이타 이전 문제를 비교적 현실성 있게 풀 수 있는 대안이라는 점이다. 이미 회사의 중요 정보가 관계형 데이타베이스에 저장되어 있는 상황에서 객체 기능들을 충분히 사용하기를 원한다면 기본적으로 관계형 데이타베이스에 저장된 정보의 전체 데이타 모델을 다시 작성해야 하고 정보 전체를 객체지향 데이타베이스로 이전해야만 할 것이다. 아니면, 간단히 관계형 데이타베이스로부터 객체 데이타베이스로 매핑시킬 수도 있겠지만, 이 경우 단순히 매핑된 데이타로는 객체지향 데이타베이스의 객체 기능들을 충분히 발휘할 수 없다는 문제가 생기게 된다.

따라서, 대부분의 경우 관계형 데이타를 객체지향 데이타베이스로 옮기기보다는 기존의 구조는 그대로 둔 채 객체지향 응용이나 관계형 데이타베이스에 저장될 수 없는 정보들을 위해 객체 지원 기능을 사용하게 되리라는 것이다. 또, 실제 관계형 데이타베이스를 사용한 컴퓨팅 환경 역시 객체 기능으로 급속히 이동하기보다는 현재 사용하고 있는 관계형 데이타베이스를 그대로 유지하면서 객체 기능을 점차적으로 받아들이는 접근 방법을 취하게 되리라는 것은 자명하다.

이러한 경우, 순수 객체지향 데이타베이스보다는 객체관계형 데이타베이스가 가장 적합한 선택이 될 것이다. 왜냐하면, 객체관계형 데이타베이스에서는 기존의 관계형 데이타베이스상에 구축된 정보들을 그대로 사용할 수 있고, 동시에 객체 기반의 정보 저장 및 검색, 애플리케이션의 작성이 가능하기 때문이다.

객체관계형 데이타베이스의 특징

기술적으로 객체관계형 데이타베이스는 관계형 데이타베이스를 기반으로 하여 중요한 객체지향 데이타베이스의 기술적인 특징들을 대부분 수용하고 있다. 확장된 주요 특징들로는 다음과 같은 것들을 들 수 있다.

• 사용자 정의 타입 지원: 사용자가 정의한 임의의 타입의 정보를 데이타베이스 내에 저장 및 검색할 수 있다.
  
• 참조 타입 지원: 객체들로 이루어진 객체 테이블의 경우 하나의 객체 레코드가 다른 객체 레코드를 참조할 수 있게 된다. 이를 통해 두 개의 관련된 객체를 살펴보기 위해 관계형 데이타베이스에서는 반드시 조인을 수행해야만 했지만 참조 구조를 이용하여 네비게이션에 기반한 접근이 가능하게 된다.
  
  
• 중첩된 테이블: 중첩된 테이블은 테이블 안의 하나의 열이 또 다른 테이블로 구성되는 구조를 말한다. 이를 통해 테이블을 구성하는 레코드상의 하나의 항목이 또 다른 레코드들의 집합(테이블)으로 구성되는 복합 구조를 모델링하는 것이 가능하다.
  
  
• 대단위 객체 지원: 이미지, 오디오 및 비디오 등의 대규모 비정형 데이타들을 저장할 수 있도록 대단위 객체(LOB: Large Object) 타입이 기본 타입으로 지원된다.
  
  
• 테이블 사이의 상속 관계: 객체들 사이의 상속성을 표현하기 위해 객체들로 구성된 테이블들 사이에 상속성 관계를 지정하는 것이 가능하다.
  

▼표 1 데이타베이스 모델의 약식 비교

객체 관계형 데이타베이스와 객체지향 데이타베이스의 객체에 대한 관점의 차이

하지만 객체관계형 데이타베이스가 객체지향 데이타베이스가 제공하는 객체지향 모델을 모두 있는 그대로 수용한 것은 아니다. 크게 다음과 같은 두가지의 차이점이 있다.

• 하나는 데이타의 저장 및 접근 방법에 대한 관점의 차이이다. 객체지향 데이타베이스는 모든 정보를 객체 형태로만 저장하며 따라서 모든 객체 정보가 유일한 객체 식별자(OID: Object Identifier)를 사용할 것을 주장한다. 반면 객체관계형 데이타베이스에서는 정보가 테이블 형태로도 또 객체 형태로도 저장될 수 있으므로, 기존의 관계형 데이타베이스에서처럼 주된 키(PK: Primary Key)를 이용한 값 기반의 데이타 접근을 원칙으로 하고, 그것이 없을 때에만 유일한 객체 식별자를 사용할 것을 주장한다.
  
  
• 또 다른 하나는 프로그래밍 언어와 데이타베이스 언어에 대한 관점의 차이이다. 대부분의 객체지향 데이타베이스는 앞에서 설명했듯이 C++, Smalltalk, 그리고 오늘날의 Java와 같은 객체지향 프로그래밍 언어에 지속성(persistence)을 도입하는 방식의 프로그래밍 방식을 지원한다. 이는 데이타베이스 언어를 따로 두지 않고 기존의 프로그래밍 언어에 지속성을 부여하여 이를 그대로 데이타베이스 언어로 사용한다는 입장이다. 또한 객체지향 데이타베이스에서는 객체를 접근하거나 다른 객체로 옮겨갈 때 객체지향 프로그래밍 언어에서 제공하는 포인터 또는 다른 참조 기법을 이용하기 때문에 객체지향 데이타베이스에서는 객체간의 포함 관계를 갖는 복합 객체를 효율적으로 저장할 수 있다. 이와는 달리 객체관계형 데이타베이스는 값에 기반한 데이타 접근을 취하고 있기 때문에 원하는 데이타를 접근할 때 별도의 데이타베이스 언어로서 기존의 SQL과 같은 질의어를 사용하는 것을 주된 데이타 접근 방법으로 사용하고 있다. 하지만, 기존의 질의어에는 복합 객체의 검색을 지원하는 기능이 없기 때문에, 이러한 복합 객체를 검색할 수 있도록 하기 위해서 SQL을 확장함으로써 값에 기반한 접근과 참조 정보 기반의 접근 모두를 지원한다.
  

객체관계형 데이타베이스의 표준화 작업

객체관계형 데이타베이스의 표준화는 기본적으로 관계형 데이타베이스의 표준 모델인 SQL92 데이타 모델에 기반하고 있으며, 이 바탕 위에 객체지향 개념을 지원하기 위해 확장된 것이다. 따라서, 객체관계형 모델은 현재 관계형 데이타베이스를 사용하고 있는 사용자가 객체지향 개념을 필요로 할 때에 가장 적합한 모델이라고 볼 수 있다.

1999년에 이를 위한 표준화 작업이 완료되어 SQL-1999라는 이름으로 발표되었다. SQL-1999는 메소드를 포함한 사용자의 추상(abstract) 데이타 타입 정의, 객체 식별자, 하위타입(subtype), 상속성, 다형성, 그리고 외부 언어와의 통합 기능을 지원하며, SQL-1999를 이용한 테이블 정의 기능을 지원한다. 또한 SQL-1999는 SQL92보다는 더욱 더 계산적으로 완전하게 지속적 객체들을 생성 및 관리하고 질의할 수 있도록 제어 구조 및 매개 변수를 갖는 타입 등을 지원한다. 이러한 SQL-1999에 추가된 기능들은 SQL92와는 상향적으로 호환 관계를 갖도록 정의되었다.

객체관계형 데이타베이스로서의 오라클 데이타베이스

오라클은 1997년 객체관계형 데이타베이스인 Oracle8을 발표하였으며, 1999년에는 인터넷 컴퓨팅을 지원하기 위한 Oracle8i, 그리고, 최근에는 e-business를 지원하기 위한 고성능 데이타베이스로서 Oracle9i를 발표하였다.

인터넷 컴퓨팅의 도래 및 데이타베이스 발전

컴퓨팅 환경은 초기 메인프레임 환경은 거대한 컴퓨터에 다수의 터미널들이 네트워크를 통해 연결되어 있는 형태로, 데이타와 애플리케이션이 모두 메인프레임 컴퓨터에 위치하고 있으며, 사용자는 단지 터미널을 통해 정보를 검색할 수 있을 뿐이었다. 메인프레임은 컴퓨터와 터미널간에 전송되는 내용이 텍스트뿐이기 때문에 WAN에서도 매우 잘 동작하여 광역 접근, 즉, 전 세계 어느 위치에 있더라도 사용자가 네트워크만 연결되어 있으면 터미널로 메인프레임 컴퓨터에 액세스할 수 있다는 장점을 가질 수 있었다. 반면에, 메인프레임 환경은 프로그래밍이 매우 힘들고 하드웨어 또한 매우 고가일 뿐 아니라, 터미널의 사용자 환경, 즉, UI(User Interface)도 매우 단조로운 단점을 가지고 있다. 이러한 문제점들로 인해서 사용자들은 메인프레임 환경을 꺼리게 되었고 가격이 저렴하고 UI가 미려한 소위 클라이언트/서버 컴퓨팅이라는 새로운 환경으로 이동하게 되었다.

클라이언트/서버 환경에서는 애플리케이션과 데이타를 서로 분리하여 데이타만 서버에서 관리하고 애플리케이션은 서버로부터 분리하여 클라이언트(주로 PC)에 위치시켰다. 따라서 데스크탑 컴퓨터에서 뛰어난 그래픽 사용자 환경(GUI: Graphic User Interface)을 구축할 수 있게 되었다. 하지만, PC에 설치되는 프로그램들이 점점 많아지게 되고 또한 서버의 수도 많아지게 되면서 전체적인 시스템의 구조 및 이의 관리가 복잡해지게 되어 관리 비용의 증가라는 문제점을 야기하게 되었다. 이뿐만 아니라 PC 애플리케이션과 서버 데이타 간에 오고 가야 하는 정보가 너무 많아지게 되면서 네트워크에 많은 부담을 주게 되어, 대규모의 WAN에는 적합하지 못하고 비교적 빠른 속도를 내는 단거리의 LAN에서만 잘 동작하는 점 등의 문제점을 나타내게 되었다. 즉, 클라이언트/서버 컴퓨팅 환경은 메인프레임의 최대 장점 중의 하나였던 광역 접근을 지원하지 못하게 되는 중요한 문제점을 가지게 되었다.

이러한 문제점에 대한 대안이 바로 웹과 브라우저의 도래로 탄생하게 된 인터넷 컴퓨팅이다. 인터넷 환경은 메인프레임 환경에서처럼 데스크탑의 애플리케이션들을 다시 서버로 위치시킨다. 따라서, 데스크탑 컴퓨터 사이를 오고 가는 것은 단지 데스크탑 화면에 보여질 내용과 사용자가 입력하는 내용뿐이기 때문에 광범위한 WAN에서도 다시 잘 동작하게 되었다. 즉, 클라이언트는 단지 웹 브라우저만 있으면 전세계 어디에서나 서버에 접속하여 애플리케이션을 실행하고 정보를 검색할 수 있게 되었다. 따라서, 이제는 데스크탑 PC의 관리에 드는 비용을 걱정할 필요가 없게 되었고, 중앙에 있는 통합 서버의 모든 데이타는 일괄적으로 백업되고 모든 애플리케이션은 전문적으로 업그레이드되게 되었다. 이렇듯 인터넷 컴퓨팅 환경은 매우 낮은 총소유비용(TCO: Total Cost of Ownership), 뛰어난 UI, 저렴한 하드웨어가 함께 어우러지는 환경으로서 메인프레임 컴퓨팅의 장점과 클라이언트/서버 컴퓨팅의 장점들만을 혼합하여 제공하게 되었다. 이제 컴퓨팅 환경으로 급속하게 변하게 되었다.

인터넷 컴퓨터로의 변화와 대응 방안

앞에서 데이타베이스와는 상관 없는 컴퓨팅 환경의 발전에 대해 길게 설명한 것은 다가온 인터넷 환경에 대한 이해와 이러한 환경 하에서의 데이타베이스에 대한 사용자들의 요구 조건이 바뀌게 된 배경을 이해하기 위해서이다.

인터넷 환경에서의 컴퓨팅은 이전의 환경과는 다른 특징을 보인다. 인터넷 환경에서는 여러 형태의 수많은 불특정 다수가 접근한다. 손쉬운 브라우저 기반의 접근으로 인해 네트워킹은 더 이상 어렵고 소수만이 사용하는 기술일 수 없다. 남녀노소를 불문하고 인터넷의 간단한 사용법은 모두를 인터넷의 사용자로 만들어 버린다. 그러므로 세계 곳곳에서 몰려드는 작업량을 효과적으로 처리할 수 있어야 한다. 인터넷 환경에서 사용자는 인내심이 없기 때문에 아무리 자료가 많더라도 빠른 응답을 줄 수 있어야 한다. 또한, 전세계가 하나로 엮어져 있기 때문에 낮과 밤의 개념, 즉, 사용자들이 사용할 수 있어야 한다. 그리고 시스템은 다양한 언어로 작성된 정보를 효율적으로 통합된 형태로 관리할 수 있어야 한다. 또한, 작업 대상이 어디에 있건 브라우저 하나만으로 개발 및 관리를 할 수 있도록, 웹이라는 것으로 모든 것을 처리할 수 있는 환경이 필요하다.
이러한 고찰을 기반으로 했을 때 인터넷 환경에서 요구되는 데이타베이스 요구 조건은 데이타 모델이 아닌 것이다. 어떤 모델이든지 앞서 언급한 인터넷 기반 컴퓨팅의 독특한 요구 조건을 해결할 수 있으면 반드시 해결되어야 할 과제들은 기존의 데이타베이스 모델에서 데이타베이스의 성능으로 바뀌었다. 이러한 과제들을 정리하면 다음과 같다.

• 확장성에 대한 대책 필요: 인터넷 컴퓨팅 환경에서는 폭주하는 자료 처리 요구 및 급증하는 정보 저장 요구에 대해 효과적으로 대응할 수 있는 대책이 반드시 마련되어 있어야 한다. 인터넷 환경의 특징은 세계 어느 곳에서나 하나의 시스템에 언제라도 동시에 접속을 시도하고 자료 처리를 할 수 있다는 점이다. 즉, 시스템이 널리 알려지게 되면서 인지도가 높아져 엄청나게 많은 사람들이 접속을 시도하고 순식간에 넘게 된다. 이러한 상황에 순발력 있게 대처하기 위해서 데이타베이스 시스템은 사용자 요구 수준에 따라 쉽게 확장할 수 있는 기능을 가져야 한다.
  
  
• 고성능의 트랜잭션 처리 필요: 인터넷 환경의 또 하나의 특징은 처리 요구가 일순간에 몰릴 수 있고, 또 그러한 패턴을 예측하기 힘들다는 점이다. 따라서, 시스템은 순간적으로 발생하는 과도한 처리 요구에 대응할 수 있는 고성능의 트랜잭션 처리 능력을 갖추고 있어야 한다.
  
• 시스템 가용성 및 안전에 대한 방안 필요: 인터넷 환경의 시스템은 언제나 동작하고 있어야 한다. 즉, 시스템은 어떤 여건에서도 다운되지 않고 매일 24시간 1년 365일 항상 서비스를 해야 하는 요구 조건을 안게 되는데, 이를 시스템 가용성이라고 한다. 또한, 항상 존재하는 파괴적인 의도를 가진 시스템 접근에 대해 이를 차단할 수 있는 안전 지원 기능을 갖추고 있어야 한다.
  
  
• 웹 응용 시스템과의 유연한 연동 필요: 현재 인터넷 환경에서 주도적인 시스템 개발 언어는 Java 언어이다. 만약 Java로 개발된 프로그램을 수정 없이 데이타베이스 서버에서도 수행시킬 수 있다면 개발자는 대부분의 일을 Java를 이용하여 처리할 수 있게 되고 다른 여러 가지 언어를 익혀야 하는 부담에서 해방되어 이에 따른 시간적 여유를 애플리케이션 개발 자체에 투자할 수 있게 될 것이다. 또한 다양한 웹 애플리케이션을 수행시켜 주는 애플리케이현 서버와도 쉽게 연동될 수 있어야 한다.
  
  
• 쉬운 관리 지원: 인터넷 환경에서 데이타베이스는 엄청나게 많은 데이타를 관리하게 되어 이의 관리(백업, 복구, 시스템 최적화 등)가 엄청난 업무 부담으로 작용하게 된다. 따라서, 보다 쉬운 관리를 지원하기 위한 다양한 기능들이 필요하다.
  

인터넷 컴퓨팅을 지원하는 데이타베이스로서의 Oracle8i

Oracle8i는 인터넷 컴퓨팅을 위한 데이타베이스로서, 오늘날 가장 대중적인 웹 사이트에서 발견되는 온갖 형태의 데이타를 관리할 고급 툴을 제공할 뿐만 아니라 이러한 대규모 사이트와 기타 미션크리티컬 애플리케이션을 지원하는 데 필요한 성능과 확장성도 제공한다. Oracle8i는 크게 인터넷 관련 신기능, 강화된 전통적인 데이타베이스 기능, 편리한 관리 기능 등으로 나누어 볼 수 있다.

인터넷관련 신기능으로는 최초로 데이타베이스 내에 Java VM(Virtual Machine)을 통합시켜 어떠한 종류의 Java 애플리케이션도 데이타베이스 내에서 실행할 수 있도록 지원한다는 점이다. 그 결과 Java 프로그램들을 Java 코드를 재컴파일하거나 수정하지 않고도 클라이언트에서는 서버에서든 또는 그 중간 계층에서든 가장 훌륭히 수행되는 자리에 배치할 수 있게 되었다. 또한, Oracle8i는 브라우저만으로도 손쉽게 애플리케이션을 개발, 배치 및 관리할 수 있게 해주는 툴 세트인 Oracle WebDB도 지원하고 있다. 다음으로, Oracle8i는 단순한 관계형 데이타 저장소에 그치지 않고 인터넷 파일 시스템(iFS: Internet File System)과 interMedia를 도입함으로써 다양한 인터넷 컨텐트 관리를 쉽게 수행할 수 있도록 지원한다. iFS는 파일 시스템과 데이타베이스를 통합한 형태로서 하나의 단일 서버에서 텍스트나 웹 페이지와 같은 모든 데이타의 이점을 파일 시스템의 간편한 기능과 결합하여 제공한다. 요컨대, 단일 서버를 이용하기 때문에 비용 절감과 더불어 데이타 통합을 실현할 수 있다. 이와 함께, Oracle8i는 이미지, 텍스트, 오디오/비디오 및 공간 데이타 등과 같은 멀티미디어 데이타의 관리 및 액세스를 가능케 하는 interMedia도 새롭게 도입하고 있다.

Oracle8i는 Java VM이나 iFS와 같은 인터넷 관련 신기능 이외에, 기존의 데이타베이스 기능의 강화 부분에서는 전통적인 대용량 온라인 트랜잭션 처리(OLTP) 및 질의 집약적(query-intensive) 데이타 웨어하우스 애플리케이션을 위한 중요한 새로운 특징과 기능을 비롯, 백업, 복구, 보안, 가용성 및 관리 측면에서도 새로이 강화된 기능을 갖추고 있다. Oracle8i는 미션크리티컬 애플리케이션에서 필요한 확장성, 가용성 그리고 뛰어난 성능을 제공한다. 데이타 웨어하우스의 경우, Oracle8i는 이제 일상적으로 질의되는 집합체(aggregates)를 저장하기 위해 정교한 요약 관리(summary management) 기능을 제공하므로 질의 처리를 현격히 감소시킨다. OLTP 애플리케이션의 경우, Oracle8i는 인덱스 재구축과 같은 일상적인 작업이 진행되는 동안 또는 재난 상황에서 스탠바이(standby) 데이타베이스를 제공함으로써 데이타베이스 가용성을 증대시키는 많은 기능들을 선보인다.

편리한 관리 기능에서 Oracle8i는 오라클 데이타베이스와 애플리케이션 환경을 관리하기 위한 종합 관리 프레임워크인 Oracle Enterprise Manager를 갖추고 있다. Oracle Enterprise Manager에는 사용이 간편한 중앙 콘솔, 다양한 관리 툴 세트, 그리고 문제 발생시 문제 탐지 및 해결을 위한 확장 기능이 포함되어 있다. 여기에는 또한 일상적인 백업 작업의 일정 수립 등, 매일 매일의 데이타베이스 및 애플리케이션 작업을 수행하기 위한 몇몇 관리 애플리케이션도 포함되어 있다.

E-business의 대두와 대응 방안

이제 모든 기업에 있어 e-business는 선택이 아닌 필수사항이 되었다. E-business 환경에서 한 회사의 전산 시스템은 이제 그 회사를 대표하게 된다. 즉, 한 회사의 전산 시스템이 회사 안에서 발생되는 모든 업무 처리를 지원하게 되고, 그 결과 발생한 엄청난 양의 비즈니스 정보를 관리하게 된다. 또한, 이러한 정보를 이용하여 다른 회사의 시스템과 직접 연결되어 상호 작용하기도 하고 고객들과 직접 연결되기도 한다.

예를 들어, 회사의 구매 활동의 경우 구매와 관련된 모든 업무가 인터넷 기반으로 전이되고 있다. 이제 내부 직원은 물품 구매 요청을 서류 대신에 사내 인터넷 시스템을 통해 곧 바로 수행하게 되며, 구매 담당 직원은 서류를 수합, 정리, 분석할 필요 없이 인터넷 시스템을 통해 접수된 구매 요청을 시스템상에서 일괄 처리한 후, 이러한 정보를 이용하여 공급자와 인터넷 기반으로 협상하여 물품 구매를 곧 바로 결정할 수 있게 된다. 또한, 물품의 공급 및 입고, 지불 현황 등 모든 구매 관련 정보를 인터넷상에서 처리할 수 있다. 이 밖에도 생상 관리 및 공급망 관리 활동, 고객 상대 영업 활동 및 마케팅 활동 등도 e-business의 중요한 요소가 되고 있다.

이러한 환경에서 회사 전산 시스템에서 처리되는 모든 정보를 관리하는 데이타베이스는 앞서 언급한 같은 요구 조건들에 대해 이전에 비해 더욱 더 가혹한 시스템 요구 조건을 가지게 된다. 즉, 가용성, 확장성, 빠른 트랜잭션 처리 능력, 보안, 편리한 관리 지원 등의 요구 조건에 대해, 요구되는 수준도 더욱 더 높아졌다. Oracle9i는 e-business 환경을 위한 일련의 특정 기능과 제품군을 제공함으로써 Oracle8i에 이어 인터넷 기반의 e-business를 지원하는 최적의 데이타베이스를 목표로 하고 있다.

E-business를 지원하기 위한 데이타베이스 Oracle9i

Oracle9i는 모든 e-business 애플리케이션에 필수적인 인터넷 데이타베이스 가용성 측면에서 오라클의 주도권을 획기적으로 강화한 제품이다. 여기서 말하는 고가용성은 달리 표현하면 '다운타임의 최소화'라고 할 수 있는데, 다운타임은 크게 예기치 못한 다운타임(unplanned downtime)과 일상적인 유지보수를 위한 다운타임(planned downtime)으로 나누어 볼 수 있다.

Unplanned Downtime을 위해서는 Data Guard를 통해 스탠바이 데이타베이스와의 상호 작용을 자동화함으로써 완전한 데이타 보호와 재안 복구 기능을 지원한다. 또한, Planned Downtime을 줄이기 위해 Oracle9i에서 향상된 기능으로서 온라인상에서 많은 관리 작업(테이블 및 인덱스 재구성 및 분석)을 수행할 수 있도록 지원한다.

Oracle9i는 관리의 효율성을 대폭 향상시켰는데 자동적인 메모리 관리(SQL 메모리 자동 할당 및 동적인 SGA 관리) 및 데이타베이스 구조 관리(자동작인 데이타베이스 파일 관리 및 세그먼트/인덱스 관리, 자동적인 Undo 관리) 기능을 통해 관리자의 시스템 관리 부담을 대폭 줄여주었다.

Oracle9i는 e-business가 시간당 수백만 트랜잭션을 실행함으로써 수천만 명의 사용자로 확장할 수 있도록 지원한다. 이는 Oracle9i Real Application Clusters 상에서 가능하게 되었으며, Oracle9i를 통해 공인된 최고 속도의 TPC-C 벤치마크 성능을 보유하고 있다.

Oracle9i는 개발의 효율성 또한 향상시켰는데, SQL 확장, PL/SQL 확장, XML 지원, Java 지원 개선 등을 통해 다양하고 편리한 개발 환경을 제공하게 되었다.

새로운 도전: XML 지원

최근 XML이 많은 각광을 받고 있다. XML(extensible Markup Language)은 인터넷상에서의 데이타 교환을 위한 표준 포맷으로서, W3C(World-Wide Web Consortium)에 의해 표준으로 정의되었다.

XML의 가장 큰 특징은 전자 문서의 3요소, 즉, 구조(structure), 내용(content), 표현(presentation)을 완전히 분리한 형태를 가지고 있다는 점이다. 이로 인해 정보의 구조를 나타내는 태그를 자유로이 정의할 수 있는 확장성과 내부 구조와 표현의 분리를 통한 다양한 활용 가능성을 제공함으로써 XML은 데이타 표현과 문서 교환에 있어 한계를 드러내고 있는 기존 전자 문서의 문제(예를 들면 HTML의 문서 구조 기술 미비성 등)를 해결할 수 있을 것으로 기대되면서, 전자상거래 및 EDI 애플리케이션의 내부 정보 표현 및 저장 방안으로서 빠르게 자리를 잡아가고 있다. 특히, XML은 애플리케이션 통합, 전자상거래, 인터넷 퍼블리싱, 데이타 웨어하우징 등에 효율적으로 응용될 수 있어 파급효과를 기대하며 많은 기업체들이 솔루션 개발에 참여하고 있다. 따라서, 향후 인터넷 기반의 모든 애플리케이션에서 정보 교환의 표준으로 XML은 그 중요성이 증대될 전망이다.

이러한 XML 문서의 광범위한 확산은 XML 정보의 효과적인 정보 및 검색의 문제를 야기하게 되고 앞서 인터넷 시대에 멀티미디어 정보의 확산이 객체지향 데이타베이스 및 객체관계형 데이타베이스로의 발전에 영향을 미쳤던 것처럼, XML 표준의 빠른 정착 및 XML 정보의 확산은 데이타베이스의 발전의 영향 요소로 작용하게 되었다. 따라서, 현재 데이타베이스 학계 및 업계에서는 XML 정보의 원활한 처리를 위해 데이타베이스가 갖추어야 할 요소가 무엇인가를 두고 많은 토론과 개발 작업이 진행 중에 있으며 이러한 결과로 다양한 표준들이 개발되고 있다. 이 중에서 가장 관심을 끄는 것이 XML 정보의 저장 방식과 질의 방식이다.

대부분의 상용 데이타베이스에서는 XML 정보를 요소별로 나누어 관계형 데이타베이스에 중첩된 테이블 구조로 저장하는 것이고, 두 번째는 SML정보를 LOB로 인식하여 XML정보 전체를 LOB 타입에 저장하는 것이다.

• XML 정보의 분할과 저장: 이 방식은 XML 정보의 처리를 단위요소(element)별로 저장하기 때문에 직관적이고, 기존의 SQL 문장을 사용하여 쉽게 요소별로 검색할 수 있는 장점을 가지는 반면에, XML 구조에 데이타베이스 모델이 종속되게 되어 시시각각 동적으로 변할 수 있는 다양한 XML 구조에 데이타베이스가 쉽게 대응할 수 없는 단점을 가지게 된다.
  
  
• XML 정보 전체를 LOB로 저장: 이 방식은 XML 정보 전체를 하나의 묶음으로 저장하기 때문에 XML 구조와 상관없이 데이타베이스에 저장할 수 있는 반면, XML 내부 요소 정보 검색을 위해 SQL을 사용할 수 없는 별도의 질의 방안을 강구해야 하는 문제가 발생하세 된다.
  
  

현재 XML 정보에 대한 질의 방식은 표준으로 결정된 것이 없다. 현재 W3C 컨소시엄을 통해 Xquery라는 XML 질의 언어가 표준으로의 제정을 목표로 활발히 개발되고 있다. 하지만, 아직 XML 표준 질의 언어로의 정착을 위해서는 많은 논의와 작업이 더욱 필요한 상태이다. 또 하나의 다른 문제는 Xquery가 특성상 기존의 대표적인 데이타베이스 질의 언어인 SQL과 구문과 문맥에 있어 많은 이질적인 요소를 가지고 있는데, 이러한 차이점이 현실적인 상용 시스템에서 어떻게 메워질 수 있을 것인가가 중요한 의미를 가지게 될 것이다. 현재로서는 구문적인 차이점을 완전히 일치시키기는 힘들 것으로 보이며, 예전에 그래왔던 것처럼(SQL1999가 SQL의 기능을 일부 수용했던 것처럼) SQL 질의 언어를 기반으로 하여 Xquery의 일부 기능을 채용하는 형태로 데이타베이스 상에서의 XML 질의어가 발전해 나갈 것으로 판단된다.

오라클에서는 현재 XML을 기반으로 한 개발 작업을 용이하도록 지원하기 위해 Oracle8i부터 다양한 솔루션들, 즉, XML 파서, XLST 처리기, XML Search Engine(intermedia), XDK(XML Developer's Kit), XSU(XML SQL Utility), iFS(Internet File System), Jdeveloper, WebDB 등의 제품을 통해 XML 처리 애플리케이션 개발을 단순화할 수 있도록 지원하고 있다. 또한, Oracle9i Release 1에서는 XML 타입을 기본 타입으로 지원하여 사용자가 XML 정보를 데이타베이스에 원활히 처리할 수 있도록 지원하고 있다. 최근에 발표된 Oracle9i Release 2에는 XML DB라는 이름으로 데이타베이스 상에서 대량의 XML 정보를 처리하기 위한 기능이 포함되어 있다.

XML DB는 위에서 언급한 2가지 형태의 XML 처리를 모두 지원하고 있다. 또한, XML DB는 DTD(Document Type Definition) 뿐만 아니라 XML Schema에 기반한 정보 저장 및 검색도 지원하고 있다. 이를 통해 사용자는 보다 강력한 타입 검사 기능을 XML 정보에 대해서도 적용할 수 있게 되어, XML 정보의 유효성을 더욱 확실하게 검사할 수 있게 되었다. 또한, Xpath에 기반한 정보 검색을 통해 보다 다양한 형태의 XML 정보 검색도 수행할 수 있게 되었다. XML 정보의 처리는 계속 그 중요도가 증가할 것으로 예상되므로, 향후에도 XML정보의 원활한 처리를 위한 다양한 기증들이 데이타베이스에 추가될 것이다.

E-business 시대의 데이타베이스

데이타베이스는 기업의 중요한 정보를 저장 및 관리하는 핵심 시스템으로서 중요한 역할을 수행해 왔으며 앞으로도 더욱 중요한 역할을 수행하게 될 것이다. 시간의 흐름 속에서 변화를 겪었던 데이타베이스 모델은 이제 관계형 모델과 객체형 모델의 장점을 혼합한 객체관계형 모델로 발전되어 객체관계형 데이타베이스가 시장의 주류를 이루게 외었다. 이제 인터넷 컴퓨팅 환경의 발전 및 e-Business 시대의 도래에 따라 데이타베이스 모델 자체에 대한 논의는 사라지고 대용량 고성능의 안정되고 안전하며 고가용성과 확장성을 가지는 데이타베이스에 대한 요구가 점점 거세어지고 있다.

향후 데이타베이스는 이러한 요구 조건을 만족시키기 위한 방향으로 끊임없이 발전해 나갈 것이다. 아울러 새로이 각광 받고 있는 XML 정보의 관리를 효율적으로 수행하기 위한 부분 역시 지속적으로 추가, 확장되어 갈 것이다.