ERD와 정규화

ERD는 데이터베이스를 구축할 때 사용되는 도구로, 엔티티와 그들 간의 관계를 시각적으로 표현한다. 서비스를 구축할 때 가장 먼저 ERD를 작성하는 것이 좋으며, 이는 데이터베이스 설계의 기초가 된다.

ERD

ERD(Entity-Relationship Diagram)는 시스템의 요구 사항을 기반으로 작성되며 작성된 ERD는 데이터베이스 설계의 기초가 된다. 데이터베이스를 구축한 이후에도 재설계, 디버깅 등 여러 상황에서 ERD를 참고할 수 있다. ERD는 관계형 구조로 표현할 수 있는 데이터를 구성하는 데 유용하게 사용된다는 장점이 있지만, 비정형 데이터나 복잡한 관계를 표현하기에는 한계가 있다는 단점이 있다.

ERD 설계 예제

승원 영업 부서

요구 사항

영업 사원은 0 ~ N명의 고객을 관리할 수 있다.
각 고객은 0 ~ N개의 주문을 가질 수 있다.
각 주문은 1 ~ N개의 상품을 포함할 수 있다.

ERD 설계

plaintext

erDiagram
	direction LR
	영업사원 ||--o{ 고객 : ""
	고객 ||--o{ 주문 : ""
	주문 ||--|{ 상품 : ""

리그오브레전드

요구 사항

소환사는 1명의 챔피언을 선택한다.
챔피언은 1개 이상의 스킬을 가진다.
스킬은 1개 이상의 특성을 갖는다.

ERD 설계

plaintext

erDiagram
	direction LR
	소환사 ||--|| 챔피언 : ""
	챔피언 ||--|{ 스킬 : ""
	스킬 ||--|{ 특성 : ""

정규화

정규화(Normalization)는 데이터베이스 설계에서 중복을 최소화하고 데이터 무결성을 유지하기 위해 데이터를 구조화하는 과정이다. 정규화는 여러 단계로 나뉘며, 각 단계는 데이터베이스의 구조를 점진적으로 개선한다. 정규화는 다음과 같은 단계로 진행된다.

제 1 정규형(1NF, First Normal Form)

제 1 정규형은 릴레이션의 모든 속성이 원자값(Atomic Value)을 가져야 한다는 규칙이다. 즉, 각 속성은 더 이상 분해할 수 없는 단일 값을 가져야 한다. 예를 들어, 학생 엔티티의 수강 과목 속성이 "C++, Java, Python"과 같이 여러 값을 가질 수 없다. 대신, 각 과목은 별도의 레코드로 표현되어야 한다.

ID	이름	수강 과목	성취도
1	홍길동	{ C++, Java, Python }	{ A, B, C }
2	김철수	{ Java, Python }	{ B, C }

↓

ID	이름	수강 과목	성취도
1	홍길동	C++	A
1	홍길동	Java	B
1	홍길동	Python	C
2	김철수	Java	B
2	김철수	Python	C

제 2 정규형(2NF, Second Normal Form)

제 2 정규형은 제 1 정규형을 만족하면서, 기본 키가 아닌 속성이 기본 키에 완전 함수 종속(Full Functional Dependency)을 가져야 한다는 규칙이다.

ID	이름	수강 과목	성취도
1	홍길동	C++	A
1	홍길동	Java	B
1	홍길동	Python	C
2	김철수	Java	B
2	김철수	Python	C

↓

ID	이름
1	홍길동
2	김철수

ID	수강 과목	성취도
1	C++	A
1	Java	B
1	Python	C
2	Java	B
2	Python	C

제 3 정규형(3NF, Third Normal Form)

제 3 정규형은 제 2 정규형을 만족하면서, 기본 키가 아닌 속성이 기본 키에 이행 함수 종속을 가지지 않아야 한다는 규칙이다.

이행 함수 종속(Transitive Functional Dependency) 이행 함수 종속은 A → B, B → C가 있을 때, A → C가 성립하는 경우를 의미한다.

예를 들어, 학생 엔티티에서 학생의 학과와 학과의 학과장 정보를 저장한다고 가정해보자.

ID	이름	학과	학과장
1	홍길동	컴퓨터공학	김교수
2	김철수	컴퓨터공학	김교수
3	이영희	전자공학	박교수

↓

ID	이름	학과
1	홍길동	컴퓨터공학
2	김철수	컴퓨터공학
3	이영희	전자공학

학과	학과장
컴퓨터공학	김교수
전자공학	박교수

보이스-코드 정규형(BCNF, Boyce-Codd Normal Form)

보이스-코드 정규형은 제 3 정규형을 만족하면서, 모든 결정자가 후보 키가 되어야 한다는 규칙이다. 즉, 비트 결정자(Non-trivial Functional Dependency)가 있을 때, 그 결정자는 반드시 슈퍼키(Super Key)여야 한다. 예를 들어, 아래와 같이 학생이 없이 학과와 학과장만 있는 경우를 생각해보자.

ID	이름	학과	학과장
1	홍길동	컴퓨터공학	김교수
2	김철수	컴퓨터공학	김교수
3	이영희	전자공학	박교수
		자동차공학	이교수

↓

ID	이름	학과
1	홍길동	컴퓨터공학
2	김철수	컴퓨터공학
3	이영희	전자공학

학과	학과장
컴퓨터공학	김교수
전자공학	박교수
자동차공학	이교수

이렇게 정규화된 데이터베이스는 중복을 최소화하고 데이터 무결성을 유지할 수 있다. 하지만, 정규화는 데이터베이스의 성능을 좋게할 수 있지만, 반대로 성능을 저하시킬 수도 있다. 테이블을 과도하게 분할하면 조인 연산이 많아져 성능이 저하될 수 있기 때문이다. 따라서, 정규화는 데이터베이스의 성능과 무결성 사이의 균형을 고려하여 적절히 적용해야 한다. 일반적으로 제 3 정규형까지 적용하는 것이 좋으며, 보이스-코드 정규형까지 적용하는 것은 상황에 따라 결정하는 것이 좋다.

ERD & Normalization