맨위로가기

객체 지향 데이터베이스

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.

1. 개요

객체 지향 데이터베이스(ODBMS)는 객체 지향 프로그래밍 개념을 데이터베이스에 적용하여 데이터를 객체 형태로 저장하고 관리하는 시스템이다. 1970년대에 연구가 시작되어 1980년대에 상용화되었으며, 초기에는 GemStone, Gbase, Vbase 등이 등장했다. C++, 자바, C# 등 다양한 프로그래밍 언어와 통합되었으며, 2004년 이후 오픈 소스 ODBMS가 등장하면서 두 번째 성장기를 맞이했다. ODBMS는 공간 데이터베이스, 통신, 고에너지 물리학 등 다양한 분야에서 활용되며, 쿼리 언어, 버전 관리, 액티브 데이터베이스 기능 등을 제공한다. ODMG를 중심으로 표준화 노력이 있었으나, 네이티브 쿼리, LINQ 등의 등장으로 표준화 방향이 변화했다. ODBMS는 RDBMS보다 특정 작업에서 성능이 우수하지만, 상호 운용성, 캡슐화 개념과의 불일치 등의 비판과 과제를 가지고 있다.

더 읽어볼만한 페이지

  • 데이터베이스 모델 - 플랫 파일 데이터베이스
    플랫 파일 데이터베이스는 각 줄에 레코드를 기록하고 구분자로 필드를 구분하는 단순한 형태이지만, 데이터 중복, 대용량 처리의 어려움, 보안 취약성 등의 한계로 특정 용도로만 활용된다.
  • 데이터베이스 모델 - 네트워크 모델
    네트워크 모델은 찰스 바크만이 발명하고 CODASYL 컨소시엄에 의해 표준 사양으로 개발된 데이터베이스 모델이며, 바흐만 다이어그램으로 표현되고 IDS, IDMS, IMAGE 등 다양한 시스템에서 구현되었다.
  • 데이터베이스 관리 시스템 - 트랜잭션 처리
    트랜잭션 처리는 데이터베이스 시스템에서 데이터의 일관성과 무결성을 보장하기 위한 기술이며, ACID 속성을 통해 데이터 정확성을 유지하고 롤백, 데드락 처리 등의 기술을 활용한다.
  • 데이터베이스 관리 시스템 - 저장 프로시저
    저장 프로시저는 데이터베이스 관리 시스템에서 SQL 문들을 미리 컴파일하여 저장하고, 모듈화, 보안성, 성능 향상, 유지보수 용이성과 같은 특징을 가지며, 데이터베이스 시스템마다 구현 방식과 지원하는 언어가 다를 수 있는 코드 묶음이다.
객체 지향 데이터베이스
개요
유형객체 지향 데이터베이스 관리 시스템
개발 모델중앙 집중식
역사
등장 시기1980년대 후반 ~ 1990년대 초반
영향객체 관계 데이터베이스
NoSQL
특징
장점복잡한 데이터 구조를 효율적으로 관리할 수 있다.
객체 지향 프로그래밍 언어와의 통합이 용이하다.
데이터 모델링의 유연성이 높다.
단점관계형 데이터베이스 관리 시스템에 비해 성능이 떨어질 수 있다.
쿼리 언어의 표준화가 미흡하다.
개발 및 유지 보수가 복잡할 수 있다.
예시
데이터베이스GemStone/S
Versant Object Database
ObjectDB
db4o
관련 기술객체 지향 프로그래밍
객체 관계 매핑
NoSQL

2. 역사

객체 지향 데이터베이스 기술은 1970년대 중반, 데이터베이스 관리 시스템(DBMS)에서 그래프 구조를 이루는 객체를 다루기 위한 연구에서 발전했다.

1985년경 "객체 지향 데이터베이스 시스템"이라는 용어가 처음 등장했다.

2004년부터 객체 데이터베이스는 오픈 소스 객체 데이터베이스가 등장하면서 두 번째 성장기를 맞이했다. 이러한 객체 데이터베이스는 OOP 언어(예: 스몰토크, 자바 또는 C#)로 완전히 작성되어 널리 사용 가능하고 사용하기 쉬웠다. 예를 들어 Versant의 db4o (db4objects), Obsidian Dynamics의 DTS/S1 및 Perst (McObject)는 이중 오픈 소스 및 상용 라이선스로 제공된다.

연대별 주요 사건들은 다음과 같다.

연도사건
1966년MUMPS
1979년InterSystems M
1980년TORNADO – CAD/CAM용 객체 데이터베이스[7]
1982년젬스톤(Gemstone)이 집합론적 모델 데이터베이스 머신 구축 시작 (Servio Logic으로 시작)
1985년객체 데이터베이스라는 용어 처음 도입
1986년Servio Logic (Gemstone Systems)이 Gemstone 1.0 출시
1988년Object Design, Incorporated 설립, ObjectStore 개발 시작Versant Corporation 시작 (Object Sciences Corp로 시작)Objectivity, Inc. 설립
1990년대 초Servio Logic이 Gemstone Systems로 이름 변경젬스톤 (스몰토크) - (C++) - (자바)GBase (LISP)VBase (O2 - ONTOS - INFORMIX)Objectivity/DB
1990년대 중반InterSystems CachéVersant Object DatabaseODABAZODBPoetJADEMatisseIllustra Informix
2000년대lambda-DB: 레오니다스 페가라스(Leonidas Fegaras), 찬드라세카르 스리니바산(Chandrasekhar Srinivasan), 아르빈드 라젠드란(Arvind Rajendran), 데이비드 마이어(David Maier)의 ODMG 기반 객체 지향 DBMSdb4o 프로젝트는 칼 로젠버거(Carl Rosenberger)가 시작ObjectDB
2001년IBM이 Informix 인수
2003년odbpp 공개 출시
2004년db4o의 상업적 출시, db4objects, Inc.
2008년db4o가 Versant Corporation에 인수됨
2010년VMware가 GemStone 인수[8]
2011년db4o의 개발 중단
2012년Wakanda의 첫 생산 버전, 오픈 소스 및 상업적 라이선스 출시Actian이 Versant Corporation 인수
2013년GemTalk Systems가 Gemstone 제품을 VMware에서 인수[9]
2014년db4o의 상업적 제공이 Actian(Versant를 인수)에 의해 공식적으로 중단됨[10]Realm[11]
2017년ObjectBox[12]


2. 1. 주요 연구 프로젝트

"객체 지향 데이터베이스 시스템"이라는 용어는 1985년경에 처음 등장했다.[4] 주목할 만한 연구 프로젝트는 다음과 같다.

프로젝트명기관
Encore-Ob/Server브라운 대학교
EXODUS위스콘신-매디슨 대학교
IRIS휴렛 팩커드
ODE벨 연구소
ORION마이크로일렉트로닉스 및 컴퓨터 기술 공사 (MCC)
VodakGMD-IPSI
Zeitgeist텍사스 인스트루먼트



ORION 프로젝트는 다른 어떤 노력보다 더 많은 논문을 발표했다. MCC의 원 킴은 MIT Press에서 출판한 책에 해당 논문들을 엮었다.[5]

2. 2. 상용 제품의 등장

1980년대 후반부터 1990년대 중반까지 여러 상용 객체 지향 데이터베이스 제품들이 시장에 등장했다. 주요 제품들은 다음과 같다:[6]

제품명개발/판매 회사비고
젬스톤Servio Logic (이후 GemStone Systems로 변경)
GbaseGraphael
VbaseOntologic
ITASCAItasca Systems
Jasmine후지쯔, CA에서 판매
MatisseMatisse Software
Objectivity/DBObjectivity, Inc.
ObjectStoreProgress Software, eXcelon에서 인수 (원래 Object Design, Incorporated)
ONTOSOntos, Inc. (Ontologic에서 이름 변경)
O2O2 Technology (여러 회사와 합병, Informix에 인수, 이후 IBM에 인수됨)
POET현재 [http://www.versant.com/developer FastObjects], Versant가 Poet Software를 인수
Versant Object Database[http://www.versant.com Versant] Corporation
VOSSLogic Arts
JADEJade Software Corporation



이러한 제품 중 일부는 현재까지도 시장에 남아 있으며, InterSystems Caché와 같은 새로운 오픈 소스 및 상용 제품들이 추가되고 있다.

초기 상용 제품들은 스몰토크, LISP, COP등 다양한 프로그래밍 언어와의 통합을 제공했다. 1990년대 대부분 동안 C++가 상용 객체 데이터베이스 관리 시장을 지배했으며, 이후 자바와 C#이 추가되었다.

3. 기술적 특징

객체 지향 데이터베이스 관리 시스템(OODBMS)은 ODBMS(객체 데이터베이스 관리 시스템)라고도 불리며, 데이터베이스 기능과 객체 지향 프로그래밍 언어 기능을 결합한 것이다. OODBMS를 사용하면 객체 지향 프로그래머가 제품을 개발하고, 이를 객체로 저장하며, 기존 객체를 복제하거나 수정하여 OODBMS 내에서 새로운 객체를 만들 수 있다.[3]

인트라넷엑스트라넷의 구현으로 웹 기반 기술의 사용이 증가함에 따라, 기업들은 복잡한 데이터를 표시하기 위해 OODBMS에 대한 관심을 갖게 되었다. 데이터를 객체로 저장하도록 특별히 설계된 DBMS를 사용하면 멀티미디어 프레젠테이션에 중점을 둔 회사나 컴퓨터 지원 설계(CAD)를 활용하는 조직에 유리하다.[3]

대부분의 객체 지향 데이터베이스는 선언적 프로그래밍 방식을 사용하여 객체를 찾을 수 있도록 하는 일종의 쿼리 언어도 제공한다. ODMG는 객체 쿼리 언어(OQL)를 사용하여 표준화를 시도했다. 객체는 포인터를 따라 검색할 필요 없이 직접 검색할 수 있으므로 데이터 접근이 빠르다. 데이터와 관련된 클래스 메서드가 해당 데이터를 올바르게 해석하므로 멀티미디어 애플리케이션 개발이 용이하다.

예를 들어 Gemstone 또는 VOSS와 같은 많은 객체 데이터베이스는 버전 관리를 지원한다. 객체는 모든 버전의 집합으로 볼 수 있으며, 각 버전은 자체적으로 객체로 취급될 수 있다. 일부 객체 데이터베이스는 액티브 데이터베이스의 기반인 데이터베이스 트리거 및 제약 조건에 대한 체계적인 지원도 제공한다. 이러한 데이터베이스의 효율성은 한 항목에 대한 방대한 양의 데이터를 요구하는 영역에서 크게 향상된다. 예를 들어, 은행은 사용자의 계정 정보, 거래, 계정 정보 항목 등과 같은 광범위한 정보를 효율적으로 제공할 수 있다.

데이터베이스를 사용하는 사람들에게 ODBMS가 필요한 배경에는 주로 두 가지 요인이 있었다.

# 기존 관계형 데이터베이스에서 복잡한 구조를 가진 데이터를 다루는 것이 번거롭고 비효율적이며 다루기 어렵다는 점이 데이터베이스 관련자들에게 인식되기 시작했다.

# 최근 데이터를 다루는 애플리케이션 소프트웨어를 객체 지향 프로그래밍 언어 (스몰토크, C++, 자바, 델파이, 루비, 파이썬, C# 등)로 기술하는 경우가 많아졌다.

이러한 상황에서 관계형 데이터베이스를 사용하면 애플리케이션 소프트웨어에서 객체로 표현된 데이터와 관계형 모델에 기초한 관계형 데이터베이스의 관계 (테이블 구조) 데이터를 상호 변환하는 처리를 프로그래머가 직접 기술해야 했다. 이러한 객체 지향 프로그래밍 언어와 관계형 데이터베이스 간의 불일치를 임피던스 불일치라고 한다.

애플리케이션 소프트웨어는 내비게이션 데이터베이스처럼 내비게이션 방식으로 객체 데이터베이스에 저장된 객체에 대한 참조를 취득할 수 있다. 객체는 다른 객체에 대한 참조를 가질 수 있다. 이를 이용하여 애플리케이션 소프트웨어는 객체 간의 참조 관계를 따라가서 목적하는 객체에 대한 참조를 취득할 수 있다.

ODBMS의 검색 속도는 관계(테이블 구조)로 구현하는 RDBMS에 비해 빨라질 가능성이 있다. ODBMS에서는 RDBMS와 달리 조인(join)과 같은 처리를 거의 수행하지 않고, 객체의 참조를 통해 직접 목적 객체에 대한 참조를 취득할 수 있기 때문이다.

3. 1. 주요 특징

객체 지향 데이터베이스 관리 시스템(OODBMS)은 데이터베이스 기능과 객체 지향 프로그래밍 언어 기능을 결합한 것이다. 이를 통해 프로그래머는 객체 지향 프로그래밍 언어와 데이터베이스에서 동일한 표현 모델을 사용, 일관성을 유지할 수 있다.[3]

객체 지향 프로그래밍 언어와 동일한 모델을 사용하며, 주요 특징은 다음과 같다.

  • 데이터 접근 속도: 포인터를 통해 직접 객체를 검색하여 데이터 접근 속도가 빠르다.
  • 스키마 정의: 프로그래밍 언어와 데이터베이스 스키마가 동일한 유형 정의를 사용한다.
  • 멀티미디어 처리: 데이터와 관련된 클래스 메서드가 데이터를 올바르게 해석하여 멀티미디어 애플리케이션 개발에 용이하다.
  • 버전 관리: (예: Gemstone, VOSS) 객체의 모든 버전 집합을 관리하고, 각 버전을 객체로 취급한다.
  • 데이터베이스 트리거 및 제약 조건: (일부 OODBMS) 액티브 데이터베이스의 기반이 되는 기능을 지원한다.
  • 대용량 데이터 처리 효율성: 은행의 사용자 계정 정보처럼 한 항목에 대한 방대한 데이터가 필요한 영역에서 효율적이다.
  • 객체 지향 프로그래밍 언어와의 연동: ODBMS는 객체 지향 프로그래밍 언어의 기능을 확장한 것으로, 투명한 데이터 영속성, 병행성 제어, 데이터 복구, 조인 쿼리 등을 제공한다.
  • 객체 질의 언어: 대부분의 객체 지향 데이터베이스는 선언적 프로그래밍 방식의 쿼리 언어를 제공하여 객체를 찾는다. ODMG는 객체 쿼리 언어인 OQL을 통해 표준화를 시도했다.

3. 2. 관계형 데이터베이스(RDBMS)와의 비교

객체 지향 데이터베이스 관리 시스템(OODBMS)는 데이터베이스 기능과 객체 지향 프로그래밍 언어 기능을 결합한 것이다. 반면 관계형 데이터베이스(RDBMS)는 데이터베이스 모델과 응용 프로그램 간의 구분이 명확하다. OODBMS는 프로그래밍 언어와 동일한 표현 모델을 사용하므로 단일 환경 내에서 일관성을 유지할 수 있다.[3]

객체 지향 데이터베이스는 복잡한 데이터와 그 관계를 행과 열로 매핑하지 않고 직접 저장한다. 따라서 매우 복잡한 데이터를 처리하는 애플리케이션에 적합하다.[19] 객체는 다대다 관계를 가지며 포인터를 사용하여 접근하고, 포인터는 객체에 연결되어 관계를 설정한다.[20]

기존 관계형 데이터베이스에서는 복잡한 구조의 데이터를 다루는 것이 번거롭고 비효율적이었다. 또한 객체 지향 프로그래밍 언어로 작성된 애플리케이션 소프트웨어에서 객체로 표현된 데이터와 관계형 데이터베이스의 관계 (테이블 구조) 데이터를 상호 변환하는 처리를 프로그래머가 직접 기술해야 했다. 이러한 불일치를 임피던스 불일치라고 부르며, 이를 줄이는 기술로 객체 데이터베이스와 객체 관계형 매핑이 있다.

ODBMS의 검색 속도는 RDBMS에 비해 빨라질 가능성이 있다. ODBMS에서는 조인(join)과 같은 처리를 거의 수행하지 않고, 객체의 참조를 통해 직접 목적 객체에 대한 참조를 취득할 수 있기 때문이다.[23]

벤치마크를 통한 성능 비교에서 ODBMS는 일부 처리 형태에서 RDBMS보다 뛰어난 성능을 보이기도 한다. 이는 ODBMS가 많은 처리를 선언적 지시가 아닌 네비게이션 지시를 기반으로 실행하기 때문이다.

그러나 ODBMS는 상호 운용성이 낮다는 단점이 있다. RDBMS는 데이터베이스와 애플리케이션 소프트웨어 연결에 대해 업계 표준(JDBC 및 ODBC)을 따르고, 보고서 작성 도구, OLAP 도구, 백업 및 복구 표준 등 다양한 상호 운용 가능한 도구와 기능을 제공한다.

4. 활용 분야

객체 지향 데이터베이스는 객체 지향 프로그래밍 언어와 결합하여 복잡한 데이터를 처리하는 데 강점을 보인다. 특히 웹 기반 기술의 발전으로 복잡한 데이터 처리에 대한 요구가 증가하면서, 객체 지향 데이터베이스 관리 시스템(OODBMS)에 대한 관심이 높아졌다.

컴퓨터 지원 설계(CAD)나 멀티미디어 프레젠테이션과 같이 복잡한 데이터를 다루는 분야에서 OODBMS가 유용하게 활용될 수 있다.[3]

객체 지향 데이터베이스는 공학, 공간, 전기 통신, 자연 과학 분야의 데이터베이스로 사용되어 왔으며, 금융업의 몇몇 특정 분야에서도 사용된다. 특히, 스탠퍼드 선형 가속기 센터의 객체 데이터베이스는 세계 최대 용량 및 데이터 증가 속도 기록을 보유하고 있다. 또한, 장비, 패키지 소프트웨어, 실시간 시스템에 내장되어 사용되기도 한다.

4. 1. 주요 활용 분야

객체 지향 데이터베이스는 복잡한 데이터의 고속 처리에 대한 비즈니스 요구가 있을 때 일반적으로 권장된다. 웹 기반 기술의 사용이 증가함에 따라, 기업들은 복잡한 데이터를 표시하기 위해 객체 지향 데이터베이스 관리 시스템(OODBMS)에 관심을 갖게 되었다. 특히 멀티미디어 프레젠테이션에 중점을 둔 회사나 컴퓨터 지원 설계 (CAD)를 활용하는 조직에 유리하다.[3]

객체 데이터베이스는 다음과 같은 여러 분야에서 사용되어 왔다.

  • 공학 데이터베이스
  • 공간 데이터베이스
  • 전기 통신 데이터베이스
  • 고에너지 물리학, 분자 생물학(생물 정보학) 등 자연 과학 분야


금융업의 몇몇 특정 분야에서 사용되는 사례도 나타나고 있다. 객체 데이터베이스는 현재 세계 최대 용량의 데이터베이스라는 기록을 가지고 있다. 스탠퍼드 선형 가속기 센터에서는 1000 테라바이트 이상의 객체 데이터베이스가 운영되고 있으며, 하루에 1테라바이트 이상 증가하는 높은 데이터 증가 속도를 기록하고 있다.

몇몇 ODBMS는 장비, 패키지 소프트웨어 및 실시간 시스템에 내장하는 용도로 사용된다.

5. 표준화 및 네이티브 쿼리

객체 데이터 관리 그룹(Object Data Management Group, ODMG)은 객체 데이터베이스 표준화를 위해 노력했지만, 2001년 활동을 중단했다. 이후 객체 지향 데이터베이스 개념은 SQL:1999에 일부 반영되었고, 객체-관계형 데이터베이스(object–relational database) 제품에서 다양하게 구현되었다.

2005년에는 객체 지향 프로그래밍 언어 자체를 쿼리 표현에 사용하는 네이티브 쿼리(Native Queries) 방식이 제안되었다. 마이크로소프트는 Language Integrated Query(LINQ)를 통해 이 방식을 채택했다.

객체 관리 그룹(Object Management Group, OMG)은 ODMG의 뒤를 이어 객체 데이터베이스 기술 표준화를 시도했으나, 2009년에 중단되었다. 한편, 월드 와이드 웹 컨소시엄(World Wide Web Consortium)의 XQuery와 같은 기술은 XML 데이터 처리에 활용되며 객체 데이터베이스와 경쟁했다. JSON 형식의 부상과 PostgreSQL의 JSONB 지원은 객체 데이터베이스 기술의 새로운 흐름을 보여주었다.

5. 1. 표준화 노력 (ODMG)

객체 데이터 관리 그룹(Object Data Management Group)은 객체 데이터베이스 및 객체-관계형 매핑 벤더, 학계 회원 및 관련 당사자들의 컨소시엄이었다. 이 그룹의 목표는 데이터베이스 관리 시스템에 객체를 저장하는 이식 가능한 애플리케이션을 허용하는 일련의 사양을 만드는 것이었다. 이 그룹은 여러 버전의 사양을 발표했으며, 마지막 릴리스는 ODMG 3.0이었다. 2001년까지 주요 객체 데이터베이스 및 객체-관계형 매핑 벤더 대부분은 ODMG 자바 언어 바인딩을 준수한다고 주장했다. 사양의 다른 구성 요소에 대한 준수는 혼조세를 보였다. 2001년에 ODMG 자바 언어 바인딩은 자바 커뮤니티 프로세스(Java Community Process)에 자바 데이터 객체(Java Data Objects) 사양의 기반으로 제출되었다. 이후 ODMG 회원사는 자바 데이터 객체 사양에 노력을 집중하기로 결정했다. 그 결과, ODMG는 2001년에 해산되었다.

5. 2. 네이티브 쿼리 (Native Queries)

2005년에 쿡, 라이, 로젠버거는 객체 지향 쿼리 API를 추가하기 위한 모든 표준화 노력을 중단하고, 대신 쿼리를 표현하기 위해 OO 프로그래밍 언어 자체, 즉 자바와 .NET을 사용할 것을 제안했다. 그 결과 네이티브 쿼리(Native Queries)가 등장했다.[15] 마찬가지로, 마이크로소프트는 2005년 9월에 프로그래밍 언어 C# 및 VB.NET 9을 사용하여 언어 통합 데이터베이스 쿼리 기능을 제공하기 위해 Language Integrated Query(LINQ) 및 LINQ의 구현인 DLINQ를 발표했다.

5. 3. 기타 표준화 동향

객체 데이터 관리 그룹(Object Data Management Group, ODMG)은 객체 데이터베이스 및 객체-관계형 매핑 벤더, 학계 회원, 관련 당사자들의 컨소시엄이었다. ODMG의 목표는 데이터베이스 관리 시스템에 객체를 저장하는 이식 가능한 애플리케이션을 허용하는 일련의 사양을 만드는 것이었다. 이 그룹은 여러 버전의 사양을 발표했으며, 마지막 릴리스는 ODMG 3.0이었다. 2001년까지 주요 객체 데이터베이스 및 객체-관계형 매핑 벤더 대부분은 ODMG 자바 언어 바인딩을 준수한다고 주장했다. 그러나 사양의 다른 구성 요소에 대한 준수는 혼조세를 보였다. 2001년에 ODMG 자바 언어 바인딩은 자바 커뮤니티 프로세스(Java Community Process)에 자바 데이터 객체(Java Data Objects) 사양의 기반으로 제출되었다. 이후 ODMG 회원사는 자바 데이터 객체 사양에 노력을 집중하기로 결정했고, 그 결과 ODMG는 2001년에 해산되었다.[24]

많은 객체 데이터베이스 아이디어는 SQL:1999 표준에 흡수되었으며, 객체-관계형 데이터베이스(object–relational database) 제품에 다양한 수준으로 구현되었다.

2005년, 쿡(Cook), 라이(Rai), 로젠버거(Rosenberger)는 객체 지향 쿼리 API를 추가하기 위한 모든 표준화 노력을 중단하고, 대신 쿼리를 표현하기 위해 객체 지향 프로그래밍 언어 자체(자바, .NET 등)를 사용할 것을 제안했다. 그 결과 네이티브 쿼리(Native Queries)가 등장했다. 이와 유사하게, 마이크로소프트는 2005년 9월에 프로그래밍 언어 C# 및 VB.NET 9을 사용하여 언어 통합 데이터베이스 쿼리 기능을 제공하기 위해 Language Integrated Query(LINQ) 및 LINQ의 구현인 DLINQ를 발표했다.

2006년 2월, 객체 관리 그룹(Object Management Group, OMG)은 ODMG 3.0 사양을 기반으로 새로운 사양을 개발할 권한을 받았으며, 객체 데이터베이스 기술 워킹 그룹(Object Database Technology Working Group, ODBT WG)을 구성했다고 발표했다. ODBT WG는 객체 데이터베이스 기술(예: 복제), 데이터 관리(예: 공간 인덱싱), 데이터 형식(예: XML)의 발전을 통합하고, 객체 데이터베이스가 채택되는 도메인(예: 실시간 시스템)을 지원하는 새로운 기능을 포함하는 일련의 표준을 만들 계획이었다. 그러나 2008년 말 경제적 혼란으로 인해 ODB 벤더들이 다른 곳에 자원을 집중하기로 결정하면서, ODBT WG의 작업은 2009년 3월에 중단되었다.

2007년 1월, 월드 와이드 웹 컨소시엄(World Wide Web Consortium, W3C)은 XQuery 언어에 최종 권고 상태를 부여했다. XQuery는 XML을 데이터 모델로 사용한다. 객체 데이터베이스를 위해 원래 개발된 아이디어 중 일부가 XQuery에 도입되었지만, XQuery는 본질적으로 객체 지향적이지 않다. XML의 인기로 인해 XQuery 엔진은 관계형 데이터베이스에 편리하게 보관하기에는 너무 복잡하거나 가변적인 데이터를 저장하는 수단으로 객체 데이터베이스와 경쟁한다. 또한 XQuery를 통해 객체 지향 시스템에서 제공되는 캡슐화 기능을 제공하도록 모듈을 작성할 수 있다.

XQuery v1과 XPath v2 및 이후 버전은 강력하며, 오픈 소스 및 자유(FOSS) 소프트웨어[15][16][17] 뿐만 아니라 상용 시스템에서도 사용할 수 있다. 이들은 배우고 사용하기 쉬우며 매우 강력하고 빠르다. 또한 관계형이 아니며 XQuery는 SQL을 기반으로 하지 않는다(XQuery를 설계한 사람 중 한 명이 SQL도 공동으로 발명했지만). 하지만 프로그래밍 측면에서 객체 지향적이지도 않다. XQuery는 은닉, 암시적 디스패치 및 클래스와 메서드를 사용한 캡슐화를 사용하지 않는다. XQuery 데이터베이스는 일반적으로 XML과 JSON을 교환 형식으로 사용하지만, 다른 형식도 사용된다.

2000년대 초반부터 JSON은 개발자가 데이터 형식을 제어하는 애플리케이션에서 커뮤니티의 채택과 인기를 얻었다. JSON용 XQuery의 쿼리 아날로그인 JSONiq는 (XQuery의 핵심 표현식과 연산을 공유하면서) 데이터 지향 정보에 대한 JSON 및 XML 형식의 기능적 등가성을 보여주었다. 이러한 맥락에서, OODBMS 유지 관리자의 주요 전략은 JSON을 데이터베이스에 재적용하는 것이었다(내부 데이터 형식으로 사용).

2016년 1월, PostgreSQL 9.5 릴리스[18]는 모든 기본 관계형 및 비관계형 조작을 위한 완벽한 함수 및 연산 세트를 갖춘 효율적인 JSON 내부 데이터 형식(JSONB)을 제공하는 최초의 FOSS OODBMS였다.

6. 비판 및 과제

벤치마크를 통한 성능 비교에서 일부 처리 형태에서 ODBMS가 RDBMS보다 뛰어난 성능을 보이기도 한다. 이는 ODBMS가 많은 처리를 선언적 지시가 아닌 네비게이션 지시를 기반으로 실행하기 때문이다. 객체 데이터베이스에 대한 네비게이션 접근은 대부분의 경우 참조를 따라 대상 객체를 획득하는 효율적인 방법으로 구현된다.[23]

하지만 많은 사람들은 객체 데이터베이스 기술의 본질적인 방향성은 현 시점에서도 유효하다고 생각한다. 현재도 객체 데이터베이스 기술을 포함하여 데이터베이스 기능을 밀접하게 객체 지향 프로그래밍 언어와 통합하려는 노력이 연구자와 개발자 커뮤니티 모두에서 계속되고 있다.

6. 1. 비판

ODBMS와 같은 네비게이션 데이터베이스 DBMS에 대한 비판으로는, 참조를 따라 데이터에 접근하는 기법이 특정 "탐색 경로"나 시점에 최적화되어 있다는 점이 지적된다. 이러한 관점에 따르면, 범용적인 데이터 조작 언어(ODMG가 제정한 객체 질의 언어 등)를 통해 데이터에 접근할 때, ODBMS처럼 참조를 따라가는 방식은 RDBMS 등에 비해 처리 속도가 느리고, 데이터 조작 언어로 검색식을 작성하기도 어렵다는 단점이 있다.[23] ODBMS와 같은 네비게이션 DBMS는 데이터베이스 구축 시 예상했던 용도에 대해서는 접근성이 최적화되어 용이하지만, 예상하지 못했던 다양한 용도로 접근할 경우에는 단점이 발생한다는 것이다. (단, 참조 경로 최적화 등을 적용할 가능성은 있다.)

또한, ODBMS는 많은 도구 및 기능과의 상호 운용성이 낮다는 점도 불리하게 작용하는 요소로 꼽힌다. RDBMS는 상호 운용성을 가진 다양한 도구와 기능을 제공한다. 예를 들어, RDBMS는 데이터베이스와 애플리케이션 소프트웨어 간의 연결을 위한 업계 표준(JDBC, ODBC)을 지원하며, 보고서 작성 도구, OLAP 도구, 백업 및 복구 표준 등이 존재한다. 반면, ODBMS는 RDBMS와 달리 형식화된 수학적 기반이 없어, 데이터 조작 언어 지원에 불리하게 작용한다는 비판도 있다. 그러나 현재는 이러한 비판이 반드시 타당하지만은 않다. 일부 ODBMS 구현에서는 네비게이션 접근 외에도 완전한 SQL을 통한 접근을 제공하기도 한다.

객체 지향에서의 캡슐화 개념과 많은 데이터베이스 기술의 기본 전제 사이에는 본질적으로 불일치하는 부분이 존재한다. 객체 지향 캡슐화에서는 객체 데이터가 은폐되어 객체가 공개하는 인터페이스(메서드)를 통해서만 조작 가능하다. 반면, 데이터베이스 기술은 데이터베이스 구축 시점에 미리 예상한 접근 경로뿐만 아니라, 예상하지 못했던 접근 경로를 통한 데이터 접근도 가능해야 한다는 전제를 가진다. 데이터베이스 중심 관점은 사물을 선언적으로 인식하는 경향이 있는 반면, 객체 지향 관점은 사물을 여러 객체의 동적인 행위로 인식하는 경향이 있다. 이러한 관점 차이는 객체 지향과 데이터베이스 간 임피던스 불일치의 일부이다.

일부에서는 객체 데이터베이스 기술이 실패했다는 견해를 제시하기도 한다.

6. 2. 과제

벤치마크를 통한 성능 비교에서 일부 처리 형태에서 ODBMS가 RDBMS보다 분명히 뛰어난 성능을 보여주고 있다. 그 주된 이유는 ODBMS가 많은 처리를 선언적 지시가 아닌 네비게이션 지시를 기반으로 실행하기 때문이다. 객체 데이터베이스에 대한 네비게이션 액세스는 대부분의 경우 참조를 따라 대상 데이터(객체)를 획득하는 성능 측면에서 유효한 방법으로 구현된다[23]

ODBMS와 같은 네비게이션 데이터베이스의 DBMS에 대한 비판으로, 참조를 따라 데이터에 액세스하는 기법은 특정 "탐색 경로" 또는 시점에 최적화되어 있다는 의견이 있다. 이 의견에 따르면, 범용적인 데이터 조작 언어(ODMG가 제정한 객체 질의 언어 등)에 의한 데이터 액세스를 수행하는 경우, ODBMS처럼 참조를 따라가는 기법은 RDBMS 등과 비교하면 처리 속도가 느리고, 데이터 조작 언어로 검색식을 작성하는 것도 쉽지 않다는 단점이 있다. 이처럼 ODBMS와 같은 네비게이션 DBMS에서는 데이터베이스 구축 시 예상했던 용도에 대해서는 액세스가 최적화되어 쉬워지지만, 이는 예상하지 못했던 다양한 용도로 액세스하는 경우의 단점을 희생한 후에 실현된다는 견해가 있다.

그 외 ODBMS에 불리하게 작용한다고 여겨지는 요소로는 많은 도구와 기능에 대해 상호 운용성이 낮은 점이 꼽힌다. RDBMS에서는 상호 운용성을 가진 많은 도구와 기능이 있다. 예를 들어 RDBMS에서는 데이터베이스와 애플리케이션 소프트웨어와의 연결에 대해 업계에서 표준화되어 있으며(JDBC 및 ODBC), 보고서 작성 도구 및 OLAP 도구가 있으며, 백업 및 복구의 표준이 있다. 또한 ODBMS에는 RDBMS와 달리 형식화된 수학적 기반이 없다. 수학적 기반이 없는 것이 ODBMS에서의 데이터 조작 언어 지원에 관해 불리하게 작용한다는 비판이 있다. 하지만 현재는 이러한 비판이 반드시 타당하지 않은 것으로 보인다.

일부 ODBMS 구현에서는 네비게이션 액세스 외에 완전한 SQL에 의한 액세스도 제공하고 있다.

실제로 객체 지향에서의 캡슐화 개념과 많은 데이터베이스 기술의 기본적인 전제 사이에는 본질적으로 불일치하는 부분이 있다. 객체 지향 캡슐화 개념에서는 객체 데이터가 은폐되어 있으며, 객체가 공개하는 인터페이스(메서드)를 통해서만 다룰 수 있다. 한편 데이터베이스 기술에서는 데이터베이스 구축 시 미리 데이터에 대한 액세스 경로를 예상해 두는 발상보다, 구축 시 예상하지 못했던 액세스 경로에 의한 데이터 액세스도 가능해야 한다는 전제가 있다. 데이터베이스 중심의 관점에서는 사물을 선언적인 시각으로 인식하는 경향이 있다. 이에 반해 객체 지향의 관점에서는 사물을 여러 객체의 동적인 행위로 인식하는 경향이 있다. 이러한 관점의 차이는 객체 지향과 데이터베이스 간의 임피던스 불일치의 일부이다.

일부 사람들은 객체 데이터베이스 기술이 실패했다는 견해를 가지고 있다.

하지만 많은 사람들은 객체 데이터베이스 기술의 본질적인 방향성은 현 시점에서도 유효하다고 생각한다. 현재도 객체 데이터베이스 기술을 포함하여 데이터베이스 기능을 밀접하게 객체 지향 프로그래밍 언어와 통합하려는 노력이 연구자 커뮤니티와 개발자 커뮤니티 모두에서 계속되고 있다.

참조

[1] 웹사이트 Data Integration Glossary http://knowledge.fhw[...] U.S. Department of Transportation 2001-08
[2] 웹사이트 ODBMS.ORG :: Object Database (ODBMS) | Object-Oriented Database (OODBMS) | Free Resource Portal http://odbms.org/Int[...] 2013-08-31
[3] 서적 Management Information Systems McGraw-Hill/Irwin 2009
[4] 논문 Three example references from 1985 that use the term
[5] 서적 Introduction to Object-Oriented Databases The MIT Press 1990
[6] 서적 Building an Object-Oriented Database System: The Story of O2 Morgan Kaufmann Publishers 1992
[7] 간행물 TORNADO: a DBMS for CAD/CAM systems 1981-07
[8] 웹사이트 SpringSource to Acquire Gemstone Systems Data Management Technology https://web.archive.[...] WMware 2014-08-05
[9] 웹사이트 GemTalk Systems Acquires GemStone/S Products from VMware https://web.archive.[...] PRWeb 2014-08-05
[10] 웹사이트 restructuring our Versant Community Website http://supportservic[...]
[11] 웹사이트 Realm Releases Object Database for Node.js https://www.infoq.co[...]
[12] 웹사이트 Object Database Ranking on DB-Engines https://db-engines.c[...] 2021-05-21
[13] 웹사이트 Stanford Linear Accelerator (SLAC) https://www.service-[...]
[14] 서적 Addendum to the proceedings on Object-oriented programming systems, languages, and applications (Addendum) - OOPSLA '92
[15] 웹사이트 BaseX XQuery Processor https://basex.org/ba[...]
[16] 웹사이트 XQuery in eXist-db https://exist-db.org[...]
[17] 웹사이트 Saxon - Using XQuery https://www.saxonica[...]
[18] 웹사이트 PostgreSQL: Documentation: 10: 9.15. JSON Functions and Operators https://www.postgres[...]
[19] 간행물 So what the Hell is ODBMS?
[20] 간행물 OODBMSs gaining MIS ground but RDBMSs still own the road 1994
[21] 서적 Introduction to Object-Oriented Databases The MIT Press 1990
[22] 서적 Building an Object-Oriented Database System: The Story of O2 Morgan Kaufmann Publishers 1992
[23] 웹사이트 オブジェクトデータベースがどのように動くかを示すアニメーション http://www.service-a[...]
[24] 서적 Object Storage Fact Books: Object DBMSs and Object-Relational Mapping http://www.barryanda[...] Barry & Associates, Inc. 2001
[25] 웹사이트 Data Integration Glossary http://knowledge.fhw[...] U.S. Department of Transportation 2001-08
[26] 웹사이트 ODBMS.ORG :: Object Database (ODBMS) | Object-Oriented Database (OODBMS) | Free Resource Portal http://odbms.org/Int[...] 2013-08-31



본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.

문의하기 : help@durumis.com