Unit 1.1 — JOIN이 필요한 이유 (정규화의 결과)
F-LAB JAVA · 7주차 · Phase 1 · SQL JOIN: 관계형 DB의 본질
📚 7주차 시작 — Part A: 데이터 모델링과 ORM
📌 학습 목표
이 Unit을 끝내면 다음을 답할 수 있어야 한다.
- JOIN 이 왜 필요한가 ?
- 정규화 (Normalization) 의 정의는?
- 정규화의 효과 (중복 제거) 는?
- 정규화의 비용 (JOIN 필요) 는?
- employees / departments 예시 분석은?
- 하나의 정보가 여러 테이블에 분산 의 의미는?
- 비정규화 (역정규화) 시나리오는?
- JOIN 등장 배경 은?
- 정규화 장단점 트레이드오프 는?
🎯 핵심 한 문장
관계형 DB 는 정규화 (Normalization) 를 통해 데이터 중복을 제거하기 때문에 하나의 정보가 여러 테이블에 분산되며, "이 직원은 어느 부서?" 같은 자연스러운 질문에 답하려면 흩어진 테이블을 다시 합쳐야 해서 JOIN 이 필요하다.
관계형 DB 의 핵심 설계 원칙은 정규화 — 데이터 중복을 제거하고 무결성을 높이기 위해 큰 테이블을 작은 테이블로 분할한다.
예를 들어 직원 정보를 한 테이블에 다 넣지 않고 employees (직원) 테이블과 departments (부서) 테이블 로 나누면, 부서명을 한 곳에서만 관리해 부서명 변경 시 한 번만 수정하면 된다 (중복 제거).
하지만 비용도 있다 — "Alice 가 어느 부서인가?" 같은 자연스러운 질문에 답하려면 두 테이블을 다시 합쳐야 하므로 JOIN 연산이 필요해진다.
즉 JOIN 은 단순한 SQL 문법이 아니라 정규화의 필연적 결과 이며, 7주차의 모든 학습 (ORM/JPA/연관관계 매핑) 의 출발점이다.
비유 — 정리된 책장 (정규화) 과 책 찾기 (JOIN)
정규화 = 정리된 책장:
정규화 전 (하나의 큰 테이블):
- 한 책상에 책/저자정보/출판사정보 모두
- "민음사" 정보가 책 100권에 100번
- 민음사 주소 바뀌면 100번 수정
- 중복 ↑
정규화 후 (책장 분리):
- 책 책장 (제목, 저자_id, 출판사_id)
- 저자 책장 (저자_id, 저자명)
- 출판사 책장 (출판사_id, 주소)
- 민음사 주소 바뀌면 1번 수정
- 중복 ↓
JOIN (책 찾기):
- "이 책의 저자명?" 답하려면
- 책 책장 → 저자_id 확인
- 저자 책장에서 그 id 찾기
- 두 책장 합치기 = JOIN
ILIC 의 정규화:
- shipments (배송)
- bookings (예약)
- customers (고객)
- 모두 분리 → 정규화
- "이 배송의 고객명?" → JOIN
트레이드오프:
- 중복 ↓, 무결성 ↑
- JOIN 비용 ↑
- 정규화 = 절약 + 성능 비용→ JOIN = 정규화의 결과 (분산된 데이터를 합쳐야), 트레이드오프 (무결성 ↑ vs 성능 ↓).
🧭 9개 섹션 로드맵
1. JOIN 이 필요한 이유
2. 정규화의 정의
3. 정규화의 효과 (중복 제거)
4. 정규화의 비용 (JOIN 필요)
5. employees / departments 예시
6. 여러 테이블 분산
7. 비정규화 (역정규화)
8. JOIN 등장 배경
9. 면접 + 자기 점검1️⃣ JOIN 이 필요한 이유
1.1 핵심 질문
JOIN 이 필요한 이유:
"왜 하나의 정보가
여러 테이블에 흩어져 있나?"
→ 정규화 때문
→ 그래서 합쳐야1.2 일상 질문
일상 질문:
"Alice 의 부서는?"
"이 주문의 고객명은?"
"이 배송의 운임은?"
→ 모두 두 개 이상 테이블 정보
→ JOIN 필요1.3 한 테이블이면?
한 테이블이면? (반정상):
직원_정보:
- 사번, 이름, 부서명, 부서주소, ...
문제:
- 부서 정보가 직원마다 중복
- 부서명 바뀌면 모든 행 수정
- 부서만 있는 정보 저장 X
- 데이터 무결성 ↓
→ 그래서 정규화1.4 RDB 의 설계 정신
RDB 의 설계 정신:
- 중복 제거 (정규화)
- 무결성 우선
- JOIN 으로 합침
→ JOIN = RDB 의 본질1.5 ILIC 의 맥락
JOIN 필요성 (ILIC)
ILIC 102 테이블:
- shipments (배송)
- bookings (예약)
- customers (고객)
- freights (운임)
- shipment_items (배송 품목)
- 모두 정규화로 분리
"이 배송의 고객명/운임/품목 전부?":
- shipments + bookings + customers + freights + shipment_items
- JOIN 5개 테이블
→ 자연스러운 질문에 JOIN 필수
→ ILIC = 정규화 + JOIN 의 실제1.6 자기 점검 답변
JOIN 이 왜 필요한가?
답:
1. 핵심:
- 정규화로 분산된 데이터
-
일상 질문:
- 여러 테이블 정보
-
한 테이블이면:
- 중복/무결성 ↓
-
본질:
- RDB 의 정신
2️⃣ 정규화의 정의
2.1 정규화
정규화 (Normalization):
데이터 중복을 제거하기 위해:
- 큰 테이블을 분할
- 작은 테이블로
- 관계 설정 (FK)
→ 1NF, 2NF, 3NF, BCNF, 4NF, 5NF2.2 정규형 (Normal Form)
정규형:
1NF (제1정규형):
- 원자값 (한 칸에 한 값)
- 반복 그룹 X
2NF (제2정규형):
- 1NF + 부분 함수 종속 제거
3NF (제3정규형):
- 2NF + 이행 함수 종속 제거
BCNF:
- 3NF 의 더 엄격한 버전
→ 실무는 보통 3NF 까지2.3 목적
정규화 목적:
1. 데이터 중복 제거
2. 데이터 무결성 ↑
3. 이상 현상 방지
- 삽입 이상
- 수정 이상
- 삭제 이상2.4 이상 현상
이상 현상 (정규화 안 했을 때):
수정 이상:
- 부서명 바뀌면 100 행 수정
- 누락 시 데이터 불일치
삽입 이상:
- 직원 없는 부서 못 넣음
- (직원 테이블에만 부서 정보)
삭제 이상:
- 마지막 직원 삭제 시
- 부서 정보도 사라짐2.5 ILIC 의 맥락
정규화 (ILIC)
ILIC 가 정규화 안 했다면:
shipment_flat (하나의 큰 테이블):
- id, bl_no, status,
- customer_id, customer_name, customer_address, customer_phone,
- port_loading, port_loading_country,
- freight_amount, freight_currency,
- item_1_name, item_1_quantity,
- item_2_name, item_2_quantity,
- ...
문제:
- 한 고객 100 배송 → 고객명 100 번 중복
- 고객 주소 바뀌면 100 번 수정
- 품목 가변 → 컬럼 무한 증가
정규화 후 (ILIC 실제):
- shipments, customers, ports, freights, shipment_items
- 분리, FK 로 연결
- JOIN 으로 합치기2.6 자기 점검 답변
정규화 (Normalization) 의 정의는?
답:
1. 정규화:
- 중복 제거, 분할
-
정규형:
- 1NF~5NF
-
목적:
- 무결성
-
이상 현상:
- 삽입/수정/삭제
3️⃣ 정규화의 효과 (중복 제거)
3.1 중복 제거
중복 제거:
같은 정보:
- 한 곳에서만 저장
- 변경 시 한 번만
- 일관성 ↑3.2 예시 — 부서 정보
부서 정보 (정규화 전):
직원 테이블:
| id | name | dept_name | dept_addr |
|----|-------|--------------|----------------|
| 1 | Alice | Engineering | 서울 강남 |
| 2 | Bob | Engineering | 서울 강남 |
| 3 | Carol | Engineering | 서울 강남 |
→ "Engineering, 서울 강남" 이 3번 중복
→ 부서 이전 시 3번 수정
정규화 후:
직원: { id, name, dept_id }
부서: { id, dept_name, dept_addr }
→ 부서 정보 1번만
→ 이전 시 1번 수정3.3 무결성 ↑
무결성 ↑:
중복 X:
- 데이터 불일치 X
- "Engineering" vs "engineering"
- 누락 위험 X
- 신뢰3.4 저장 공간
저장 공간:
중복 ↓ = 공간 ↓:
- 디스크 절약
- 캐시 효율
- 백업/복원 빠름
하지만:
- 현대는 공간 < 무결성
- 무결성이 더 중요3.5 ILIC 의 맥락
-- 중복 제거 효과 (ILIC)
-- 고객 테이블 (정규화 후)
CREATE TABLE customers (
id BIGINT PRIMARY KEY,
name VARCHAR(100),
address VARCHAR(200),
phone VARCHAR(20)
);
-- 배송 테이블 (FK 로 참조)
CREATE TABLE shipments (
id BIGINT PRIMARY KEY,
bl_no VARCHAR(50),
customer_id BIGINT,
FOREIGN KEY (customer_id) REFERENCES customers(id)
);
-- 효과:
-- ABC 무역이 1000 배송 등록 시:
-- - 정규화 X: "ABC 무역" 정보 1000 번 중복
-- - 정규화 O: customers 에 1번, shipments 에 customer_id 만
-- ABC 무역 주소 변경:
-- - 정규화 X: 1000 행 UPDATE
-- - 정규화 O: 1 행 UPDATE
-- → 압도적 차이3.6 자기 점검 답변
정규화의 효과 (중복 제거) 는?
답:
1. 중복 제거:
- 한 곳 저장
-
예시:
- 부서명 1번만
-
무결성:
- 불일치 X
-
공간:
- 절약
4️⃣ 정규화의 비용 (JOIN 필요)
4.1 비용
정규화의 비용:
데이터 분산:
- 여러 테이블
- 자연 질문에 JOIN 필요
- 성능 ↓ (JOIN 비용)4.2 JOIN 의 성능 비용
JOIN 성능:
- 두 테이블의 매칭 (조인 알고리즘)
- 인덱스 활용 중요
- JOIN 개수 ↑ → 비용 ↑
- 5+ JOIN 은 느림4.3 트레이드오프
트레이드오프:
정규화 ↑:
- 무결성 ↑
- 중복 ↓
- JOIN 비용 ↑
정규화 ↓ (비정규화):
- 무결성 ↓
- 중복 ↑
- JOIN 비용 ↓ (조회 빠름)
→ 균형4.4 현실의 선택
현실의 선택:
OLTP (트랜잭션):
- 3NF 정도 정규화
- 무결성 우선
OLAP (분석):
- 비정규화
- 조회 성능 우선
- Star Schema, Snowflake
→ 시스템 성격4.5 ILIC 의 맥락
JOIN 비용 (ILIC)
ILIC OLTP 시스템:
- 3NF 정도
- JOIN 필요
배송 상세 조회:
SELECT s.*, c.name, p.port_name, f.amount
FROM shipments s
JOIN customers c ON s.customer_id = c.id
JOIN ports p ON s.port_id = p.id
LEFT JOIN freights f ON f.shipment_id = s.id
WHERE s.id = ?
→ 4 테이블 JOIN
→ 인덱스 (FK) 잘 만들면 빠름
→ ILIC 의 표준 패턴
통계 조회 (느림):
- 10+ 테이블 JOIN
- 별도 분석 DB / 캐시 / 비정규화 고려4.6 자기 점검 답변
정규화의 비용 (JOIN 필요) 는?
답:
1. 비용:
- JOIN 필요
-
성능:
- JOIN 비용
-
트레이드오프:
- 무결성 vs 성능
-
현실:
- OLTP 정규화, OLAP 비정규화
5️⃣ employees / departments 예시
5.1 예시 데이터
employees (직원):
┌────┬─────────┬─────────────┐
│ id │ name │ dept_id │
├────┼─────────┼─────────────┤
│ 1 │ Alice │ 101 │
│ 2 │ Bob │ 102 │
│ 3 │ Charlie │ NULL │
└────┴─────────┴─────────────┘
departments (부서):
┌─────┬──────────────┐
│ id │ dept_name │
├─────┼──────────────┤
│ 101 │ HR │
│ 102 │ Engineering │
│ 103 │ Sales │
└─────┴──────────────┘5.2 관찰
관찰:
Alice 는 dept_id=101 → HR
Bob 은 dept_id=102 → Engineering
Charlie 는 dept_id=NULL → 부서 미배정
Sales (103) 부서는 직원 없음
→ 정규화 결과5.3 "Alice 의 부서?" 질문
"Alice 의 부서?":
1. employees 에서 Alice 찾음 → dept_id=101
2. departments 에서 id=101 찾음 → "HR"
→ 두 테이블 조회
→ JOIN5.4 JOIN 으로 답
-- JOIN 으로 답
SELECT e.name, d.dept_name
FROM employees e
JOIN departments d ON e.dept_id = d.id
WHERE e.name = 'Alice';
-- 결과
-- name | dept_name
-- ------|----------
-- Alice | HR5.5 4가지 JOIN
4가지 JOIN (다음 Unit 들):
INNER JOIN:
- 양쪽 매칭만 (Alice, Bob)
- Charlie 제외 (dept_id NULL)
LEFT JOIN:
- 왼쪽 전부 + 매칭 (Alice, Bob, Charlie)
RIGHT JOIN:
- 오른쪽 전부 + 매칭 (HR, Eng, Sales)
FULL OUTER:
- 양쪽 전부 (모두 등장)5.6 ILIC 의 맥락
-- ILIC 의 직원/부서 패턴
-- (실제 ILIC 는 employees 아니라 다른 테이블)
CREATE TABLE shipments (
id BIGINT PRIMARY KEY,
bl_no VARCHAR(50),
customer_id BIGINT,
port_id BIGINT
);
CREATE TABLE customers (
id BIGINT PRIMARY KEY,
name VARCHAR(100)
);
CREATE TABLE ports (
id BIGINT PRIMARY KEY,
port_name VARCHAR(100)
);
-- 배송 정보 + 고객명 + 항구명
SELECT s.bl_no, c.name AS customer_name, p.port_name
FROM shipments s
JOIN customers c ON s.customer_id = c.id
JOIN ports p ON s.port_id = p.id;
-- → ILIC 의 표준 패턴 (정규화 + JOIN)5.7 자기 점검 답변
employees / departments 예시 분석은?
답:
1. 두 테이블:
- employees + departments
-
관계:
- dept_id (FK)
-
질문:
- "Alice 부서?" → JOIN
-
4가지 JOIN:
- 다양한 결과
6️⃣ 여러 테이블 분산
6.1 분산의 의미
여러 테이블 분산:
하나의 도메인 정보:
- 여러 테이블에 나뉨
- FK 로 연결
- JOIN 으로 합침
→ 정규화의 본질6.2 예시 — 주문 정보
주문 정보 (4개 테이블):
orders (주문):
- id, customer_id, order_date
customers (고객):
- id, name, email
order_items (주문 품목):
- id, order_id, product_id, quantity
products (상품):
- id, name, price
→ "주문 1번의 모든 정보":
4 테이블 JOIN6.3 1:N 관계
1:N 관계 (대표):
customer 1 : N orders
order 1 : N order_items
product 1 : N order_items
→ FK 로 1:N 표현6.4 N:M 관계
N:M 관계 (중간 테이블):
학생 N : M 과목 (수강)
students (학생)
courses (과목)
enrollments (수강) — 중간 테이블
- student_id, course_id
→ N:M = 1:N + 1:N 분해6.5 ILIC 의 맥락
-- ILIC 의 도메인 분산 예시
-- 한 배송의 모든 정보 (분산):
-- shipments (1) + customers (1) + ports (2) + freights (N) + shipment_items (N)
-- + bookings (1) + bill_of_lading (1) + ...
-- 한 배송 조회 시:
SELECT
s.*,
c.name AS customer_name,
pl.port_name AS port_loading,
pd.port_name AS port_discharge,
f.amount AS freight_amount,
si.item_name
FROM shipments s
JOIN customers c ON s.customer_id = c.id
LEFT JOIN ports pl ON s.port_loading_id = pl.id
LEFT JOIN ports pd ON s.port_discharge_id = pd.id
LEFT JOIN freights f ON f.shipment_id = s.id
LEFT JOIN shipment_items si ON si.shipment_id = s.id
WHERE s.id = ?;
-- → 5+ 테이블 JOIN
-- → ILIC 의 일반적인 조회 패턴
-- → 인덱스 (FK) 잘 만들면 충분히 빠름6.6 자기 점검 답변
하나의 정보가 여러 테이블에 분산의 의미는?
답:
1. 분산:
- 도메인 → 여러 테이블
-
연결:
- FK
-
1:N:
- 대표
-
N:M:
- 중간 테이블
7️⃣ 비정규화 (역정규화)
7.1 비정규화
비정규화 (Denormalization):
정규화 반대:
- 의도적 중복 허용
- JOIN 줄임
- 조회 성능 ↑
- 무결성 ↓ (트레이드)7.2 언제 사용
언제 사용:
- 조회 매우 빈번 (읽기 위주)
- JOIN 너무 많아 느림
- 분석 / 리포트 / 캐시
- 데이터 변경 적음
→ 신중한 선택7.3 방법
비정규화 방법:
1. 컬럼 추가:
- shipments 에 customer_name 도 저장
- JOIN 없이 조회
2. 요약 테이블:
- 일별 통계 미리 계산
- shipment_daily_summary
3. 캐시:
- Redis 에 최종 결과
- DB JOIN 안 함7.4 위험
위험:
- 데이터 불일치
- customer_name 바뀌면 shipments 도 갱신
- 누락 시 불일치
- 갱신 복잡
- 한 정보 여러 곳
- 모두 동기화
→ 트리거 / 애플리케이션 로직 보완7.5 ILIC 의 맥락
-- ILIC 의 비정규화 예시 (가상)
-- 정규화 (기본):
SELECT s.*, c.name FROM shipments s JOIN customers c ON s.customer_id = c.id
-- 매 조회 JOIN
-- 비정규화 (조회 매우 빈번 시):
ALTER TABLE shipments ADD COLUMN customer_name VARCHAR(100);
-- shipments 에 고객명도 저장
-- 조회 시 JOIN X
SELECT * FROM shipments WHERE customer_id = 1;
-- 비용:
-- - 고객명 변경 시 customers + shipments 모두 갱신
-- - 트리거 또는 애플리케이션 로직
-- ILIC 실무:
-- - OLTP 는 정규화 기본
-- - 통계/리포트는 별도 요약 테이블 (비정규화)
-- - 또는 Redis 캐시7.6 자기 점검 답변
비정규화 (역정규화) 시나리오는?
답:
1. 비정규화:
- 의도적 중복
-
언제:
- 조회 빈번
-
방법:
- 컬럼 추가/요약/캐시
-
위험:
- 무결성
8️⃣ JOIN 등장 배경
8.1 자연스러운 흐름
JOIN 등장 흐름:
1. RDB 가 정규화 도입 (중복 제거)
2. 데이터가 여러 테이블 분산
3. 자연 질문은 여러 테이블 정보 필요
4. → JOIN 연산 등장
→ RDB 의 필수 기능8.2 SQL 표준
SQL 표준:
ANSI SQL:
- INNER JOIN
- LEFT/RIGHT/FULL OUTER JOIN
- CROSS JOIN
- SELF JOIN (같은 테이블)
→ 거의 모든 RDB 지원8.3 7주차 학습 흐름
7주차 학습 흐름:
Phase 1 (현재):
- JOIN 4가지 (1.1 → 1.5)
Phase 2-4:
- ORM 패러다임
- JPA 입문
- 엔티티 매핑
→ JOIN 이해 = JPA 의 출발
→ "객체와 관계 모델 미스매치" 의 핵심8.4 JOIN ≠ JPA 의 끝
JOIN ≠ JPA 의 끝:
JPA:
- 자동으로 JOIN SQL 생성
- 객체 그래프로 표현
- @OneToMany, @ManyToOne 등
하지만:
- JOIN 동작은 알아야
- JPA 가 만든 SQL 확인 위해
- N+1 문제 등 진단
→ JOIN 기초 → JPA 깊이8.5 ILIC 의 맥락
7주차 학습 → ILIC
ILIC 가 JPA 전:
- JdbcTemplate + SQL 직접
- JOIN 직접 작성
ILIC 가 JPA 후:
- @ManyToOne, @OneToMany 어노테이션
- JOIN SQL 자동 생성
- 객체 그래프로 탐색
Shipment shipment = repository.findById(1);
Customer customer = shipment.getCustomer();
// 내부적으로 JOIN SQL 자동
// 또는 Lazy Loading
→ JOIN 이해가 JPA 활용의 기반8.6 자기 점검 답변
JOIN 등장 배경은?
답:
1. 흐름:
- 정규화 → 분산 → JOIN
-
SQL 표준:
- 4가지 + a
-
7주차:
- JOIN → ORM → JPA
-
JPA 도:
- JOIN 이해 필수
9️⃣ 면접 + 자기 점검
9.1 면접 단골 질문 매핑
| Q | 핵심 답변 |
|---|---|
| JOIN 필요한 이유? | 정규화 분산 |
| 정규화? | 중복 제거 |
| 정규형? | 1NF~5NF |
| 이상 현상? | 삽입/수정/삭제 |
| 중복 제거 효과? | 무결성 ↑ |
| JOIN 비용? | 분산 합치기 |
| 트레이드오프? | 무결성 vs 성능 |
| 비정규화? | 의도적 중복 |
| OLTP vs OLAP? | 정규화 vs 비정규화 |
| 4가지 JOIN? | INNER/LEFT/RIGHT/FULL |
9.2 자기 점검 체크리스트
JOIN 이유
- 정규화 분산
정규화
- 정의
효과
- 중복 제거
비용
- JOIN 필요
예시
- employees/departments
분산
- 여러 테이블
비정규화
- 시나리오
등장
- 자연스러운
9.3 추가 심화 질문
Q1: 1NF, 2NF, 3NF 차이?
답:
- 1NF: 원자값 (한 칸에 한 값)
- 2NF: 1NF + 부분 종속 제거
- 3NF: 2NF + 이행 종속 제거
- 실무는 3NF 까지
Q2: BCNF?
답:
- 3NF 의 더 엄격
- 모든 결정자가 후보 키
- 거의 3NF 와 차이 X
- 학술적 더 강함
Q3: 반정규화 vs 비정규화?
답:
- 같은 의미 (Denormalization)
- 정규화 반대
- 의도적 중복
Q4: Star Schema vs Snowflake?
답:
- Star: 중심 fact + 주변 dimension (비정규화)
- Snowflake: dimension 도 정규화
- OLAP 설계 패턴
Q5: ORM 시대에 JOIN 학습 가치?
답:
- JPA 가 SQL 자동 생성
- 하지만 SQL 확인/디버깅 필요
- N+1 문제 진단
- 복잡 쿼리는 직접
🎯 핵심 요약 — 3줄 정리
1. JOIN = 정규화의 결과
- 관계형 DB 는 중복 제거를 위해 정규화 → 데이터가 여러 테이블에 분산
- 자연스러운 질문 ("Alice 의 부서?") 에 답하려면 합쳐야 → JOIN
2. 정규화의 트레이드오프
- 효과: 중복 제거, 무결성 ↑, 이상 현상 방지 (삽입/수정/삭제)
- 비용: JOIN 필요 (성능 ↓), 복잡도 ↑
3. 7주차의 출발
- JOIN 이해 → ORM/JPA 의 객체 그래프 매핑 이해
- ILIC 의 102 테이블도 정규화 + JOIN 구조
📚 다음으로...
Unit 1.2 — INNER JOIN (교집합)
이번 Unit에서 JOIN 의 배경을 봤다면, 다음은 INNER JOIN (첫 번째 종류).
- INNER JOIN: 양쪽 매칭만
- ON vs WHERE 차이
- 단순 카르테시안 vs JOIN
Phase 1 진행 상황
📚 Phase 1 — SQL JOIN
✅ Unit 1.1 JOIN 이 필요한 이유 ← 여기
⏭ Unit 1.2 INNER JOIN
⏭ Unit 1.3 LEFT/RIGHT JOIN
⏭ Unit 1.4 FULL OUTER JOIN
⏭ Unit 1.5 JOIN 선택 가이드 ★깊이7주차 누적 진행
🗂️ Part A — 데이터 모델링과 ORM
📚 Phase 1 (1/5 진행)
총: 1/24 Unit📚 7주차 시작 — Part A: 데이터 모델링과 ORM
Software Developer