[DB] CH8. 관계형 데이터베이스 디자인(Relational DB Design) - good form이란?

 

Decomposition

• relation에서 특정 속성의 값이 반복적으로 나타나는 경우(data redundancy) 해당 relation을 더 작은 schema로 쪼개는 것

Lossy decomposition

• 나뉘어진 2개의 relation을 하나로 합칠 때 원래의 테이블에서 데이터 손실이 발생하는 것
• 주로, 나뉘어진 relation에서 functional dependency가 없기 때문에 발생

lossy decomposion의 예

lossless-join decomposition의 예

First Normal Form

• 모든 attribute의 domain이 atomic하다면 relational schema R은 First Normal Form에 있다고 할 수 있다.

Non-atomic value는 왜 안 좋은가?

• atomic하지 않기 때문에 data redundancy를 만들어낸다.
• 어찌보면 atomic하지 않다는 것은 최소 단위가 아니기에 storage를 복잡하게 만든다.
• atomicity는 다른 측면에선 해당 element가 어떻게 이용되는지를 나타내는데 만약 학생을 나타내는 ID가 CS0012, EE1127과 같이 된다면 DB가 아닌 Application program에서 encoding을 하게 만든다.(바꿔 말하면, 단순히 DB 접근만을 통해서 완벽하게 데이터의 정보를 알 수 없다)

Relation R이 not "good" form일 때 decompose해 "good" form으로 만들려면 다음 조건을 만족해야 한다.

• 분해한 각 relation이 "good" form이어야 한다.
• 분해가 lossless-join decomposition이어야 한다.

Functional dependency

• 어떤 relation R의 속성 A,B가 있을 때 A값이 같으면 B의 값도 같은 경우 A에서 B로의 functional dependency가 있다고 하고 A->B로 나타낸다.(아래 사진을 보면 더 자세히 이해하는데 도움이 된다.)

functinal dependency

functional dependency와 key

• 만약, relation R의 모든 instance들이 특정 functional dependency를 만족하면 해당 F.D.는 trivial하다고 한다. (아래 사진과 같은 경우가 그러하다.)

trivial한 functional dependency

• F.D.는 유도될 수도 있다. 만약 A->B, B->C라면 A->C를 유도할 수 있다.
• F가 functional dependency set일 때, F에 의해 imply될 수 있는 모든 F.D.의 set을 F의 closure라고 한다.

closure표현과 superset

BCNF(Boyce-Codd Normal Form)란?

• relation R에 대해 F(set of FD)의 superset F+의 모든 FD에 대해 a->b가 다음의 두 가지 중 최소 하나는 만족하는 경우
  • a->b is trivial(즉, b가 a의 subset)
  • a가 R의 superkey

BCNF가 아닌 예

BCNF 분해(Decomposition)

• 스키마 R의 non-trivial FD a->b가 BCNF violation을 일으킨다고 하자
• 그럼 다음과 같이 R을 분해하면 된다.
  • a U b
  • R-(b-a)=R-b+a

BCNF 분해의 예 1

BCNF 분해의 예 2

BCNF와 dependency preserving

• 실사용 관점에서, constraint(FD포함)이 하나의 relation에만 관계되지 않는 경우 그것이 지켜지는지 검사하는 것은 어렵다.
• 따라서, 분해 후 FD가 지켜지는지 검사할 때 각 FD마다 하나의 relation만으로 판별 가능한 경우 dependency preserving이라 한다.(every FD can be checked using single relation)
• 위 사진의 예시를 보면 분해의 결과로 BCNF는 지켜지나 ID->building이라는 FD를 파악하려면 두 개의 relation을 조합해야 하므로 dependency preserving이 지켜지지 않는다.
• 이렇듯, BCNF와 dependency preserving을 동시에 얻어내는 것이 항상 가능한 것은 아니다. 그래서 나온 것이 BCNF보다 약한 조건의 3rd NF(weaker BCNF)이다.

3rd NF

• 3rd NF는 BCNF에서 dependency preserving을 위한 하나의 최소 조건이 더 추가된 NF로 다음의 세가지 중 최소 하나를 만족하면 된다.
  • a->b is trivial
  • a is a superkey for R
  • each attribute A in b-a is contained in a candidate key for R(Note: each attribute may be in a different candidate key)
• relation R이 BCNF를 만족하면 3rd NF는 무조건 만족한다(BCNF라면 위의 조건 중 1,2 중 최소 하나를 만족하므로)

3rd NF 예시

• 하지만, 3rd NF에는 redundancy가 발생할 수 있다.(아래의 예시 참조)

3rd NF를 만족하지만 (i_ID,dept_name)의 redundancy 발생

"not good" form인 R을 "good" form으로 만들려면?(Goal of Normalzation)

• R을 {R1,R2,R3...}로 분해했을 때 다음의 조건을 만족해야 한다.
  • 분해된 각 relation이 good form이다.
  • lossless-join decomposition이다
  • 가능하다면, dependency preserving이 유지되면 좋다.
• BCNF와 dependency preserving을 함께 얻는 것은 힘들다
• 3rd NF의 경우 redundancy는 있으나 dependency preserving이 된다.

	BCNF	3NF
lossless decomposition	O	O
dependency preserving	X	O
redundancy	X	O

4th NF의 도입

• 아래의 예시는 분명 BCNF이다.(non-trivial한 FD가 없으므로)
• 하지만 insertion anomaly가 발생할 수 있다.
  • 만약, 99999에게 981-992-3443을 insert하는 상황을 가정해보자.
  • 그럼 (99999, David, 981-992-3443),(99999, William, 981-992-3443) 두개를 insert해야 한다
  • 그러나 데이터 삽입 시 하나만 추가하도록 설계하는 것이 이상적이다.

BCNF는 과연 최상의 good form일까?

• 그래서, 아래와 같이 분해하면 이 문제를 해결할 수 있다. 이러한 논의가 4th NF 도입의 필요성을 제시한다.

inst_info decomposition

NF간의 포함관계

 

아래의 링크에 Normalization에 관한 추가적인 설명이 자세히 되어있어서 첨부한다. 참조하면 좋을 듯하다.

3months.tistory.com/193

데이터베이스 정규화 1NF, 2NF, 3NF, BCNF