3NF를 만족하는 테이블에도 중복이 남아 BCNF로 더 나누려 합니다. 원래 데이터를 복원할 수 있는지와 기존 제약을 계속 검사할 수 있는지는 어떻게 확인하나요?

BCNF는 3NF보다 강한 정규형입니다. 릴레이션에 성립하는 모든 비자명 함수 종속 X→Y에서 X가 슈퍼키여야 합니다. 3NF는 Y가 단일 속성 A일 때 X가 슈퍼키가 아니더라도 A가 어떤 후보키에 포함되는 주요 속성이면 허용합니다. 그러므로 BCNF 릴레이션은 3NF이지만 그 역은 성립하지 않습니다. 다만 BCNF가 항상 실무에서 더 좋은 답은 아닙니다. 분해 뒤에도 원래 행을 정확히 복원하는지와 애플리케이션이 원래 제약을 각 테이블만 보고 검사할 수 있는지를 따로 확인해야 합니다.

함수 종속과 분해를 먼저 검증합니다

학생, 과목, 담당강사 릴레이션에서 (학생, 과목) → 담당강사와 담당강사 → 과목이 성립한다고 하겠습니다. 후보키는 (학생, 과목)과 (학생, 담당강사)가 될 수 있습니다. 담당강사 → 과목의 결정자 담당강사는 슈퍼키가 아니므로 BCNF를 위반하지만, 오른쪽 과목은 후보키에 포함되는 주요 속성이어서 3NF에서는 허용될 수 있습니다. 담당강사와 과목을 별도 릴레이션으로 만들고 학생과 담당강사의 관계를 다른 릴레이션으로 옮기면 반복되는 강좌 정보는 줄어듭니다.

이때 현재 데이터에서 우연히 성립하는 관계를 함수 종속으로 취급하면 안 됩니다. 한 강사가 실제로 하나의 과목만 담당한다는 업무 규칙이 영속적인지, 기간이나 캠퍼스에 따라 달라지는지 먼저 정해야 합니다. 후보키를 잘못 정하면 BCNF 위반 판단도 달라집니다. 종속성 집합의 폐포를 계산해 어떤 속성이 결정되는지 확인하고, 각 분해의 공통 속성이 한쪽의 키가 되는지 또는 표준 추적표 절차로 무손실성을 검사하겠습니다.

무손실 조인과 종속성 보존은 별개입니다

분해가 무손실 조인(lossless join)이라는 말은 분해한 관계를 공통 속성으로 다시 조인했을 때 원래 유효한 튜플만 복원되고 가짜 조합이 생기지 않는다는 뜻입니다. 반면 종속성 보존(dependency preservation)은 각 분해 테이블의 제약을 따로 검사해도 원래 함수 종속을 모두 확인할 수 있다는 뜻입니다. BCNF 분해 알고리즘은 무손실성을 보장하도록 만들 수 있지만 종속성 보존까지 항상 보장하지는 않습니다.

예를 들어 담당강사 → 과목은 담당강사-과목 테이블에서 검사할 수 있어도 (학생, 과목) → 담당강사는 학생-담당강사와 담당강사-과목을 함께 보지 않으면 판정할 수 없을 수 있습니다. 이 제약을 애플리케이션의 추가 조회나 별도 트리거로 강제하면 쓰기 경로가 복잡해지고 동시성 경계도 새로 생깁니다. 그래서 강한 중복 제거보다 모든 핵심 제약을 DB에서 단순하게 보존하는 3NF를 택할 때도 있습니다.

실제 검증에서는 분해 전후의 함수 종속을 목록화하고, 유효한 원본 인스턴스와 무효한 인스턴스를 만들어 조인 결과와 제약 탐지 결과를 비교하겠습니다. NULL의 의미, 외래키의 지연 검사, 사용하는 DBMS의 제약 표현력까지 포함해야 합니다. 결론은 BCNF라는 이름이 아니라 무손실 복원과 제약 검사 가능성, 조인·갱신 비용을 함께 만족하는 설계입니다.

마지막으로 분해를 실제 스키마로 옮길 때는 함수 종속의 이름만 적지 않고 제약을 어디에서 집행할지 표시하겠습니다. 한 테이블의 UNIQUE만으로 표현되는 종속인지, 여러 테이블을 조인해야 하는 전역 규칙인지가 다릅니다. 전역 규칙을 트리거로 넣을 때도 트리거의 격리 수준과 동시 삽입 순서를 시험하지 않으면 검사가 빈틈을 가질 수 있습니다. 이 비용까지 포함해 3NF와 BCNF 중 운영 가능한 쪽을 선택하겠습니다.