ERD와 정규화 과정

ERD(Entity Relationship Diagram)는 DB 구축의 뼈대이며 릴레이션 간의 관계를 정의한 것이다. 서비스를 구축할 때 ERD를 고려하지 않으면 큰일날 것이다.

ERD의 중요성

ERD는 시스템 요구 사항을 기반으로 작성된다. 그리고 이를 기반으로 DB 구축한다. DB 구축 후에도 디버깅, 리팩토링 등에 유용하다. 하지만 이런 ERD도 정형 데이터는 구성할 수 있지만 비정형 데이터는 표현할 수 없다.

 

예시

-승원 영업부서의 ERD

요구 사항

1. 영업 사원은 0~n명의 고객 관리

2. 고객은 0~n개의 주문 넣을 수 있다.

3. 주문에는 1~n개의 상품이 들어간다.

정규화 과정

정규화 과정은 릴레이션 간의 잘못된 종속 관계로 인해서 DB에 이상 현상이 일어나는 것을 막아준다. 그 뿐만 아니라 저장 공간을 효율적으로 사용하기 위해 릴레이션을 여러 개로 분리한다. 

• DB 이상 현상: 한 회원이 한 개의 등급을 가져야 하는데 세 개를 갖거나 NULL 값을 가지면 데이터 삽입, 삭제가 어렵다.

-정규형 원칙

정규형 원칙은 같은 의미를 표현하는 릴레이션이지만 더 구조적이며, 중복성 감소, 독립 관계는 별개 릴레이션으로 표현해야 한다. 즉, 각 릴레이션은 독립적인 표현이 가능해야 한다.

 

-제1정규형

릴레이션의 모든 도메인은 더 이상 분해 불가능한 원자값(atomic value)로만 구성되어야 한다. 릴레이션의 속성 값은 한 개의 기본키에 대해 두 개 이상의 값을 가지는 반복 집합이 있으면 안된다.

사진 처럼 나눠서 반복 집합을 제거해야 한다.

 

-제2정규형

릴레이션이 제1정규형이고 부분 함수의 종속성을 제거한 것이다.

부분 함수 종속성 제거: 기본키가 아닌 모든 속성이 기본키에 완전 함수 종속적인 것

• 완전 함수적 종속: 종속자가 기본키에만 종속되며, 기본키가 여러 속성으로 구성되어 있을경우 기본키를 구성하는 모든 속성이 포함된 기본키의 부분집합에 종속된 경우

여기서 기본키는 {ID, 수강명}이다. 완전 종속된 유저번호와 기본키에 따른 성취도로 2개의 릴레이션으로 분리되었다.

주의할 점은 동등한 릴레이션으로 분해해야 한다. 그리고 정보 손실이 발생하면 안된다.

 

-제3정규형

제 2정규형이고 기본키가 아닌 모든 속성이 이행적 함수 종속(transitive FD)을 만족하지 않는 상태 

 

• 이행적 함수 종속

이행적 함수 종속은 A -> B, B -> C이면 A -> C가 성립한다. 이 경우 C가 A에 이행적으로 함수 종속이 되었다고 한다.

 

예시

쇼핑몰에 ID, 등급, 활인율이 있으면 다음 처럼 분리해야 한다.

 

-보이스/코드 정규형(BCNF)

보이스/코드 정규형은 제3정규형이고 결정자가 후보키가 아닌 함수 종속 관계를 제거하여 릴레이션의 함수 종속 관계에서 모든 결정자가 후보키인 상태이다.

• 결정자: X -> Y이면 X는 결정자, Y는 종속자

예시

여기서 후보키는 {학번, 수강명} 혹은 {학번, 강사}가 후보키이다. 범석이는 학번이 NULL이라 문제가 된다.

 

사진을 보면 강사 속성이 결정자이지만 후보키가 아니라서 강사 속성을 분리해야 한다.

 

이렇게 잘 분리를 해야한다.

 

정규형 과정을 거쳐 테이블을 나눠도 성능이 100% 좋아지진 않는다. 나빠질 수도 있다. 테이블을 나누면 어떠한 쿼리는 조인을 해야해서 오히려 느려질 수도 있어 서비스에 따라 정규화 혹은 비정규화를 해야한다.