22강. 정규화와 좋은 테이블 설계

?1. 이번 강의에서 해결할 문제

한 테이블에 username, region, game time, character를 반복 저장하면 사용자명 변경과 경기 수정 때 여러 행을 고쳐야 합니다. 중복과 갱신 이상을 줄이는 설계를 만듭니다.

✓2. 학습 목표

✓이 강의를 마치면

• 삽입·갱신·삭제 이상을 설명합니다.
• 1NF, 2NF, 3NF의 실용적 목적을 구분합니다.
• 의도적인 비정규화의 비용과 측정 기준을 설명합니다.

◇3. 핵심 개념

1NF는 열 값의 원자성과 반복 그룹 제거, 2NF는 복합 키 일부에만 의존하는 속성 분리, 3NF는 키가 아닌 속성 사이의 이행 의존 제거에 집중합니다. 정규화는 이론 점수가 아니라 사실의 저장 위치를 하나로 만드는 도구입니다.

§4. 단계별 SQL 예시

대상: 잘못된 설계 비교 후 현재 네 테이블 조회, 데이터 변경 없음
파일 경로: C:\dev\game-ranking-db\sql\22-normalization.sql

sql/22-normalization.sql

-- 피해야 할 예: 플레이어와 경기 사실이 매 결과마다 반복됨
-- flat_results(username, region, game_started_at, mode,
--              character_name, score, result)

-- 정규화된 스키마의 책임 확인
SELECT 'players' AS table_name, '플레이어 계정과 지역' AS responsibility
UNION ALL
SELECT 'games', '경기 자체의 시간과 모드'
UNION ALL
SELECT 'match_results', '플레이어와 경기의 관계·결과'
UNION ALL
SELECT 'character_stats', '결과에 속한 캐릭터 전투 지표';

-- 중복 여부 검증
SELECT game_id, player_id, COUNT(*) AS duplicate_count
FROM match_results
GROUP BY game_id, player_id
HAVING COUNT(*) > 1;

PRAGMA foreign_key_check;

PowerShell · 실행 순서

sqlite3 -header -box .\data\game_ranking.db ".read .\sql\22-normalization.sql"
sqlite3 .\data\game_ranking.db ".schema"

→5. 쿼리가 동작하는 이유

각 테이블이 한 종류의 사실만 저장하므로 region은 players 한 행에서만 바뀝니다. match_results의 UNIQUE와 외래 키가 관계 중복과 고아 행을 막습니다. 검증 쿼리 결과가 0행이면 중복 조합이 없습니다.

!6. 자주 하는 실수와 안전한 해결법

!자주 하는 실수

• 무조건 테이블을 많이 나눔: 함께 조회·변경되는 사실과 실제 cardinality를 기준으로 나눕니다.
• 성능 이유로 먼저 중복 저장: 측정 전 비정규화는 일관성 비용만 늘릴 수 있습니다. VIEW, 인덱스, 캐시를 먼저 검토합니다.
• 기존 테이블을 DROP해 재설계: 데이터 손실 위험이 있습니다. 새 스키마 생성, 복사 검증, 트랜잭션 마이그레이션을 계획합니다.

✎7. 직접 실습

✎직접 실습

1. flat_results에서 생길 수 있는 세 가지 이상을 각각 예로 듭니다.
2. characters 마스터 테이블 분리가 필요한 조건을 정합니다.
3. 현재 스키마의 각 비키 열이 어느 키에 의존하는지 표로 작성합니다.

?8. 이해 점검 질문 3개

?이해 점검

1. 사용자 지역이 여러 경기 행에 반복되면 어떤 갱신 이상이 생기나요?
2. 3NF가 줄이려는 이행 의존은 무엇인가요?
3. 비정규화를 고려하기 전에 무엇을 측정해야 하나요?

■9. 핵심 요약

■핵심 요약

정규화는 같은 사실을 한 곳에 저장해 변경 이상을 줄입니다. 성능 최적화는 검증된 쿼리와 측정 후 적용하고 데이터 중복 비용을 명시합니다.