[정규화] 효율적인 데이터베이스 스키마 구축

"효율적"인 데이터베이스가 무엇일까?

 

개념적 설계를 통해 <학생>이라는 개체에 필요할 만한 속성을 이것저것 넣었다고 해보자.

학번, 이름, 주민번호, 성별, 주소, 학과, 동아리, 학점, ......

 

너무도 완벽한 것 같다. 마치 나의 <학생> 릴레이션이라면 학생들의 모든 정보를 다 담고 있는 것 같아 행복하다. 이를 가지고 <학과>나 <동문> 릴레이션과 관계를 가지면 엄청난 빅데이터가 탄생할 것만 같다.

 

그러나 이 많은 정보를 <학생>이라는 단 하나의 릴레이션에 다 담고 있으면, 나중에 부피가 커졌을 때 관계가 복잡해지고 유지보수에 상당한 비용을 지출하게 된다.

만약 정보를 잘못 저장한 곳이 있다면 탐색하고 수정하는 데에도 꽤 많은 비용을 들여야 할 것이다.

그리고 정보가 많은 만큼 데이터베이스의 주 적인 "중복"을 만날 수 있으며, 데이터의 중복은 이 커다란 테이블을 앞으로 조작할 때 분명 문제를 발생시킬 것이다.

이를 "이상(Anomaly)"현상이라고 하며, 이러한 데이터베이스가 바로 "비효율적"인 데이터베이스다.

삽입이상 : 원래 기본키로 선정된 속성은 개체무결성 제약에 의해 Null이나 중복값을 가질 수 없는데, 잘못된 설계로 인해서 값을 추가할 때 Null이 입력되는 등 원치 않는 값이 입력되는 현상

삭제이상 : 외래키를 가지고 [참조테이블]을 참조하는 [참조하는 테이블]은, 참조무결성 제약에 의해 [참조테이블]의 기본키의 속성 중 하나의 값을 삭제할 시, [참조하는 테이블]의 해당 외래키의 속성 값도 같이 삭제시킬 수 있다. 하지만 잘못된 설계로 인해서 그 외래키의 속성 값 말고도 삭제되면 안되는 정보들까지 같이 삭제되는 현상

갱신이상 : [참조테이블] 내 어떤 값을 업데이트 하면, 이를 [참조하는 테이블]도 참조무결성 제약에 의해 같이 업데이트 되어야 한다. 하지만 잘못된 설계로 인해서 어떤 곳은 업데이트가 되고, 어떤 곳은 안되는 등 일관성(무결성)이 깨지는 현상

 

이처럼 하나의 테이블에 속성을 막 때려넣는다고 좋은 것이 절대 아니고, 이는 오히려 잘못된 설계로 본다.

그래서 이렇게 하나의 크고 무거운 테이블을 여러 개의 작은 테이블로 쪼갬으로써 효율성을 확보하는 과정이 필요하고, 이를 "정규화"라고 한다.

 

---

정규화를 할 때는 "함수적 종속성"이라는 원칙을 따른다.

커다란 테이블을 무작정 쪼개는 것이 아니라, 테이블이 서로 종속된 관계를 가질 때, 그 종속성이 어떤 유형에 속하는지에 따라 효율적인 정규화의 방법을 달리한 것이다.

 

X -> Y

X, Y : 각 릴레이션의 속성으로, 임의의 X를 입력했을 때 Y는 유일하게 나와야 한다(검색결과가 오직 1건). ex X:학번, Y:이름

Y가 X에 의해 결정되므로 X를 결정자, Y를 종속자라고 하며,

"Y는 X에 종속된다" 또는 "X는 Y를 결정한다" 라고 한다.

 

---

 

1. 2NF : 부분함수적종속을 없애는 정규화 (기본키가 복합속성으로 되어있는 경우의 정규화 방법(2개 이상의 Attributes가 모두 기본키일 때))

 

먼저 기본키가 단일속성일 때를 살펴보자.

만약 <학생> 테이블에서 기본키가 "학번"으로 단일속성일 때는 부분함수종속을 따질 필요가 없다.

즉 기본키가 "학번" 하나로 구성되어 있다면, 그 학번(X) 하나로 이름과 학번, 주민번호 등(Y)을 유일하게 식별해낼 수 있어, 이미 완전히 종속된 "완전함수종속" 상태이기 때문이다.

 

그런데 이번에는 <수강> 테이블에서 기본키가 "학번"과 "과목코드" 모두 동시에 등록되어 있다고 해보자.

이 테이블에는 ["학번", "과목코드", "학점", "학과", "주소"] 속성이 있다고 가정하자.

이렇게 기본키가 복합속성으로 되어있을 때는, 그 복합속성을 이루는 모든 기본키들을 하나로 묶었을 때(X) 비로소 하나의 결과(Y)를 검색할 수 있는 경우를 "완전함수적종속"이라고 한다.

예를 들어 "학번"과 "과목코드"가 복합속성 기본키라면 "학번"과 "과목코드"를 동시에 적용해야만 학생A의 COM과목의 유일한 "학점"을 검색할 수 있고, 이를 "완전함수적종속"이라고 한다.

하지만 이번에는 "학점"이 아니라 "학과"를 검색한다고 해보면, 굳이 이 모든 기본키를 다 적용하는 것이 아니라, "학번" 기본키로만 검색해도 유일한 결과가 나온다. 이를 "부분함수적종속"이라고 한다.

 

이렇게 한 테이블에 복합속성이 있으면서, 완전함수적종속과 부분함수적종속이 모두 존재하는 경우에는, 완전함수적종속인 속성끼리 하나로 묶고, 부분함수적종속인 테이블을 별도의 테이블로 쪼개면 된다.

즉 ["학번", "과목코드", "학점"] 속성을 하나의 테이블로 만들고, ["학번", "학과"] 속성을 또 다른 테이블로 만들면 된다.

 

이렇게 되면 각 테이블은 모두 "완전함수적종속"을 만족하게 되고, 같은 말로 "2정규형"을 만족한다고 할 수 있다.

 

---

 

2. 3NF : 이행적함수종속을 없애는 정규화 (X->Y를 만족함과 동시에, Y->Z도 만족하는 경우의 정규화 방법(X->Z까지 될 때))

 

<학생> 테이블에 ["학번", "성명", "주민번호", "학과"] 속성이 있다고 가정하자.

이때 "학번"은 각각의 성명/주민번호/학과를 유일하게 검색할 수 있기 때문에 결정자가 될 수 있다.

"주민번호"도 마찬가지로 각각의 학번/성명/학과를 유일하게 검색할 수 있기 때문에 결정자가 될 수 있다.

 

그런데 여기서 중복되는 문제가 발생한다.

"학번"과 "주민번호" 모두 유일하게 검색할 수 있는 속성들이 있기 때문에,

"학번" -> "주민번호" -> "성명" 순으로 검색하는 것과 "학번" -> "성명" 으로 바로 검색하는 것이 서로 같다는 것이다.

이를 "이행적함수종속"이라고 한다.

 

이때 가운데 과정에 위치한 중복적인 속성을 기준으로 좌/우 나누어 이행적함수종속을 없앤 것을 "3정규형"을 만족한다고 한다.

 

---

 

3. 4NF : 다치 종속을 없애는 정규화 (X->>Y (하나의 테이블에서 임의의 속성 X를 입력했는데 Y가 유일하지 않고 여러 개 나오며, 그 Y가 2개 이상 존재할 때, 이를 분할하는 방법))

 

기존 : {과목} ->> {강의실 | 교수}

과목	강의실	교수
DB	D001	Dat Abase
DB	D002	Dat Abase
DB	D001	Ope Rating
DB	D002	Ope Rating
DB	D001	Rel Ation
DB	D002	Rel Ation
C++	C001	C. Plus
C++	C002	C. Plus

▼

1번째 테이블 : {과목} ->> {강의실}

과목	강의실
DB	D001
DB	D002
C++	C001
C++	C002

2번째 테이블 : {과목} ->> {교수}

과목	교수
DB	Dat Abase
DB	Ope Ating
DB	Rel Ation
C++	C.Plus

 

즉 4정규형은 한 테이블 내에 [하나의 속성값 X에 여러 개의 Y가 대응되는 관계]가 2번 이상 존재하는 경우, 그 X->>Y의 관계를 1번씩 따로따로 구분하여 테이블을 쪼개는 방법이다.

이는 복잡하기 때문에 실무에서 거의 쓰이지 않는다.

---

 

4. 5NF : 조인종속이 있는 테이블이 후보키가 아닌 속성들로 구성되어 있을 때, 후보키로 쓰일 수 있는 형태의 속성끼리 묶어서 테이블을 쪼개는 정규화 방법

 

일반적인 테이블은 2개의 테이블로 쪼개면 정규화가 되기 마련이다.

하지만 "조인종속"이 있는 테이블은 더 많은 테이블로 쪼개야 할 수 있다.

"조인종속"이란, 테이블을 쪼개고 나서 다시 조립할 때 기존 테이블로 원상복구해야 하는 "무손실분해 원칙"을 만족하기 위해 "조인"이 필요한 테이블을 의미한다.

만약 "조인"없이 그냥 합치면 원래 없던 이상한 데이터가 생성되는 "위조튜플"이 생기게 된다.

 

이렇게 조인종속이 있는 테이블을 쪼갤 때, 그 테이블이 후보키가 아닌 속성들(유일성 확보 X)로 이루어져 있을 때, 유일성을 만족시키도록 복합속성을 구성하는 최소의 단위들로 쪼개는 것을 "5정규형"이라고 한다.

 

5정규형 역시 복잡하여 실무에서 거의 쓰이지 않는다.