[DB13] Normal Form과 Normalization

* 12.18 업데이트

해당 게시물은 한양대학교 컴퓨터소프트웨어학부 김상욱 교수님 데이터베이스시스템 온라인 강의를 듣고 정리한 자료입니다.

오류가 있다면 언제든 알려주세요!

 

● 해당 강의의 목표

1. normal form과 normalization에 대해 배운다.

▪ normalization의 개념 (바람직하지 않은 상태에서의 table을 바람직한 형태로 바꾸는 것)

▪ Normal forms (바람직한 table의 형태)

- 1NF, 2NF, 3NF, BCNF

 

◆ Normalization

◆ Normal Forms

▪ table의 바람직한 형태를 정의하는 것

어떤 table이 normal form이면 좋은 것이고 normal form이 아니면 좋은 것이 아니다.

◆ normalization

▪ 어떤 relation schema가 바람직하지 않은 형태에 있을 때 그것을 쪼개서 각 table이 좀 더 바람직한 형태로 되게 끔하는 작업이다. 

◆ 각 table이 바람직한 형태(normal form)이면서 다음 두 가지를 만족하도록 쪼개는 것이 중요하다. 

▪ Lossless join property

 - 쪼개진 table을 join하면 원래 table에 있었던 정보가 빠짐없이 있도록 해야한다.

▪ Dependency preservation property

 - functional dependency가 보존되도록 쪼개야한다. 

 

◆ Prime Attribute

◆ 주어진 relation schema R이 있을 때 R에 속하는 attribute 중 candidate key의 일부를 prime attribute이라고 한다. table의 candidate key의 각 attribute를 prime attribute이라고 한다.

 

◆ Example

▪ WORKS_ON (Ssn, Pnumber, Hours) table이 있다.

- {Ssn, Pnumber} : candidate key

- 각 Ssn, Pnumber은 prime attribute이 된다. candidate key의 member이기 때문이다. 

- Hours는 non-prime이다. candidate key의 일부가 아니기 때문이다.

 

◆ First Normal Form

◆ 1NF의 정의 (normal form: table의 바람직한 형태)

▪ 어떤 table이 1NF이 되기 위해서는 그 table의 각각의 attribute가 single atomic value만 허용해야한다. 즉, 어떤 table에 속하는 attribute은 single atomic value가 아닌 것이 들어올 수 있는 형태이면 그 table은 1NF이 아니다. 

- 이 table에 속하는 각 tuple의 attribute는 주어진 domain 중 하나의 simple value만을 가지고 있어야한다. 

- Multiple value를 가지는 것은 허용하지 않는다.

◆ relational model에서는 모든 table이 1NF이어야 한다. 따라서 relational database안에 있는 table들은 모두 그 정의에 의해서 1NF이다. 

◆ 특징

▪ non-atomic attribute를 허용하지 않는다. 

- composite attribute을 허용하지 않는다. (name: Fname, Minit, Lname이므로 허용하지 않는다.)

- multi-value attribute을 허용하지 않는다.  (전화번호는 multi-valued attribute 이었으므로 허용하지 않는다. 이는 relational model에서 허용하지 않았다. 별도의 table로 mapping 했다는 것을 기억할 것이다.)

- Nested relations을 허용하지 않는다. (하나의 table 안에 relation이 들어가 있는 형태이다.)

◆ Example

하나의 department가 여러 location에 있는 것을 허용했다. 이를 relational model에서는 허용하지 않지만 허용한다고 가정을 하고 table을 그리면 (b)와 같이 나타난다. 1NF에 의해서 이는 허용되지 않으니 relational database에 저장하기 위해서는 (c)와 같이 그릴 수 있다. 서로 다른 tuple로 나눠서 저장하면 1NF이 된다. (b)와 같은 form이 나올 것 같으면 미리 database designer가 (c)처럼 바꾸어 주어야한다. 

 

◆ Second Normal Form

first normal form을 제외하고부터는 functional dependency와 관련이 되어있다. 

 

◆ 개념

▪ Full functional dependency

 - X -> Y는 어떤 서로 다른 tuple이 X값이 같다면 Y값도 같다는 의미이다. 즉, X의 값이 Y의 값을 함수적으로 종속시킨다. 어떤 table의 attribute에 대해서 X -> Y가 존재하고 특정한 조건을 만족시키면 해당 functional dependency가 full functional dependency라고 한다. 조건은 다음과 같다. X라는 attribute 집합에서 어떤 하나의 attribute A를 제거했을 때 더 이상 functional dependency가 만족하지 않으면 이 functional dependency를 full functional dependency라고 한다. 

▪ Partial functional dependency

 - X -> Y라는 functional dependency가 있을 때 어떤 attribute A를 X로 부터 제외했을 때 여전히 functional dependency를 만족한다면 해당 functional dependency를 partial functional dependency라고 한다. 

 

◆ Example

 

▪ FD1: {Ssn, Pnumber} → Hours

 - FD ‘Ssn → Hours’ and ‘Pnumber → Hours’ do not hold: Ssn이 같더라도 Hours가 다를 수도 있다. Ssn이 같더라도 어떤 project에 참여하더라고 hours가 달라질 수 있기 때문이다. 

 - Full functional dependency

▪ {Ssn, Pnumber} → Ename

 - FD ‘Ssn → Ename’ does hold: Pnumber -> Ename은 만족하지 않는다. 어떤 project이더라도 여러 employee가 일할 수 있기 때문이다. 반면, Pnumber를 제거하면 FD를 만족한다. 

 - Partial functional dependency

 

◆ 2NF의 정의

▪ relation schema R이 있을 때 이 table이 2NF일 조건

 - R에 속하는 모든 nonprime attribute는 R의 candidate key에 fully functional dependent해야 한다.

 - non-prime attribute: table에서 key에 해당되는 attribute이 아닌 것들

▪ 2NF가 아닐 조건

 - nonprime attribute이 candidate key에 의해서 partially functional dependent한 경우이다.

◆ Example

 

County_name과 Lot#가 정해지면 해당 table에 있는 모든 tuple들을 결정할 수 있다.

Property_id#도 또 다른 candidate key이기 때문에 다른 attribute들을 함수적으로 종속시킨다.

▪ Keys: Property_id, {Country_name, Lot#}

▪ FD3 is partially dependent on {Country_name, Lot#} : Lot#가 없더라도 County_name이 Tax_rate을 함수적으로 종속시키므로 {County_name, Lot#} -> Tax_rate는 partial functional dependency이다. 어떤 table이 2NF이 되기 위해서는 candidate key에 의해서 모든 non prime attribute이 full functional dependency가 되어야한다. 하지만 Tax_rate은 partial functional dependency를 가지므로 2NF이 아니다. 

▪ Not in 2NF: County_name과 Tax_rate이 모두 같은 tuple들이 많이 나오기 때문에 이 table은 바람직하지 않다. 중복이 많다. 

◆ Normalization into 2NF

▪ 원래의 table LOTS를 2개의 table LOTS1, LOTS2로 나눠야한다.

 - LOTS1: Tax_rate attribute를 제거한다. (FD3이 제거되었다.)

 - LOTS2: FD3에 있는 attribute로 새로운 table을 만든다. County_name이 Tax_rate를 functionally dependence하기 때문에 PK이자 key가 된다. 따라서 LOTS1과 LOTS2를 join하면 원래의 table인 LOTS가 된다. Join attribute은 county_name이고 LOTS1에서는 FK가 된다. 

▪ 2NF이 아닌 1NF인 table이 있다면 normalization process을 통해 2NF을 가진 table로 나눌 수 있다.

 

◆ Third Normal Form

table내의 nonprime attribute이 table내의 candidate key에 의해서 full functional dependent하는 조건을 만족하면 그 table을 2NF이라고 부른다.

◆ 3NF의 정의 (2NF보다 더 중복이 적은 Normal form의 형태)

▪ table에 존재하는 모든 Functional dependency X -> A 에 대해서도 다음과 같은 2개의 조건 중 하나를 만족하게 되면 해당 table을 3NF이라고 부른다. 다만, 여러개의 functional dependency 중에 하나라도 둘 다 만족하지 않는 FD가 있다면 3NF라고 할 수 없다. 

 - X는 R의 superkey이다.

 - A는 R의 prime attribute이다. 

X라는 attribute 집합에 의해서 A attribute이 함수적으로 종속된다는 것은 X가 같은 tuple은 A도 같아야한다. 따라서 functional dependency가 존재하면 중복이 존재한다는 의미이다. 만약 X가 superkey이면 X가 같은 tuple은 이 table에서 존재하지 않는다는 의미이다. 따라서 중복이 존재하지 않는다는 것이다. 

두번째 조건은 X가 super key가 아니면 X가 같으면 A가 같아서 중복이 있다는 뜻인데 만약 A가 prime attribute이면 중복이 생기더라도 excuse하겠다는 것이다. 따라서 원래 첫 번째 조건을 원했는데 두번째 조건은 excuse한다고 이해하면 된다.

◆ Example

▪ 이는 3NF이다. 첫번째 조건을 만족하기 때문이다.

◆ Example

▪ FD1은 첫번째 조건을 만족한다. Property_id#가 super key이기 때문이다.

▪ FD2는 첫번째 조건을 만족한다. County_name, Lot#가 super key가 될 수 있기 떄문이다.

▪ FD4는 두 조건 모두 만족하지 않는다. 

 

◆ Normalization into 3NF

▪ LOTS1에 해당되는 table을 LOTS1A, LOTS1B로 나눈다.

 - LOTS1A: FD4의 오른쪽에 있는 attribute인 Price를 제거한다.

 - LOTS1B: FD4의 attribute로 새로운 relation을 만든다. Area가 PK가 된다. 마찬가지로 LOTS1A와 LOTS1B를 join하면 손실없이 LOTS1를 복원할 수 있다.

 - 어떠한 table이 2NF이고 3NF이 아닐 때 normalization process를 통해서 3NF으로 만들 수 있다.

 

◆ Boyce-Codd Normal Form

◆ BCNF의 정의

▪ table R이 있을 때 이 R과 관련된 X -> A와 같은 모든 functional dependency에 대해서 해당 table이 BCNF가 되기 위해서는 X가 R의 super key이어야 한다. 

▪ X가 superkey이면 서로 같은 tuple이 존재하지 않아서 중복이 존재하지 않는다. BCNF를 따지는 조건과 3NF를 따지는 조건이 비슷하다.

◆ 3NF의 정의를 다시 보도록 하자.

▪ (a) X가 super key이어야 한다.

▪ (b) A가 prime attribute이어야 한다. 

BCNF에서는 2번째 조건이 없어졌다. 따라서 더 까다로운 조건을 가지고 있다. 

 

◆ Example

▪ LOTS1A는 BCNF가 아니다.

 - FD5에서 Area는 super key가 아니기 때문이다. 다만, County_name이 prime attribute이기 때문에 LOTS1A는 3NF는 만족한다.

 

◆ Normalization into BCNF

▪ LOTS1A를 LOTS1AX, LOTS1AY로 분리한다.

 - LOTS1AX: FD5를 제거해서 County_name을 제거한다. 

 - LOTS1AY: FD5의 attribute로 새로운 table을 만든다.

따라서 BCNF가 된다.

▪ 어떠한 table이 3NF이고 BCNF가 아니라면 normalization process를 거쳐 BCNF로 만들 수 있다.

 

◆ Summary

◆ 상위의 normal form은 아랫 단계의 normal보다 더 tight한 condition을 가지고 있다.

▪ 모든 2NF은 1NF이다.

▪ 모든 3NF은 2NF이다.

▪ 모든 BCNF은 3NF이다.

 

계속 normalization을 거쳐 자신이 원하는 형태의 normal form을 얻을 수 있다. 이것도 하나의 relational database design 단계에 속한다. 보통은 ER model을 통해 design하고 그것을 통해 relational mapping을 하게 된다. 그렇게 하면 대부분 3NF, BCNF으로 design된다. 따라서 직관적인 ER modeling 후에 relational modeling을 하는 것이다. 

 

◆ 좋은 relational design을 하는 궁극적인 목표

▪ database에 속하는 모든 table들이 BCNF, 3NF으로 만드는 것이다. 이는 ER modeling -> relational modeling 혹은 반복적인 normalization으로 동일한 효과를 얻을 수 있다. 전자가 훨씬 더 많이 사용된다.

 

◆ 좋은 relational design을 위한 추가적인 properties

▪ Lossless join property

▪ Dependency preservation property

이후에 배운다.