새소식

CS

데이터 정규화

  • -

 

코딩애플 정규화 영상 3번, 학교 강의 1번, 복습 1번 했지만 아직 애매한 정규화...

데이터 정규화

 우선 데이터 정규화에 대해 설명하기 전에 관계형 DB를 사용하는 이유부터 생각해보자. 첫 번째는 데이터 저장을 위해서이고 두 번째는 데이터의 중복을 줄이기 위해서이다.

 

개요

 그러면 관계형 스키마를 위한 가이드라인부터 한번 알아보자. 이것만 지키면 최고의 스키마??

 

1. Making sure the semantics of the attributes

 즉, 엔티티를 섞지 말라는 말이다. 오직 foreign key로만 다른 엔티티를 가리켜야 한다.

 

2. Reduce the redundant information in tuples

 redundancy(중복)이 생기면 update 이상이 생길 수 있다. 이때 update는 modification(update), insertion, deletion을 모두 포함한다.

 

modification 이상

 만약에 Ssn이 333...인 엔트리의 Pname을 Computerization에서 딴걸로 바꾸면 Ssn이 999..., 987... 인 엔트리도 바뀌어야 하는데 이때 문제가 발생할 수 있다.

 

insert 이상

 해당 상황에서 프로젝트에 할당된 직원이 없다면? 반대로 직원이 프로젝트에 할당이 되어있지 않으면 어떻게 삽입할까?

 

delete 이상

 위 그림(EMP_PROJ)에서 만약 프로젝트에 할당된 직원이 오직 한 명일 때를 생각해보자. 그 직원이 퇴사하면  그 직원이 할당된 프로젝트도 삭제될 수 있다.

 

3. Reducing NULL values

 만약 NULL이 불가피하게 자주 사용된다면 PK를 사용해서 분리하는게 낫다.

 

4. Satisfy the lossless join condition

 즉, 분해한 걸 다시 JOIN 해도 원래 데이터가 나와야 한다는 것이다. Join 시 non-additive이어야 하고, functional dependenciy 가 보존되어야 한다.

 

Functional Dependancy

X가 주어지면 Y가 unique하게 결정되어야 한다. 이때 X -> Y 로 나타낼 수 있다.

예를 들어 course가 한 professor에 의해 가르쳐진다면

course -> professor

로 나타낼 수 있고 course가 professor에 의존한다고 말할 수 있다.

 

결국 길게 말했지만 데이터 정규화 시 핵심은 다음과 같다. redundancy를 줄이고 update 이상을 최소화 하는 것이다.

 

데이터 정규화는 1NF(Normal Form, 제1정규형), 2NF, 3NF, BCNF(Boyce-Codd Normal Form), 4NF, 5NF가 존재하는데, 보통 여러 비용등의 문제 때문에 1NF, 2NF 까지만 한다고 한다.

 

1NF

제1정규형은 딱 3가지만 지키면 된다.

- composite attribute

- multi-valued attritube

- nested relations

만 금지하면 된다.

 

즉 relation의 모든 값을 atomic하게, 더 이상 분리 못하는 값으로만 구성하면 된다.

위 그림에서 같이 Dlocations를 분리하면 저렇게 되는데 그러면 Dnumber에서 데이터 중복이 발생한다.

그런 상황에서는 Dnumber를 fk, pk로 한번 더 분리하면 된다. 위 그림 같은 케이스에서는 Ssn에 따라 Ename과 {Pnumber, Hours}로 분리할 수 있다.

2NF

 제2정규형은 모든 nonprime attribute가 primary key에 대해 fully functionally dependent이어야 한다.

(non)prime attribute

prime attribute 후보키에 속하는 attribute
nonprime attribute prime attribute가 아닌 것

Ssn과 Pnumber가 prime attribute고 Hours가 non-prime attribute다.

 

이때

key인 Ssn에 대해 Ename의 값이 정해지는데, 즉 dependent 상태인데 굳이 key Ssn, Pnumber 둘다 쓸 필요가 없다. 그래서 위와 같이 Ssn, Pnumber 둘다 써야 하는 값(Hours), Ssn만 써도 되는 값(Ename) 그리고 Pnumber만 써도 되는 값(Pname, Plocation)으로 나눈다. 이러면 결과적으로 Partial FD(Functional Dependancy)가 모두 Full FD로 바뀌어진다.

3NF

 제3정규형은 제2정규형에 다음 조건이 추가된 경우이다.

모든 nonprime attribute에 대해 transitively dependent를 제거

위 그림에서 Ssn -> Dnumber 이고, Dnumber -> {Dname, Dmgr_ssn} 이다. 이를 transitively dependent라 한다. 이때 이를 분리하는 것이 제3정규형이다.

BCNF

BCNF(Boyce Codd Normal Form)3차 정규화를 조금 더 강화한 버전으로 모든 결정자가 항상 후보키가 되도록 하는 것이다.

예를 들어 다음과 같은 데이터들이 있다. 위 데이터에서는 학생번호와 과목이 기본키 집합에 속한다. 

 

만약 한 교수당 하나의 수업만을 맡는다는 가정이 존재하면 교수로 과목명을 결정가능하다. 즉, 위 테이블에서는 학번으로 지도교수를 알 수 있고 지도교수를 알면 과목을 알 수 있는데 지도교수는 후보키 집합에 속하지 않는다. 이를

다음과 같이 수정하여 지도교수가 후보키 집합에 속하게 정규화 할 수 있고 이를 BCNF라 한다.

Contents

포스팅 주소를 복사했습니다

이 글이 도움이 되었다면 공감 부탁드립니다.