1. ERD란?

ERD(Entity Relationship Diagram)는 데이터베이스의 구조를 시각적으로 표현하는 다이어그램입니다.

데이터베이스를 구축할 때 가장 기초적인 뼈대 역할을 하며, Relation 간의 관계들을 정의한 것입니다.

 

ERD는 시스템 요구 상황을 기반으로 작성되며 이 ERD를 기반으로 데이터베이스를 구축합니다.

 

https://velog.io/@kjhxxxx/DataBase-ERD%EB%9E%80

ERD는 Entity, Attribute, Relationship으로 이루어져 있습니다.

ERD를 작성할 때, 요구 사항을 분석하고 entity와 attribute를 정의하고 각 entity 간의 관계를 정의해야 합니다. 또한, 데이터 중복을 최소화하기 위해 정규화를 고려해야 합니다.

2. 정규화

정규화는 데이터 중복을 최소화하고 데이터의 일관성을 유지하기 위한 거치는 과정입니다. 릴레이션 간의 잘못된 종속 관계로 발생되는 문제를 해결하고, 저장 공간을 효율적으로 사용하기 위해 릴레이션을 여러 개로 분리하는 과정입니다.

정규화는 여러 단계로 구성되며, 각 단계는 특정 규칙을 만족해야 합니다.

정규화된 정도에 따라 제1 정규형(NF, Normal Form), 제2 정규형, 제3 정규형, 보이스/코드 정규형, 제4 정규형, 제5 정규형이 있습니다.

2-1. 제1 정규형(1NF)

테이블의 모든 속성은 원자값(더 이상 분해할 수 없는 값)을 가져야 합니다.

StudentID Name Course
1 홍길동 {물리, 화학}
2 이순신 {수학, 영어}

 

속성 값 중에서 한 개의 기본키에 대해 두 개 이상의 값을 가지는 반복 집합이 있습니다. 홍길동의 Course가 {물리, 화학}인데 이것을 제1 정규형에 따르면 이것을 나눠야 합니다.

StudentID Name Course
1 홍길동 물리
1 홍길동 화학
2 이순신 수학
2 이순신 영어

 

2-2. 제2 정규형(2NF)

제1 정규형을 만족하면서 기본 키가 아닌 속성은 기본 키에 종속되어야 합니다.(부분 종속성 제거) 쉽게 말해, 현재 테이블의 주제와 관련없는 속성을 다른 테이블로 빼는 작업입니다.

OrderID(주문번호) CustomerID(고객ID) Product(상품명) Category(카테고리) Price(가격)
1 A 도서 15,000원
2 A 티셔츠 의류 25,000원
3 B 컴퓨터 마우스 전자제품 10,000원

 

이 테이블의 기본 키는 주문번호 및 고객ID입니다.

제 2정규형을 적용하기 위해선 기본 키에 완전히 종속되지 않은 속성을 찾아야 합니다. 기본 키가 아닌 키에 종속이 되는 키를 찾는다는 의미와 같습니다. Product, Category, Price는 기본 키인 {OrderID, CustomerID}에 완전히 종속되지 않습니다. 따라서 테이블을 아래와 같이 분리합니다.

 

<주문 테이블>

OrderID CustomerID Product
1 A
2 A 티셔츠
3 B 컴퓨터 마우스

 

<상품 테이블>

Product Category Price
도서 15,000원
티셔츠 의류 25,000원
컴퓨터 마우스 전자제품 10,000원

 

2-3. 제3 정규형(3NF)

제2 정규형을 만족하면서 이행적 함수 종속성(transitive FD)이 없어야 합니다.

이행적 함수 종속이란 A->B, B->C 관계에서 A->C 관계가 성립하는데 이 때, C가 집합 A에 이행적으로 함수 종속이 되었다고 합니다.

다시 말해, 기본 키가 아닌 속성이 다른 키(기본키 제외)에 종속되면 안됩니다.

위 예시에서 이행적 종속 관계를 확인해봅시다.

카테고리 내 상품들은 가격이 같다고 가정하면 상품 테이블에서 Product -> Category, Category -> Price 관계가 있으므로 이행적 종속인 Product -> Price 관계가 성립합니다. 따라서 상품 테이블을 아래와 같이 분리할 수 있습니다.

 

<상품 테이블>

Product Category
도서
티셔츠 의류
컴퓨터 마우스 전자제품

 

<카테고리 테이블>

Category Price
도서 15,000원
의류 25,000원
전자제품 10,000원

 

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

보이스/코드 정규형은 제 3정규형을 만족하면서 모든 결정자가 후보키여야 합니다.

 

결정자란 다른 속성의 값을 고유하게 결정하는 속성(또는 속성들의 집합)입니다.
간단히 말해, 결정자는 다른 속성에 대한 정보를 제공합니다.
학번(StudentID) 이름(Name) 전공(Major)
1 홍길동 경영학
2 이순신 컴퓨터공학
3 김유신 기계공학

이 테이블에서 학번 이름 전공을 결정합니다. 다시 말해, 학번을 알고 있다면 해당 학생 이름과 전공을 알 수 있습니다. 따라서 이 테이블의 결정자는 학번입니다. 함수 종속성으로 표현하면 학번 -> 이름, 학번 -> 전공 관계가 성립합니다.

 

<프로젝트 할당 테이블>

직원ID 프로젝트ID 역할 프로젝트매니저
1 100 개발자 김매니저
2 101 디자이너 박매니저
3 100 테스트 김매니저
4 102 개발자 이매니저

여기서 기본 키는 (직원ID, 프로젝트ID)입니다. 이 테이블은 제 3정규형을 만족합니다. 모든 비기본 키 속성(역할, 프로젝트매니저)이 기본 키 전체에 종속되기 때문입니다.

이 테이블을 보면 다음과 같은 함수 종속성이 있습니다.

1. (직원ID, 프로젝트ID) -> 역할, 프로젝트매니저

2. 프로젝트ID -> 프로젝트매니저

위의 두 번째 종속성을 보면 프로젝트ID 프로젝트매니저를 결정하고 있습니다. 하지만 프로젝트ID는 후보 키가 아닙니다.(기본 키 조합에 포함되어 있는 것이지 그 자체로 후보 키가 아님)

BCNF를 만족시키기 위해 테이블을 분리합니다.

 

<프로젝트 할당 테이블>

직원ID 프로젝트ID 역할
1 100 개발자
2 101 디자이너
3 100 테스트
4 102 개발자

 

<프로젝트 테이블>

프로젝트ID 프로젝트매니저
100 김매니저
101 박매니저
102 이매니저

 

이렇게 분리하면 모든 결정자(프로젝트 할당 테이블 - (직원ID, 프로젝트ID) / 프로젝트 테이블 - 프로젝트ID)가 후보 키가 되어 BCNF를 만족하게 됩니다.

 

정규형 과정을 거친다고 해도 성능이 무조건 좋아지는 것은 아닙니다. 경우에 따라 정규화 또는 비정규화 과정을 진행해야 합니다.

728x90

'DB' 카테고리의 다른 글

[데이터베이스] 조인의 원리  (0) 2024.05.29
[데이터베이스] 조인 JOIN  (0) 2024.05.28
[데이터베이스] 종류  (0) 2024.05.21
[데이터베이스] 트랜잭션 Transaction  (0) 2024.05.21
[데이터베이스] 데이터베이스 개념  (0) 2024.05.15

+ Recent posts