(edX stanfordOnline Databases: Modeling and Theory) Shortcomings of BCNF/4NF

https://www.edx.org/learn/databases/stanford-university-databases-modeling-and-theory

StanfordOnline: Databases: Modeling and Theory | edX

 

* BCNF

Whenever we have functional dependency on a relation

the left hand side needs to be a key or contain a key.

 

* Fourth Normal Form

Whenever we have a non-trivial multi value dependency,

the left-hand side is a key.

 

FD는 MTV의 부분집합이기 때문에
Fourth Normal Form은 BCNF를 내포한다.

 

 

* BCNF나 Fourth normal form이 필요하지 않은 경우를 살펴보자

모든 학생들이 한 대학에 한 번, 한 전공으로 지원할 수 있고,

데이터베이스에 있는 모든 대학들이 서로 겹치지 않는 원서 접수 기간을 가진다고 가정해보자.

 

BCNF를 만족하지 못 한다.

왜? date -> cName 이라는 FD에서 왼쪽에 있는 date가 key가 아니기 때문.

 

BCNF를 다음과 같이 만들자

A1(date, cName)

A2(SSN, date, major)

 

만들었지만 good design이 아니다.

cName과 date, major를 분리했기 때문.

또한, 첫 번째 FD에 있는 속성들이 모두 같이 있는 것도 아니다.

 

Apply(SSN, cName, date, major) 릴레이션은 3정규화를 만족하기 때문에 이대로 유지하는 것이 더 좋다.

제 3정규형(Third Normal Form)이란?

한 릴레이션이 제2정규형(2NF)을 만족하고,

모든 비-기본키 속성이 이행적 종속 없이 기본키에만 종속된다면 3NF에 있다.

 

No Key는 잘못 적은 것.

Correction: [SSN, SAT, ACT] is a key.

 

SAT, ACT는 score

 

SAT scores are independent of the rest of the attributes

 

4NF 위반 상태. 왜?

SSN →→ SAT

SSN →→ ACT라는 MVD가 있음.
그리고 SSN은 후보키가 아님! SAT, ACT가 붙어야 유일해지므로.

좌변이 후보키가 아니므로 4NF 위반

 

 

4NF 만족하게 분해하기
S3(SSN, sName)

S4(SSN, SAT)

S5(SSN, ACT)

 

각 릴레이션의 다치 종속의 좌변이 후보키임

• S2: SSN이 후보키이고 SSN →→ SAT
• S3: SSN이 후보키이고 SSN →→ ACT
• S1: SSN이 후보키이고 SSN → sName (FD)

 

하지만 모든 쿼리가 이름과 composite score을 리턴해야 한다면?

항상 recombine 해야 한다.

 

이럴 때는 denormalization이 더 선호된다.

 

한 개 릴레이션이나 두 개 릴레이션으로 해도 BCNF를 만족할 수 있다.

너무 쪼개져 있다.

 

 

* dependency enforcement (종속성 보장 문제)

BCNF나 4NF로 정규화를 하다 보면, 원래 존재하던 함수적 종속(FD)이나 다치 종속(MVD)이 분해된 릴레이션에서 더 이상 직접적으로 표현되지 않을 수 있다.

이로 인해 종속성을 보장하기가 어려워지는 상황이 생긴다.

 

예를 들어,

릴레이션 R:

R(A, B, C)
FDs: A → B, B → C

 

R이 BCNF가 아니라서 분해하면:

1. R1(A, B)
2. R2(B, C)

이제 이 두 릴레이션을 정규화했지만, 문제 발생:

• A → C는 원래 R에서 A → B → C였지만,
  이제 R1, R2에는 A → C가 직접 표현되어 있지 않다
• 즉, A → C를 DB 시스템이 보장할 수 없다

→ 이게 바로 dependency enforcement failure
→ 분해했더니 원래의 의미(FD나 MVD)를 보존하기 어려워졌다.

 

용어	의미
Dependency Enforcement	분해된 릴레이션 안에서 원래의 종속성(FD, MVD)이 계속 성립되도록 강제할 수 있는가
문제 상황	정규화를 위해 릴레이션을 분해하다 보면 어떤 종속성은 새 릴레이션들에 존재하지 않음
결과	정합성 유지를 위해 트리거, 애플리케이션 로직 등 외부에서 강제로 검증해야 하는 일이 생김

 

너무 정규화하면:

• FD나 MVD가 사라짐
• 원래 규칙이 DB에서 자동 보장되지 않음
• 무결성 제약을 수동으로 체크해야 함 → 개발 복잡도 증가