공유 원인 하나

학생의 수강 사실과 교수의 담당 사실이 같은 행에 묶여 있습니다.

그래서 교수-과목 정보가 학생 행의 생성·수정·삭제에 끌려다니고, BCNF 위반이 바로 삽입 이상·갱신 이상·삭제 이상으로 이어집니다.

왜 흔들리는가 교수 → 과목 사실이 독립 테이블이 아니라 수강 행 안에 중복 저장됩니다.

담당 정보가 별도로 분리되지 않아, 학생이 없으면 기록할 수 없고, 같은 교수가 여러 행에 나오면 바꿀 때마다 모두 수정해야 합니다.

혼합된 테이블 안에서 담당 사실이 반복됨

학번 과목 교수
1001 DB 이교수
1002 DB 이교수
1001 OS 최교수
같은 담당 사실: 이교수 → DB가 학생 1001, 1002 두 행에 걸쳐 반복됩니다.

한 행이 사실 두 종류를 동시에 담음

학생 관점 누가 어떤 수업을 듣는가

수강 사실은 학생이 생기거나 취소할 때 자연스럽게 변합니다.

교수 관점 누가 어떤 과목을 담당하는가

이 사실은 학생 수와 무관해야 하지만, 지금은 수강 행이 있어야만 함께 남습니다.

같은 구조에서 세 가지 이상 현상이 갈라집니다

원인은 하나지만, 행 수준에서는 기록 불가·중복 수정·정보 소실로 나타납니다.

이상 행 수준에서 실제로 벌어지는 일 결과
삽입 김교수가 AI를 담당한다는 사실만 기록하고 싶어도, 수강 행을 만들려면 학번이 필요합니다. 수강 학생이 없으면 담당 사실을 저장할 수 없습니다.
갱신 이교수의 담당 과목이 DB → ML로 바뀌면, 1001·1002 두 행을 모두 수정해야 합니다. 한 행만 바뀌면 같은 교수의 담당 과목이 서로 달라져 불일치가 생깁니다.
삭제 1001 학생이 OS 수강을 취소해 그 행을 지우면, 그 행에 같이 있던 최교수-OS 사실도 함께 사라집니다. 수강 취소가 담당 정보 삭제로 번집니다.
정리: BCNF 분해가 필요한 이유는 같은 결정자 사실을 학생 수강 행과 분리해 한 번만 저장하려는 데 있습니다.