서로 다른 사실을 한 표에 반복 저장하면 일부만 고쳐지거나 함께 사라질 수 있다. 함수 종속을 확인하고 사실의 단위로 나눈다.
book_id → shelf_code이고 shelf_code → shelf_name이라는 업무 규칙을 가정하자. 책마다 서가 이름까지 저장하면 같은 서가 이름이 반복된다. 서가 이름을 일부 행에서만 고치면 수정 이상이 생긴다. 마지막 책을 지울 때 서가 정보도 없어지면 삭제 이상이다.
books(book_id, title, shelf_code)와 shelves(code, name)로 나누면 서가 이름을 한 곳에서 관리한다. 분해 뒤 원래 관계를 잘못된 추가 행 없이 복원하는 무손실 조인인지도 확인한다.
3NF는 비자명한 X → A마다 X가 슈퍼키이거나 A가 어떤 후보키에 포함되는 주요 속성이면 허용한다. BCNF는 주요 속성 예외 없이 결정자 X가 슈퍼키여야 한다. 더 강한 정규형일수록 언제나 최선인 것은 아니며 종속성 보존과 실제 작업도 살핀다.
- 01 →
업무 규칙을 적는다
- 02 →
종속을 찾는다
- 03 →
사실을 나눈다
- 04
복원과 갱신을 확인한다
같은 상황에서 비교하기
| 개념 | 기준 | 확인할 점 |
|---|---|---|
| 1NF | 도메인의 값을 원자적으로 다룬다 | 원자성은 선택한 데이터 모델의 문맥에서 판단한다 |
| 2NF | 후보키의 일부에 대한 비주요 속성의 종속을 제거한다 | 복합 후보키와 부분 종속을 확인한다 |
| 3NF | 결정자가 슈퍼키이거나 오른쪽 속성이 주요 속성 | 모든 결정자가 키라는 정의와 다르다 |
| BCNF | 비자명한 종속의 결정자는 슈퍼키 | 3NF보다 엄격하다 |
도서관 예제로 따라가기
별도 학습 가정 R(독자, 분야, 담당자)에서 (독자, 분야) → 담당자, 담당자 → 분야만 있다고 하자. 후보키는 (독자, 분야)와 (독자, 담당자)다. 담당자는 슈퍼키가 아니지만 분야는 주요 속성이므로 3NF는 만족하고 BCNF는 위반한다.
공통 예제 데이터 보기
| book_id | title | shelf_code | pages |
|---|---|---|---|
| 1 | SQL 입문 | DB | 120 |
| 2 | 설계 노트 | SW | 200 |
| 3 | 관계 모델 | DB | NULL |
| 4 | 분산 읽기 | NULL | 160 |
| loan_id | book_id |
|---|---|
| 11 | 1 |
| 12 | 1 |
| 13 | 2 |
내 말로 설명해 보기
3NF가 허용하지만 BCNF가 허용하지 않는 조건을 말해 보자.
설명 예시 확인
결정자가 슈퍼키가 아니어도 오른쪽 속성이 주요 속성이면 3NF에서 허용할 수 있다. BCNF에는 이 예외가 없다.
참고한 자료
이전 개념 자료와의 연결
이전 자료에서 다룬 주제를 이어받아 설명과 예시를 다시 썼어요.
- 이상 현상과 반정규화
- 3NF와 BCNF: 결정자가 키인가