수강생과 강좌 정보를 한 행에 함께 저장했더니 수정·삽입·삭제 때 이상 현상이 생깁니다. 무엇이 문제인가요?

수강 신청, 수강생, 강좌의 사실을 한 행에 반복 저장하면 한 행이 여러 사실의 생명주기를 동시에 표현하게 됩니다. 예를 들어 강좌명과 교수명이 수강 신청마다 복사되어 있으면 강좌명 변경 때 모든 행을 빠짐없이 바꿔야 합니다. 한 행을 놓치면 같은 강좌가 서로 다른 이름으로 보이는 수정 이상이 생깁니다. 수강 신청자가 아직 없어 강좌만 등록할 수 없거나, 강좌만 저장하려고 가짜 수강생을 넣어야 하면 삽입 이상입니다. 마지막 신청을 삭제했더니 강좌 정보까지 사라지면 삭제 이상입니다.

반복이 아니라 결정 관계를 분리합니다

정규화는 값이 반복된다는 이유만으로 테이블을 기계적으로 쪼개는 작업이 아니라, 어떤 식별자가 어떤 사실을 결정하는지와 각 사실의 생명주기를 분리하는 과정입니다. 강좌 ID→강좌명·교수, 학생 ID→학생명, (학생 ID, 강좌 ID)→신청일 같은 종속을 둔다면 강좌 테이블, 학생 테이블, 수강 테이블로 나눌 수 있습니다. 수강 테이블에는 두 엔터티의 연결과 신청 자체의 속성을 저장합니다. 외래키는 존재하지 않는 학생·강좌를 가리키는 수강 행을 막고, 복합 고유 제약은 같은 학생의 중복 신청을 막는 업무 규칙이 될 수 있습니다.

같은 강좌 ID가 여러 수강 행에 나타나는 것은 관계를 연결하는 정상적인 반복입니다. 이를 모두 없애려 하면 연결 자체를 잃습니다. 반대로 교수명 같은 사실을 수강 행마다 복사하면 수정 위치가 여러 곳이 됩니다. 후보키와 함수 종속을 먼저 정하지 않고 테이블 수만 늘리면 다른 이상이나 불필요한 JOIN이 생길 수 있습니다.

정확성과 읽기 비용을 함께 다룹니다

정규화된 모델은 강좌명 수정 위치가 하나라는 장점이 있지만, 화면마다 학생·강좌·신청을 JOIN해야 할 수 있습니다. PostgreSQL·MySQL·SQL Server는 조인 알고리즘, 인덱스 통계, MVCC·클러스터링과 잠금이 다르므로 ‘테이블이 세 개라 느리다’고 단정하지 않고 실행 계획·실제 반환 행·논리 읽기·p99를 측정하겠습니다. 부모와 자식의 일대다를 동시에 JOIN하면 행 증폭으로 결과 크기가 커질 수 있습니다.

조회 병목이 측정되면 원본 정규화 모델을 먼저 유지하고, 요약 테이블·캐시·검색용 읽기 모델을 별도로 둡니다. 복사본을 추가할 때는 원본, 갱신 시점, 중복·순서·소비자 장애, 재구축과 불일치 탐지까지 정합니다. 외래키만 추가한다고 강좌명 중복이나 모든 갱신 이상이 사라지는 것은 아니며, 실제 중복 사실을 한 곳에 모으고 제약으로 관계를 보호해야 합니다. 검증은 강좌명 변경, 신청 없는 강좌 생성, 마지막 신청 삭제, 동시 신청을 실행해 각 사실이 독립적인 생명주기를 갖는지 확인하는 방식입니다.

정규화 후에도 신청일·성적처럼 수강 관계에만 속한 속성을 학생이나 강좌 테이블로 잘못 옮기면 다른 이상이 생깁니다. 각 컬럼이 학생의 사실인지 강좌의 사실인지 관계의 사실인지 분류하고, 후보키·외래키·삭제 정책을 함께 정하겠습니다. 강좌 삭제가 수강 기록 삭제를 의미하지 않는다면 cascade를 무조건 사용하지 않고 제한·보관 상태를 선택합니다. 이런 생명주기 결정이 정규화의 이름보다 데이터 손실을 막는 핵심입니다.