1NF: relation의 각 위치에 relation-valued 반복 그룹을 두지 않음
2NF: 모든 non-prime 속성이 모든 candidate key 전체에 완전 함수 종속
3NF: X -> A마다 X가 superkey이거나 A가 prime attribute

종속성 찾기

주문 row마다 고객 주소를 반복 저장하면 고객 주소 변경 시 여러 row를 모두 수정해야 합니다. 고객 정보와 주문 정보를 분리하고 key로 연결하면 고객 주소라는 사실의 owner가 한 곳으로 모입니다.

정규형은 column type만 보고 자동 판정할 수 없습니다. 어떤 속성이 어떤 key에 함수적으로 의존하는지 업무 규칙을 알아야 합니다.

예를 들어 (student_id, course_id) -> grade이고 course_id -> course_name이면 course_name은 composite candidate key의 일부에만 의존하므로 2NF 위반입니다. 또 employee_id -> department_id이고 department_id -> department_name이면 department_name은 key에 이행적으로 의존하므로 일반적인 3NF 분리 대상입니다.

Candidate key가 여러 개라면 primary key 하나만 검사해서는 안 됩니다. Prime attribute는 어떤 candidate key에든 포함되는 속성이며, 3NF의 정확한 판정에는 이 구분이 필요합니다.

비정규화

읽기 성능과 snapshot 보존을 위해 값을 중복 저장할 수 있지만, 어느 값이 원본이고 어떻게 갱신할지 명시해야 합니다. Measurement 없이 join이 느릴 것이라는 추측만으로 중복부터 만들지 않습니다.

Event나 주문 당시 가격처럼 역사적 사실을 보존하려는 중복은 현재 상품 가격의 단순 복사와 의미가 다릅니다.

자주 틀리는 점

• 1NF의 “원자적” 의미를 모든 문자열을 더 작은 column으로 쪼개라는 규칙으로 보지 않습니다.
• Surrogate key를 추가했다고 2NF·3NF 문제가 자동으로 해결되지는 않습니다.
• 정규화와 index 설계를 같은 작업으로 보지 않습니다.
• 비정규화에는 동기화·복구 비용이 따라옵니다.