정규화(Normalization)의 기본 목표 : 테이블 간에 중복된 데이타를 허용하지 않는다
중복된 데이터를 허용하지 않음으로써 무결성(Integrity)를 유지할 수 있으며, DB의 저장 용량 역시 줄일 수 있다.이러한 테이블을 분해하는 정규화 단계가 정의되어 있는데, 여기서 테이블을 어떻게 분해되는지에 따라 정규화 단계가 달라지는데, 각각의 정규화 단계에 대해 자세히 알아보도록 하자.
제1 정규화 : 테이블의 컬럼이 원자값(Atomic Value, 하나의 값)을 갖도록 테이블을 분해하는 것
예를 들어 아래와 같은 고객 취미 테이블이 존재한다고 하자.
위의 테이블에서 추신수와 박세리는 여러 개의 취미를 가지고 있기 때문에 제1 정규형을 만족하지 못하고 있다. 그렇기 때문에 이를 제1 정규화하여 분해할 수 있다. 제1 정규화를 진행한 테이블은 아래와 같다.
제2 정규화 : 제1 정규화를 진행한 테이블에 대해 완전 함수 종속을 만족하도록 테이블을 분해하는 것
완전 함수 종속 :기본키중에 특정 컬럼에만 종속된 컬럼(부분적 종속)이 없어야 한다는 것 즉, 기본키의 부분집합이 결정자가 되어선 안된다는 것
예를 들어 아래와 같은 수강 강좌 테이블을 살펴보자.
이 테이블에서 기본키는 (학생번호, 강좌이름)
으로 복합키이다. 이 두 개가 합쳐져야 (성적)
을 구분할 수 있다. (학생번호, 강좌이름) → (성적)
그런데 여기서 강의실이라는 컬럼은 기본키의 부분집합인 강좌이름만에 의해 결정될 수 있다. (강좌이름) → (강의실)
즉, 기본키(학생번호, 강좌이름)
의 부분키인 강좌이름이 결정자이기 때문에 위의 테이블의 경우 다음과 같이 기존의 테이블에서 강의실을 분해하여 별도의 테이블로 관리하여 제2 정규형을 만족시킬 수 있다.
제3 정규화 : 제2 정규화를 진행한 테이블에 대해 이행적 종속을 없애도록 테이블을 분해하는 것 즉, 기본키 이외의 다른 컬럼이 기본키 외 다른 컬럼을 결정할 수 없도록 하는 것
이행적 종속 : A → B, B → C가 성립할 때 A → C가 성립되는 것
예를 들어 아래와 같은 특강 테이블을 살펴보자. (하나의 강좌는 한 교수만 수업 가능하다고 가정)
강좌이름 | 강의료 | 교수 | 출신 대학 |
---|---|---|---|
Spring | 50,000원 | 스OO | 서울대 |
C++ | 45,000원 | 터OO | 명지대 |
C | 30,000원 | 디OO | 한양대 |
위의 테이블에서 기본키는 강좌이름
이기 때문에, 완전함수 종속을 만족하므로 제 2정규화가 진행되었다고 볼 수 있다.
하지만 위 테이블을 보면 강좌이름 → 교수, 강좌이름 → 출신 대학
으로 의존하는 것이 아니라, 강좌이름 → 교수, 교수 → 출신 대학
으로 이행적 종속이 되어 있음을 알 수 있다.
이 때 제 3 정규화를 만족하려면 어떻게 해야할까? 출신 대학
컬럼은 기본 키가 아닌 교수
컬럼이 결정하므로 (교수
컬럼에 종속되어있음) 아래와 같이 교수
와 출신 대학
을 따로 테이블로 빼어 분리해주어야 한다.
강좌이름 | 강의료 | 교수 | 출신 대학 |
---|---|---|---|
Spring | 50,000원 | 스OO | 서울대 |
C++ | 45,000원 | 터OO | 명지대 |
C | 30,000원 | 디OO | 한양대 |
교수 | 출신 대학 |
---|---|
스OO | 서울대 |
터OO | 명지대 |
디OO | 한양대 |
BCNF 정규화 : 제3 정규화(일반 칼럼이 다른 일반 칼럼에 영향을 주면 안된다)를 진행한 테이블에 대해 모든 결정자가 후보키가 되도록(일반 칼럼이 기본키에 영향을 주면 안된다) 테이블을 분해하는 것
→ 일반 칼럼이 어떠한 칼럼에도 영향을 주면 안된다(일반 칼럼이 결정자가 되면 안된다)
기본키 : 후보키 중에 선택한 주키
후보키 : 테이블에서 각 행을 유일하게 식별할 수 있는 최소한의 속성들의 집합. 후보키는 기본키가 될 수 있는 후보들이며 유일성과 최소성을 동시에 만족해야함.
결정자: 다른 속성을 고유하게 결정하는 하나 이상의 속성 (기본키는 결정자의 부분집합)
아래의 강의 테이블을 살펴보자.
각 교수는 1개의 과목만 가르친다고 가정해보자.
이렇게 되면 제3 정규형을 만족한다. 이 경우에는 어떤 이상현상이 생길까?
이러한 이상현상이 생기는 이유는, 결정자(Determinant)가 후보키(Alternative Key)로 취급되고 있지 않기 때문이다.
이 릴레이션에서는 (학번, 과목명)
이나 (학번, 담당교수)
가 후보키가 된다. 담당 교수
만으로는 후보키가 될 수 없다.
하지만, 후보키가 아님에도 과목명
을 결정할 수 있기 때문에 담당 교수
는 결정자에 속한다.
이 이상현상을 해결하기 위해서 모든 결정자는 항상 후보키가 되도록 릴레이션을 분해해주면 강한 제3 정규형, 즉 BCNF를 만족하게 된다.
[적용 후]
BCNF에 대해서 더 파보자..! 후보키로 취급된다는 것이 무엇인지 아직 모르겠다.
Table명: Number
칼럼명: 1,2,3,4,5
기본키: 1,2
기본 설정: 1,2가 3,4,5의 결정자 → 3NF, BCNF 모두 만족
1) 3이 4,5의 결정자다(3이 4,5에 영향을 준다) → 3NF,BCNF 둘다 위반
2) 3이 1의 결정자다(3이 1에 영향을 준다) → 3NF 만족, BCNF 위반
3) 3이 1,4의 결정자다(3이 1,4에 영향을 준다) → 3NF,BCNF 둘다 위반