정규화

목차

• 정규화의 필요성 (목적)
• 함수적 종속성
• 정규화

---

정규화의 필요성 (목적)

 

 아래와 같이 축구선수의 정보를 기입한 릴레이션 (테이블)이 있습니다.

 만약 소속팀 속성 "맨체스터시티"의 팀명이 변경된다면 어떤 작업이 이루어져야 할까요? 변경하려는 데이터는 1개인데, 수정해야 할 레코드 수는 3개입니다. 아래와 같이 분리한다면 어떨까요?

 

 팀 관련 테이블로 분리하고, 해당 테이블에서 관리하는 것입니다. 이와 같은 작업을 정규화라고 합니다. 

 

정규화 목적

• 데이터의 일관성 유지 (무결성)
• 저장공간 확보 (중복 데이터 제거)
• 갱신 이상 해소

 

갱신 이상

• 삽입 이상 : 레코드를 추가하려고 할때, 필요치 않은 컬럼 값까지 포함하여 추가해야 하는 경우
• 삭제 이상 : 레코드 삭제 시 의도하지 않은 다른 컬럼의 값까지 삭제되는 경우
• 수정 이상 : 레코드 수정을 위한 컬럼 값이 중복 데이터인 경우 그중 일부만 반영되어 일관성이 깨지는 경우

 

---

함수적 종속성

 

 함수적 종속성이란 릴레이션을 분석하여 속성들 간의 연관관계를 표현하는 것입니다. 속성 간의 연관관계를 분석하여 더 효율적인 릴레이션으로 변환할 수 있습니다. 

 예를 들어 위 테이블에서 소속팀과 리그 2가지 속성 간의 연관관계를 파악해보겠습니다. 

 

소속팀이 "아스날" 이면 리그는 "EPL"입니다. (소속팀이 리그를 결정함 = 리그는 소속팀에 종속됨.)

 

 이때 리그 속성은 소속팀 속성에 종속되는 종속자라 하고, 소속팀은 리그를 결정짓기 때문에 결정자라고 합니다. 표현은 아래와 같이 함수 종속성 다이어그램으로 표현할 수 있습니다.

 

 반면 리그가 "EPL"이면 "아스날"일 수도 있고 아닐 수도 있습니다. (리그는 소속팀을 결정하지 못함) 이런 경우는 아무런 종속성의 없는 것입니다.

---

정규화

 

 속성 간의 함수적 종속성 등을 판별하여 이상현상을 최소화할 수 있도록 속성들을 설계하여 만들어진 릴레이션을 정규형이라 하고 이렇게 정규형을 만드는 과정을 정규화라고 합니다. 

 

정규화의 기능

• 데이터베이스 내에서의 릴레이션들을 효과적으로 표현, 설계
• 검색 알고리즘의 효율성 증대
• 갱신 이상 방지
• 데이터 삽입시 릴레이션 재구성 (수정) 소요 최소화

 

 

정규형의 분류

• 제1 정규화
• 제2 정규화
• 제3 정규화
• BC 정규화 (보통 실무에서는 여기까지만 진행)
• 제4 정규화
• 제5 정규화

 

 

제1 정규화

 정규화의 첫 번째로 가장 조건이 단순한 정규형입니다. 모든 속성의 도메인이 원자 값을 갖는 상태이면 됩니다. 예를 들어 선수 소속 테이블에서 선수에 대한 데이터들이 반복적으로 저장된다면 선수 테이블로 별도로 분리하는 것입니다.

 

제2 정규화 (복합 키, COMPOSITE KEY)

 제1 정규형을 만족하는 전제에 기본키의 부분집합이 특정 속성을 결정하지 않는 상태를 말합니다. 같은 말로 기본키가 아닌 속성들은 모두 기본키에 종속되어야 하는 상태입니다.  무슨 말이야...  쉽게 예를 들어보겠습니다.

 아래와 같이 선수의 소속팀 릴레이션이 있고, 기본 키는 (선수 번호, 소속팀 번호) 속성 2가지로 가집니다. 이 때 선수번호 속성은 선수 이름을 종속합니다. (선수 번호는 선수 이름 속성의 결정자) 이러한 경우에 제2 정규화를 거칩니다.

 

제3 정규화

 제2 정규형을 만족하는 전제 하에 기본키가 아닌 속성이 기본키에 의해 이행적함수 종속 상태가 아닌 것을 말합니다. 아래 예시를 통해 설명해보겠습니다.

 아래 예시를 보면, <소속팀, 리그> 속성의 데이터가 반복되고 있습니다. 그 원인으로 기본키 <번호> 속성이 소속팀을 결정하고, 다시 <소속팀> 속성이 <리그>를 결정하는 것을 볼 수 있습니다.  이렇게 종속자가 다시 결정자가 되는 것을 이행적함수 종속 상태라고 합니다. 이는 갱신 이상을 야기시키기 때문에 제3정규화를 통해 해소합니다.

 

 

BC 정규화

 제3 정규형을 만족하는 전제에 모든 결정자가 후보 키 집합에 속하는 상태를 말합니다. 후보 키가 아닌 속성 (컬럼)이 결정자이면 안됩니다.  아래 그림을 보면 후보키가 아닌 <감독> 속성이 <소속팀> 속성을 결정하고 있습니다. 이런 릴레이션은 bc 정규화 대상이 됩니다.

 

 

 

 

역정규화

 정규화를 통해 릴레이션이 계속 분리가 되면, SELECT 질의 시 많은 조인 연산을 유발하게 됩니다. 그에 따라 정규화한 릴레이션을 반대로 역정규화하는 과정이 존재합니다. 이를 통해 SELECT시 데이터 접근 질의문을 간결하게 만들 수 있습니다.