관계형 데이터베이스

이름 붙은 칸에 값을 채운 표들로 데이터를 적어 두는 데이터베이스입니다. 표와 표는 값을 맞춰서 이어 붙입니다. 어느 자리에 어떻게 저장돼 있는지는 꺼내는 쪽이 몰라도 됩니다.

상세

동아리 명부와 회비 장부가 따로 있습니다. 명부에는 학번과 이름이, 장부에는 학번과 낸 금액이 적혀 있습니다. 누가 얼마를 냈는지는 두 장부를 학번으로 맞춰 보면 나옵니다.

이름에 든 관계는 수학에서 쓰는 뜻 그대로입니다. Codd 는 1970년 논문에서 이렇게 적습니다. 집합 S1, S2, …, Sn 이 주어졌을 때, R 이 n-튜플의 집합이고 각 튜플의 첫 원소가 S1 에서, 둘째 원소가 S2 에서, 그런 식으로 온다면 R 은 이 n 개의 집합 위의 관계입니다. 논문은 각 집합을 그 관계의 도메인이라고 부릅니다. 원소가 n 개면 그 관계는 차수 n 을 가진다고 적습니다. 차수 1 은 단항, 2 는 이항, 3 은 삼항이라고 흔히 부른다고 덧붙입니다.

표는 이 관계를 눈에 보이게 그린 것입니다. 논문은 설명을 위해 관계의 배열 표현을 자주 쓰겠지만 이 특정 표현이 지금 펼치는 관계형 관점의 본질적인 부분은 아니라는 것을 기억해야 한다고 적습니다. 그러면서 n항 관계를 나타내는 배열의 성질 다섯을 답니다. 각 행은 R 의 n-튜플 하나를 나타냅니다. 행의 순서는 무의미합니다. 모든 행은 서로 다릅니다. 열의 순서는 유의미합니다. 열의 순서가 관계가 정의된 도메인들의 순서에 대응하기 때문입니다. 각 열의 의미는 대응하는 도메인의 이름을 그 열에 붙임으로써 부분적으로 전달됩니다.

관계 안에 있는 것은 도메인에서 온 값뿐입니다. 어느 파일 어느 위치에 놓였는지를 가리키는 자리도, 다음 레코드로 건너가는 사슬도 관계 자체에는 들어가지 않습니다. 그래서 저장 방식이 바뀌어도 단말에서 하는 일과 대부분의 응용 프로그램은 영향을 받지 않아야 합니다. 같은 논문의 초록이 이 자리를 못 박습니다. 앞으로 큰 데이터 뱅크를 쓸 사람들은 데이터가 기계 안에 어떻게 조직돼 있는지를 알아야만 하는 처지에서 보호받아야 한다고 적습니다.

배경

이전에도 데이터를 모아 두는 시스템은 있었습니다. Codd 의 논문은 그때의 형식화된 데이터 시스템 상당수가 사용자에게 트리 구조 파일이나 그보다 조금 더 일반적인 데이터의 네트워크 모델을 내준다고 적습니다. 그런 시스템에 맞춰 개발된 응용 프로그램은 그 트리나 네트워크의 구조가 바뀌면 논리적으로 망가지는 경향이 있다고 적습니다. 논문은 이 대목에 접근 경로 의존이라는 이름을 붙입니다.

flowchart TD
    subgraph 이전
        A[응용 프로그램] -->|구조를 알고 길을 따라| B[트리·네트워크]
        B --> C[레코드]
    end
    subgraph 관계형
        D[응용 프로그램] -->|무엇을 원하는지만| E[관계]
    end

길을 아는 쪽이 프로그램이었습니다. Bachman 은 1973년 튜링상 강연에서 그 그림을 그대로 적습니다. 데이터 처리를 하는 사람들이 근본적으로 새로운 관점을 받아들이면 득을 볼 것이라는 느낌이 커지고 있다고 적습니다. 응용 프로그래머의 사고를 코어 저장소 중심주의에서 해방시키고 데이터베이스 안의 항해자로 행동할 자유를 주는 관점이라고 적습니다. 그러려면 프로그래머는 먼저 여러 항해 기술을 익혀야 하고, 다른 프로그래머들과 함께 데이터베이스 정보 공간을 항해하면서 충돌을 피하기 위한 도로 규칙도 배워야 한다고 적습니다.

필요한 것은 그 길을 몰라도 되는 방식이었습니다. Codd 의 논문은 자기가 다루는 문제를 데이터 독립성이라고 부릅니다. 응용 프로그램과 단말 활동이 데이터 종류의 증가와 데이터 표현의 변화로부터 독립인 것입니다. 데이터를 값들의 대응으로만 적으면 따라갈 길이 사라집니다. 남는 것은 어느 값이 어느 값과 짝이 되느냐뿐입니다. 그 대응을 부르는 수학 용어가 관계였고, 이름은 거기서 왔습니다.

예시

PostgreSQL 의 테이블

PostgreSQL 문서는 관계형 데이터베이스의 테이블이 종이 위의 표와 많이 닮았다고 적습니다. 행과 열로 이뤄집니다. 열의 개수와 순서는 고정이고 각 열은 이름을 갖습니다. 행의 개수는 가변이라고 적습니다. 어느 시점에 데이터가 얼마나 저장돼 있는지를 그 수가 반영합니다.

테이블을 만들 때는 새 테이블의 이름, 열들의 이름, 각 열의 데이터 타입을 적습니다.

CREATE TABLE products (
    product_no integer,
    name text,
    price numeric
);

세 열이 각각 무엇을 담을지가 이 한 벌로 정해집니다. product_no 는 정수, name 은 텍스트, price 는 수치입니다. 열이 값을 길어 오는 범위를 여기서는 열마다 붙은 데이터 타입이 정합니다.

행의 순서는 여기서도 없습니다. 문서는 SQL(Structured Query Language, 구조화 질의 언어)이 테이블 안 행의 순서에 대해 아무것도 보장하지 않는다고 적습니다. 테이블을 읽으면 정렬을 명시적으로 요청하지 않는 한 행들이 지정되지 않은 순서로 나타난다고 적습니다.

PostgreSQL 의 외래 키

값이 다른 표를 가리키는 자리가 외래 키입니다. 문서는 외래 키 제약이 한 열 또는 여러 열의 값들이 다른 테이블 어떤 행에 나타나는 값들과 일치해야 한다고 명시하는 것이라고 적습니다. 이것이 관련된 두 테이블 사이의 참조 무결성을 유지한다고 적습니다.

CREATE TABLE products (
    product_no integer PRIMARY KEY,
    name text,
    price numeric
);

CREATE TABLE orders (
    order_id integer PRIMARY KEY,
    product_no integer REFERENCES products (product_no),
    quantity integer
);

orders 의 product_no 열에 붙은 REFERENCES products (product_no) 한 줄이 그 제약입니다. 문서는 이제 products 테이블에 나타나지 않는 널이 아닌 product_no 값으로 주문을 만드는 것이 불가능하다고 적습니다. 이 상황에서 orders 는 참조하는 테이블, products 는 참조되는 테이블이라고 부릅니다.

두 테이블을 잇는 것은 위치가 아니라 값입니다. orders 의 어느 행이 products 의 몇 번째 행에 놓여 있는지는 어디에도 적혀 있지 않습니다. 같은 값이 양쪽에 있다는 것만 적혀 있습니다.

SQLite 의 파일 한 개

이 모델이 서버 프로세스를 전제하지 않는 자리도 있습니다. SQLite 문서는 자기를 자기완결적이고 서버가 없으며 설정이 필요 없는 트랜잭션 SQL 데이터베이스 엔진을 구현한 인프로세스 라이브러리라고 적습니다. 대부분의 다른 SQL 데이터베이스와 달리 별도의 서버 프로세스를 갖지 않는다고 적습니다. 보통의 디스크 파일에 직접 읽고 씁니다. 여러 테이블과 인덱스, 트리거, 뷰를 갖춘 완전한 SQL 데이터베이스가 디스크 파일 하나에 담긴다고 적습니다.

경계

SQL 테이블과 관계

SQL 로 다루는 테이블은 논문이 말하는 관계인가. 그대로는 아닙니다. 논문이 든 배열의 성질 셋째는 모든 행이 서로 다르다는 것이었습니다. SQL 테이블은 그렇지 않습니다. PostgreSQL 문서는 SQL 이 행에 고유 식별자를 부여하지 않아서 완전히 동일한 행이 한 테이블에 여러 개 있는 것이 가능하다고 적습니다. 이것이 SQL 의 바탕에 있는 수학적 모델의 결과이지만 보통은 바람직하지 않다고 덧붙입니다.

질의에서도 갈립니다. 문서는 SELECT DISTINCT 가 결과에서 중복 행을 제거한다고 적습니다. 기본값인 SELECT ALL 은 중복을 포함해 모든 후보 행을 반환한다고 적습니다. 중복을 없애는 쪽이 기본이 아니라 요청하는 쪽입니다.

그러니 관계형이라는 이름은 이 모델을 바탕으로 삼는다는 뜻입니다. 모델의 성질을 전부 그대로 지킨다는 뜻은 아닙니다.

자료형별로 나뉜 저장소

데이터가 종류별로 나뉘어 담기면 관계형인가. 아닙니다. 가르는 선은 담는 모양이 아니라 값의 대응입니다. Redis 문서는 자기를 자료구조 서버라고 적습니다. 핵심에서 캐싱부터 큐잉, 이벤트 처리까지 갖가지 문제를 푸는 데 도움이 되는 네이티브 자료형 모음을 제공한다고 적습니다. 그리고 자기 데이터 모델을 설명하며 문자열·해시·리스트·집합·정렬된 집합·스트림 같은 자료형 이름을 늘어놓습니다.

한 값이 다른 레코드를 가리키게 하고 그 대응을 질의가 이어 붙이는 자리는 이 설명에 없습니다. 앞의 외래 키가 그 자리였습니다. 데이터를 종류별로 나눠 담는다는 것만으로는 이 선을 넘지 않습니다.

관련 항목

이 모델을 이루는 구성 요소

관계 · 도메인 · 튜플 · 차수 · 테이블 · 행 · 열 · 데이터 타입 · 기본 키 · 외래 키 · 제약조건 · 스키마 · 뷰 · 인덱스 · 트리거

관계를 다루는 질의 수단

SQL · 관계 대수 · 질의 · 조인 · 실행 계획

이것이 지키는 성질

참조 무결성 · 데이터 독립성 · 정규화 · 트랜잭션

이것이 비롯된 배경

계층형 모델 · 네트워크 모델 · 접근 경로 의존 · 레코드

같은 자리를 두고 겨루는 저장 방식

키-값 저장소 · 문서 저장소 · 자료구조 서버

이것을 실제로 구현·채택한 제품

관계형 데이터베이스 관리 시스템 · PostgreSQL · SQLite · Oracle Database