[ 데이터베이스 ] 22. DB 정규화 ( Normalization )

DB 정규화 

: [ 데이터 중복 ] + [ Insertion , Update , Deletion anomaly ] 를 최소화하기 위해

 일련의 Normal Form(NF)에 따라 Releational DB를 구성하는 과정

 

* Normal form  정규화 되기 위해 준수해야하는 규칙

 

 

 

우리는 1NF부터 BCNF까지만 배울 예정

 

---

---

예제1)

 

 

● KEY

 

 

● FD

 

특정 Attribute를 통해 Table의 Tuple을 Unique하게 식별할 수 있다면

그게 FD가 될 수 있다.

 

FD가 될 수 있는 것

- account_id

- bank_name & account_num

+ empl_id 이 같으면 empl_name도 같다.

+ class가 같으면 bank_name도 같다.

 

 

---

---

정규화 

 

● 1NF

- 규칙 : Attribute의 Value는 반드시 나눠질 수 없는 단일한 값이어야 한다.

이런 면에서 마지막 Tuple에서 card_id가 맞지 않다.

 

가장 원시적인 방법으로는 그냥 튜플 하나(겹치는 갯수만큼)를 더 만드는 것이다.

 

뒤에 Card_id만 나누다보니, Primary key인 account_id가 더 이상 Primary하지 않게 되었다.

이렇게 되었을 때는 Primary key도 수정을 해야한다.

 

같은 account_id 가 card_id에 의해 2개가 되었으므로 

Primary key :  { accout_id }    →  { accout_id , card_id } 로 된다. 

 

---

---

● 2NF

- 규칙 : 모든 Non-prime attribute는 반드시 모든 key에  fully functionally dependent 해야 한다.

 

- (candidate) Key  :  { account_id , card_id } ,  { bank_name, account_num , card_id }

- non-prime attribute  : class , ratio , empl_id , empl_name

 

 

(candidate) Key들을 분석해보자

 

non-prime attribute들은 { account_id , card_id } key에 의존한다.

하지만 생각해본다면, 모든 non~~ 들이 {  "" ""  } 에 의존하냐? 그건 또 아니다.

 

class , ratio , empl_id만 account_id에 대해 unique함.

 

  

 

다른 key들을 보면?

 

 

2 NF 조건에 맞추기 위해서는 문제를 일으키는 Attribute를 손봐야한다.

하나 이상의 Value를 갖기 때문에 이를 해결하기 위해서는 card_id를 다루는 테이블을 하나 새로 만들어 주어야 한다.

 

 

 

되는 과정 자세히 보기

 

 

 

EMPLOYEE_ACCOUNT는 이제 다시

account_id ( 모든 key ) 에 대해 모든 non-prime Attribute가 unique하게 되었으므로 Full functionally dependent하다.

 

 

 

(출처)

유튜브 쉬운코드