데이터베이스

오래 남기려고 모아 둔 데이터입니다. 한 프로그램이 자기 안에만 들고 있는 것이 아닙니다. 여러 프로그램이 함께 쓰도록 정리해 둡니다. 프로그램이 꺼져도 그 자리에 남습니다.

상세

집집마다 책을 쌓아 두는 대신 한 건물에 모아 둡니다. 여럿이 거기서 빌려 봅니다. 어느 서가 몇 번째 칸에 꽂혀 있는지는 찾는 사람이 몰라도 됩니다.

데이터베이스는 여러 프로그램이 함께 쓰도록 체계적으로 정리해 오래 남기는 데이터 모음입니다. 데이터가 주인공입니다. 그 데이터를 만든 프로그램은 주인공이 아닙니다.

프로그램 안의 자료구조와 갈리는 자리가 셋 있습니다. 첫째, 프로그램이 끝나도 남습니다. 메모리에 잡아 둔 배열은 프로세스가 죽으면 같이 사라집니다. 데이터베이스는 그다음 프로그램이 이어서 봅니다. 둘째, 여럿이 동시에 봅니다. 그래서 누가 무엇을 언제 볼 수 있는지를 정하는 규칙이 따라붙습니다. 셋째, 어떻게 저장돼 있는지 몰라도 꺼낼 수 있습니다. 무엇을 원하는지만 적으면 됩니다. 어느 파일 어느 위치에서 읽어 올지는 쓰는 쪽이 정하지 않습니다.

데이터를 다루는 소프트웨어는 데이터베이스 자체가 아닙니다. 그쪽은 데이터베이스 관리 시스템(Database Management System, DBMS)이라고 따로 부릅니다. 데이터베이스는 담긴 것입니다. 관리 시스템은 담는 일을 맡은 프로그램입니다. 낱말 하나가 둘을 함께 가리키는 자리는 흔합니다. 그래도 정의는 담긴 쪽에 붙습니다.

배경

프로그램마다 자기 파일을 따로 들고 있던 시절이 있었습니다. 같은 사람의 이름이 프로그램 수만큼 여러 벌로 갈립니다. 저장 방식도 프로그램 안에 박혀 있습니다. 데이터를 기계 안에 어떻게 늘어놓을지 바꾸면 그것을 읽던 프로그램을 다시 짜야 했습니다. Codd 는 1970년 논문에서 이 자리를 못 박습니다. 앞으로 큰 데이터 뱅크를 쓸 사람들은 데이터가 기계 안에 어떻게 조직돼 있는지를 알아야만 하는 처지에서 보호받아야 한다고 적습니다. 단말 앞의 사용자 활동과 대부분의 응용 프로그램은 데이터의 내부 표현이 바뀌어도 영향을 받지 않은 채로 남아야 한다고 적습니다. 외부 표현의 일부 측면이 바뀔 때도 마찬가지라고 적습니다. 그리고 데이터 표현의 변경은 질의·갱신·보고 트래픽의 변화와 저장되는 정보 종류의 자연스러운 증가 탓에 자주 필요해질 것이라고 덧붙입니다.

그래서 쓰는 쪽과 담는 쪽을 떼어내야 했습니다. 같은 논문은 자기가 다루는 문제를 데이터 독립성이라고 부릅니다. 응용 프로그램과 단말 활동이 데이터 종류의 증가와 데이터 표현의 변화로부터 독립인 것입니다. 여기에 연역 기능이 없는 시스템에서조차 골칫거리가 될 것으로 예상되는 몇 가지 데이터 불일치가 따라붙습니다. 논문이 내놓은 답은 데이터를 그 자연스러운 구조만으로 기술하는 것입니다. 기계 표현을 위한 구조를 위에 덧씌우지 않습니다. 그러면 한쪽의 프로그램과 다른 쪽의 기계 표현·데이터 조직 사이에 최대한의 독립성을 내주는 고수준 데이터 언어의 바탕이 됩니다.

이름은 그 필요를 그대로 받아 적은 자리에 붙습니다. Bachman 은 1973년 튜링상 강연에서 데이터를 쓰는 응용 프로그램들로부터 독립인 데이터, 곧 많은 응용과 많은 사용자를 섬기도록 조직·구조화된 데이터를 원한다고 적습니다. 우리가 찾는 것이 데이터 베이스라고 적습니다. 같은 강연은 그 데이터를 건사하는 일에 주된 기능이 둘 있다고 적습니다. 첫째로 든 것이 조회입니다. 앞서 저장된 데이터를 다시 읽어 어떤 실세계 개체나 관계의 기록된 상태를 확인하는 활동입니다. 그 데이터는 몇 초 전일 수도, 며칠 전일 수도 있는 다른 작업이 저장해 둔 것입니다. 관리 시스템은 저장된 때부터 나중에 조회될 때까지 데이터를 유지할 지속적인 책임을 집니다. 강연은 또 공유 접근이 다중 프로그래밍의 특수한 형태라고 적습니다. 여기서 임계 공유 자원은 데이터베이스의 레코드들입니다.

예시

PostgreSQL 의 클러스터와 데이터베이스

flowchart TD
    A[클러스터] --> B[데이터베이스]
    B --> C[스키마]
    C --> D[테이블]

서버 한 대 안에 데이터베이스가 여럿 있습니다. 롤·데이터베이스·테이블스페이스 이름처럼 적은 수의 객체는 클러스터 수준에서 정의됩니다. 저장되는 자리는 pg_global 테이블스페이스입니다. 클러스터 안에는 여러 데이터베이스가 있습니다. 서로 격리돼 있습니다. 그래도 클러스터 수준 객체에는 접근할 수 있습니다. 각 데이터베이스 안에는 여러 스키마가 있습니다. 스키마가 테이블과 함수 같은 객체를 담습니다. 문서는 전체 계층을 클러스터, 데이터베이스, 스키마, 테이블 순으로 적습니다. 마지막 자리에는 함수처럼 다른 종류의 객체가 올 수도 있습니다.

어디에 나눠 담을지도 문서가 적어 둡니다. 한 서버 클러스터에 서로 무관한 프로젝트나 사용자가 들어갈 수 있습니다. 그들이 대체로 서로를 모르고 지내야 한다면, 별도의 데이터베이스로 나누는 것이 권장됩니다. 권한과 접근 제어도 그에 맞게 조정합니다. 서로 관련이 있어 자원을 함께 써야 한다면 같은 데이터베이스에 둡니다. 다만 스키마는 별도로 나누는 쪽입니다. 그러면 네임스페이스 격리와 권한 제어를 갖춘 모듈식 구조가 됩니다.

SQLite 의 단일 파일 데이터베이스

파일 하나가 통째로 데이터베이스이기도 합니다. 여러 테이블과 인덱스, 트리거, 뷰를 갖춘 완전한 SQL(Structured Query Language, 구조화 질의 언어) 데이터베이스가 디스크 파일 하나에 담깁니다. SQLite 자신은 그 파일을 다루는 쪽입니다. 문서는 SQLite 를 트랜잭션 SQL 데이터베이스 엔진을 구현한 인프로세스 라이브러리라고 적습니다. 그 엔진은 자기완결적입니다. 서버가 없습니다. 설정도 필요 없습니다.

Redis 의 번호로 고르는 데이터베이스

> SELECT 0

SELECT 명령은 지정한 0부터 시작하는 숫자 인덱스를 가진 논리적 Redis 데이터베이스를 고릅니다. 위 호출이 고르는 0 번은 새 연결이 항상 쓰는 자리입니다. 문서는 이 고를 수 있는 데이터베이스들이 네임스페이싱의 한 형태라고 적습니다. 모든 데이터베이스가 여전히 같은 하나의 영속화 파일에 저장됩니다. 다만 서로 다른 데이터베이스는 같은 이름의 키를 가질 수 있습니다. FLUSHDB · SWAPDB · RANDOMKEY 같은 명령은 특정 데이터베이스에만 작용합니다.

키와 값만 담는 자리에도 이 이름이 붙습니다.

> SET bike:1 "Process 134"
> GET bike:1

bike:1 이 키입니다. "Process 134" 는 그 키에 담긴 값입니다. SET 이 값을 넣습니다. GET 은 같은 키로 값을 다시 꺼냅니다. 문서는 Redis 문자열이 바이트 배열과 비슷하게 텍스트, 직렬화된 객체, 카운터 값, 바이너리 배열을 포함한 바이트 열을 저장한다고 적습니다.

MySQL 의 데이터베이스 디렉터리

MySQL 에서 데이터베이스는 디렉터리 하나로 구현됩니다. 그 안에 데이터베이스의 테이블들에 대응하는 파일들이 들어 있습니다. 만드는 문은 CREATE DATABASE 입니다. 주어진 이름으로 데이터베이스 하나를 만듭니다. 이 문을 쓰려면 그 데이터베이스에 대한 CREATE 권한이 있어야 합니다.

경계

데이터베이스와 관리 시스템

flowchart TD
    관리[데이터베이스 관리 시스템] -->|저장·조직·조회를 제어| 데이터베이스[디스크 위 파일 집합]

데이터를 다루는 그 소프트웨어도 데이터베이스인가. 아닙니다. Oracle 문서는 둘을 따로 정의합니다. 데이터베이스는 디스크 위 파일들의 집합입니다. 그 파일들이 사용자 데이터를 저장합니다. 데이터베이스 관리 시스템은 데이터의 저장·조직·조회를 제어하는 소프트웨어입니다. 담긴 것과 담는 일을 하는 쪽이 갈립니다. 같은 문서가 물리 구조와 논리 구조도 분리해 둡니다. 둘이 분리돼 있습니다. 그래서 논리 저장 구조에 대한 접근에 영향을 주지 않은 채로 데이터의 물리 저장을 관리할 수 있습니다.

스프레드시트 파일 한 장

표 한 장이 담긴 스프레드시트 파일도 데이터베이스인가. Bachman 이 든 차이 하나로는 아닙니다. 같은 강연은 파일과 데이터베이스를 가르는 구분이 명확하게 확립돼 있지는 않다고 먼저 적습니다. 그리고 차이 하나를 듭니다. 데이터베이스에서는 여러 종류의 레코드를 두는 것이 흔합니다. 인사 데이터베이스라면 사원 레코드, 부서 레코드, 기능 레코드, 공제 레코드, 근무 이력 레코드, 학력 레코드가 있을 수 있습니다. 각 레코드 종류는 자기만의 기본 데이터 키를 가집니다. 나머지 필드들은 전부 보조 데이터 키가 될 수 있습니다. 한 종류의 행만 늘어놓은 표 한 장은 이 차이를 만족하지 못합니다.

같은 낱말이 가리키는 자리

MySQL 이 데이터베이스라 부르는 것이 다른 제품에서도 데이터베이스인가. 아닙니다. MySQL 문서는 CREATE SCHEMA 가 CREATE DATABASE 의 동의어라고 적습니다. 두 낱말이 같은 것을 가리킵니다. Oracle 문서는 가릅니다. 데이터베이스 스키마는 스키마 객체라 불리는 데이터 구조들의 논리적 컨테이너입니다. 각 사용자 계정은 자기 이름과 같은 이름의 스키마 하나를 소유합니다. 데이터베이스는 스키마에 담기지 않는 종류의 객체도 저장합니다. 사용자 계정, 롤, 컨텍스트, 딕셔너리 객체가 그것입니다. PostgreSQL 도 데이터베이스 안에 스키마를 두는 쪽입니다. 그 문서는 SQL 표준이 데이터베이스를 카탈로그라 부른다고 덧붙입니다. 실무상 차이는 없다고 적습니다. 그러니 이 낱말을 만나면 어느 제품의 어휘인지를 먼저 봐야 합니다.

관련 항목

담는 구조

클러스터 · 스키마 · 테이블 · 레코드 · 테이블스페이스 · 인덱스 · 뷰 · 트리거 · 함수 · 컨텍스트 · 딕셔너리 객체 · 네임스페이스

구조를 정하는 규칙

정규화 · 관계형 모델 · 기본 키 · 보조 키

접근을 관리하는 주체

권한 · 롤 · 사용자 계정

헷갈리는 이웃

데이터베이스 관리 시스템(Database Management System, DBMS) · 카탈로그 · 데이터 뱅크

질의를 표현하는 수단

SQL · 질의 · 데이터 서브언어

질의가 거치는 처리 단계

실행 계획 · 질의 최적화 · 플래너

지키는 성질

트랜잭션 · 격리 수준 · 데이터 독립성 · 공유 접근 · 다중 프로그래밍

늘리고 지키는 방법

복제 · 논리적 복제 · 샤딩 · 샤드 · 고가용성 · 부하 분산 · 커넥션풀 · 세션 · 백업과 복구

실제로 구현·채택한 제품

PostgreSQL · SQLite · Redis · MySQL · Oracle

비롯된 배경

Codd · Bachman

맞세워지는 대립 개념

프로세스 · 자료구조 · 배열