주문 상세에 상품명·수량·고객번호·고객명을 함께 저장해 값이 반복됩니다. 어떤 함수 종속을 확인하고 1NF·2NF·3NF에 맞춰 테이블을 어떻게 나누나요?

주문번호, 상품번호, 상품명, 수량, 고객번호, 고객명을 한 릴레이션에 저장하고 (주문번호, 상품번호)를 후보키로 가정하겠습니다. 한 주문의 동일 상품은 한 행만 허용하고 상품명·고객명은 현재 정보를 뜻한다고 가정합니다. 전통적인 관계형 모델에서 한 칸에 원자값이 있고 한 행이 한 상품 항목을 나타내면 1NF의 출발 조건을 만족합니다. 여기서 핵심은 열이 많다는 사실이 아니라 어떤 속성이 어떤 키나 식별자에 의해 결정되는지입니다. 주문 당시 상품명·가격을 보존하는 역사 데이터라면 현재 상품 정보와 다른 사실로 취급해야 합니다.

1NF에서 2NF로 부분 종속을 제거합니다

2NF는 1NF이면서 모든 비주요 속성이 모든 후보키 전체에 완전 함수적으로 종속되어야 한다는 조건입니다. 상품명은 상품번호만으로 결정되므로 복합키의 일부에만 의존하는 부분 함수 종속입니다. 따라서 상품번호·상품명을 상품 테이블로 옮기고, 주문 상세에는 주문번호·상품번호·수량처럼 주문과 상품의 관계 및 항목 사실을 남깁니다. 주문번호만으로 고객번호가 결정되면 고객번호는 주문 테이블로 이동합니다.

후보키가 둘 이상이면 기본키만 보고 2NF를 판단하면 안 됩니다. 모든 후보키에서 일부 속성만으로 비주요 속성이 결정되는지 확인합니다. 배열이나 JSON에 상품 목록을 넣는다고 관계형 정규형 판단이 자동으로 해결되는 것도 아닙니다. 사용하는 저장 모델의 질의·제약 계약을 별도로 검토하겠습니다.

3NF에서 이행 종속을 분리합니다

3NF는 모든 비자명 X→A에서 X가 슈퍼키이거나 A가 후보키에 포함되는 주요 속성이어야 한다는 조건입니다. 주문번호→고객번호이고 고객번호→고객명이라면 주문 테이블에 고객명을 함께 둔 경우 주문번호에서 고객번호를 거쳐 고객명으로 가는 이행 종속이 남습니다. 고객번호·고객명을 고객 테이블에 두고 주문에는 고객번호만 저장하면 고객명 변경 위치가 하나가 됩니다.

이 분해는 수정·삽입·삭제 이상을 줄이지만 조회 시 주문·고객·상품 JOIN이 필요합니다. PostgreSQL·MySQL·SQL Server는 조인 계획, 통계, 클러스터링과 covering 인덱스 비용이 다르므로 정규화 후 실제 조회에서 인덱스·반환량·p99를 확인하겠습니다. 당시 상품명은 상품 테이블의 현재 값을 조인하면 안 되고 주문 상세의 스냅샷 컬럼으로 남겨야 합니다.

정규화는 기계적으로 테이블을 최대한 많이 만드는 작업이 아닙니다. 후보키와 함수 종속이 업무 규칙에 맞는지 먼저 확인하고, 필요한 조인을 감당할 수 없다는 측정 결과가 있을 때만 별도 읽기 모델을 반정규화합니다. 그때도 원본·갱신 책임·불일치 복구를 분리합니다. 검증은 분해 전후의 삽입·이름 변경·주문 삭제와 동시 갱신을 실행해 중복과 사실 소실이 사라지고 외래키·고유 제약이 유지되는지 보는 방식입니다.

또한 가격·상품명은 이름만으로 현재 사실인지 주문 시점의 사실인지 결정되지 않습니다. 주문 당시 가격을 보존해야 한다면 상품 테이블로 분리하는 순간 역사적 의미를 잃을 수 있으므로 주문 상세에 스냅샷을 남깁니다. 고객명이 변경될 때 과거 주문도 새 이름으로 보여야 하는지 역시 조회 요구입니다. 정규형 검사는 이런 업무 의미를 바꾸지 않는 범위에서 수행하고, 조인 비용 때문에 복사본을 둘 때는 원본과의 차이를 탐지할 수 있게 합니다.