[ 데이터베이스 정규화란? ]
정규화의 기본 목표는 테이블 간의 중복 된 데이터를 허용하지 않는 것이다.
중복 된 데이터를 허용하지 않음으로써 무결성을 유지하고 DB의 저장 용량을 줄일 수 있다.
[ 제 1 정규화 ]
제 1 정규화란 테이블의 컬럼이 원자값을 갖도록 테이블을 분리하는 것이다.
- 원자값 : 더이상 쪼개질 수 없는 단위를 의미한다.
아래와 같이 수강 강좌 테이블이 있다고 가정해보자.
위 테이블은 1, 2번 학생이 여러 개의 강의를 가지고 있기 때문에 제 1 정규화에 위배된다.
그렇기 때문에 아래와 같이 제 1 정규화하여 분해할 수 있다.
제 1 정규화를 했음에도 불구하고 아직까지 문제가 있다.
어떤 문제가 있을까?
- 삽입 이상 : 학생이 새 과목을 신청할시, 반드시 지도 교수와 학과 정보를 알아야만 한다. (불필요한 정보)
- 삭제 이상 : 3번 학생이 과목을 취소하면, 해당 과목에 대한 정보가 모두 사라진다.
제 1 정규화에서 이러한 문제가 발생하는 이유는 기본키가 아닌 속성들이 기본키에 완전 함수 종속되지 못하고 부분 함수 종속되어 있기 때문이다.
즉, 기본키(학생번호, 강좌이름)의 일부 속성에만 의존하고 있기 떄문이다.
- (학생번호, 강좌이름) -> 성적
- (학생번호) -> 지도교수, 학과
[ 제 2 정규화 ]
제 2 정규화란 제 1 정규화를 진행한 테이블에 대해 완전 함수 종속을 만족하도록 테이블을 분해하는 것이다.
- 완전 함수 종속이란 기본키의 부분 집합이 결정자가 되어선 안된다는 것이다.
- 제 2정규화는 복합키의 경우에만 해당된다.
제 1 정규화를 진행한 테이블을 보자.
이 테이블의 기본키는 (학생번호, 강좌이름)으로 복합키이다.
그리고 기본키(학생번호, 강좌이름)는 성적을 결정하고 있다.
그런데 (지도교수, 학과) 컬럼은 기본키의 부분 집합인 학생번호에 의해 결정 될수 있다.
즉, 강좌 이름이 없더라도 (지도교수, 학과)을 결정 할 수 있는 것이다.
따라서 아래와 같이 (지도교수, 학과) 컬럼을 분해하여 제 2 정규형으로 분해할 수 있다.
제 2 정규형에도 여전히 문제는 존재한다.
- 삽입 이상 : 지도교수 추가시 반드시 지도 학생이 있어야한다.
- 삭제 이상 : 3번 학생이 자퇴하는경우, P4 교수의 학과 정보가 사라진다.
- 갱신 이상 : 지도 교수의 학과가 변경되는 경우, 모두 찾아서 변경해주어야 한다.
이러한 문제가 발생하는 이유는 '이행적 종속성' 때문이다.
- 이행적 종속성이라는것은 A->B, B->C가 성립할때 A->C가 성립되는것을 의미한다.
위 예제에서는 학생번호 -> 지도교수, 지도교수 -> 학과, 학생번호 -> 학과의 관계가 존재한다.
따라서 지도 교수의 학과를 추가하기 위해서 학생 번호까지 필요하게 되고, 학생이 자퇴하였는데 지도 교수의 학과 정보가 사라진다는 문제점이 있다.
[ 제 3 정규화 ]
제 3 정규화란 제 2 정규화를 진행한 테이블에서 이행적 종속을 없애도록 테이블을 분리하는 것이다.
즉, 기본키에 속하지 않는 모든 속성이 기본키에 이행적 종속이 아닐때 제 3 정규화이라고 말한다.
제 2 정규화를 진행한 테이블을 보자.
기본키가 아닌 지도 교수가 학과를 결정하므로, 아래와 같이 테이블을 분리하여 이행적 종속을 없애보자.
[ BCNF 정규화 ]
BCNF 정규화란 제 3 정규화가 진행 된 테이블에 대해 모든 결정자가 후보키로 되도록 테이블을 분해하는 것이다.
아래와 같이 제 3정규화가 된 테이블이 있다고 가정해보자.
한 교수당 하나의 수업만 맡는다고 가정한다.
이렇게 되면 제 3 정규화를 만족한다. 이 경우에는 어떤 이상현상이 생길까?
- 삽입 이상 : 새로운 교수가 특정 과목을 담당한다는 새로운 정보를 추가할 수가 없다. 학생번호가 필요하다.
- 삭제 이상 : 3번 학생이 수강을 취소한다면 P4가 자바프로그래밍 과목을 담당한다는 정보도 사라진다.
- 갱신 이상 : P1의 담당 과목이 변경된다면 모두 변경해주어야 한다.
이러한 이상현상이 발생하는 이유는 결정자가 후보키로 취급하고 있지 않기 때문이다.
후보키는 슈퍼키(super key) 중에서 최소성을 갖는 키이므로 이 릴레이션에서는 (학번, 과목명)이나 (학번, 담당교수)가 후보키가 된다. 담당 교수만으로는 후보키가 될 수 없다.
하지만, 후보키가 아님에도 과목명을 결정할 수 있기 때문에 담당 교수는 결정자에 속한다.
이 이상현상을 해결하기 위해서 모든 결정자는 항상 후보키가 되도록 릴레이션을 분해해주면 강한 제3 정규형, 즉 BCNF를 만족하게 된다.
[ 참고 사이트 ]
