릴레이션 정규화

릴레이션 정규화
부주의한 데이터베이스 설계는 제어할 수 없는 데이터 중복을 야기하여 여러 가지 갱신 이상(update anomaly)을 유발함
어떻게 좋은 데이터베이스 설계를 할 것인가? 데이터베이스에 어떤 릴레이션들을 생성할 것인가? 각 릴레이션에 어떤 애트리뷰트들을 둘 것인가?   
 정규화(normalization)는 주어진 릴레이션 스키마를 함수적 종속성과 기본 키를 기반으로 분석하여, 원래의 릴레이션을 분해함으로써 중복과 세 가지 갱신 이상을 최소화함

 

정규화 개요

좋은 관계 데이터베이스 스키마를 설계하는 목적
정보의 중복과 갱신 이상이 생기지 않도록 하고, 정보의 손실을 막으며, 실세계를 훌륭하게 나타내고, 애트리뷰트들 간의 관계가 잘 표현되는 것을 보장하며, 어떤 무결성 제약조건의 시행을 간단하게 하며, 아울러 효율성 측면도 고려하는 것
먼저 갱신 이상이 발생하지 않도록 노력하고, 그 다음에 효율성을 고려함 

 갱신 이상(update anomaly)
 수정 이상(modification anomaly)
 반복된 데이터 중에 일부만 수정하면 데이터의 불일치가 발생
 삽입 이상(insertion anomaly)
불필요한 정보를 함께 저장하지 않고는 어떤 정보를 저장하는 것이 불가능
 삭제 이상(deletion anomaly)
유용한 정보를 함께 삭제하지 않고는 어떤 정보를 삭제하는 것이 불가능

 정보의 중복
각 사원이 속한 부서 수만큼 동일한 사원의 투플들이 존재하므로 사원이름, 사원번호, 주소, 전화번호 등이 중복되어 저장 공간이 낭비됨

 수정 이상
만일 어떤 부서의 이름이 바뀔 때 이 부서에 근무하는 일부 사원 투플에서만 부서이름을 변경하면 데이터베이스가 불일치 상태에 빠짐

 

 삽입 이상
만일 어떤 부서를 신설했는데 아직 사원을 한 명도 배정하지 않았다면 이 부서에 관한 정보를 입력할 수 없음

 삭제 이상
만일 어떤 부서에 속한 사원이 단 한 명이 있는데, 이 사원에 관한 투플을 삭제하면 이 사원이 속한 부서에 관한 정보도 릴레이션에서 삭제됨

 

릴레이션 분해
하나의 릴레이션을 두 개 이상의 릴레이션으로 나누는 것
릴레이션의 분해는 필요한 경우에는 분해된 릴레이션들로부터 원래의 릴레이션을 다시 구할 수 있음을 보장해야 한다는 원칙을 기반
분해를 잘못하면 두 릴레이션으로부터 얻을 수 있는 정보가 원래의 릴레이션이 나타내던 정보보다 적을 수도 있고 많을 수도 있음
릴레이션의 분해는 릴레이션에 존재하는 함수적 종속성에 관한 지식을 기반으로 함

 

예: 릴레이션 분해
그림 7.2의 사원 릴레이션을 그림 7.3의 사원1 릴레이션과 부서 릴레이션으로 분해한다. 

그림 7.2에서 예를 들었던 갱신 이상 문제는 아래와 같이 해결됨
부서이름의 수정
어떤 부서에 근무하는 사원이 여러 명 있더라도 사원1 릴레이션에는 부서 이름이 포함되어 있지 않으므로 수정 이상이 나타나지 않음
새로운 부서를 삽입
만일 어떤 신설 부서에 사원이 한 명도 배정되지 않았더라도, 부서 릴레이션의 기본 키가 부서번호이므로 이 부서에 관한 정보를 부서 릴레이션에 삽입할 수 있음
마지막 사원 투플을 삭제
만일 어느 부서에 속한 유일한 사원에 관한 투플을 삭제하더라도 이 부서에 관한 정보는 부서 릴레이션에 남아 있음

 

정규형(normal form)의 종류
 제1정규형(first normal form), 제2정규형(second normal form),
    제3정규형(third normal form), BCNF(Boyce-Codd normal form),
    제4정규형(fourth normal form), 제5정규형(fifth normal form)
일반적으로 산업계의 데이터베이스 응용에서 데이터베이스를 설계할 때 BCNF까지만 고려함

관계 데이터베이스 설계의 비공식적인 지침
지침 1: 이해하기 쉽고 명확한 스키마를 만들라
여러 엔티티 타입이나 관계 타입에 속한 애트리뷰트들을 하나의 릴레이션에 포함시키지 않음

지침 2: 널값을 피하라
지침 3: 가짜 투플이 생기지 않도록 하라
지침 4: 스키마를 정제하라