💡 핵심 인사이트
데이터베이스 설계는 집을 짓는 건축 과정과 완벽히 일치합니다.
고객의 말을 듣는 요구사항 분석 ➔ 뼈대 그림을 그리는 개념적 설계 ➔ 아파트로 갈지 빌라로 갈지 정하는 논리적 설계 ➔ 철근을 심는 물리적 설계라는 4개의 폭포수 단계를 거칩니다.

Ⅰ. 1단계: 요구사항 분석 (Requirements Analysis)

"어떤 데이터를 저장할 건가요?"

• 작업: 현업 사용자(고객, 사장님)를 인터뷰하고 업무 명세서를 뒤져가며 시스템에 필요한 데이터와 기능의 밑그림을 잡습니다.
• 산출물: 요구사항 정의서 (명세서).

Ⅱ. 2단계: 개념적 설계 (Conceptual Design) - 스케치

"현실 세계의 단어들을 동그라미 네모 기호로 바꿔보자!"

• 작업: 컴퓨터나 DB(오라클, MySQL)는 전혀 신경 쓰지 않고, 순수하게 비즈니스 구조(개체, 속성, 관계)만 끄집어냅니다. 앞서 배운 [피터 첸의 ER 모델]이 여기서 쓰입니다.
• 산출물: 개념적 ER 다이어그램 (ERD).
• 특징: 개발자뿐만 아니라 코딩을 모르는 기획자나 사장님도 이해할 수 있는 범용적인 '그림(개념 스키마)'입니다.

Ⅲ. 3단계: 논리적 설계 (Logical Design) - 도면 변환

"그림을 표(테이블) 모양으로 다듬고 중복을 짜내자!"

• 작업:
  1. 목표 DBMS의 데이터 모델에 맞춥니다. (현재 99%는 '관계형 데이터 모델'을 씁니다).
  2. 예쁜 사각형/마름모 그림(ERD)을 컴퓨터가 이해할 수 있는 2차원 표(Table/Relation)의 뼈대로 맵핑(변환)합니다.
  3. 가장 중요한 작업: 이 뼈대들이 이상 현상(Anomaly)을 일으키지 않는지 검사하는 **정규화(Normalization)**를 수행합니다.
• 산출물: 논리적 릴레이션 스키마 (정규화된 테이블 구조도).
• 특징: "오라클을 쓸지 MySQL을 쓸지"는 아직 정해지지 않았지만, '테이블'이라는 형태 자체는 확정됩니다.

Ⅳ. 4단계: 물리적 설계 (Physical Design) - 실제 건축

"하드디스크의 어디에, 어떤 속도로 데이터를 꽂아 넣을까?"

• 작업: 오라클이나 MySQL 같은 구체적인 DB 엔진을 확정 짓고, 디스크의 I/O 성능을 극대화하기 위한 철저한 기계적인 세팅을 합니다.
  • VARCHAR(20) 같은 구체적 데이터 타입을 정합니다.
  • 성능을 위한 인덱스(Index) 설계, 파티셔닝(Partitioning), 클러스터링을 설계합니다.
  • 조인이 너무 무거우면 이 단계에서 **반정규화(De-normalization)**를 감행합니다.
• 산출물: 물리적 스키마 (데이터 저장소 구조), 실제 CREATE TABLE DDL 스크립트.

📢 섹션 요약 비유: 건물을 지을 때, "방 3개 화장실 2개요(요구사항 분석)", "그럼 거실 옆에 주방을 스케치해 드릴게요(개념적 설계)", "도면을 보아하니 기둥이 약하네요, 하중을 분산(정규화)하는 3D 도면으로 고치죠(논리적 설계)", "실제 공사는 A급 철근과 방음벽을 써서 튼튼하게(인덱스, 파티셔닝) 세웁시다(물리적 설계)"로 이어지는 완벽한 건축 프로세스입니다.