정규화(Normalization)
정규화란 이상현상이 있는 릴레이션을 분해하여 이상현상을 없애는 과정이다. 이상현상이 존재하는 릴레이션을 분해하여 여러 개의 릴레이션을 생성하게 된다. 정규형이 높아질수록 이상현상은 줄어들게 된다. 즉, 쉽게말하면 테이블 간에 중복된 데이터를 허용하지 않는다는 것이다. 중복된 데이터를 허용하지 않음으로써 무결성(Intergrity)을 유지할 수 있으며, DB의 저장 용량 역시 줄일 수 있다.
정규화의 장점
•
동일한 정보의 중복 저장을 방지하여 저장 공간 절약
•
한 곳만 수정하면 되므로 데이터 불일치 발생 가능성 감소
•
정규화를 통해 데이터 이상 현상을 줄일 수 있음.
•
테이블 간의 관계가 명확하여 유지보수 용이
•
관계형 제약조건을 통한 데이터 정확성 보장
정규화의 단점
•
테이블이 분리되어 있어 데이터 조회 시 JOIN이 많아지고 성능 저하 가능
•
테이블 간의 관계를 잘 이해해야 하며 쿼리가 복잡해질 수 있음.
•
읽기(조회)가 많은 시스템에서는 과도한 정규화가 응답 속도 저하로 이어질 수 있음.
•
너무 세분화된 테이블은 전체 구조 파악이 어려워질 수 있음.
•
만약 조인이 많이 발생하여 성능 저하가 나타나면 반정규화(denormalization)를 적용할 수도 있음.
제1 정규화(1NF)
테이블의 각 컬럼이 원자값(Atomic Value)을 가져야 한다.
위의 테이블에서 철수는 여러 개의 과목을 수강하고 있기 때문에 제1 정규형을 만족하지 못하고 있다. 그렇기 때문에 이를 제1 정규화하여 분해할 수 있다. 제1 정규화를 진행한 테이블을 아래와 같다.
제2 정규화(2NF)
제1 정규화를 만족하면서, 기본 키가 아닌 모든 필드들이 모든 기본 키에 완전히 종속돼야 한다. 즉, 완전 함수 종속을 만족해야 한다.
제1 정규화를 진행한 학생 테이블을 다시 살펴보자. 학생 테이블에서 기본 키는 무엇일까? 학생 테이블의 기본 키는 (학생이름, 수강과목)이다. 이 조합으로 레코드를 고유하게 식별할 수 있다. 하지만, 문제는 나이다. 나이는 기본 키 전체 (학생이름, 수강과목)이 아니라 부분 집합인 학생이름에만 종속되어 있다. 이것을 부분 함수 종속(partial functional dependency)이라고 부르며, 제2 정규형에서는 허용되지 않는다.
따라서, 부분 함수 종속을 제거하기 위해 테이블을 위처럼 두 개로 나눈다. (학생이름, 수강과목) 조합으로 수강 이력을 관리하고, 학생이름 → 나이 종속성을 분리하여 독립된 테이블로 만든다. 각 테이블은 이제 기본 키에 대해 완전 함수 종속(full functional dependency)을 만족한다.
제3 정규화(3NF)
제2 정규화를 만족하면서, 기본 키가 아닌 모든 필드들이 이행적 종속성이 없어야 한다.
만일 어떤 테이블에 A, B, C라는 필드가 있을 때 A가 B를 결정하고(A → B) B가 C를 결정한다면(B → C) A도 C를 결정하게 되어(A → C) 종속 관계를 형성한다. 이때 필드 A와 C 사이에는 이행적 종속 관계(transitive dependency), 이행 함수 종속성이 있다고 표현한다. 예를 들어 아래와 같은 고객 정보 테이블을 살펴보자.
고객 정보 테이블에서 기본 키는 고객 번호다. 고객 번호는 나머지 모든 필드들을 결정하고, 등급은 할인율을 결정한다. 따라서 고객 번호, 등급, 할인율 간에 이행 함수 종속 관계가 성립하고, 제3 정규형에서는 허용되지 않는다.
따라서, 이행 함수 종속을 제거하기 위해 테이블을 위처럼 두 개로 나눈다. 이제 중간 단계를 거치는 이행적 종속성이 사라지므로 제3 정규형을 만족하게 된다.
보이스/코드 정규화(BCNF)
제3 정규화를 만족하면서, 모든 결정자가 후보 키가 되도록 테이블을 분해해야 한다.
대부분의 경우, 제3 정규형을 만족하면 데이터의 이상 현상이 크게 줄어들지만, 아주 특수한 경우에 이상 현상이 발생할 수 있다. 다음 예제를 살펴보자.
특강수강 테이블에서 기본키는 (학생번호, 특강이름)이다. 그리고 기본키 (학생번호, 특강이름)는 교수이름을 결정하고 있다. 그런데 만약 교수는 하나의 특강만을 담당할 수 있다고 가정하면, 교수이름은 특강이름을 결정할 수 있게 된다. 이 경우, 교수이름은 후보 키가 아니지만, 특강이름의 결정자 역할을 하게 되고, BCNF에서는 이를 허용하지 않는다.
따라서, 후보 키가 아닌 결정자를 제거하기 위해 테이블을 위처럼 두 개로 나눈다. 이제 두 테이블 모두 BCNF를 만족하게 된다.
