정규화 과정

👣 개요

릴레이션 간의 잘못된 종속 관계로 인해 DB 이상 현상이 일어날 때, 이를 해결하는 과정.
저장 공간을 효율적으로 사용하기 위해 릴레이션을 여러 개로 분리하는 과정.
절대로 정규화가 성능 상의 이점을 준다는 것은 아니기 때문에 서비스의 상황에 맞춰서 정규화 결정을 내려야 함.

[정규화를 진행함]
데이터 무결성을 지키기 용이해진다. 때문에 삽입, 수정, 삭제 성능이 좋아진다.
But, 조회 시 Join 연산이 늘어난다. 때문에 조회 성능이 떨어진다.

👣 갱신 이상

1. 수정 이상
반복된 데이터 중에 일부만 수정하면 데이터 불일치 발생

2. 삽입 이상
불필요한 정보를 함께 저장하지 않고는 어떤 정보를 저장하는 것이 불가능.

3. 삭제 이상
유용한 정보를 함께 삭제하지 않고는 어떤 정보를 삭제하는 것이 불가능.

👣 정규형의 원칙

내용적으론 동일하지만 자료의 중복성을 줄이고 독립적인 관계는 별개의 릴레이션으로 표현해야 한다.

👣 제 1 정규화

도메인은 더이상 분해될 수 없는 원자 값으로 구성되어야 함.
쉽게 말해 셀 내부에는 List가 들어가면 안 된다.

👣 제 2 정규화

릴레이션이 제 1 정규형이면서 부분 함수의 종속성을 제거한 형태.
쉽게 말해서 기본키가 아닌 모든 속성이 기본키에 종속적이여야 한다는 것이다.
F({기본키}) => {값 1, 값 2, 값 3, ...}

주문 테이블

위 경우 기본키는 {주문 번호, 제품 번호}이지만 '제품 이름'과 '제조사'는 {제품 번호}에만 종속된 것일 뿐 기본키에 종속된 것은 아니다. 이는 삽입 이상과 수정 이상을 야기하므로 다음과 같이 수정한다.

👣 제 3 정규화

릴레이션이 제 2 정규형이면서 이행적 함수의 종속성을 제거한 형태.
쉽게 말해서 '기본키 이외의 속성'이 다른 '기본키 이외의 속성'에 종속되지 않는 상태를 일컫는다.

해당 사진은 아래 예시와 관계가 없다.

위 테이블에서 모든 속성이 기본키{학번}에 종속되긴 하지만 '학과 전화번호'는 명백히 '학과'에 종속되어 있다.
이 역시 삽입 이상과 수정 이상을 야기하므로 다음과 같이 수정한다.

👣 보이스/코드 정규화

릴레이션이 제 3 정규형이면서 결정자가 후보키가 아닌 함수 종속 관계를 제거한 형태.