데이터베이스 정규화란(함수 종속,개념,종류)

배경지식 : 함수 종속

두 튜플의 X값이 같다면 Y값도 같은 경우가 있다. 즉 X 값에 따라서 Y의 값이 결정되는 것인데, X와 Y를을 함수 종속 관계라고 한다.

관점에 따라서 X가 Y를 함수적으로 결정한다. 라고 할수도 있고 Y가 X에 함수적으로 의존한다. 라고 표현할 수도 있다.

이러한 관계를 함수 종속 혹은 Funtional Dependency(FD)라고 한다.

 

예를 들어 아래 테이블에서는 회원이름과 프로그램이 primary key이며 이는 가격을 결정한다.

(회원 번호가 좀 더 자연스럽지만 설명을 위해 다른 키를 예시로 든다.)

이 둘을 FD 관계라고 할 수 있으며 기호로는 {회원이름,프로그램} -> 가격 으로 표시한다.

회원번호	회원이름	프로그램	가격
101	민수	테니스	5000
102	철수	농구	7000
103	영희	축구	4000
103	영희	농구	7000

 

여기서 주의할 점은 FD를 파악할때는 스키마의 의미를 보고 파악해야하며 테이블의 데이터들을 보고 추론해서는 안된다.

왜냐하면 회원 이름과 가격 데이터가 FD처럼 보인다고 생각해도 동명이인이라는 변수가 있을 수 있고 여러 예외 상황들이 있기 때문이다.

이렇게 구축하려는 데이터베이스의 속성(애트리뷰트)가 관계적으로 어떤 의미를 지닐지에 따라서 FD들이 달라진다.

 

따라서 데이터(or state)만 보고 판단하기보단 스키마를 보고 의미적으로 존재하는 지 파악해야한다.

 

또 한가지 중요한 점은 FD는 역관계가 성립하지 않는다는 것이다.

X -> Y 관계라고 해서 Y->X가 성립하지는 않는다. 예를 들어보면 프로그램이 가격을 결정짓는 다고 해서 가격이 프로그램을 결정하는 것은 아니다!

{프로그램} -> 가격 (O)
{가격} -> 프로그램 (X)

 

*{}-> Y 는 "Y은 언제나 하나의 값만을 가진다"는 의미이다.

 

Trivial Funtional Dependcy

X -> Y의 관계에서 Y가 X의 부분 집합이라면 이 관계를 Trivial Funtional Dependcy라고 한다.

예를 들어, {a,b,c} -> {c} 같이 c가 a,b,c의 부분집합인 경우가 있다. 

반대의 경우로는 당연히 non-Trivial Funtional Dependcy (아예 안겹치면 completely-non) 같은 관계가 있다.

 

Partial Functional Dependency

X->Y의 관계에서 X의 부분집합(전체를 제외한)만으로 Y를 결정지을 수 있다면 이를 Partial Functional Dependency라고 한다.

예를 들어, {a,b,c} -> {c} 에서 {a} -> {c}가 성립하는 경우가 있다. 반대의 경우는 Full Funtional Dependcy가 있다.

 

DB 정규화란

데이터 중복과 insertion , update , deletion anomaly를 최소화하기 위해 함수의 종속성을 이용해서 relational DB를 구성하는 과정이다.

 

삽입이상 : 자료를 삽입할 때 의도치 않은 자료까지 삽입해야한다. (ex. null)

갱신이상 : 중복된 데이터 중 일부만 수정되어 모순이 발생하는 것이다.

삭제이상 : 어떤 정보를 삭제하면 의도치 않은 다른 정보까지 삭제된다.

 

정규화를 진행하게 되면 데이터 수정 시에 여러 이상 현상들을 줄일 수 있고, 확장에 용이하여 데이터 구조가 변경되어도 어플리케이션에 최소한의 영향만을 미친다.

 

정규형에는 몇 단계의 nf(normal forms)가 있는데 처음 단계부터 순차적으로 진행하며 앞 단계를 만족해야 다음 단계를 진행할 수 있다.

보통 실무에서 3nf까지 하면 정규화되었다라고 말한다.

 

제 1 정규형(1NF)

모든 attribute의 value는 더 이상 나눠질 수 없는 값이어야한다. -> 여러 값을 가지고 있으면 안된다.

 

회원번호	회원이름	프로그램
101	민수	테니스
102	철수	농구
103	영희	축구,농구

(예시 참고: 코딩애플)

 

영희에 해당하는 프로그램 데이터가 두 개를 가지고 있으므로 이는 제 1 정규형을 위반한다.

 

제 2 정규형(2NF)

모든 non-prime attribute는 모든 key에 대해 full funtional dependent해야한다.
(현재 테이블과 상관없는 컬럼들을 분리한다.)

 

제 1 정규형을 적용하였으면 이제 제 2 정규형을 진행할 차례이다.

현재 테이블에서는 회원 정보와 프로그램 정보가 혼재해있다. 이런 테이블 구조는 데이터를 변경해야할 시에 매우 번거로울 수 있다.

 

회원번호	회원이름	프로그램	가격
101	민수	테니스	5000
102	철수	농구	7000
103	영희	축구	4000
103	영희	농구	7000

(예시 참고: 코딩애플)

 

예시에서는 가격 컬럼이 프로그램에 partial funtional dependent하다.

{회원이름,프로그램} -> 가격

{프로그램} -> 가격

primary key가 회원번호,프로그램이지만 가격은 프로그램 하나만으로 결정될 수 있다. -> 현재 테이블에 상관 없는 데이터가 들어간 것이다!

이 상황에서 가격이 변경됨에 되면 컬럼을 일일이 수정해주어야 하기 때문에 매우 비효율적이다. 따라서 다음과 같이 분리할 수 있다.

 

프로그램	가격
테니스	5000
농구	7000
축구	4000

 

이제 가격은 프로그램에 full functional dependency하며 프로그램 테이블에 연관있는 컬럼들만 들어가 있다.

만약 가격이 수정된다고 하더라도 이 테이블의 값만 수정하면 되기 때문에 효율적이라고 할 수 있다.

 

제 3 정규형 (3NF)

모든 non-prime attribute(키를 제외한)는 어떤 key에도 transitive FD(이행적 함수 종속) 하면 안된다.

 

transitive FD(이행적 함수 종속) 이란, X -> Y 이고 Y -> Z이면 X -> Z 인 경우이다.

프로그램	가격	강사	전화번호
테니스	5000	한석원	010-xxxx
농구	7000	이지영	010-xxxx
축구	4000	이명학	010-xxxx

 

이 경우에는 프로그램을 통해 강사가 결정되는데 동시에 강사가 전화번호 또한 결정할 수 있다.

프로그램 -> 강사 

강사  -> 전화번호

=> 프로그램 -> 전화번호 같은 이행적 함수 종속이 발생한다.

다음과 같은 문제가 발생할 수 있다. 예를 들어 강사가 여러 개의 과목을 담당한다고 가정하였을 때 중복된 강사는 여러 개일 것이다.

프로그램	가격	강사	전화번호
테니스	5000	한석원	010-xxxx
테니스 입문	3000	한석원	010-xxxx
농구	7000	이지영	010-xxxx
축구	4000	이명학	010-xxxx

 

그렇다면 만약 해당 강사가 전화번호를 변경하였을 경우 일일이 변경해주어야 하며 이는 갱신 이상이 발생할 수 있다.

따라서 다음과 같이 해당 컬럼을 분리해줌으로써 문제를 해결할 수 있다.

강사	전화번호
한석원	010-xxxx
이지영	010-xxxx
이명학	010-xxxx

 

보통 여기까지 오면 정규화 되었다고 말할 수 있지만 BCNF까지만 더 알아보려고 한다.

 

BCNF

모든 유효한 non-trivial FD X -> Y 는 X가 슈퍼키여야한다.

 

만약 테이블에 강의실 정보까지 추가되었다고 가정해보자 

프로그램	가격	강사	강의실
테니스	5000	한석원	207호
테니스 입문	3000	한석원	207호
농구	7000	이지영	211호
축구	4000	이명학	213호

 

이제 강의실을 통해 해당 강사의 정보를 알 수 있다. 하지만 굳이 중복된 강사의 데이터들을 가지고 있어야할까? 라는 의문이 드는데 이와 관련된 개념이 BCNF이다.

 

테이블을 보면 강의실을 통해 현재 어떤 강사가 배정되었는 지 알 수 있으므로 강의실 -> 강사는 non-trivial FD 라고 할 수 있다.

하지만 강의실은 슈퍼키가 아니므로 BCNF를 위반한다.

강의실	강사
207호	한석원
2011호	이지영
213호	이명학

 

테이블을 분리한 결과 강의실은 슈퍼키가 되었고 더 이상 원래 테이블에 중복된 강사 데이터를 넣지 않아도 된다.

이렇게 해두면 BCNF를 지키면서 중복된 데이터들을 최소화 할 수 있다.