System R: Relational Approach to Database Management

ono·2025년 10월 23일
Data EngineerDatabase

Paper

목록 보기
3/3

System R: 관계형 데이터베이스의 기술적 기원과 구조적 혁신

1. 서론 — 관계형 데이터 모델의 실현을 향한 시도

1970년대 초반, 데이터베이스 관리 시스템(DBMS)은 대부분 계층형(IMS) 또는 네트워크형(DBTG) 모델을 따랐습니다.
이러한 시스템은 개발자에게 높은 제어권을 제공했지만, 데이터의 구조적 의존성이 강해 응용 프로그램 변경 시마다
데이터 접근 코드를 수정해야 하는 문제가 있었습니다.

1970년 Edgar F. Codd는 논문 “A Relational Model of Data for Large Shared Data Banks”를 통해
데이터베이스의 새로운 패러다임을 제시했습니다.
그 핵심은 데이터 독립성(Data Independence) 과 관계형 표현(Relational Representation) 이었습니다.

즉, 데이터는 튜플(Tuple) 과 릴레이션(Relation) 으로 표현되어야 하며,
사용자는 데이터를 논리적 수준에서 다루어야 한다는 개념이었습니다.

그러나 이 이론은 당시 기술 수준에서 “현실적으로 구현이 불가능하다” 는 평가를 받았습니다.
이에 IBM 산호세 연구소는 1974년 System R 프로젝트를 시작하여,
Codd의 이론이 실제 시스템으로 구현 가능한지를 검증하고자 하였습니다.

System R은 연구용 실험 시스템이었지만,
그 결과는 현대 관계형 데이터베이스(RDBMS) 의 기술적 기초를 확립하는 계기가 되었습니다.

2. System R의 설계 철학 — 선언적 데이터 처리와 독립성의 추구

System R의 설계 목표는 단순히 새로운 DBMS를 만드는 것이 아니라,
관계형 모델의 핵심 철학을 실질적으로 구현하는 것이었습니다.

2.1 데이터 독립성(Data Independence)

System R은 응용 프로그램이 데이터의 물리적 구조로부터 완전히 독립되도록 설계되었습니다.
즉, 인덱스 구조, 저장 포맷, 페이지 배치 등이 변경되더라도 응용 프로그램의 SQL 코드는 영향을 받지 않습니다.

이를 위해 System R은 3단계 데이터 독립성 구조를 채택했습니다.

계층역할System R 구성요소
외부 (External)사용자 관점의 뷰(View) 정의SEQUEL DEFINE VIEW
개념 (Conceptual)논리적 스키마 관리 및 카탈로그RDS Catalog Manager
내부 (Internal)물리적 저장 및 인덱스 관리RSS (Relational Storage System)

2.2 비절차적 질의 언어 (Non-Procedural Language)

System R의 두 번째 설계 철학은 “무엇(What)”을 정의하고 “어떻게(How)”는 시스템이 결정한다는 것입니다.
즉, 사용자는 데이터를 검색하거나 수정할 때 절차를 기술하지 않고,
SEQUEL(Structured English QUEry Language) 로 명세만 제공하면 됩니다.

이 접근 방식은 쿼리 옵티마이저(Query Optimizer) 의 도입을 필연적으로 요구했습니다.
System R은 최초로 비용 기반 최적화(Cost-Based Optimization)를 도입하여
다양한 인덱스 경로 중 가장 효율적인 방법을 자동으로 선택했습니다.

2.3 트랜잭션의 원자성 및 일관성(Atomicity and Consistency)

System R은 관계형 모델의 이론을 “현실적인 시스템 보장” 으로 확장했습니다.
즉, 데이터 갱신 중 시스템이 중단되거나 동시에 여러 사용자가 접근해도
데이터의 일관성이 깨지지 않도록 보장했습니다.

이를 위해 System R은 다음 세 가지 구조를 도입했습니다.

  1. 트랜잭션 경계 – BEGIN TRANS / END TRANS 명령으로 트랜잭션 단위를 명시했습니다.
  2. 로그 기반 복구 (Logging & Recovery) – Write-Ahead Logging 기법을 사용했습니다.
  3. 락킹(Locking) – 다중 사용자 환경에서 동시성 제어를 수행했습니다.

이러한 기법들은 후대 DBMS 의 ACID 모델 (Atomicity, Consistency, Isolation, Durability) 로 정립되었습니다.

3. System R의 전체 시스템 아키텍처

System R은 두 개의 핵심 서브시스템으로 구성되었습니다:
Relational Data System (RDS) 와 Relational Storage System (RSS) 입니다.

3.1 RDS 와 RSS 의 관계

RDS는 SQL 명령을 해석하고 최적화하여 RSS로 전달하며,
RSS는 데이터를 물리적으로 저장하고 트랜잭션을 관리합니다.

즉, RDS는 논리적 데이터 처리 레이어, RSS는 물리적 저장 및 복구 레이어 역할을 수행합니다.

사용자 (SEQUEL/SQL)
        │
        ▼
  RDS (Relational Data System)
    ├─ Parser / Optimizer
    ├─ Authorization / Integrity
    └─ Catalog Manager
        │
        ▼
  RSS (Relational Storage System)
    ├─ Access Method (Images, Links)
    ├─ Transaction Manager
    └─ Logging & Recovery

이러한 아키텍처는 오늘날 모든 RDBMS (예: Oracle, PostgreSQL, DB2, MySQL) 의 기본 구조가 되었습니다.

3.2 VM/370 환경과 멀티유저 지원

System R은 IBM 의 VM/370 가상화 환경 위에서 동작했습니다.
사용자마다 별도의 “Database Machine” (가상 머신 단위)을 할당받았으며,
각 머신은 데이터 공유를 위해 공유 가상 메모리(Shared Virtual Memory) 와
프로세서 인터럽트 기반 통신 을 사용했습니다.

이는 오늘날 멀티스레드 DBMS 의 전신이라 볼 수 있습니다.
특히 System R은 단일 서버 모델(single server) 이 아닌 분산형 멀티 데이터베이스 머신 모델을 채택하여,
동시성 및 확장성을 실험적으로 입증했습니다.

4. Relational Data System (RDS) — SQL 논리 계층의 기술 기반

RDS는 System R의 상위 모듈로, 사용자가 데이터를 정의하고(DDL), 질의하며(SELECT), 조작(DML) 할 수 있도록 제공했습니다.
또한, 권한 관리(DCL), 무결성 제약, 트리거 (trigger) 등의 기능도 담당했습니다.

4.1 SEQUEL 언어의 구조

RDS는 SEQUEL(Structured English Query Language) 을 기반으로 동작했습니다.
이는 현재의 SQL의 직접적인 전신으로, 아래와 같은 형태로 사용되었습니다.

SELECT NAME, SAL
FROM EMP
WHERE DNO = 50 AND JOB = 'PROGRAMMER';

SEQUEL은 당시로서는 혁명적인 언어였습니다. 그 이유는 다음과 같습니다.

  1. JOIN 구문 표준화 – FROM EMP X, EMP Y WHERE X.MGR = Y.EMPNO 형태의 대칭적 조인 표현 도입
  2. GROUP BY / HAVING 절 – 집계 및 그룹 조건을 명시적으로 구분
  3. ORDER BY – 결과 정렬 지원
  4. UNIQUE 키워드 – 중복 제거 기능 도입

이러한 문법은 1970년대 다른 시스템(IS/1, XRM, INGRES)과 달리,
비절차적 관계 대수식을 사용자 친화적인 문장 구조로 변환했습니다.

4.2 호스트 언어 인터페이스

System R은 단순한 대화형 쿼리 시스템이 아니라,
호스트 언어(PL/I 등) 에서 데이터베이스를 조작할 수 있는 API 를 제공했습니다.

이때 사용된 핵심 개념이 Cursor (커서) 입니다.
커서는 쿼리 결과 집합(active set)을 참조하며, 각 튜플을 순차적으로 읽거나 갱신할 수 있습니다.

예를 들면 다음과 같습니다.

CALL BIND('X', ADDR(X));
CALL SEQUEL(C1, 'SELECT NAME:X, SAL:Y FROM EMP WHERE JOB = "PROGRAMMER"');
CALL FETCH(C1);

이 커서 기반 모델은 현대 JDBC, ODBC, SQL Embedded API 의 기초가 되었습니다.

4.3 데이터 정의 및 뷰(View) 지원

System R은 데이터 정의(DDL) 도 완전하게 지원했습니다.
예를 들면 다음과 같습니다.

CREATE TABLE EMP (
  EMPNO INTEGER,
  ENAME CHAR(20),
  JOB CHAR(10),
  SAL DECIMAL(10,2),
  DNO INTEGER
);

또한, 뷰(View) 를 정의할 수 있었으며, 이는 데이터 독립성의 핵심 수단이었습니다.

DEFINE VIEW VEMP AS
SELECT ENAME, SAL
FROM EMP
WHERE DNO = 50;

뷰는 기존 테이블을 기반으로 생성되는 가상 릴레이션으로,
업데이트가 가능한 경우(단일 베이스 릴레이션, 1:1 매핑)에는 수정 연산도 지원했습니다.

5. 쿼리 최적화기 (Query Optimizer) — 비용 기반 접근의 시작

System R의 가장 혁신적인 구성요소 중 하나는 쿼리 최적화기(Optimizer)입니다.
이는 사용자가 작성한 SEQUEL 문장을 해석하여 가장 효율적인 실행 경로(Access Path)를 자동으로 결정하는 역할을 담당했습니다.

5.1 최적화기의 설계 목적

기존의 데이터베이스 시스템(예: IMS, CODASYL)은 사용자가 데이터를 접근하는 절차적 경로를 명시해야 했습니다.
하지만 System R은 사용자가 “무엇을 원하느냐”만 정의하면,
시스템이 내부적으로 최적의 접근 계획을 선택하도록 설계되었습니다.

따라서 최적화기의 핵심 목표는 다음과 같습니다.

  1. 비용 최소화 (Cost Minimization) – 디스크 페이지 접근 수를 최소화
  2. 데이터 접근 투명성 (Data Access Transparency) – 물리적 저장 구조로부터 사용자 코드 분리
  3. 자동 경로 선택 (Access Path Selection) – 인덱스, 릴레이션 스캔, 조인 등의 다양한 경로 중 최소 비용 선택

5.2 최적화 과정의 단계별 구조

System R 최적화기의 작동 흐름은 다음 네 단계로 구성되었습니다.

  1. 쿼리 분석 (Parsing & Classification)
    SEQUEL 문장을 구문 분석하여 구문 트리를 생성하고, 쿼리 유형(SELECT, JOIN, GROUP 등)을 분류합니다.

  2. 후보 접근 경로 탐색 (Access Path Enumeration)
    가능한 인덱스(Images), 릴레이션 스캔, 또는 조인 순서(Join Order) 조합을 생성합니다.

  3. 비용 평가 (Cost Estimation)
    각 후보 경로에 대해 다음과 같은 비용 함수를 계산합니다.

    [
    C = P{I/O} + H \times C{CPU}
    ]

    • ( P_{I/O} ): 예상 디스크 페이지 접근 수
    • ( C_{CPU} ): 튜플 비교 및 필터링 비용
    • ( H ): CPU 비용 가중 계수

    즉, 디스크 접근이 주요 병목이던 시절,
    I/O 횟수를 최소화하는 것이 최적화의 중심 목표였습니다.

  4. 최적 계획 선택 (Plan Selection)
    모든 후보의 비용을 비교하여 최소 비용 경로를 선택하고,
    Optimized Package (OP) 형태로 실행 계획을 저장합니다.
    뷰(View) 정의의 경우에는 Pre-Optimized Package (POP) 로 저장되어 재사용이 가능했습니다.

5.3 예시: 단일 릴레이션 쿼리 최적화

다음 SEQUEL 문장을 고려해봅시다.

SELECT NAME, SAL
FROM EMP
WHERE JOB = 'PROGRAMMER' AND SAL > 10000;

System R은 이 쿼리를 처리하기 위해 다음 8가지 접근 방법 중 하나를 선택했습니다.

방법접근 방식설명
1클러스터링 인덱스 + '='인덱스 키 값으로 직접 접근 (가장 효율적)
2클러스터링 인덱스 + '>'인덱스 순회 (범위 검색)
3비클러스터 인덱스 + '='랜덤 접근, 페이지 수 많음
4비클러스터 인덱스 + '>'랜덤 범위 접근
5클러스터링 인덱스 전체 스캔모든 튜플 탐색
6비클러스터 인덱스 전체 스캔높은 비용
7릴레이션 스캔페이지 전체 순회
8공유 세그먼트 스캔비용 불확실, 일반적으로 비효율적

최적화기는 시스템 카탈로그에 저장된 통계정보(튜플 수, 페이지 수, 인덱스 정보 등)를 기반으로
각 경로의 비용을 계산하고 최소 비용의 실행 계획을 선택했습니다.

이 방식은 이후 Selinger-style optimizer (1979) 로 발전하여
모든 현대 RDBMS의 기본 최적화 모델로 자리 잡았습니다.

5.4 조인 최적화 (Join Optimization)

System R은 이항 조인(binary join)을 기준으로 다양한 조인 전략을 실험했습니다.
논문에서 제시된 대표적 네 가지 방법은 다음과 같습니다.

방법설명
1. Index Merge Join조인 필드에 인덱스가 존재할 때, 두 릴레이션의 인덱스를 병합하여 매칭
2. Sort-Merge Join두 릴레이션을 조인 키로 정렬한 뒤, 병합하면서 조인 수행
3. Nested Loop Join외부 릴레이션의 각 튜플에 대해 내부 릴레이션 탐색
4. TID Join튜플 식별자(TID)를 이용해 인덱스 기반 조인 수행

System R은 조인 순서의 카르테시안 폭발(Cartesian Explosion) 을 방지하기 위해,
비용 기반 조인 순서 탐색 제한(Bounded Join Enumeration) 기법을 도입했습니다.

6. 트랜잭션 관리 및 복구 시스템

System R은 트랜잭션(Transactions)의 원자성(Atomicity) 과 복구성(Recoverability) 을 실험적으로 검증한 최초의 시스템 중 하나였습니다.

6.1 트랜잭션 모델

System R은 트랜잭션 단위를 명시적으로 정의했습니다.

BEGIN TRANS;
  UPDATE EMP SET SAL = SAL * 1.1 WHERE DNO = 50;
END TRANS;
  • BEGIN TRANS / END TRANS : 트랜잭션의 경계 정의
  • SAVE / RESTORE : 중간 복구 지점 설정
  • ENFORCE INTEGRITY : 트랜잭션 내부 무결성 검증 지점

6.2 Write-Ahead Logging (WAL)

모든 변경 로그는 실제 데이터 페이지 쓰기보다 먼저 기록되었습니다.
이를 통해 장애 발생 시 다음 두 단계로 복구할 수 있었습니다.

  1. UNDO – 커밋되지 않은 트랜잭션의 변경 사항을 되돌림
  2. REDO – 커밋된 트랜잭션의 변경 사항을 재적용

이 방식은 이후 ARIES 알고리즘 (IBM, 1992)의 기반이 되었습니다.

6.3 동시성 제어 (Concurrency Control)

System R은 다중 사용자 환경을 지원하기 위해 Lock-based Concurrency Control 을 채택했습니다.

락의 단위는 세 가지였습니다.

  1. Segment-level Lock
  2. Relation-level Lock
  3. Tuple-level Lock

락 충돌 시 Deadlock Detection 알고리즘이 주기적으로 실행되어 교착 상태를 해소했습니다.
이 접근법은 현대의 DB2, SQL Server, Oracle에서 사용하는 2-Phase Locking (2PL) 구조의 시초라 할 수 있습니다.

7. 데이터 제어 및 무결성 관리

System R은 단순한 데이터 저장 시스템이 아니라,
데이터 보안(Authorization), 무결성(Integrity), 트리거(Trigger) 기능까지 포함한 완전한 관리 시스템이었습니다.

7.1 권한 관리 (Authorization System)

사용자는 테이블 또는 뷰 단위로 세분화된 권한을 부여받을 수 있었습니다.

권한 유형설명
READ데이터 조회 권한
INSERT / DELETE / UPDATE데이터 변경 권한
DROP / EXPAND스키마 변경 권한
IMAGE / LINK인덱스 및 관계 정의 권한
CONTROL트리거 및 무결성 제약 정의 권한

각 권한은 다른 사용자에게 GRANT / REVOKE 할 수 있었습니다.
이는 SQL의 DCL(데이터 제어 언어)의 직접적인 기원입니다.

7.2 무결성 제약 (Assertions & Triggers)

System R은 데이터 무결성(Data Integrity) 을 보장하기 위해
사용자가 직접 제약 조건을 정의하고 자동으로 검사할 수 있도록 설계되었습니다.

예시: 직원의 급여가 5만 달러를 넘지 않도록 제한하는 제약

ASSERT ON EMP: SAL <= 50000;

또는, 데이터 변경 시 자동 실행되는 트리거 정의:

DEFINE TRIGGER EMPINS
ON INSERTION OF EMP:
(UPDATE DEPT SET NEMPS = NEMPS + 1 WHERE DNO = NEW EMP.DNO);

이러한 선언적 데이터 제어는 현대 SQL의
CHECK constraints, TRIGGER, FOREIGN KEY 의 전신이라 할 수 있습니다.

8. System R의 기술적 유산과 현대적 의의

System R은 상용 제품으로 출시되지 않았지만,
그 기술적 성과는 이후 관계형 데이터베이스 발전의 토대가 되었습니다.

System R 기술계승된 형태
SEQUEL 언어SQL (Structured Query Language)
Cost-Based OptimizerSelinger Optimizer (1979)
WAL 기반 복구ARIES 알고리즘
트랜잭션 제어ACID 모델
카탈로그 기반 스키마 관리System Catalog / Information Schema
권한 관리 및 뷰 기반 접근 제어SQL GRANT/REVOKE
선언적 무결성SQL Constraints / Triggers

특히 IBM DB2는 System R의 직접적인 후계로 개발되었으며,
Oracle, Ingres, Sybase, PostgreSQL 등 모든 현대 RDBMS가 그 설계 철학을 계승했습니다.

결론

System R은 관계형 데이터베이스의 이론을 실용으로 전환한 첫 성공 사례였습니다.
이 시스템은 SQL 언어, 트랜잭션 처리, 옵티마이저, 무결성 제어 등
오늘날 RDBMS의 모든 핵심 기술을 최초로 통합적으로 구현했습니다.

결국 System R은 “연구용 프로토타입” 이상의 존재였습니다.
그것은 데이터 관리 패러다임의 전환점이자,
현대 데이터베이스 기술의 기원점이었습니다.

profile
ono
이전 포스트

The Entity-Relationship Model-Toward a Unified View of Data

0개의 댓글