7강. 정규화 1~3정규형과 비정규화 판단

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

경기 결과 행마다 플레이어 닉네임과 캐릭터 이름을 반복하면 이름을 바꿀 때 일부 행만 수정되는 이상 현상이 생깁니다. 1~3정규형으로 사실의 저장 위치를 정하고 비정규화가 필요한 조건을 분리합니다.

✓2. 학습 목표

✓이 강의를 마치면

• 1NF, 2NF, 3NF를 함수 종속성 관점에서 설명합니다.
• 삽입·수정·삭제 이상을 발견합니다.
• 비정규화를 측정과 동기화 전략이 필요한 최적화로 판단합니다.

◇3. 핵심 개념

1NF는 한 칸에 원자값을 두고 반복 그룹을 제거합니다. 2NF는 복합 키 일부에만 의존하는 속성을 분리하고, 3NF는 키가 아닌 속성에 의존하는 속성을 분리합니다. 정규화의 목표는 테이블 수 증가가 아니라 한 사실을 한 장소에 저장하는 것입니다. 비정규화는 조회 비용을 줄이는 대신 중복 동기화 책임을 만듭니다.

§4. 단계별 예시

문서 경로: C:\dev\game-ranking-service\docs\database\07-normalization.md

docs/database/07-normalization.md

나쁜 결과 테이블:
(game_id, player_id, player_nickname, character_id, character_name, score)

함수 종속:
player_id → player_nickname
character_id → character_name
(game_id, player_id) → character_id, score

분해:
players(player_id, nickname)
characters(character_id, display_name)
match_results(game_id, player_id, character_id, score)

database/sql/07-normalization-check.sql

-- 중복 이름이 불일치하는지 점검하는 진단 쿼리
SELECT player_id, count(DISTINCT player_nickname) AS nickname_versions
FROM legacy_match_results
GROUP BY player_id
HAVING count(DISTINCT player_nickname) > 1;

PowerShell · 진단만 실행

psql -d game_ranking_dev -f .\database\sql\07-normalization-check.sql

§5. 동작 원리

닉네임은 player_id에 의존하므로 경기 참가 사실과 같은 행에 저장할 이유가 없습니다. 분해 후 match_results는 참가 사실만, players는 플레이어 사실만 관리합니다. 과거 당시 닉네임 보존이 요구사항이라면 단순 중복이 아니라 시점 이력이라는 별도 모델로 설계해야 합니다.

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

!자주 하는 실수

• 정규화를 테이블 쪼개기로 암기: 먼저 키와 함수 종속을 적습니다.
• JOIN이 싫어 즉시 중복 저장: 실행 계획과 응답 시간을 측정하고 캐시·뷰·집계 테이블 대안도 검토합니다.
• 비정규화 동기화 규칙 없음: 원본과 파생값의 소유자, 갱신 트랜잭션, 재계산 절차를 함께 문서화합니다.

✎7. 직접 실습

✎직접 실습

1. 레거시 한 테이블의 후보 키와 함수 종속을 표시합니다.
2. 1NF부터 3NF까지 단계별 분해 결과를 작성합니다.
3. current_rating을 players에 둘 때 원본 사건과 재계산 방법을 정의합니다.

?8. 이해 점검 질문 3개

?이해 점검

1. 2NF가 특히 복합 키에서 다루는 문제는 무엇인가요?
2. 3NF 위반이 수정 이상을 만드는 과정은 무엇인가요?
3. 비정규화를 승인하기 전에 필요한 증거는 무엇인가요?

■9. 핵심 요약

■핵심 요약

정규화는 하나의 사실을 한 장소에 저장해 이상 현상을 줄입니다. 비정규화는 성능 측정 후 원본·동기화·복구 방법까지 확보했을 때 선택하는 운영 최적화입니다.