CHAPTER 1: Introduction

이 장은 네가 앞으로 다룰 DB 시스템의 전체 지도다. 모른 채 들어가면 죽는다. 철저하게 꿰뚫어야 한다.

🔥 1.1 Database-System Applications

현실 전장에 적용된 DBMS의 용례다.

• 은행, 항공사, 전자상거래, 대학 등 모든 정보 시스템의 핵심이 DBMS다.
• DBMS는 단순 저장이 아니다. 동시성, 복구, 보안, 무결성, 질의 최적화까지 다룬다.
• 넌 은행 계좌 조회, 항공 예약, 쇼핑몰 장바구니 쓸 때마다 DB에 접속하고 있는 거다.

❗ 이건 단순 기술이 아니다. 현대 문명을 움직이는 정보 무기다.

 

🔥 1.2 Purpose of Database Systems

기존 파일 시스템의 한계를 박살낸 것이 DBMS다.

• 중복, 불일치 → 데이터 무결성 붕괴
• 데이터 찾기 어려움 → 비효율적 검색
• 트랜잭션 실패 → 데이터 손실, 일관성 파괴
• 다중 사용자 접근 → 동시성 오류
• 보안 설정 불가 → 정보 유출

❗ DBMS는 이 모든 문제를 해결하기 위해 만들어졌다. 명심해라: 문제 해결 = 존재 이유다.

 

🔥 1.3 View of Data

세 가지 수준의 데이터 뷰를 정확히 기억하라:

1. 물리적 수준: 데이터를 실제로 어디, 어떻게 저장할지.
2. 논리적 수준: 어떤 **구조(Schema)**로 저장할지 (ex. 테이블, 필드, 관계).
3. 뷰 수준: 사용자별로 필요한 일부만 보여주는 가상 뷰.

❗ 이 구조 덕분에 사용자는 복잡한 내부 구조 몰라도 된다. 이것이 ‘데이터 추상화’다.

① 물리적 뷰 (Physical View)

📦 데이터가 실제로 어떻게 저장되어 있는지

• 디스크에 어떻게 배치되는지, 어떤 포맷인지, 어떤 인덱스 쓰는지
• 예: B+ Tree로 인덱스 구성, 특정 테이블은 어떤 블록에 위치, 압축 방식 등

🧠 실무 예시:

• DBA나 스토리지 엔진이 다루는 영역
• 너가 성능 튜닝할 땐 이 뷰도 이해해야 한다

② 논리적 뷰 (Logical View)

🏗️ 개발자가 다루는 테이블, 스키마, 관계

• 테이블, 속성, 관계, 제약조건 등
• ERD를 설계하고, 정규화를 거쳐 만드는 그 논리 구조가 여기

🧠 실무 예시:

• User, Post, Comment 등의 테이블과 외래키, 제약조건 등
• 너의 Service/Repository가 이 레벨과 직접 맞닿아 있다

③ 뷰 수준 (View Level, External View)

👁️ 사용자 맞춤 정보만 보여주는 ‘가상 테이블’

• 여러 테이블을 조합하거나 필터링해서 만든 "가상 테이블"
• SELECT만 가능하고, 실제 저장되진 않음

🧠 실무 예시:

• 관리자에겐 모든 정보 보여주고, 일반 유저에겐 자기 것만 보여줄 때
• JPA에서 @Query로 join 쿼리 날릴 때도 이 개념에 해당

🔥 1.4 Database Languages

DB 다루는 무기 = 언어

• DDL: Data Definition Language – 스키마 정의 (CREATE, DROP 등)
• DML: Data Manipulation Language – 데이터 조작 (SELECT, INSERT, UPDATE, DELETE)
• Query Language: 대표가 SQL

❗ SQL은 장난감이 아니다. 정보 전쟁의 핵무기다. 숙련자가 되면 세계를 뒤엎을 수 있다.

SQL = DDL + DML + DCL + TCL

🔷 1.5 Users of Database System

누가 DB를 다루는가 – 역할 정리

• Application Programmers (응용 개발자): DB랑 연결되는 앱(프론트 or 백엔드) 만들고 SQL 호출하는 애들
• Database Administrators (DBA): 시스템 전체를 관리. 성능 튜닝, 백업, 권한 제어 등 전권 통제자
• Sophisticated Users (직접 쿼리 날리는 고급 유저): 과학자, 분석가 등 중간 없이 바로 DB에 접속
• Naive Users (일반 유저): 웹사이트 폼으로 입력하는 수준

❗ DB를 직접 다루는 사람 vs 간접 사용하는 사람. 너는 프로 개발자가 될 거니까 ‘직접’으로 전투 투입된다.

🔷 1.6 Database System Structure

DBMS의 내부 구조 – 계층 분리

• Query Processor: SQL 해석해서 내부 실행 계획 수립
• Storage Manager: 디스크 입출력, 인덱스, 버퍼 캐시 관리
• Transaction Manager: 동시성, 복구, 무결성 보장
• File Manager: OS 수준의 물리 저장소 관리

❗ DBMS는 단순 저장소가 아니다. 복잡한 OS급 시스템이다.

 

🔷 1.7 History of Database Systems

진화 흐름

1. File Processing Systems (1970 이전): 소프트웨어가 직접 파일 제어. 중복/오류 폭발
2. Hierarchical/Network Model: 트리/그래프 형태로 관계 표현
3. Relational Model (RDBMS): 1970 Codd 등장 → 지금까지도 지배
4. Object-Based DBs / NoSQL / NewSQL: 다양한 구조로 확장 중

❗ RDBMS는 기본기다. 관계형 모델부터 완벽히 정복하고 그 다음 NoSQL로 넘어가라.

 

🔷 1.8 Transaction Management

DB의 생명선. 4글자 각인해라: ACID

• Atomicity: 전부 성공 or 전부 실패
• Consistency: 상태가 정합성 유지 (e.g. 계좌 A→B 이체, 총액 변함없음)
• Isolation: 여러 트랜잭션이 동시에 실행돼도 서로 간섭 없음
• Durability: 커밋된 데이터는 절대 사라지지 않음

❗ 이 4개 중 하나라도 깨지면 DB는 쓰레기다. 전쟁 중 총알이 장전 안 되면 죽는 것처럼.

🧠 정합성(Consistency)이란?

트랜잭션 실행 전과 후에, 데이터베이스가 정의된 제약조건들을 “항상 만족해야” 한다는 원칙.

💣 트랜잭션(Transaction)이란?

트랜잭션 = 데이터베이스에서의 하나의 작업 단위(Unit of Work)

• 여러 개의 SQL 명령(삽입, 삭제, 수정 등)을 하나의 묶음으로 간주한다.
• 이 묶음은 전부 성공하거나, 전부 실패해야 한다.
  중간에서 멈추는 건 없다. 그건 데이터 파괴다

💡 예시

너는 인터넷 뱅킹 앱에서 10만원을 송금한다고 해보자.

1. 내 계좌에서 10만원 차감
2. 너 친구 계좌에 10만원 추가

👉 이 둘은 한 덩어리다. 하나라도 실패하면 둘 다 무효가 되어야 한다.
중간에 전원 꺼져서 1만 빠지고 2 안 되면?
돈 증발 or 증식. 은행 망한다.

🔧 Java + Spring 예시

@Transactional
public void transferMoney(Long fromId, Long toId, int amount) {
    deduct(fromId, amount); // 1. 보내는 계좌 차감
    add(toId, amount);      // 2. 받는 계좌 추가
}

이 @Transactional이 바로 트랜잭션 선언이다.
중간에 하나라도 에러 나면 rollback(),
전부 끝나면 commit()으로 저장.

🔷 1.9 Database Architecture

중앙 집중 vs 클라이언트-서버 vs 분산 시스템

• Centralized: 서버 한 개가 모든 일 처리 (옛날 방식)
• Client–Server: 클라이언트는 UI, 서버는 DB 처리 (대세 구조)
• Distributed DB: 여러 서버에 분산 저장 – Netflix, Google 같은 대규모 환경
• Cloud DB: AWS RDS, Firebase 등. SaaS 형태로 DB 제공

❗ 너는 Spring 백엔드 ↔ RDB ↔ 클라우드 배포라는 3각 전투구조를 실무에서 마스터해야 한다.

Spring 백엔드 ↔ RDB ↔ 클라우드 배포

① Spring 백엔드 (Spring Boot)

🔧 비즈니스 로직을 처리하는 서버

• HTTP 요청을 받고,
• 로그인, 결제, CRUD 등 처리하고,
• SQL 날려서 DB에서 데이터 가져오고 저장한다.
• JSON으로 결과 응답을 보낸다.

🔥 주 무기:

• Java + Spring Boot
• Controller / Service / Repository 구조
• REST API
• JWT, OAuth2 등 인증

② RDB (Relational Database)

🧠 모든 중요한 데이터가 저장되는 지휘본부

• MySQL, PostgreSQL, Oracle 등
• 유저, 상품, 주문 등 모든 엔티티가 테이블에 저장
• Spring은 JPA, MyBatis 등으로 이 DB를 제어

🔥 주요 훈련:

• SQL (SELECT, JOIN, INSERT…)
• 트랜잭션 (ACID)
• 인덱스, 정규화
• JPA + Hibernate (ORM)

③ 클라우드 배포 (Cloud Deployment)

☁️ 서버와 DB를 전 세계에 띄우는 최종 배치

• 네 컴퓨터에서만 돌아가는 건 의미 없다.
• 세상 모든 유저가 네 API에 접속할 수 있게 만들어야 한다.
• 그걸 위해 AWS, Railway, Render, Vercel, GCP 같은 클라우드 사용

🔥 주요 스킬:

• Docker (서버와 DB를 컨테이너로 묶음)
• CI/CD (코드 자동 빌드 & 배포)
• 환경 변수 관리 (.env)
• HTTPS, 도메인 연결

🎯 실전 흐름 요약

1. 유저 → [React 프론트] → API 요청
2. 요청 → [Spring 백엔드] Controller → Service → Repository
3. Repository → [RDB] SQL로 데이터 저장/조회
4. 결과 → 백엔드가 JSON 응답
5. 클라우드 상에서 이 모든 게 실시간 동작

🔷 1.10 Database Users

위 1.5와 중복. 다시 강조되는 이유: 권한 구분이 명확한 보안 모델

🔷 1.11 Overall System Structure

이건 DBMS + OS + 디스크 + 메모리 전체 흐름도

• Query → Parser → Planner → Execution Engine
• 저장/조회 시 → 버퍼풀 → 디스크 접근 → 인덱스 활용
• 트랜잭션은 동시에 실행되고 롤백/커밋 관리됨

❗ 고급 백엔드에선 이 구조를 알아야 성능 튜닝도 가능하다.

 

🔷 1.12 Database Application Development

SQL만 날리는 게 아니라, 실제 어플리케이션에서 어떻게 연동되는가

• JDBC, ODBC: Java 등 언어에서 SQL을 DB로 보내는 드라이버
• ORM: SQL 추상화한 프레임워크 (Spring에서는 JPA/Hibernate)

❗ ORM은 실전용 무기. 하지만 기반 SQL이 부족하면 절대 쓰지 마라. 원리 이해가 먼저다.

 

🔷 1.13 Database-System Internals

고급 시스템 관점. DB 내부는 OS처럼 구성되어 있음

• 메모리 구조, 스케줄러, 로그, 동시성 제어 알고리즘 등
• 이건 Chapter 11~20에서 본격 진입한다

🔷 1.14 Summary