#title 정규화의 이해
[[TableOfContents]]

==== 정규화의 의미 ====
우리는 이제까지 데이터베이스의 설계를 위한 여러 가지를 살펴보았다. 위에서 다룬 것은 현실을 어떻게 하면 가장 근접하게 표현하는가에 대한 고려사항들이다. 이것들은 현실을 직관적으로 바라보고, 논리적으로 현실을 제대로 데이터베이스에 반영할 것인가에 대한 것 이였다. 데이터베이스의 설계에서 가장 중요한 것은 현실을 제대로 반영하는 것이며, 이를 어떻게 논리적으로 구성하는가를 결정하는 것이다. 특히 관계형 데이터 모델에서는 데이터 값들이 2차원의 평면 테이블 형태로 표현하므로 어떤 릴레이션들이 필요하고, 어떤 애트리뷰트가 필요한가를 결정하는 것이 중요하다.  
 
직관적으로 바라보았던 것들을 ‘정규화’라는 원리를 도입할 것이다. 정규화는 관계형 데이터 모델에서 아주 중요한 역할을 하고 있다. 학자마다 정규화는 튜닝의 도구 또는 설계 검증의 도구이다라고 의견이 약간씩은 다르지만 결국은 같은 의미를 가지고 있다. 현실을 제대로 반영하는 것은 튜닝과 검증이라는 것을 모두 포함하고 있기 때문이다. 데이터베이스 설계를 할 때 우리는 단계적인 사고방식을 가져야 한다고 했다. 단계적인 사고 방식에서 윗 단계를 생각해 보자. 대부분은 설계의 초기단계에서 복잡한 생각을 하지 않는다고 나중에 누락되지는 않을까 하고 생각하는 분들이 많다. 그러나 이러한 것들은 정규화 과정이나 앞의 단계를 거치면서 데이터 모델링은 멋있게 틀을 잡아 간다. 이렇게 틀을 잡아가는 것 중 정규화는 그야말로 아주 큰 역할을 하는 것이다. 우리가 이제까지 행했던 설계를 검증하고, 데이터의 중복을 없앤다 것 자체가 정보의 질을 높이고, 설계의 튜닝을 하는 것이다.
 
정규화란 속성이 제 위치에 제대로 찾아가게끔 하는 것이다. 정규화의 목적은 당연히 데이터의 중복의 최소화와 여러 가지 이상(Anomaly)들을 제거함에 있다. 데이터가 중복되어 있으면 여러 문제를 일으킬 수 있다. 삽입, 삭제, 변경에서 나타나는 이상들이 개발자를 괴롭히는 것이다. 이것은 결국 속성이 제자리에 있지 않기 때문에 발생하는 중복의 문제점 때문이라고 할 수 있다. 정규화 과정은 속성간에 관계성, 데이터 종속성, 성능, 데이터베이스의 일관성 유지 등을 고려해야 한다. 정규화를 검증도구라고 하는 것도 설계가 잘못되면 일어날 수 있는 여러 가지 문제점을 예방하는 차원이기 때문이다. 또한 데이터의 중복을 없앤다는 자체가 엄청난 튜닝의 효과를 가지는 것이다. 일단 데이터의 중복이 많은 설계는 뭔가 문제가 있는 설계이다. 데이터베이스는 중복의 최소화로 기존의 파일처리방식이나 수작업 방식에서 오는 정보의 질을 떨어뜨리는 문제점을 없애는 것이다. 이러한 문제점을 좋은 정보의 질을 유지하기 위한 하나의 정형화된 도구 즉, 정규화를 통해 해결을 하게 되는 것이다. 정규화는 데이터의 중복으로 인한 문제를 해결하기 위해서 속성들 간에 종속성(Dependency)을 분석해서 기본적으로 하나의 릴레이션(테이블)에 표현하도록 분해를 하는 것이다. 어떻게 보면 테이블을 무작정 쪼개는 것으로 보일 수도 있다. 그러나 테이블을 쪼개는 기준은 “함수적 종속”이란 개념으로 쪼개는 것이다. 즉, 함수적 종속성을 파악한 다음 그 함수적 종속을 기본으로 해서 속성들을 하나의 테이블로 그룹 짓는 것이다.

==== 함수적 종속 ====
그럼 “함수적 종속” 이란 것이 무엇인가 살펴보도록 하겠다 일단 함수라 하면 다음의 그림과 같이 나타낼 수 있다.

attachment:정규화의이해/normalization01.jpg

이것을 테이블로 표현한다면 다음과 같다. 

attachment:정규화의이해/normalization02.jpg

일단 함수적 종속이란 말에서 함수라는 것에 대해서 살펴보도록 하겠다. 함수가 무엇인가? 다음의 그림을 보고서 설명을 하도록 하겠다

attachment:normalization03.jpg

그림처럼 왼쪽은 2라는 원소가 두 개가 들어 있다. 2를 어떤 함수에 집어 넣어야지 4가 될까? 일반적으로 생각해 보면 2의 제곱을 구하는 함수에 값을 집어 넣는다면 4가 된다. 그러나 역으로 4를 집어 넣는다면 16이 되버리는 것이다. 즉, 2와 –2는 4가 되기 위해서 함수적으로 종속되어 있는 것이다. 결국 4는 2와 –2가 4가 되기 위한 함수에 종속적이기 때문에 2의 제곱이라는 함수에 종속적이게 만드는 4는 “결정자”라고 부른다. 또한 2와 –2를 “종속자”라고 한다. 
 
사실 이렇게 수학적으로 함수적 종속을 설명하였으나 정규화는 시스템을 구축하고자 하는 조직내의 의미에 함수적 종속을 설명해야 하다. 즉, 정규화는 관계형 모델에서 표현하고자 하는 주제가 동일한 속성들끼리 뭉쳐져 있는 것이다. 그러므로 설계의 초기부터 나타내고 자 하는 정보를 의미론적으로 묶는다면 정규화라는 과정의 설계의 검증도구가 되는 것이다. 위의 예에서 2를 X로 하고 4를 Y라 한다면 함수적 종속의 표현 "X->Y"로 표기한다. 이러한 표현을 실제의 예를 들어서 살펴보겠다.

{{{
학생 릴레이션에서 ...

학번->이름
학번->학과
학번->학년
}}}

위에서 보는 바와 같이 학번은 이름, 학과, 학년을 결정하고 있다. 즉, 학생 릴레이션에서 각각의 학생을 유일하게 구분 지을 수 있는 속성은 학번으로 학번은 기본키의 역할을 하는 속성이다. 즉, 이름만 가지고는 각각의 학생을 알 수 없다는 것이다. 필자가 옛날에 휴학을 하려고 했는데 시간이 없어서 조교님께 휴학 신청을 대신해달라고 한 적이 있었다. 그런데 필자와 같은 이름을 가진 다른 사람이 있었는데 그 사람으로 휴학을 한적이 있어서 상당히 난감했던 적이 있다. 즉, 필자의 이름인 “이재학” 만 가지고는 정확성이 있는 정보가 될 수 없던 것이다. 만약 교수님께서 “이재학”을 불러오라 라고 한다면 이미 과에 “이재학”이란 이름을 가진 사람이 2명이라는 것을 아는 사람은 학번을 교수님께 되물을 것이다. 이렇듯 이름은 학번에 종속되어 있다는 것이다. 이름이 이재학이고, 학과가 정보통신공학과이고, 4학년인 학생은 필자 말고도 한 명이 더 있다. 즉, 이것들은 학번에 종속적이라는 것이다. 
 
테이블로 표현한 것을 가지고 좀더 살펴보도록 하겠다 

attachment:normalization04.jpg

9555023, 이재학, 4학년, 정보통신공학과 라는 것은 한 명의 학생에 대한 데이터이다. 학번, 이름, 학년, 학과 중에 대표성을 띄고 있는 것은 학번이고, [9555023, 이재학], [9555023, 4학년], [9555023, 정보통신] 이라고 해야지만 정확한 정보를 표현할 수가 있는 것이죠. 앞에서 언급했듯이 [이재학, 4학년, 정보통신]이라고 해서 정확한 정보가 되는 것일까요? 당연히 학번이 9555023인 학생과 학번이 9839011인 학생을 구별하지 못하는데 문제가 있다. 이렇듯 학번은 이름, 학년, 학과를 결정하고, 이름, 학년, 학과는 학번에 종속적이다. 이렇게 데이터에 대한 의미를 표현한 것을 함수적 종속이라고 한다. 

'''참고'''
{{{
함수 종속에 대한 증명된 추론 규칙 (R->릴레이션)
(데이터베이스시스템, 이석호, 정익사)
 
R1: (반사규칙) A  B 이면 A->B 이다.
R2: (첨가규칙) A->B 이면 AC->BC 이고 AC->B 이다.
R3: (이행규칙) A->B 이고 B->C 이면 A->C 이다.
R4: (분해규칙) A->BC 이면 A->B 이다.
R5: (결합규칙) A->B 이고 A->C 이면 A->BC 이다.
}}}

정규화는 이러한 “함수적 종속”을 기본 원칙으로 하나의 의미를 가지는 집합으로 나누는 작업이다. 정규화는 1차 정규화, 2차 정규화, 3차 정규화, 보이스/코드 정규화, 4차 정규화, 5차 정규화, 도메인/키 정규화가 있다. 이 순서가 높아지는 단계의 정규화일수록 무결성은 강화되나 과도하게 테이블이 쪼개지므로 쓸 때 없는 부하가 걸릴 수 있다. 그러므로 현실을 감안해서 어느 정도 수준의 정규화까지 행해야 하는가를 결정해야 하다. 보통 실무에서는 3차 정규화와 보이스/코드 정규화까지 하다. 기본으로 3차 정규화까지는 해야 하며, 3차 정규화 과정을 마치고도 사용자의 요구사항에 의해서 여러 가지 이상들이 발생할 요지가 있다면 더 높은 차원의 정규화를 해야 하다. 이제 각 단계별 정규화에 대해서 설명하도록 하겠다.

==== 정규화 ====
정규화의 개념은 이미 설명하였다. 각각의 정규화에 대해서 알아보자. 

{{{
1차 정규화
 -. 반복되는 그룹이 없는 레코드
 -. 반복그룹 제거
2차 정규화
 -. 키가 아닌 데이터 항목들은 기본키에 완전히 함수적으로 종속된다
 -. 기본키에 종속되도록 분리
3차 정규화
 -. 키가 아닌 데이터 항목들은 기본키에 완전히 독립이고, 서로에게 독립이다
 -. 이행종속 제거
}}}

말은 어렵지만 매우 쉽다. 이제까지 우리는 정규화에 대한 언급이 없이 정규화를 했었다. 중요한 것은 각각의 컬럼의 제자리에 맞게 두는 것이다. 이것은 주제중심으로 속성들끼리의 관계를 정의한 것과 같다. 다음의 그림을 보자. 각 화살표는 함수적 종속을 나타낸다. 

attachment:normalization05.jpg

첫 번째의 경우 (A, B, C) , (A, D) 로 정규화 할 수 있으며, 두 번째의 경우 (A, B), (B, C)와 같이 정규화된다. 정규화를 하기 전에 함수 종속도(FD)를 작성하면 3차 정규화는 자연스럽게 이루어 질 수 있다. 
 
==== 1차 정규화 ====
하나의 릴레이션은 어떤 도메인의 집합이다. 각각의 속성은 해당 도메인에 속하는 단지 하나의 값(원자값)을 가져야 하다. 이것이 1차 정규화 이며, 실제로 1차 정규화도 거치지 않은 테이블이 많이 존재하다. 예를 들면 다중값 속성들이 그대로 표현될 때 정규화된 테이블이 아닌 즉, 비정규화 테이블인 것이다. 사원테이블에 사번, 이름, 보유기술, 월급의 속성이 있는데 보유기술은 여러 개를 가질 수 있다는 현실을 생각해 보도록 하겠다. 일반적으로 문서를 만들면 다음과 같은 문서가 나올 수 있다. 보유기술에서 하나의 속성값에 여러 개의 값이 들어간 것을 볼 수 있다. 이러한 표현은 비정규화 된 테이블이다. 여기서 기본키는 사원번호이다.  

attachment:normalization06.jpg

그렇다고 다음과 같이 보유기술을 옆으로 펼친다고 해서 달라지는 것은 없다. 이도 역시 1차 정규화된 테이블이 아니라고 볼 수 있다. 의미상으로 보유기술1, 보유기술2, 보유기술3는 그냥 보유기술의 종류일 뿐이다. 그러니 하나의 속성에 여러 개의 값을 다른 표현으로 한 것 뿐이다. 

attachment:normalization07.jpg

어떤 사람든 보유기술 속성에 속성값을 넣는데 콤마로 구분하면 어떻겠냐? 라는 생각을 가질 수도 있다. 만약 사원번호 1111 인 사원의 보유기술을 하나 더 추가하려면 기본키가 “사원번호” 이므로 “사원번호”가 1111 인 사원이 추가되지 못하는 것을 알 수 있다. 즉, 다음과 같은 그림이 되어 삽입을 할 수 없는 형태가 되는 것이다. 

attachment:normalization08.jpg

이제 본격적인 정규화에 대해서 알아보겠다. 아래의 테이블은 각각의 학생에 대해서 각각의 속성마다 단일값을 가지고 있으므로 1차 정규화된 테이블이 이다. 여기서 독자들은 함수적 종속관계를 찾아보아야 할 것이다. 여러분은 찾아낸 함수적 종속성을 바탕으로 데이터가 많이 중복되어 있고, 그 데이터의 중복으로 인한 여러 가지 문제점(이상)들을 찾아내어야 한다. 

attachment:normalization09.jpg

이 테이블의 함수적 종속 다이어그램의 다음과 같다. 

attachment:normalization10.jpg

함수적 종속 다이어그램에서 보는 바와 같이 학번은 학생명과 학년을 결정하고, 학번은 학과를 결정하다. 또한 수강코드는 담당교수와 과목명을 결정하다. 각각의 학생은 자신이 수강 신청한 과목의 성적등급을 알기 위해서 학번과 수강코드가 필요하다. 담당교수는 학과를 결정한다. 여기서 자칫 잘못하면 학과가 담당교수를 결정할 수 있다고 볼 수 있는데 하나의 학과에 소속된 교수는 여러 명인 것이 보인다. 즉, 지도교수가 학과를 결정하는 것이지 학과가 교수를 결정하는 것이 아니다. 
 
이제 1차 정규화된 테이블을 가지고 나타나는 문제점을 살펴보도록 하겠다 이러한 문제점은 함수적 종속과 관련하여 찾아보아야 하다. 

attachment:normalization11.jpg

이 테이블은 학번만 가지고는 어떤 과목의 성적의 등급이 얼마인지를 모른다. 그러므로 이 테이블의 기본키는 학번 + 수강코드이다. 여기서 주의할 것은 수강코드라는 속성의 이름이 수강을 해야만 존재 코드가 아니라는 사실이다. 즉, 수강할 때 그 과목을 나타내는 과목의 고유번호를 나타내는 것이다. 
 
==== 2차 정규화 ====
앞서서 삽입, 삭제, 갱신 이상들이 일어 날 수 있다는 것을 보았다. 1차 정규화된 테이블에서 이러한 문제점이 일어나는 원인이 무엇일까? 원인은 바로 기본키가 아닌 각각의 속성들이 기본키에 종속적이지 않고, 부분적으로 함수 종속이 되기 때문이다. 즉, 기본키를 제외한 모든 속성이 기본키에 함수적 종속이 아니기 때문이다. 이러한 문제를 해결하기 위해서는 기본키에 함수 종속을 시킨 것 끼리 따로 테이블을 만들어야 하다. 2차 정규화된 테이블은 다음과 같다 ( 테이블 밑은 점(...)은 생각치 않도록 하겠다 )

attachment:normalization12.jpg

2차 정규화의 결과로 위와 같은 3개의 테이블이 나왔다 학생과 수강과목은 다:다의 관계를 맺고 있기 때문에 학생의 학번과 수강과목의 수강코드가 합쳐진 것을 기본키로 하여 학생 테이블과 수강과목 테이블을 연관 지어 주고 있다. 사실 데이터 모델링의 초기단계부터 차근 차근 진행해 오면서 엔티티만 제대로 도출해 냈다면 이와 같은 2차 정규화 작업은 필요가 없다 그러나 이와 같은 검증된 원리를 알고 있다면 애매모호 함이 없어지고, 좀더 정확한 정보를 산출하는 정보시스템이 만들어 질 수 있는 것이다. 
 
학생 테이블과 수강과목 테이블에 학과라는 속성이 중복되어 존재하는 것이 보이다. 이것은 어떤 다른 엔티티 집합이 더 존재한다는 것을 의미하다. 즉, “학과” 엔티티가 “학생”과 “수강과목”과 관계를 맺고 있다는 것이다. 위의 테이블을 볼 때 학과와 관련된 엔티티와 학생, 수강과목은 1:다의 관계를 맺고 있음을 알 수 있다. 즉, 
 
학과 : 학생->1 : 다
학과 : 수강과목->1 : 다
 
의 관계이다. (사실 더 많은 객관적인 업무규칙이 파악되어야 정확히 알 수 있다.) 그러므로 속성의 이름은 학과보다는 “학과명”이라고 하는 것이 더 명확하겠다. 그러나 이 단원에서는 다른 엔티티 집합은 생각치 않겠다
 
이제는 어느 정도 속성들이 자신이 있어야 할 곳에 배치된 것으로 보이다. 그러나 이러한 2차 정규화 테이블에도 이상들이 존재하다. 이러한 이상들을 살펴보도록 하겠다 
 
2차 정규화된 테이블에서 이상이 일어나는 이유는 기본키가 아닌 다른 속성들 간에 함수적 종속이 일어나기 때문이다. 이렇게 기본키가 아닌 속성들끼리의 종속성을 가지는 것은 이행 종속(Transitive Function Dependency) 라고 하다. 이러한 개념으로 위의 테이블에서 일어날 수 있는 문제점을 찾아보록 하겠다 먼저 문제의 이행 종속이 일어나고 있는 테이블을 추려내야 하다. 앞서서 그려본 함수적 종속 다이어그램에서와 같이 이행 종속이 일어나고 있는 테이블은 수강과목 테이블이다. 

'''삽입이상:'''
각 과목을 담당하는 교수가 특정 학과에 속한다는 사실을 삽입하려 할 때 과목이 존재하지 않는다면 이 사실을 삽입할 수 없다 즉, 각각의 행을 구분할 수 있는 대표성을 지닌 속성(기본키)가 존재하지 않으므로 삽입이 불가능하다는 것이다. 기본키는 수강과목 테이블에서 반드시 들어가야만 하는 것인데 이를 무시한 채 다른 속성값을 삽입하려 한 것이 문제이다. 
 
'''삭제이상:'''
만약 해당 학과의 커리큘럼이 바뀌어 오상훈 교수가 담당하고 있는 과목인 “자료구조”라는 과목이 없어진다면 오상훈 교수가 정보통신공학과에 소속된다는 사실도 없어지게 된다. 오상훈 교수가 정보통신공학과에 소속된다는 사실은 이행종속이 일어나고 있다는 것이며, 역시 2차 정규화된 테이블에서 일어나는 삭제이상도 이행 종속 때문이라는 것을 알 수 있다. 
 
'''갱신이상:'''
만약 박덕규 교수의 소속 학과가 정보통신에서 다른 학과로 변경된다면 박덕규 교수에 해당되는 학과에 대한 속성값을 모두 변경시켜 주어야 한다. 역시 이행종속이 일어나서 일어나는 이상현상이다. 

==== 3차 정규화 ====
2차 정규화된 테이블에서 이행 종속에 의해서 여러 가지 이상현상이 발생되는 것을 보았다. 이러한 여러 이상현상을 제거하려면 어떻게 해야 할까? 당연히 이상현상의 원인이 되었던 이행종속을 없애면 된다. 어떻게 없애야 할까? 당연히 이행종속을 일으키는 속성들을 묶어서 그룹 지어 주면 문제는 해결된다. 

attachment:normalization13.jpg

이렇게 이행 종속성을 제거한 테이블은 3차 정규화된 테이블이다. 만약 독자들 중에 여기까지 대충 읽어 본 분들은 아마도 정규화란 것이 테이블을 쪼개는 것이구나 라고 생각하시는 분들도 있을 것이다. 그러나 테이블을 쪼갠다는 개념을 갖지 말고, 좀더 세부적으로 관련성이 많은 것끼리 새로운 그룹을 만드는 개념으로 정규화를 생각하셔야 하다. 
 
==== 보이스/코드 정규화 ====
3차 정규화도 여러 가지 이상이 존재하다. 그렇다면 이상이 발생하지 않는 정규화 과정은 어떤거냐고 의문을 가지는 분도 있을 것이다. 이상이 발생하지 않는 정규화는 키/도메인 정규화이다. 이것은 증명은 되었으나, 키/도메인 정규화 테이블을 만드는 구체적인 방법을 발견하지 못했기 때문에 실무에서 직관적으로 사용되는 방법이기도 하다. 그러나 보통 실무에서는 3차 정규화 과정이나 보이스/코드 정규화까지 한다. 그 이유는 일반적으로 4차 정규화나 5차 정규화 과정을 거쳐야 하는 상황은 거의 발생하지 않기 때문이다. 이 책에서는 보이스/코드 정규화 과정까지만 언급하겠다 만약 보이스/코드 정규화 과정을 거쳤으나 사용자가 원하는 작업을 수행할 때 이상이 발생한다면 4차 정규화 과정을 거쳐야 할 것이다. 4차, 5차 정규화는 다른 책을 참고해야 할 것이다.
 
이제 위의 3차 정규화를 거친 테이블에 대한 이상현상이 발생하는 원인을 분석하고 보이스/코드 정규화에 대해서 언급하도록 하겠다. 3차 정규화 과정을 거치 테이블에서 이상현상을 발생시키는 원인은 후보키들이 중첩되어 있다는 것 때문이다. 후보키는 기본키가 될 수 있는 자격이 있는 속성 또는 속성들이다. 즉, 하나의 릴레이션에 여러 개의 후보키가 존재하는데 하나 또는 여러 개의 속성이 중첩되어서 후보키될 때 이상현상이 발생할 수 있다는 것이다. 보이스/코드 정규화 과정은 바로 이러한 문제점을 해결하는 것이다. 이러한 의미에서 볼 때 보이스/코드 정규형은 “엄격한 3차 정규형”이라고도 하다. 
 
보이스/코드 정규형은 릴레이션의 모든 결정자가 후보키이면 보이스/코드 정규형이라고 보는 것이다. 결정자라는 개념은 어떤 속성을 함수적으로 완전히 종속시키는 속성을 의미하다. 만약 다음의 업무 규칙이 존재하는 테이블이 있다고 가정 한다면

 * 하나의 과목을 여러 교수가 담당할 수 있다.
 * 각 교수는 하나의 과목만을 담당한다. 
 * 각각의 학생은 같은 과목명을 가진 다른 과목을 수강하지 못한다.

attachment:normalization14.jpg

앞서서 언급한 3차 정규화의 문제점인 후보키의 일부가 되는 속성인 “학번”이 중첩되어 있는 것이 보인다. 즉, 수강_교수 릴레이션의 후보키는 “학번 + 과목명”, “학번 + 담당교수” 이다. 이 후보키중 “학번 + 과목명”을 기본키라고 가정하겠다. 함수 종속 다이어그램에서 보는 바와 같이 “학번 + 과목명”은 “담당교수”를 결정하고, “담당교수”는 “과목명”을 결정한다. 이런 구조를 가지고 있는 릴레이션의 문제점을 파악해 보도록 하겠다.


'''삽입이상:'''
만약 이현태 교수도 자료구조를 담당하게 되었다면 수강신청을 한 학생이 있어야만 이와 같은 사실을 입력할 수 있다. 만약 “담당교수”의 의미가 해당 과목을 담당하고, 또한 그 학생에 대한 생활지도 등의 “지도”를 할 수 있다면(여기서는 담당과목을 수강하지 않은 학생도 지도할 수 있다는 가정), 과목을 수강하지 않은 학생은 지도교수가 누구인지 결정을 할 수 없게 된다. 
 
'''삭제이상:'''
학번이 “9655032” 인 학생이 자료구조의 수강 취소를 한다면 오용선 교수가 자료구조를 담당하고 있다는 사실도 함께 삭제된다. 이뿐만 아니라 다른 과목들도 마찬가지로 수강하는 학생이 수강을 취소한다면 과목에 대한 담당교수도 같이 삭제되므로 이상현상이 일어난다. 만약 다른 수강 신청자가 있다면 이와 같은 사실은 같이 삭제되지 않으나 현재 상황으로 볼 때 어떤 교수가 어떤 과목을 담당하고 있는지를 나타내는 것이 한 개의 투플(행)뿐이기 때문에 이러한 문제를 해결되어야 한다. 
 
'''갱신이상:'''
만약 이현태 교수가 “DB” 에서 “네트웍 프로그래밍”으로 담당과목이 바뀌었다면 3개의 투플(행)을 모두 변경해주어야 한다. 


이러한 문제점은 보이스/코드 정규화 과정을 거치면 해결되는 문제이다. 즉, “모든 결정자가 후보키” 가 되게 하면 되는 것이다. 다음은 보이스/코드 정규화의 결과이다.

attachment:normalization15.jpg

이제 1차 정규화에서 3차 정규화 까지를 종합적으로 살펴볼 필요가 있다. 즉, 이러한 원리만 알고 있다면 바로 3차 정규화 또는 보이스/코드 정규화까지 직접 도출이 가능하다.  직접 도출하는 예를 들어 보겠다 다음과 같은 스키마가 존재한다고 가정하겠다 
 
대출 (대출번호, 고객명, 지점명, 지점위치, 자산, 대출합계)
 
이 스카마는 어떤 은행은 대출에 관련된 스키마이다. 이 스키마를 가지고 함수적 종속만 파악한다면 나머지 보이스/코드 정규형을 도출하는 과정은 간단하다. 다음은 이 스키마에 대한 함수적 종속을 나타내는 것이다. 
 
'''함수적 종속'''
{{{
 지점명->자산
 지정명->지점위치
 대출번호->대출합계
 대출번호->지점명
}}}

attachment:normalization16.jpg

도출한 R1, R2, R3, R4, R5는 모두 보이스/코드 정규형을 만족하다. 각각의 릴레이션의 모든 결정자가 후보키이다. 그러나 이렇게 너무 불필요한 정규화는 결과적으로 성능을 떨어뜨릴 수 있다. 그러므로 다음과 같은 통합작업을 거쳐야 하다. 
 
결과적으로 R1(지점명, 자산),  R2(지점명, 지점위치),  R3(대출번호, 대출합계),  R4(대출번호, 지점명), R5(대출번호, 고객명)으로 일단은 테이블을 최대한 분해하였다 그러나 R1과 R2는 기본키가 같으므로 통합할 수 있다. 그러므로 R1_2 (지점명, 자산, 지점위치) 로 통합되고, R3와 R4, R5가 기본키가 같으나 R3, R4와 R5는 은행(R3, R4)과 고객(R5)으로 서로 다른 것을 나타내므로 R3와 R4는 통합되고, R5는 독립적으로 존재하게 됩니다. 즉, (R3, R4)와 R5는 표현하려는 정보가 틀리기 때문에 통합이 불가능하다. 마지막에 나온 R5는 원래 정규화되기 전의 원래 테이블의 기본키가 된다. 결과적으로 다음과 같이 보이스/코드 정규화가 이루어졌다. 실제로 대출합계는 집계이므로 유도속성이다. 그러므로 필요 없는 컬럼인지 아닌지 다시 정의해야 한다. 
 
R1_2 (지점명, 자산, 지점위치)
R3_4 (대출번호, 지점명, 대출합계)
R5 (대출번호, 고객명)
 
결과적으로 정규화라는 과정은 함수적 종속이라는 하나의 원칙으로 관련성으로 속성들을 묶어서 데이터의 중복을 없애고, 데이터의 중복에 의한 여러 가지 이상현상을 없애는 유용한 도구이다. 데이터의 중복이 최소화되는 자체는 시스템이 가장 가벼운 데이터를 가지고 처리하기 때문에 전체적인 시스템의 성능이 높아지기도 하는 것이다. 
 
 
==== 키/도메인 정규화 ====
'정규화란것은 '함수적 종속'관계를 파악하는 것이다. 이 종속관계를 파악하여 속성이 원래 갈 자리에 가게 하는 것이다. 즉, 주제에 맞는 한 객체가 관련된 업무에 관한 속성들이 있어야 할 곳에 있게 하는 것이다. 우리는 1차 정규화에서 보이스/코드 정규화까지 알아보았다 보통 실무에서는 3차 정규화나 보이스/코드 정규화 때에 따라서는 아주 가끔씩 4차 정규화를 행하다. 
 
그러나 검증은 되었으나 그 방법이 찾아지지 않은 키/도메인 정규화를 이 글에서 이야기하고자 하다. 여기서 말하는 키(key, 주키)라는 것은 객체를 유일하게 구별할 수 있는 속성 중에 가장 관련된 대표적인 것을 이야기 하다. 이 키에 함수적으로 모두 종속되고, 속성의 도메인이 맞다면 즉, 모든 제약이 키와 도메인의 정의에 따른 논리적인 결과인 것은 모두 키/도메인 정규화인 것이다. 
　
이것은 완벽한 정규화이다. 3차 정규형은 기본키에 모두 함수적 종속적인 것들로 테이블을 분리하고, 기본키가 아닌 속성들끼리의 종속성 즉, 이행종속을 일으키는 속성들을 다른 테이블로 옮기고 그 테이블에 기본키를 정의할 수 있으면 된다. 이와 같이 분리된 테이블은 기본키를 가지게 됩니다. 이러한 개념으로 테이블을 봤을 때 데이터가 중복되어 나타나는 것들 잘 살펴보면, 왜 중복이 일어났는지 알 수 있을 것이다. 
 
정규화의 해법들이 키/도메인 정규화 빼고는 모두 나와있다. 그러나 직관적으로 바라본다면 해법이 나와 있지는 않지만 키/도메인 정규화가 더 쉽다 또한 초기에 엔티티를 선정할 때 우리가 시스템화 하고자 하는 관련된 것들끼리 모인 즉, 엔티티를 잘 선정한다면 직관적인 관점에서 3차 정규화는 충분히 할 수 있으리라 생각하다.
　
그렇다고 정규화 과정을 무시해서는 안 된다. 이렇게 직관적으로 설계를 하면서 나갈 때는 정규화는 검증도구가 되는 것이다. 학자에 따라서 정규화는 검증도구다 또는 튜닝도구다라고 하는 의견들이 분분하다. 그러나 정규화는 반드시 필요한 것이 틀림이 없다. 
 
도메인/키 정규화에서 중요한 단어는 제약, 키, 도메인이다. 한가지 주의할 것은 제약에 시간의 개념을 뺏다는 것이다. 엑기스만 뽑는다면 키와 도메인에 대한 제약을 준수시켰을 때 모든 제약이 준수되는 릴레이션은 키/도메인 정규형이다. 
 
다시 핵심단어 키, 도메인, 제약 이 세 가지의 관점에서 살펴보겠다 키라는 것은 객체들을 유일하게 구분지어 주는 속성이다. 즉, 속성들 중 대표하는 것을 말하다. 이 속성들이 가질 수 있는 값들의 범위를 정의한 것이 바로 도메인이다. 독자들 중에 아시는 분이 별로 없으시겠지만 푸리에 변환 같은 것을 보면 시간 도메인에서 주파수도메인으로 주파수 도메인에서 시간 도메인으로 변환을 할 수 있다. 시간 도메인에서 본다면 이 값들은 절대로 변환과정을 거치지 않고는 시간이라는 단위밖에 가지지 못하는 것이다. 실제로 주민번호를 본다면 생년월일 담에 오는 1이란 숫자는 남자밖에 가지지 못하는 숫자이다. 이 도메인을 벗어난다면 현실에 맞지 않게 되는 것이다. 누누히 얘기하지만 데이터베이스는 현실을 최대한 반영하는 것이다. 
 
정리하자면 키라는 것은 “unique + not null + 대표성” 이다. 도메인은 앞에서 얘기한 것처럼 속성이 가질 수 있는 값의 범위이고 가질 수 있는 꼭 그것을 가져야만 하는 의미이다. 이것은 현실의 제약이라고 볼 수 있으며, 이러한 제약이 지켜진다면 이것은 완벽한 이상이 없는 정규형이다. 
　
==== 정규화의 정리 ====
이제 앞에서 살펴보았던 정규화에 대해서 의미로만 따져 보도록 하겠다. 필자의 경우는 정규화 과정은 성능도구로 사용하는 편이다. 사실 함수적 종속이란 것이 조직의 범위내에서 통용되는 의미에 따라 틀려진다. 그러므로 모델링을 하기 전 단계에서부터 정보시스템을 구축하려는 조직에서 사용되는 정보의 의미를 파악하는 것이 더 중요하다고 하겠다. 
 
3차 정규화된 테이블을 보면 테이블마다 어떤 정보들을 나타내기 위해서 데이터 들이 뭉쳐있다. 즉, 각각의 속성들이 뭉쳐서 어떠한 하나의 정보(의미)를 만들어 내기 때문에 그 의미만 잘 파악한다면 앞에서 행했던 것처럼 바로 보이스/코드 정규화까지 직접 도출이 가능한 것이다. 그냥 어떤 “의미”를 나타내기 위해서 그룹짓는 과정이라고 하기엔 너무 애매모호 하다. 그래서 함수적 종속이란 개념을 도입하여 누구나 고개를 끄덕이게 만든 것이 정규화이다. 
 
독자는 사용자가 원하는 정보가 무엇인지 정확하게 판단하여야 할 것이다. 만약 사용자의 요구사항이 정확하게 파악되면, 그 요구사항을 정확히 반영하기 위해서 엔티티를 도출하고, 각각의 속성들을 배치해야 한다. 엔티티는 속성의 집합이기도 하다. 하나의 엔티티가 다른 엔티티와 관계를 맺고, 어떠한 정보를 만들어 낼 수 있다. 
 
일반적으로 데이터 모델링은 하향식(Top-Down)의 방식으로 설계를 하고, 정규화를 통한 하향식(Bottom-up) 방식으로 검증을 하는 방법론을 사용한다. 이제 속성을 가지고 다음 그림을 살펴보도록 하겠다 

attachment:normalization17.jpg

제일 먼저 파악해야 할 것은 “관련성” 이다. 릴레이션이란 것이 속성들이 어떠한 관련성에 묶여서 있는 모습이다. 그러니 관련성이라는 의미는 매우 중요한 것이다. 이것은 기본키와의 관련성이다. 하나의 개체( 학생으로 하였을 경우 학번이 9555023인 학생 하나는 인스턴스이다.)를 대표하는 것이 기본키이기 때문이다. 
 
두 번째는 파악해야 할 것은 속성의 도메인이다. 각각의 속성은 가질 수 있는 값의 범위 즉, 도메인을 가지고 있다. 이 도메인에서 표현할 수 있는 속성값들을 대표할 수 있는 것들을 찾는 것이다. 이 도메인도 관련된 엔티티의 범위를 가지기 때문에 관련성이라는 것은 매우 중요하다. 
 
의미상으로 볼 때 학번과 학생명이 같은 객체의 다른 표현인 것을 알 수 있다. 그러나 한 학년에 속하는 학생이 여러 명인 것을 알 수 있지만, 학년자체는 독립적으로 존재할 수 있는 즉, 엔티티가 아니라 속성이라는 것이다. 결과적으로 이 릴레이션은 “학생” 엔티티 집합이 포함된 것이다.  
 
이러한 방식으로 속성값을 살펴보면 위의 그림이 나올 수 있다. 그림에서 학과명과 관련된 것을 살펴보면, 일단 학번이 이름과 학년을 결정하는 것은 앞에서 체크 하였으므로 이 두 속성은 제외하고 학번으로만 생각해보도록 하겠다. 학번이 학과명을 결정하나요? 이 부분은 상당한 혼돈의 여지가 있다. 그러나 좀더 원천적으로 생각하면 데이터베이스 시스템을 개발하려는 도메인이 무엇인가요? 바로 “학교”이다. 즉, 학교에는 기본적으로 “학생”과 “학과”가 존재해야 “학교”가 존재할 수 있는 것이다. 즉, 학과와 학생은 기본엔티티 집합인 것이다. 이렇게 “닭이 먼저냐? 달걀이 먼저냐?” 라고 따지는 상황이 온다면 이것은 기본엔티티 집합이다. 그러므로 학과명은 “학과” 엔티티 집합의 속성이다. 그러므로 이것은 외부키인 것이다. 그렇다면 다른 속성은 어떨까? 당연히 다른 속성들도 따져볼 것이 못 되는 것이다. 만약 관련이 있다면 그것은 실제 테이블로 표현되었을 때의 외부키로의 기능을 하는 것이다. 
 
결과적으로 이 테이블에서 도출할 수 있는 엔티티 집합은 “학생”, “수강(또는 과목)”, “학과”, “교수” 이다. “학생” 과 “수강” 은 다:다의 관계를 맺고 있으므로 “수강코드, 학번, 등급” 은 이 다:다의 관계를 해소한 것이 되는 것이다. 
 
이렇게 엔티티와 속성과 관계를 도출하는 것은 데이터 모델링의 핵심이다. 이와 같은 기본적인 것만 확실히 파악이 된다면 정규화는 데이터 모델링의 검증의 도구와 튜닝의 도구로 써 훌륭한 역할을 할 것이다.

==== 참고자료 ====
 * attachment:정규화.ppt [http://blue.wonkwang.ac.kr/lecture/200601Lecture/db4/reading_data/ch11.ppt 출처]