객체관계형 DBMS로 복잡한 데이터 모델 다루기

관계형 모델만으로 표현하기 어려운 데이터

객체관계형 데이터베이스 관리 시스템(Object-Relational Database Management System, ORDBMS)은 관계형 DBMS의 안정성에 객체지향 DBMS의 유연성을 더한 하이브리드 시스템이다. 복잡한 데이터 구조와 관계를 보다 직관적으로 모델링하고 관리하는 데 초점을 둔다.

1990년대 초반 객체지향 프로그래밍이 널리 쓰이기 시작하면서 데이터베이스에도 객체지향 개념을 적용하려는 시도가 이어졌다. 순수 객체지향 DBMS(OODBMS)는 객체 모델링에 강점이 있었지만, 표준화 부족과 성능 문제, 기존 시스템과의 호환성 한계를 드러냈다.

ORDBMS는 시장에서 검증된 RDBMS의 기반을 유지하면서 객체지향 특성을 접목하려는 요구에서 등장했다. 이런 배경 때문에 제3세대 DBMS로 평가되기도 한다.

데이터 타입과 관계를 확장하는 방식

사용자 정의 타입으로 복합 값 표현하기

기본 데이터 타입 외에 사용자가 복합 데이터 타입을 정의할 수 있다. 예를 들어 주소는 도시, 구/군, 상세주소, 우편번호를 하나의 타입으로 묶어 표현할 수 있다.

CREATE TYPE AddressType AS OBJECT (
    city VARCHAR(50),
    district VARCHAR(50),
    street VARCHAR(100),
    postal_code VARCHAR(10)
);

CREATE TABLE Customer (
    id INTEGER PRIMARY KEY,
    name VARCHAR(100),
    address AddressType
);

참조 타입으로 객체 연결하기

참조 타입은 객체 사이의 관계를 직접 참조로 나타낸다. 외래 키 제약조건과 다른 방식으로 객체 간 연결을 표현할 수 있다.

CREATE TYPE PersonType AS OBJECT (
    id INTEGER,
    name VARCHAR(100)
);

CREATE TYPE DepartmentType AS OBJECT (
    dept_id INTEGER,
    dept_name VARCHAR(50),
    manager REF PersonType
);

LOB에 대용량 콘텐츠 보관하기

이미지, 비디오, 오디오처럼 큰 데이터를 저장하기 위해 CLOB(Character Large Object)과 BLOB(Binary Large Object)을 지원한다. 의료 시스템에서 환자 MRI 스캔 이미지를 저장하는 경우가 한 예다.

CREATE TABLE MedicalRecord (
    record_id INTEGER PRIMARY KEY,
    patient_id INTEGER,
    record_date DATE,
    doctor_notes CLOB,
    mri_scan BLOB
);

테이블 상속과 중첩 구조

객체지향의 상속 개념을 테이블 구조에 적용하면 상위 테이블의 속성을 하위 테이블이 이어받을 수 있다. 재사용성과 확장성을 높이는 방식이다.

CREATE TABLE Person (
    id INTEGER PRIMARY KEY,
    name VARCHAR(100),
    birth_date DATE
);

CREATE TABLE Employee UNDER Person (
    employee_id VARCHAR(20),
    department VARCHAR(50),
    salary DECIMAL(10,2)
);

중첩된 테이블은 테이블 안에 다른 테이블을 포함해 복잡한 구조를 나타낸다. 일대다 관계를 단일 테이블 안에서 표현할 수 있어 조인 연산을 줄일 수 있다.

CREATE TYPE PhoneNumberType AS OBJECT (
    phone_type VARCHAR(20),
    number VARCHAR(20)
);

CREATE TYPE PhoneListType AS TABLE OF PhoneNumberType;

CREATE TABLE Contact (
    contact_id INTEGER PRIMARY KEY,
    name VARCHAR(100),
    phone_numbers PhoneListType
) NESTED TABLE phone_numbers STORE AS phone_numbers_tab;

객체관계형 기능을 제공하는 제품

Oracle Database는 가장 널리 사용되는 ORDBMS 가운데 하나다. Oracle 8부터 객체관계형 기능을 도입했고, Oracle 21c까지 사용자 정의 타입, 컬렉션, 객체 뷰 등 객체지향 기능을 발전시켜 왔다.

PostgreSQL은 대표적인 오픈소스 ORDBMS다. 테이블 상속, 사용자 정의 타입, 복합 타입을 지원하며, PostGIS를 통한 GIS 데이터 처리처럼 특수 데이터 영역에도 활용된다.

IBM DB2는 객체 확장 기능과 XML 데이터 처리 기능을 통합해 제공하는 엔터프라이즈급 ORDBMS다. Microsoft SQL Server도 최신 버전에서 제한적이지만 사용자 정의 타입과 XML 데이터 타입 같은 객체관계형 기능을 제공한다.

엔진 내부에서 객체와 관계를 연결하는 구조

ORDBMS는 SQL 인터페이스와 쿼리 처리기를 거쳐 객체 타입 정의와 관계 스키마를 저장 엔진에 연결한다.

⤢✕

GIS와 콘텐츠 저장소에서의 활용

공간 데이터를 객체로 모델링하면 저장과 조회를 효율적으로 다룰 수 있다. PostgreSQL의 PostGIS 확장은 ORDBMS 기능을 활용하는 대표 사례다.

CREATE TABLE landmarks (
    id INTEGER PRIMARY KEY,
    name VARCHAR(100),
    location GEOMETRY(POINT)
);

-- 특정 지점으로부터 10km 이내의 랜드마크 검색
SELECT name FROM landmarks
WHERE ST_Distance(location,
    ST_SetSRID(ST_Point(127.0, 37.5), 4326)) < 10000;

멀티미디어 콘텐츠 관리에서는 영화, 음악, 이미지와 그 메타데이터를 함께 관리할 수 있다. 메타데이터는 구조화된 객체로 두고, 실제 콘텐츠는 LOB에 저장하는 방식이다.

CREATE TYPE MediaMetadata AS OBJECT (
    title VARCHAR(200),
    creator VARCHAR(100),
    created_date DATE,
    keywords VARCHAR(500)
);

CREATE TABLE MediaLibrary (
    media_id INTEGER PRIMARY KEY,
    metadata MediaMetadata,
    content_type VARCHAR(50),
    content BLOB
);

전자상거래 시스템에서는 제품, 고객, 주문처럼 연결이 많은 비즈니스 엔티티를 객체로 모델링할 수 있다. 객체 간 관계를 자연스럽게 표현해 시스템의 복잡성을 줄이는 데 활용한다.

⤢✕

선택할 때 함께 봐야 할 점

ORDBMS는 복잡한 실세계 객체를 데이터베이스에 더 직관적으로 매핑하고 객체지향 프로그래밍 패러다임과의 일관성을 유지할 수 있다. 객체 참조로 일부 조인 연산을 줄일 수 있으며, 복잡한 객체를 분해하지 않고 원자적으로 처리할 수도 있다. 새로운 데이터 타입과 함수를 추가하기 쉬워 GIS나 멀티미디어 같은 특수 도메인에 맞춘 기능을 개발하기에도 적합하다.

반면 순수 관계형 모델보다 설계와 구현이 복잡해질 수 있고, 객체관계형 기능을 효과적으로 사용하려면 추가 학습이 필요하다. SQL:1999에 일부 객체관계형 기능이 포함됐지만 DBMS별 구현은 서로 다르다. 벤더 종속성(vendor lock-in)과 일부 기능의 처리 비용, 부적절한 설계에서 발생할 수 있는 성능 저하도 검토 대상이다.

ORM과는 적용 계층이 다르다

ORDBMS와 ORM(Object-Relational Mapping) 프레임워크는 객체지향 모델과 관계형 데이터를 연결한다는 점에서는 닮았지만, 그 기능이 놓이는 계층이 다르다.

⤢✕

ORDBMS는 객체지향 특성을 데이터베이스 자체에 내장한다. ORM은 Hibernate, JPA, Entity Framework 등의 미들웨어로 애플리케이션 계층에서 객체-관계 변환을 처리한다.

복잡한 도메인 모델을 위한 선택지

빅데이터와 NoSQL 데이터베이스가 부상한 뒤에도, 복잡한 비즈니스 로직과 데이터 무결성이 중요한 영역에서 ORDBMS의 활용 가치는 유지된다. 클라우드 네이티브 환경에 맞춘 기능 확장이 예상되며, 그래프 데이터베이스와 문서 데이터베이스 등 여러 데이터 모델의 특성을 통합하는 멀티모델 DBMS로 발전할 가능성도 있다.

관계형 데이터베이스의 견고한 기반 위에서 객체지향 모델의 유연성을 활용해야 할 때 ORDBMS는 유효한 선택지다. 특히 복잡한 비즈니스 도메인과 다양한 데이터 타입을 함께 다뤄야 하는 환경에서 강점을 보인다.