관계형 모델에서 객체‑관계형 모델로의 진화

Source: Dev.to

번역하려는 전체 텍스트를 제공해 주시면, 요청하신 대로 한국어로 번역해 드리겠습니다.

소개

데이터베이스의 역사는 크게 수학적 엄밀성, 계산 효율성, 그리고 소프트웨어 개발의 실용적 요구 사이의 균형을 맞추려는 시도의 연속이라고 할 수 있습니다. 1970년대 초에 Edgar F. Codd가 관계형 모델을 제안했을 때, 그는 그 당시 널리 사용되던 계층형 및 네트워크형 시스템에 대한 구조적이고 형식적인 대안을 제시했습니다. 관계형 모델은 집합 이론과 술어 논리에 기반한, 데이터를 테이블 형태로 조직하는 단순하면서도 강력한 방식을 도입했습니다. SQL이 표준 언어로 정착하면서 관계형 데이터베이스 관리 시스템(RDBMS)은 수십 년 동안 기업 시스템의 중추가 되었습니다.

하지만 이후 몇 십 년 동안 Java와 C++ 같은 언어를 중심으로 객체 지향 프로그래밍이 보편화되면서, 관계형 모델과 객체 지향 모델 사이의 구조적 불일치라는 새로운 과제가 등장했습니다. 이 현상은 Impedance Mismatch 라고 불리며, 객체 지향 데이터베이스와 이후 등장한 객체‑관계형 시스템의 주요 촉매제가 되었습니다.

이 전환 과정을 이해하는 것은 현대 시스템인 PostgreSQL이 왜 객체‑관계형으로 분류되는지, 그리고 이 접근 방식이 원래 모델의 파괴가 아니라 진화임을 파악하는 데 필수적입니다.

임피던스 문제

소위 Impedance Mismatch는 두 개의 매우 다른 패러다임 사이에 존재하는 개념적 마찰을 설명합니다.

• 관계형 모델 – 행과 열로 구성된 테이블에 정보를 조직하고, 관계 대수에 기반한 선언적 연산을 통해 데이터를 조작합니다.
• 객체 지향 패러다임 – 클래스, 객체, 상속, 캡슐화, 고유 식별자를 중심으로 시스템을 구조화합니다.

문제는 객체가 테이블에 자연스럽게 들어맞지 않는다는 점에서 발생합니다. 객체 지향 언어에서는 각 인스턴스가 내부 값과 무관한 고유한 식별자를 가집니다. 반면 관계형 모델에서는 식별자가 기본 키로 표현됩니다. 또한 객체는 중첩 구조, 컬렉션, 메서드, 직접 참조 관계 등을 포함할 수 있지만, 관계형 데이터베이스는 스칼라 타입과 외래 키 및 조인 연산으로 모델링된 관계만을 다룹니다.

이러한 구조적 차이로 인해 개발자들은 객체를 레코드로, 레코드를 객체로 변환하는 중간 계층을 만들어야 했습니다. 이 매핑 과정은 기능적으로는 가능했지만 다음과 같은 부작용을 초래했습니다.

• 추가적인 복잡성
• 코드 양 증가
• 성능 문제 가능성

이 부담에 대한 불만은 OODBMS(Object‑Oriented Database Management System)의 등장을 촉발했습니다. OODBMS는 객체를 네이티브하게 저장하도록 설계되어, 변환 없이도 객체의 구조적 특성을 그대로 보존합니다.

객체 지향 데이터베이스는 임피던스 불일치 문제를 완전히 제거하려는 목표를 가졌습니다. 여기서는 객체가 고유 식별자, 상속, 직접적인 관계와 함께 영속화됩니다. 복잡한 계층 구조나 그래프 형태의 데이터를 많이 사용하는 애플리케이션에 대해 모델링이 보다 자연스러워졌습니다. 그러나 개념적 우아함에도 불구하고 다음과 같은 실용적 어려움에 직면했습니다.

• SQL에 상응하는 보편적인 표준 부재
• 쿼리 최적화 메커니즘의 미성숙
• 특정 프로그래밍 언어에 대한 강한 의존성

이미 관계형 인프라에 막대한 투자를 해 놓은 기업 시장은 기존 생태계를 포기하기를 꺼려했습니다. 따라서 관계형 모델을 완전히 대체하기보다는 확장하는 방향으로 산업이 움직였습니다.

통합: ORDBMS의 등장

답은 관계형 모델을 배제하는 것이 아니라 진화시키는 것이었습니다. 이렇게 해서 ORDBMS(Object‑Relational Database Management Systems), 즉 객체‑관계형 데이터베이스 관리 시스템이 등장했습니다. ORDBMS는 기존의 SQL과 전통적인 관계형 기반을 유지하면서도 객체 지향적인 기능을 추가했습니다.

as incorporavam mecanismos de extensibilidade inspirados na orientação a objetos.

Essa abordagem permitiu que os bancos de dados continuassem organizados em tabelas e consultas declarativas, mas agora com suporte a:

• Tipos definidos pelo usuário
• Estruturas compostas
• Arrays
• Dados semiestruturados (JSON, XML)
• Funções personalizadas

Em vez de eliminar o SQL, os ORDBMS o expandiram.

O PostgreSQL tornou‑se um dos exemplos mais expressivos dessa filosofia. Embora preserve integralmente o modelo relacional, ele oferece suporte a tipos complexos, herança de tabelas, operadores customizados e extensões que ampliam drasticamente suas capacidades. Essa integração entre estabilidade relacional e flexibilidade estrutural é o que caracteriza a natureza objeto‑relacional.

RDBMS, OODBMS 및 ORDBMS 비교

PostgreSQL 아키텍처와 “Catalogue‑Driven” 개념

PostgreSQL의 가장 눈에 띄는 특징 중 하나는 catalogue‑driven 시스템으로 설명된다는 점입니다. 이 표현은 데이터베이스 내부의 거의 모든 구성 요소가 자체 시스템에 저장된 메타데이터 테이블을 통해 기술된다는 의미입니다.

• 데이터 타입, 연산자, 함수, 인덱스, 확장 등이 카탈로그에 정의되고 기록됩니다.

• 이 접근 방식은 두 가지 큰 장점을 제공합니다:

  1. 확장성 – 새로운 타입, 함수 또는 연산자는 카탈로그에 행을 삽입하거나 자동으로 수행되는 확장을 만들기만 하면 추가할 수 있습니다.
  2. 내부 일관성 – 옵티마이저와 쿼리 실행기는 타입, 비용, 전략 정보를 얻기 위해 동일한 카탈로그를 조회하므로 예측 가능한 동작을 보장합니다.

요약하면, “catalogue‑driven” 모델은 PostgreSQL이 모듈식으로 진화하면서 전통적인 관계형 데이터베이스 시스템이 갖는 일관성과 견고함을 유지하도록 합니다.

PostgreSQL 내부 확장성

이는 데이터베이스가 자체 관계형 모델을 사용해 내부 구조를 기술한다는 의미입니다. 코드에 하드코딩된 고정 정의에 의존하는 대신, 시스템은 자체 카탈로그를 조회해 타입, 연산자 및 구조를 어떻게 해석해야 하는지 파악합니다.

이 설계 선택은 매우 중요한 의미를 갖습니다. 개발자는 데이터베이스를 재컴파일할 필요 없이 새로운 데이터 타입과 함수를 만들 수 있습니다. 해당 정의를 적절한 카탈로그에 등록하기만 하면 시스템이 자동으로 이를 환경의 일부분으로 인식합니다.

이러한 확장성은 예를 들어 다음과 같은 분야에 특화된 도메인을 만드는 것을 가능하게 합니다:

• 지리 처리
• 과학적 분석
• 반구조화 데이터 처리

PostGIS와 같은 확장은 핵심 시스템을 수정하지 않고도 고급 공간 연산을 완전히 지원하도록 하는 능력을 보여줍니다. 데이터베이스 자체는 그대로이지만, 내부에 카탈로그화된 레코드를 통해 기능이 확장됩니다.

이 접근 방식은 PostgreSQL이 복합 타입을 제공하는 것뿐만 아니라, 확장성을 근본 원칙으로 설계된 객체‑관계형 시스템이라는 점을 강조합니다. 데이터베이스는 단순히 데이터 저장소가 아니라, 적응 가능한 플랫폼입니다.

결론

관계형 모델에서 객체‑관계형 모델로의 진화는 급격한 대체로 해석되어서는 안 되며, 기술 성숙도의 점진적인 과정으로 보아야 합니다. 관계형 모델은 데이터 관리에 혁신을 가져온 견고한 이론적 기반과 표준화된 언어를 제공했습니다. 객체 지향은 애플리케이션 구축 방식을 변화시켰으며, 두 패러다임 간 통합의 한계를 드러냈습니다.

OODBMS의 등장은 관계형 모델을 배제함으로써 갈등을 해결하려는 시도였습니다. 그러나 ORDBMS의 하이브리드 접근 방식이 더 지속 가능함이 입증되었습니다. SQL과 테이블 구조를 유지하면서도 확장 및 복합 타입을 허용함으로써, 이러한 시스템은 안정성과 유연성을 동시에 확보했습니다.

PostgreSQL은 이러한 통합을 명확히 보여줍니다. 카탈로그 기반 아키텍처와 재컴파일 없이 확장할 수 있는 능력은 기존의 확고한 기반을 포기하지 않고도 진화할 수 있음을 증명합니다. 따라서 역사적 전환은 파괴가 아니라 아이디어의 점진적 통합이었으며, 이는 소프트웨어 공학 자체의 발전과 보다 표현력 있고 적응 가능하며 현대 개발 관행에 부합하는 데이터 시스템에 대한 증가하는 요구를 반영합니다.