Database System Foundation

이 페이지는 Database, DBMS, Database System 같은 기본 정의에서 시작해, 데이터베이스 접근 방식이 왜 단순 파일 저장과 다른지, 그리고 Transaction이 왜 all-or-nothing이어야 하는지를 다룬다. 후속 concept인 3-schema architecture와 ER model은 이 기초 위에 선다. DBMS 성능이 disk I/O에 좌우된다는 점에서 OS Memory Management와도 보조 기억장치 관점에서 맞닿아 있다.

기본 정의

Mini-world의 변화도 데이터베이스에 반영된다.^[4] Mini-world를 가져오는 이유는 현실 세계의 일부를 데이터로 사용함으로써 발생하는 문제를 해결하기 위해서다.^[2:1]

DBMS 성능 결정 요소

Disk I/O가 DBMS 성능을 결정한다.^[5] 방대한 양의 데이터를 제한된 메모리로 관리하므로, 보조 저장 매체(하드디스크)에서 데이터를 얼마나 효율적으로 가져오느냐가 핵심이다. 따라서 DBMS 설계는 disk I/O 패턴과 저장 구조(index 등)에 크게 좌우된다고 볼 수 있다.^[6]

SQL 중첩이 가능한 이유는 닫힌 성질 — 연산 결과가 다시 relation이 되는 성질 — 때문이다.^[7] ER model 페이지의 Relational Algebra 절에서 이 성질을 다시 참조한다.

Database system의 경계

flowchart TD
    U[Users / Programmers] --> A[Application programs / queries]
    A --> Q[DBMS: query and program processing]
    Q --> X[DBMS: stored-data access]
    X --> M[(Stored database definition / metadata)]
    X --> D[(Stored database)]

Database system은 저장 데이터만이 아니라 application/query, DBMS software, metadata를 함께 포함한다. metadata는 DBMS가 데이터 구조와 제약을 해석하는 근거이며, 사용자 프로그램과 저장 데이터를 직접 같은 것으로 보지 않게 한다고 볼 수 있다.^[6:1]

데이터베이스 접근 방식의 핵심 특성

Transaction — All or Nothing

Transaction은 데이터베이스에서 일어나는 하나의 논리적 작업 단위다. Multi-user transaction은 하나의 operation 집합이며, all or nothing으로 처리된다.^[13] Transaction의 모든 작업이 완료되지 않으면 수행한 모든 작업은 취소되어야 한다.^[13:1] 즉 다 수행하거나 아무것도 수행하지 않아야 한다(atomic).^[14] 또한 각 트랜잭션이 서로 고립되어 수행되는 것처럼 보장한다(고립성, isolation).^[14:1]

OLTP(Online Transaction Processing)는 데이터베이스 응용의 주요 부분으로, 매초 수백 개의 동시 트랜잭션을 실행할 수 있다.^[12:1]

데이터베이스 사용자 범주

데이터베이스 사용자는 "장면의 배우들"(데이터베이스 콘텐츠 사용/제어, 응용 설계/개발/유지)과 "장면 뒤의 노동자들"(DBMS 소프트웨어/도구 설계·개발·운영)로 나뉜다.^[15]

장면의 배우들

장면 뒤의 노동자들

• 시스템 설계자 및 구현자 — DBMS 패키지 설계·구현. 애플리케이션/언어 컴파일러/운영체제와 인터페이스 테스트·디버그^[17]
• 도구 개발자 — 모델링/설계, 성능 모니터링, 프로토타입, UI 생성 소프트웨어 개발^[17:1]
• 운영자 및 유지보수 직원 — 하드웨어/소프트웨어 환경 운영·유지^[17:2]

DBMS 접근 방식의 이점

• 중복 제어 — 데이터 저장/개발/유지보수 중복 제어 (정규화).^[18][19]
• 불법적 접근 통제 — DBA 직원만 특권 명령·기능 사용 가능.^[18:1]
• 영구 저장 제공 — 프로그램 객체에 대한 영구 저장.^[18:2]
• 효율적 쿼리 처리 — 저장 구조(index 등) 제공.^[18:3]
• 쿼리 최적화 — Relational Algebra 기반. A는 100번 실행하는 결과를 B는 10번 실행으로 같은 결과(동치)가 나오도록 변환.^[18:4]
• 백업/복구 서비스.^[18:5]
• 다양한 인터페이스 제공.^[18:6]
• 복잡한 관계 표현.^[18:7]
• 무결성 제약 조건 강제.^[18:8]
• 규칙과 트리거로 추론·액션 도출.^[18:9]

추가로 표준 준수 가능성, 애플리케이션 개발 시간 감소, 데이터 구조 변경 유연성, 최신 정보 가용성, 규모의 경제 같은 의미도 있다.^[20]

데이터베이스를 사용하지 말아야 할 때

• 높은 초기 투자 비용과 추가 하드웨어 필요성
• 보안/동시성 제어/복구/무결성 기능 제공에 대한 오버헤드
• 데이터베이스와 응용이 간단·명확·변경 없으면 DBMS가 불필요할 수 있음
• 다중 사용자 접근이 필요하지 않으면 불필요할 수 있음^[21]

데이터베이스 기술의 역사적 발전

종합

Database System Foundation의 핵심은, 관련된 데이터를 소프트웨어(DBMS)로 관리해 단순 파일 저장과 구분되는 자기 기술성·독립성·추상화·다중 뷰·동시성 제어를 제공하는 데 있다고 볼 수 있다. Transaction의 "all or nothing"은 단순한 실패 회피가 아니라 데이터 일관성의 기본 단위로 읽힌다. 성능의 핵심이 disk I/O이므로, DBMS 활용·설계는 저장 구조와 I/O 패턴 관점에서 접근해야 한다는 것이 이 페이지가 종합하는 지점이다.^[6:2]

흔히 놓치는 지점

• Catalog(메타데이터)를 두지 않고 애플리케이션 코드에 데이터 구조를 하드코딩하면 독립성을 잃는다.
• 무분별한 데이터 중복을 허용하면 정규화 없이 저장 비용과 일관성 문제가 커진다.
• Transaction의 all-or-nothing을 무시하고 부분 실패를 허용하면 무결성이 깨진다.
• 다중 사용자 접근에 동시성 제어(Lock 등)를 빼먹으면 race condition으로 데이터가 훼손된다.
• Disk I/O 패턴을 무시하고 인덱스 없이 대량 데이터를 매번 full scan하는 경우가 있다.
• DBMS 오버헤드(보안·동시성·복구·무결성)가 필요 없는 단순·고정 응용에 무리해 DBMS를 도입하는 경우가 있다.

관련

• 3-schema architecture — 자기 기술성·독립성·추상화를 구체화하는 아키텍처.
• ER model — 개념적 데이터 모델의 대표 예.
• OS Memory Management — Disk I/O와 저장 매체 관점에서 DBMS와 맞닿아 있다.
• DB 조회 읽기 성능 최적화 — Disk I/O 감소를 위한 InnoDB Buffer Pool, RAID, Replication 패턴.

출처

테스트 질문

• Database, DBMS, Database System의 정의 차이는 무엇인가?
• DBMS 성능이 Disk I/O에 의해 결정되는 이유는 무엇인가?
• Transaction의 "all or nothing"이 왜 필요한가? 부분 완료를 허용하면 어떤 문제가 생기는가?
• Catalog(메타데이터)가 없는 데이터 저장 방식의 문제점은 무엇인가?
• 데이터베이스를 사용하지 말아야 할 때는 언제인가?