객체지향 데이터베이스 관리 시스템; OODBMS

90년대 들어 인터넷의 성장과 발전으로 세상은 급속하게 변하고 있고, 복잡한 데이터 분석 작업에 대한 필요성이 증대되고 있다. 또한 일반 사용자도 이미지, 오디오, 그리고 비디오 등과 같은 멀티미디어 데이터 지원을 요구하고 있다. 이러한 이유로 관계형 DB에 다음과 같은 문제점이 나타나기 시작했다.

▶ SQL에서의 데이터 타입은 제한적이며 확장이 불가능하다.

▶ 테이블을 이용해 복합 객체(complex object)를 표현하기가 어렵다.

▶ SQL에서는 값에 의해 데이터 관계가 표현되기 때문에 설령 복합 객체를 표현한다고 하더라도 관련 객체를 찾기 어렵다.

▶ Impedence Mismatch 문제로 인해서 응용 프로그램 개발과 유지가 어렵다.

이와 같은 문제점을 해결할 수 있는 한 가지 방안으로 80년대 중반 이후부터 당시 주목받기 시작한 객체지향 기술을 DB에 접목하는 연구가 시작되었다. 90년대에 들어서 객체지향 기술은 소프트웨어 산업에 가장 중요한 개념 중의 하나로 자리잡았으며, DB 분야에서도 자연스럽게 객체지향 기술을 받아들여지게 되었다.

[ 기본 개념]

객체지향 모델은 데이터와 관련 코드가 결합한 구조의 객체에 기반하는 것으로써 객체에 대한 정의는 클래스에 포함되며, 각 객체는 해당 클래스의 인스턴스(instance)로 생성된다. 이와 같은 객체지향 모델에 기반을 둔 OODBMS는 기본적으로 다음과 같은 특징을 제공한다.

① 캡슐화(encapsulation) : 데이터와 코드를 하나로 포장해 객체를 생성하는데, 생성된 객체의 구현 정보는 다른 부분으로부터 숨겨진다. 이 때 정보의 특성에 따라 외부에 보여지게 할 수도 있다.

② 상속(inheritance) : 기존의 클래스에 정의된 코드와 데이터를 이용해 새로운 클래스를 생성하도록 하는 기법으로써 어떤 클래스(기본 클래스)로부터 파생된 클래스는 그 기본 클래스의 데이터와 코드를 사용할 수 있다. 일반적으로 여러 클래스의 공통된 특성을 기본 클래스에서 정의하고, 기본 클래스로부터 파생된 다른 클래스가 그 정보를 공유하도록 한다. 이 때 기본 클래스와 파생 클래스로 구성된 상속 관계를 트리 모양으로 나타낸 것을 클래스 계층도라고 한다.

③ 다형성(polymorphism) : 같은 이름의 함수를 서로 다른 클래스에 정의하는 성질로써, 다른 타입의 객체에 대한 동일한 성격의 작업을 수행할 때 똑같은 이름의 함수를 사용하는 일관성을 제공한다. 또한 새로운 타입을 추가할 때도 일관된 이름의 함수를 제공하도록 함으로써 응용 프로그램의 유지보수가 훨씬 쉬워진다. 한편 각 객체는 해당 클래스 타입 뿐만 아니라 그 클래스의 기본 클래스 타입으로도 사용이 가능하기 때문에 한 객체가 여러 타입을 갖는다는 또다른 의미에서의 다형성을 제공한다.

④ 객체 식별자 : 시스템의 모든 객체는 내부적으로 독립적인 유일한 값을 갖는다. 다시 말해 똑같은 값을 갖는 객체라고 하더라도 각 객체를 나타내는 식별자는 서로 다르다는 의미이다. 이때 DB에서의 객체 식별자와 메모리에서의 객체 식별자를 동일하게 유지하기 때문에 프로그래머가 일일이 이들 사이의 관계를 유지할 필요가 없다.

⑤ 객체 간의 참조 : 객체 사이의 관계를 포인터를 이용한 참조로 표현한다. 따라서 값을 이용해 관계를 표현하는 RDB와 달리 OODBMS에서는 올바른 관계 유지를 위해 필요한 여러 가지 고려사항이 없어진다.

[ 지속적 프로그래밍 방식을 지향하는 개발 방향 ]

OODBMS 개발 방향은 한마디로 OOPL에서의 지속성 부여로 특징지울 수 있다. C++나 Smalltalk 같은 OOPL은 이미 앞에서 언급한 객체의 특징을 모두 제공하지만, 이 모든 작업은 메모리 영역에서만 이루어지낟. 따라서 OOPL을 이용해 DB 영역까지 지원하기 위해서는 메모리 뿐만 아니라 DB에서의 객체까지 같은 방식으로 처리할 수 있도록 OOPL의 객체지향 모델을 확장해야 한다.

이와 같은 프로그래밍 언어에 지속성을 부여하는 것을 지속적 프로그래밍 방식이라 한다. 이러한 방식에 의해 프로그래밍 언어와 DB는 같은 모델을 갖게 되고, 결국 임시 데이터와 지속적 데이터를 같은 방법으로 처리할 수 있게된다. 다시 말해 OOPL의 지속성에 기반을 둔 OODBMS에서는 RDBMS와 달리 응용 프로그램과 DB가 밀접하게 연결되어 있는 상태로서 다음과 같은 지속성 유지 규칙을 따르게 된다.

규칙 1 : DB 데이터 모델과 프로그래밍 언어 타입 시스템은 동일하다.

이 규칙에 의해 RDBMS에서의 'Impedence Mismatch'로인한 데이터 맵핑이나 개발자가 서로 다른 데이터 모델을 고려해야 하는 문제가 사라진다.

규칙 2 : 데이터는 지속적인 데이터와 임시 데이터로 나뉘어진다.

응용 프로그램은 지속적인 데이터와 임시 데이터를 함께 처리할 수 있는데, 프로그램 수행이 성공적으로 끝난 후에 지속적인 데이터에 발생한 변화는 DB에 반영이 되는 반면 임시 데이터는 그대로 사라진다는 차이가 있다. 이 때 데이터에 지속성을 부여하는 지속성 모델에는 기본적으로 두 가지 타입이 있다. 첫번째 타입은 데이터를 생성할 때 지속성을 부여하는 것이며, 두번째 타입은 지속성을 갖는 객체로부터 도달될 수 있는 객체에 지속성을 부여하는 것이다.

규칙 3 : 프로그램은 지속적인 데이터와 임시 데이터를 같은 방식으로 처리할 수 있다.

다시 말해 같은 연산을 지속적인 데이터와 임시 데이터에 적용할 수 있는데, 이로 인해 모든 응용 프로그램은 DB 데이터와 프로그래밍 언어 데이터를 구별없이 처리할 수 있다.

[ ODMG에서 이루어지고 있는 표준화 동향 ]

ODMG는 OODBMS 제품 사이에 사용자 응용 프로그램의 이식성을 허용하기 위한 표준화 작업을 수행하는 비공식적인 컨소시움으로 이 모임에서는 OODBMS의 표준을 만들어 OMG(Object Management Group), ANSI, ISO 등의 관련 기구에 제안하는 작업을 수행한다.

[ OODBMS 제품 비교 ]

OODBMS는 1978년의 G-베이스(Base)를 시작으로 GemStone, 오리온(Orion), O2, ObjecStore, Versant, Objectivility 등 여러 제품이 연구 개발되어 오늘에 이르고 있다. <표 4>에 대표적인 몇몇 제품에 대한 비교를 해놓았다. 이 자료는 대표적인 비교 특성을 요약한 것이다.

<표 4> OODBMS 제품 비교

O2 v5.0 / Objectivility v5.0 / ObjectStore v5.0 / Versant v5.0