Chapter 1. Introduction

한 줄 핵심: DBMS(Database Management System)는 파일 시스템으로 데이터를 다룰 때 생기는 6가지 고질병(중복·접근곤란·고립·무결성·원자성·동시성·보안)을 해결하기 위해 등장했고, 이를 위해 데이터를 추상화 수준으로 나누고, 데이터 모델·언어(DDL/DML)·트랜잭션·저장 관리·복구를 하나의 시스템으로 묶었다.

이 챕터가 답하는 핵심 질문

Q1. 왜 파일 시스템 대신 데이터베이스를 쓰는가?

Q2. DBMS는 복잡성을 어떻게 숨기는가? (데이터 추상화)

Q3. 스키마와 인스턴스는 무엇이 다른가?

Q4. 데이터를 표현하는 모델에는 어떤 것들이 있는가?

Q5. 데이터베이스를 다루는 언어(DDL·DML)는 무엇인가?

Q6. 응용 프로그램은 어떻게 데이터베이스에 접근하는가?

Q7. 좋은 데이터베이스 설계는 어떻게 하는가?

Q8. 데이터는 디스크에 어떻게 관리되는가? (저장 관리자)

Q9. 쿼리는 어떤 과정을 거쳐 처리되는가?

Q10. 장애와 동시 접근에도 데이터의 정확성을 어떻게 보장하는가? (트랜잭션)

Q1. 왜 파일 시스템 대신 데이터베이스를 쓰는가?

A. 파일 시스템에 데이터를 직접 저장하면 6가지 고질적 문제가 생기는데, DBMS는 이를 한 번에 해결하는 소프트웨어 시스템이기 때문이다.

초기에는 데이터베이스 응용을 파일 시스템 위에 직접 만들었고, 다음 문제들이 발생했다.

문제	설명
데이터 중복(redundancy)·비일관성(inconsistency)	여러 파일·형식에 같은 정보가 중복 저장 → 한쪽만 고치면 불일치
데이터 접근 어려움	새로운 조회마다 새 프로그램을 작성해야 함
데이터 고립(isolation)	데이터가 여러 파일·형식에 흩어져 있음
무결성(integrity) 문제	제약조건(예: 잔액 ≥ 0)이 프로그램 코드에 “묻혀”있어 추가·변경이 어려움
갱신의 원자성(atomicity)	장애 시 일부만 수행된 채 비일관 상태로 남음
동시 접근(concurrent access) 이상	성능을 위해 동시 접근이 필요하지만, 제어 안 하면 비일관성 발생
보안(security) 문제	일부 데이터만 골라 권한을 주기 어려움

구체적 예시:

중복: Student_info.txt와 Student_takes_classes.txt에 학생 이름·주소가 중복 저장 → 한쪽만 수정하면 불일치
원자성: A 계좌에서 B로 이체 중 차감 후 크래시 → 입금 안 됨. 전부 수행되거나 전혀 안 되거나 해야 함
동시 접근: 잔액 100원 계좌에서 두 사람이 동시에 50원씩 인출 → 둘 다 100원을 읽고 인출하면 잔액 50원(정답 0원)
보안: 파일 수준에서는 “급여 담당자에게 급여만, 일반 직원에게 주소만” 같은 세밀한 접근 제어가 어려움

DBMS 적용 분야

대학(학생·수강·성적·시간표), 은행(고객·계좌·대출·거래), 항공사(예약·스케줄·좌석), 온라인 쇼핑(판매·주문·상품 조회) 등 거의 모든 기업이 사용한다.

Q2. DBMS는 복잡성을 어떻게 숨기는가? (데이터 추상화)

A. 데이터를 3가지 추상화 수준(물리 → 논리 → 뷰)으로 나눠, 위로 갈수록 세부사항을 감춘다.

일상 비유 — 자동차 운전

물리적 수준 = 엔진 내부에서 연료가 어떻게 폭발해 피스톤을 미는가. (정비사가 신경 쓰는 부분)

논리적 수준 = “엔진, 변속기, 바퀴가 이렇게 연결돼 있다”는 자동차의 전체 설계도. (엔지니어가 보는 부분)

뷰 수준 = 운전자가 보는 핸들·페달·계기판뿐. 엔진 내부는 몰라도 운전할 수 있다. (사용자가 보는 부분)

운전자가 핸들만 알면 되듯, 사용자는 데이터가 디스크에 어떻게 깔리는지 몰라도 쓸 수 있게 하는 것이 추상화의 목적이다.

각 수준이 같은 instructor 데이터를 어떻게 다르게 “보는지” 비교하면:

[뷰 수준]   교무처 직원 화면: 이름과 학과만 보임
            ┌─────────┬──────────┐
            │  name   │dept_name │   ← salary는 안 보임 (보안)
            ├─────────┼──────────┤
            │ Einstein│ Physics  │
            └─────────┴──────────┘
                       │ (전체 중 일부만 골라 보여줌)
[논리 수준] 테이블 설계: instructor(ID, name, dept_name, salary)
            "어떤 열이 있고, salary는 숫자형이며, dept_name은
             department 테이블을 참조한다"는 구조 정의
                       │ (실제 저장 방식은 숨김)
[물리 수준] 디스크 위 실제 바이트: 블록 17번에 레코드 배치,
            ID 컬럼에 B+트리 인덱스, salary는 8바이트 정수로 인코딩…

물리적 수준(Physical Level): 데이터가 실제로 어떻게 저장되는지(블록 배치, B+트리/해시 인덱스 등). 시스템 개발자·DBA가 성능 튜닝 시 관여.
논리적 수준(Logical Level): 어떤 데이터가 저장되고 그 관계가 무엇인지. 물리적 세부는 숨기고 전체 구조를 정의. DBA·응용 프로그래머가 사용.
뷰 수준(View Level): 전체 중 일부만 선택적으로 보여줌. 일반 사용자가 접하며, 보안과 편의를 동시에 제공. 하나의 DB에 여러 뷰 존재 가능.

수준	기술 대상	주요 사용자
뷰	데이터의 일부	일반 사용자
논리적	전체 데이터 구조·관계	DBA, 응용 프로그래머
물리적	저장 방식·인덱스·파일 구조	시스템 개발자

물리적 데이터 독립성(Physical Data Independence)

논리적 스키마를 안 바꾸고도 물리적 스키마를 수정할 수 있는 능력. 인덱스를 B+트리→해시로 바꿔도 SELECT * FROM instructor 쿼리는 그대로 동작한다. 추상화 수준을 나누는 핵심 이유.

Q3. 스키마와 인스턴스는 무엇이 다른가?

A. 스키마(Schema)는 설계(구조), 인스턴스(Instance)는 특정 시점의 실제 데이터다. 프로그래밍의 “타입 선언” vs “변수 값”에 대응한다.

비유	스키마	인스턴스
프로그래밍	`int x;` (타입 선언)	`x = 5` (실제 값)
데이터베이스	테이블 구조 정의	테이블에 저장된 실제 행들

스키마는 자주 변하지 않지만, 인스턴스는 삽입·수정·삭제마다 바뀐다. 각 추상화 수준마다 대응 스키마가 존재한다: 물리 스키마, 논리 스키마(프로그램에 가장 큰 영향), 서브스키마(뷰 스키마).

CREATE TABLE instructor (
    ID        VARCHAR(5),
    name      VARCHAR(20),
    dept_name VARCHAR(20),
    salary    NUMERIC(8,2)
);

Q4. 데이터를 표현하는 모델에는 어떤 것들이 있는가?

A. 데이터 모델은 데이터·관계·의미·제약조건을 기술하는 개념적 도구 모음이며, 대표적으로 4가지가 있다.

관계형 모델(Relational Model): 테이블(릴레이션)의 집합으로 표현. 가장 널리 사용. (Ch2)
개체-관계 모델(E-R Model): 개체(entity)와 관계(relationship)의 집합. 주로 DB 설계에 사용. (Ch6)
객체 기반 모델(Object-Based): 객체지향 개념 활용 (Object-Relational 등).
반구조화 모델(Semistructured): XML 등 스키마가 유연한 데이터. 각 항목이 자체 속성 집합을 가질 수 있음.

같은 교수 정보를 모델별로 표현하면
같은 “Einstein, Physics, 95000” 데이터도 모델에 따라 모양이 다르다.
관계형(테이블):     | ID    | name     | dept_name | salary |
                    | 22222 | Einstein | Physics   | 95000  |

E-R(개체+관계):     [instructor:Einstein] ──member──> [department:Physics]
                      (네모=개체, 화살표=관계. 설계 단계에서 그림으로 사고)

반구조화(XML):      <instructor>
                      <name>Einstein</name>
                      <salary>95000</salary>   ← 옆 교수는 salary가 없어도 OK
                    </instructor>              (항목마다 속성이 달라도 됨)
직관: 관계형은 “모든 행이 같은 열을 가진 빳빳한 표”라서 일관성·질의에 강하고, 반구조화는 “항목마다 모양이 달라도 되는 느슨한 형식”이라 유연하다.

Q5. 데이터베이스를 다루는 언어(DDL·DML)는 무엇인가?

A. DML은 데이터를 조작(조회·삽입·수정·삭제), DDL은 스키마를 정의하는 언어다.

DML (Data Manipulation Language) — 쿼리 언어

데이터를 접근·조작하는 언어. 두 유형:

절차적(Procedural): 어떤 데이터가 필요하고 어떻게 가져올지 명시.
선언적(Declarative/Nonprocedural): 무엇이 필요한지만 명시, 방법은 시스템에 맡김. SQL이 대표.

DDL (Data Definition Language) — Ch3

스키마를 정의하는 언어. DDL 컴파일러는 테이블 템플릿을 만들어 데이터 사전(Data Dictionary)에 저장한다. 데이터 사전은 **메타데이터(data about data)**를 담는다:

데이터베이스 스키마
무결성 제약조건: 기본키(ID가 교수를 유일 식별), 참조 무결성(SQL의 references — instructor의 dept_name 값은 department에 반드시 존재해야 함)
권한(Authorization)

create table instructor (
    ID         char(5),
    name       varchar(20),
    dept_name  varchar(20),
    salary     numeric(8,2)
);
-- ID가 12121인 교수 이름 찾기
select name from instructor where ID = '12121';

Q6. 응용 프로그램은 어떻게 데이터베이스에 접근하는가?

A. 프로그래밍 언어 안에서 API를 통해 SQL을 실행한다. Java는 JDBC, C/C++/C#은 ODBC를 사용한다. (Ch5)

public static void JDBCexample(String dbid, String userid, String passwd) {
    try {
        Class.forName("oracle.jdbc.driver.OracleDriver");
        Connection conn = DriverManager.getConnection(
            "jdbc:oracle:thin:@gist.ac.kr:2000:univdb", userid, passwd);
        Statement stmt = conn.createStatement();
 
        // 삽입
        stmt.executeUpdate(
            "insert into instructor values('77987','Kim','Physics',98000)");
 
        // 조회 후 결과 출력
        ResultSet rset = stmt.executeQuery(
            "select dept_name, avg(salary) from instructor group by dept_name");
        while (rset.next()) {
            System.out.println(rset.getString("dept_name") + " " + rset.getFloat(2));
        }
        stmt.close();
        conn.close();
    } catch (SQLException sqle) {
        System.out.println("SQLException: " + sqle);
    }
}

Q7. 좋은 데이터베이스 설계는 어떻게 하는가?

A. 잘못된 설계는 중복·비일관성을 낳으므로, E-R 모델(요구사항 모델링)과 정규화 이론(나쁜 설계를 형식적으로 검출·제거)으로 설계한다.

E-R 모델 (Ch6)

기업을 개체와 관계의 집합으로 모델링하고 E-R 다이어그램으로 표현한다.

개체(Entity): 다른 것과 구별되는 사물·객체. 속성(attribute)의 집합으로 기술.
관계(Relationship): 여러 개체 간의 연관.
예: instructor ◇─member─▷ department (교수가 학과에 소속). 이때 instructor의 dept_name 속성은 관계로 흡수된다.

정규화 (Normalization, Ch7)

나쁜 설계를 형식적으로 정의하고 검출하는 이론. 중복을 체계적으로 제거한다.

나쁜 설계 예시: instructor와 department를 한 테이블로 합치면 —

ID	name	dept_name	salary	building	budget
22222	Einstein	Physics	95000	Watson	70000
33456	Gold	Physics	87000	Watson	70000

→ Physics의 building·budget이 중복 저장됨. budget 변경 시 모든 Physics 행을 고쳐야 하고, 하나라도 빠뜨리면 비일관성 발생. 정규화는 이를 두 릴레이션으로 분리한다.

Q8. 데이터는 디스크에 어떻게 관리되는가? (저장 관리자)

A. **저장 관리자(Storage Manager)**는 디스크의 저수준 데이터와 응용 프로그램/쿼리 사이의 인터페이스를 제공하는 프로그램 모듈이다. (Ch13)

책임:

파일 관리자와의 상호작용 (디스크 저장 공간 할당)
데이터의 효율적 저장·검색·갱신

핵심 이슈(Issues):

Storage access: 디스크 ↔ 메모리 간 효율적 전송
File organization: 레코드를 디스크에 효율적으로 배치
Indexing and hashing: 빠른 검색을 위한 인덱스 구조 (Ch14)

Q9. 쿼리는 어떤 과정을 거쳐 처리되는가?

A. SQL 쿼리는 파싱·변환 → 최적화 → 평가의 단계를 거쳐 실행된다. (Ch15)

파싱 및 변환: SQL을 관계 대수 표현으로 변환
최적화(Optimization): 같은 결과를 내는 여러 실행 계획 중 가장 비용이 낮은 계획(evaluation plan) 선택
평가(Evaluation): 선택된 계획대로 실행

한 쿼리를 단계별로 추적
SELECT name FROM instructor WHERE salary > 90000 가 들어오면:
① 파싱·변환:  SQL  ──>  관계 대수
              Π_name( σ_{salary>90000}(instructor) )

② 최적화:    같은 답을 주는 두 계획을 비교
   계획 A: instructor 전체를 디스크에서 다 읽고 한 줄씩 검사 (full scan)
   계획 B: salary에 인덱스가 있으면 90000 초과인 행만 바로 점프
           ──> 옵티마이저가 "비용(읽을 블록 수)"을 계산해 더 싼 쪽 선택

③ 평가:      선택된 계획대로 실제 실행 ──> 결과 튜플 반환
직관: 사용자는 “무엇(name, salary>90000)“만 적고, “어떻게 빨리 찾을지”는 옵티마이저가 알아서 고른다. 이것이 선언적 언어 SQL의 핵심 이점이다.

Q10. 장애와 동시 접근에도 데이터의 정확성을 어떻게 보장하는가? (트랜잭션)

A. 트랜잭션(Transaction) 단위로 묶어, 트랜잭션 관리자가 장애에도 일관성을 보장하고, 동시성 제어 관리자가 동시 실행을 조율한다. (Ch17)

트랜잭션이란?

데이터베이스 응용에서 하나의 논리적 기능을 수행하는 연산의 집합. (예: 계좌 이체 = 차감 + 입금)

핵심 요구사항:

원자성(Atomicity): 모든 연산이 전부 수행되거나 전혀 안 되거나.
일관성(Consistency): 실행 전후 데이터 일관성 유지.
지속성(Durability): 완료된 트랜잭션 결과는 장애에도 유지.

트랜잭션 관리 컴포넌트는 시스템 장애(정전, OS 크래시)와 트랜잭션 실패에도 DB를 일관된(correct) 상태로 유지한다. **동시성 제어 관리자(Concurrency-control manager)**는 동시 트랜잭션 간 상호작용을 통제해 일관성을 보장한다.

동시성 제어 (Concurrency Control)

동시 실행이 필요한 이유는 성능(처리량·응답 시간)이다. 하지만 통제 없는 동시 접근은 비일관성을 낳는다.

Lock 기반 제어:

User1이 항목 A에 lock 획득 → 읽기/쓰기
User2가 같은 A에 접근 → lock 해제까지 wait
User1 작업 완료 후 unlock → User2가 lock 획득

장애 복구 (Recovery, Ch19)

시스템 장애 시 일관된 상태로 복구하는 메커니즘. 복구 관리자가 담당.

메모리 vs 안정 저장소(Stable Storage):

메인 메모리: 빠르지만 휘발성 — 크래시 시 손실
안정 저장소(디스크): 느리지만 비휘발성

크래시 시 메모리에만 있던 변경이 디스크에 반영 안 될 수 있다. 이를 막기 위해 로그(log) 기반 복구를 사용한다(변경을 로그에 먼저 기록 → 크래시 시 완료분 redo, 미완료분 undo).

출처: Database System Concepts, 7th Edition (Silberschatz, Korth, Sudarshan)

Juhyeon's Blog

탐색기

Ch1_Introduction

Chapter 1. Introduction

Q1. 왜 파일 시스템 대신 데이터베이스를 쓰는가?

Q2. DBMS는 복잡성을 어떻게 숨기는가? (데이터 추상화)

Q3. 스키마와 인스턴스는 무엇이 다른가?

Q4. 데이터를 표현하는 모델에는 어떤 것들이 있는가?

Q5. 데이터베이스를 다루는 언어(DDL·DML)는 무엇인가?

DML (Data Manipulation Language) — 쿼리 언어

DDL (Data Definition Language) — Ch3

Q6. 응용 프로그램은 어떻게 데이터베이스에 접근하는가?

Q7. 좋은 데이터베이스 설계는 어떻게 하는가?

E-R 모델 (Ch6)

정규화 (Normalization, Ch7)

Q8. 데이터는 디스크에 어떻게 관리되는가? (저장 관리자)

Q9. 쿼리는 어떤 과정을 거쳐 처리되는가?

Q10. 장애와 동시 접근에도 데이터의 정확성을 어떻게 보장하는가? (트랜잭션)

동시성 제어 (Concurrency Control)

장애 복구 (Recovery, Ch19)

그래프 뷰

목차

Properties