[테마특강] DB제품군 기술동향-"객체-관계형" 차세대 주역

김 원 <>1948년 강원도 강릉 출생 <>미국 MIT대 학사.석사 <>미국 일리노이주립대 컴퓨터사이언스(DB)박사 <>1980~84년 IBM 새너제이연구소 수석연구원 <>1984~90년 미국 MCC사의 객체지향및 분산시스템 연구소에서 세계 최초 객 체지향형 DBMS"오라리온" 개발 <>1990년 유니SQL사 설립 <>현재 유니SQL사 대표, ACM SIGMOD (세계DB협회) 회장 데이터베이스 제품군의 목적 본론에 앞서 우리는 데이터베이스(DB)제품군의 목적에 대해 살펴볼 필요가 있다. DB제품군은 다음과 같은 소프트웨어 요소들의 조합으로 되어 있다.

첫째 DB엔진으로 일컬어지는 DB관리 시스템 소프트웨어다. 이는 DB스키마의 생성과 DB생성, 질의, 갱신, 다수 사용자 환경하의 트랜잭션 관리, DB보호와 무결성 등을 제공한다.

둘째 DB인터페이스 소프트웨어다. 이는 애플리케이션 프로그램이 DB스키마와 DB 내용을 그래픽하게 브라우즈할 수 있는 가시화 툴(Visualization Tool)과 호스트 언어 프리프로세서(Host Language Preprocessor)를 포함하여 DB엔진 이 제공하는 모든 기능(function)을 호출할 수 있도록 허용한다.

셋째 앞에서 언급한 인터페이스 소프트웨어를 보완하는 애플리케이션 개발 툴 소프트웨어다. 이는 4세대 언어(4GL)와 그래픽 사용자 인터페이스(GUI)생 성기로서 애플리케이션의 일부를 자동적으로 생성시켜준다.

DB인터페이스와 애플리케이션 개발 툴들은 DB애플리케이션을 개발할 때 사용되며 그 목적은 애플리케이션 개발자가 애플리케이션을 가능한 한 빠르고 쉽게 개발할 수 있도록 해주는 것이다. 그러나 이러한 소프트웨어 요소들은 DB엔진의 능력이 DB인터페이스와 애플리케이션 개발 툴의 대부분의 능력을 결정하기 때문에 DB엔진의 보조일 뿐이다.

주어진 애플리케이션에 대해 DB제품군으로 애플리케이션을 개발해 업그레이드 유지보수하는 데 얼마나 쉬운가와 한번 애플리케이션이 구성된 후에 DB엔진이 얼마나 빨리 애플리케이션을 실행시킬 수 있느냐는 측면으로 볼 때 DB제품군은 2배의 이점을 가진 것은 분명하다.

그러면 DB엔진이 제공하는 기능의 특성이 무엇인지 살펴보도록 하자. 광범위 하게 DB엔진은 데이터 모델링 및 관리와 환경제어(Environment Control)의 두가지 타입의 기능을 제공한다.

데이터 모델링 및 관리 기능은 DB스키마 생성, DB에 대한 데이터생성, 질의및 갱신, DB무결성 제어(Integrity Control)가 해당된다. 환경제어 기능에는 트랜잭션 관리, 권한과 보안 제어, 컴퓨팅 자원제어, 분산환경에서의 네트워크 통신(Network Communication) 등이 해당된다.

확실히 하기 위해서 DB제품군을 선택해야 하는 결정권자는 최소한 다음과 같은 요소를 고려대상으로 삼아야 한다.

1. DB엔진의 수행속도와 견고성(Robustness).

2. 애플리케이션 프로그래밍 언어와 애플리케이션 개발 툴 선택을 포함하여 전체 애플리케이션 개발 전략.

3. 운용체계와 하드웨어, 하드웨어 구성, 네트워킹 그리고 추후 환경 변화에 대한 계획 등의 선택을 포함한 애플리케이션 수행 환경.

4. 기술자원의 질, DB제품군의 업그레이드 계획, 공급처의 장기간 자립 등을 포함한 DB벤더의 질과 안전성.

5. 실제적인 표준과 문서상 표준의 방향과 DB언어, 트랜잭션 관리, 원격 데이터 액세스 등의 분야에서 표준을 따르는 공급처.

앞에서 말한 이런 모든 요소들이 DB제품군을 선택하는 데 중요한 선택자이므 로 관계형 엔진, 객체형 엔진, 그리고 객체 관계형 엔진을 놓고 DB엔진을 선택하는 결정요소에 초점을 맞춰 살펴보아야 한다.

모든 관계형 DB엔진은 공통적으로 다음과 같은 데이터 모델링과 관리기능을 제공한다. 1. 관계형 DB엔진은 사용자가 칼럼(column)과 레코드(record)로 구성된 테이블과 테이블의 각 레코드/칼럼 엔트리에 하나의 데이터 아이템을 가질 수 있는 테이블들의 집합으로써 애플리케이션 데이터를 표현하도록 한다.

2. 일반적으로 관계형 DB엔진에서는 단일 질의문에 복잡한 질의를 표현하고 엔진의 질의 최적화 요소가 자동적으로 견정되는 최소 평가비용방식(minimal estimated cost)을 사용하여 질의문을 자동적으로는 수행한다.

3. 관계형 DB엔진은 단일 질의문에 복잡한 질의를 표현할 수 있지만 그 질의의 결과로서 리턴되는 레코드의 갯수를 일반적으로는 예측할 수 없다. 그래서 커서(cursor)라고 하는 메커니즘을 제공하는데 질의의 결과인 모든 레코드를 가지고 있는 내부 데이터 구조인 커서를 앞으로 전진시켜서 한번에 한레코드씩 검색해야 한다.

위에 제시된 관계형 DB엔진의 데이터 모델링과 관리기능의 특성은 관계형 DB엔진의 응용성과 제약성을 나타낸다. 관계형 DB엔진은 다음과 같은 특성을가지고 애플리케이션에 적용된다.

1. 애플리케이션 데이터는 단일 테이블에 대한 질의나 두개이상 테이블을 동적으로 조인하는 질의를 통해 액세스될 수 있는 데이터와 같은 독립적인 테이블들의 집합에 의한 일반적인 공식에 쓸모가 있다.

2. 애플리케이션 데이터 타입은 주로 알파누메릭(alphanumeric)이다.

3. 애플리케이션 데이터는 테이블의 각 레코드/엔트리가 하나 이상의 데이터 아이템을 수용할 필요가 없는 모델만 가능하다.

바꿔 말하면 관계형 DB엔진은 다음과 같은 특성을 가진 애플리케이션에는 적합하지 않다.

1. 애플리케이션 데이터가 중첩구조로 모델링될 필요가 있는 중요한 요소를 가지고 있다.

2. 애플리케이션 데이터 타입은 특히 멀티미디어 데이터 타입(즉 이미지, 텍스트 오디오)과 임의의 사용자 정의 데이터 타입 등과 같은 주요한 non alphanumeric 데이터도 포함한다.

3. 애플리케이션 데이터는 집합 어트리뷰트(다수 데이터 아이템을 소유하는 어트리뷰트)를 자주 액세스한다.

1980년대 중반 독립적으로 객체형 DB기술의 연구와 개발이 시작되었다.

하나는 이미 위에서 살펴본 데이터의 관계형 모델(관계형 DB공급처의 구현) 에서 중대한 결점에 대한 때늦은 인식을 한 것이고 다른 하나는 복잡한 소프트웨어의 개발, 유지보수, 그리고 업그레이드 비용을 현저히 줄일 수 있는객체형 프로그래밍의 이점을 인식한 것이었다. 비록 이 2가지 개발이 관련없어 보이지만 좀더 살펴보면 원래 관계형 모델의 결점을 해결할 필요가 있다고 생각되는 관계형 데이터 모델의 확장과 객체형 프로그래밍 언어에서 발견되는 몇가지 기본적인 개념간에 눈에 띄는 공통 요소가 있다.

그러나 불행하게도 80년대 후반에서 90년대 초반에 출시된 초기 객체형 DB시 스템들의 대부분은 연구실에서 이미 연구되어 개발된 몇가지 객체형 DB기술 을 주로 강조하고 있다. 그중 한가지 기술은 지속성(persistence)이고 다른 하나는 트랜잭션 관리다. 지속성은 자동적으로 한번에 한 객체씩 DB에 저장 하고, 그것을 생성한 프로그램이 파일에 명시적으로 저장하지 않고 끝낸 후에도 다른 프로그램에 의해 한번에 한 객체를 다시 액세스할 수 있는 것이다. 비록 몇몇 공급사는 C 스토리지와 같은 시스템내에 주요 DB기능을 추가하는 작업을 하느라 바쁘지만 오늘날 관계형 DB기술에 취하여 습관이 들기 시작하는 사용자들은 이러한 제품군들을 DB의 기존 개념에서 DB엔진으로서 분류하려는 경향이 있다. 현재 객체형 DB가 적용될 수 있는 애플리케이션은 다음과 같은 성격을 갖는다.

1. DB크기가 작고 동시 사용자수가 작다.

2.애플리케이션은C 또는Sma-lltalk로작성하여야 한다.

3. 애플리케이션은 데이터를 대부분 한 객체에서 다른 객체를 항해하여 한번에 한 객체를 액세스한다.

4. 기존 대부분의 DB기능은 지속성과 트랜잭션 관리를 제외하고는 거의 필요 하지 않다.

객체 관계형 DB기술은 관계형 DB기술과 객체형 DB기술이 빠르게 수용하고 있는 "차세대" DB기술임에 의심할 여지가 없다. 주요 관계형 DB공급처는 이미 그들의 관계형 DB엔진에 객체형 데이터 모델링과 관리기능을 갖도록 확장 시키는 계획을 발표했다. 최근 여러 객체형 DB공급처들의 모임인 ODMG(Objec t Data Management Gro-up)은 SQL 92와 호환하는 Object SQL에 대한 Object Query Language제안을 재구성하는 데 합의하였다.

객체 관계형 데이터 모델은 완전하게 관계형 모델을 포함하고, 2가지 측면에서 관계형 모델을 확장하였다.

1. 관계형 모델을 집합 어트리뷰트 지원, 임의의 데이터 타입 지원, 계층구조 지원이 가능하도록 확장하였다. 후자의 2가지는 객체형 프로그래밍 언어 에서 찾아볼 수 있는 객체형 개념을 적용한 것이다.

2.관계형모델에계승(inherita-nce)과 캡슐화(encapsulation)를 확장하였다.

객체 관계형 DB엔진은 주로 위에서 살펴본 관계형 엔진의 3가지 주요 제약 사항을 극복하였다. 데이터 모델링과 관리적인 측면에서 객체 관계형 DB엔진은 관계형 DB엔진이 할 수 있는 모든 기능을 할 수 있도록 하고, 관계형 엔진의 주요 제약사항을 제거한다. 그래서 데이터 모델링과 관리적인 측면에서 구현의 견고성과 완전성에 의해 객체 관계형 엔진은 관계형 엔진이 만족 스럽게 사용되고 있는 애플리케이션들과 객체형 엔진이 적용될 수 있는 애플 리케이션에 함께 적용될 수 있다.

그러나 객체 관계형 엔진은 순수 관계형 엔진이나 순수 객체형 엔진에 비해 약간의 오버헤드를 가질 수 있다. 예로 객체 인식자는 객체에 대한 각 스토리지 영역내에 별도의 영역을 더 가져야 하고 객체 관계형 DB스키마는 순수 관계형 스키마보다 유지하는데 좀더 복잡하다. 그리고 스키마 변경의 시맨틱 semantics 은 관계형 DB보다 좀더 복잡하다.

그래서 순수 관계형 엔진의 데이터 모델링과 관리기능 이상의 것을 필요로 하지 않는 애플리케이션이나, 지속성과 항해 액세스만을 필요로하는 C애플리케이션의 경우 각각 순수관계형 엔진이나 순수 객체형 엔진을 쓰는 것이 좋다.

대부분의 객체 관계형 DB엔진은 워크스페이스 관리를 아직 지원하지 않는다는 점을 인식해야 한다. 그러한 객체 관계형 DB엔진은 수행속도를 믿을수없는 객체형 프로그래밍 언어로 작성된 애플리케이션을 위해서는 사용할 수가 없다.

그리고 프로그래밍 언어와는 상관없이 컴퓨터 에디드 엔지니어링/디자인/애 널리시스 애플리케이션과 같은 대량의 메모리 상주 객체를 빠르게액세스해야하는 애플리케이션에서도 사용할 수 없다. 그러나 UniSQL 객체 관계형 DB시 스템은 완전한 Object SQL과 모든 주요 DB기능뿐만 아니라 워크스페이스 관리와 포인터 스위즐링(Pointer Swizzling)을 제공하는 유일한 객체 관계형엔진이다. 객체 관계형 DB엔진을 구현하는 방법에는 2가지가 있다. 하나는 기존 관계 형 엔진 위에 객체 관계형 계층을 올리는 것이다. 이것은 개발기간을 단축 시키지만 수행속도는 지극히 나쁘다. 또 다른 하나는 풍부한 접근방식을 가지고 전체 엔진을 만드는 것이다.