[Database] E-R 개념적 데이터 모델링

DB 설계 단계는 다음과 같습니다.

1. 요구사항 수집
2. 개념적 DB 설계 (entity)
3. 논리적 DB 설계 (tuple)
4. 물리적 DB 설계 (record)

논리적 DB 설계 단계부터는 DBMS에 의존적이지만, 개념적 DB 설계는 독립적으로 이루어집니다.

---

다음과 같은 요구사항이 수집되었다고 가정해 봅니다.

1. 회사는 여러 부서들로 구성된다. 각 부서마다 고유한 이름, 고유한 번호, 부서를 관리하는 특정 사원이 있다. 사원이 부서를 관리하기 시작한 날짜도 유지한다. 한 부서는 여러 위치에 있을 수 있다.
2. 한 부서는 여러 프로젝트들을 관리한다. 각 프로젝트는 고유한 이름, 고유한 번호,  한 개의 위치를 가진다.
3. 각 사원에 대해서 이름, 주민등록번호, 주소, 급여, 성별, 생년월일을 저장한다. 한 사원은 한 부서에 속하지만, 여러 프로젝트들에 관여할  수 있다. 한 사원이 관여하는 프로젝트들은 그 사원이 소속된 부서가 관리하는 프로젝트가 아니어도 무방하다. 반드시 한 부서의 각 사원이 각 프로젝트를 위해 일하는 주당 근무 시간을 기록한다. 또한 각 사원의 직속 상사도 유지한다.
4. 보험 목적을 위해서 각 사원의 부양 가족들을 기록한다. 각 부양 가족에 대해서 이름, 성별, 생년월일, 사원과의 관계를 기록한다.

---

해당 모델을 설계하기 전에, E-R 모델의 구성요소를 보아야 합니다.

ER 모델은 데이터를 entity(개체), relation(관계), attribute(속성)으로 모델링합니다.

ER 모델에서의 데이터를 entity라고 하며, entity와 attribute의 각 정의는 다음과 같습니다.

• Entity : 실세계에서 독립적으로 존재하는 실체
• Attribute : Entity를 기술하는 속성

[그림 1] Entity 예시

e1과 c1이라는 entity가 존재할 때, entity 안에는 여러 attribute와 attribute에 대응되는 값을 가지고 있습니다.

Attribute 유형에는 여러 형태가 존재합니다.

• 복합 Attribute
• 단순 Attribute
• 단일 값 Attribute
• 다치 Attribute
• 저장된 Attribute
• 유도된 Attribute

Attribute에 들어가는 값은 NULL을 가질 수도 있는데, 이것은 ‘적용할 수 없음’ 이거나 ‘알려지지 않음’ 두 가지 의미를 가집니다.

같은 attribute를 가진 entity(동일한 entity)를 모아 분류해 놓은 것을 entity type이라고 합니다.

예시로, [그림 1]에서 e1은 사원 entity 타입이며, c1은 회사 entity 타입입니다.

특정 Attribute가 서로 다른 값을 가짐으로써 해당 값으로 entity를 구분할 수 있는데, 이를 key attribute라고 합니다.

Attribute가 가질 수 있는 값의 범위를 domain이라고 합니다.

---

이제 위의 요구사항으로 entity를 설계합니다.

1. 엔티티 타입 DEPARTMENT는 Name, Number, Location, Manager, ManagerStartDate 애트리뷰트를 가진다. Locations은 유일한 다치 애트리뷰트이다. Name과 Number는 각 부서마다 고유하기 때문에 각각 키 애트리뷰트로 지정할 수 있다.
2. 엔티티 타입 PROJECT는 Name, Number, Location, ControllingDepartment 애트리뷰트들을 가진다. Name과 Number가 각각 키 애트리뷰트이다.
3. 엔티티 타입 EMPLOYEE는 Name, SSN, Sex, Address, Salary, BirthDate, Department, Supervisor 애트리뷰트들을 가진다. 사용자가 사원 Name의 각 구성요소(FirstName, MiddleInitial, LastName)와 Address의 각 구성요소를 참조할 것인지의 여부를 알기 위해서 사용자와 다시 협의해야 한다.
4. 엔티티 타입 DEPENDENTS는 Employee, DependentName, Sex, BirthDate, Relationship(사원과의 관계) 애트리뷰트들을 가진다.

다음 사항을 정리하면 아래와 같습니다.

[그림 2] 엔티티 설계

---

엔티티를 설계했으면 이제 관계를 지정해야 합니다.

관계 타입은 엔티티 간의 연관되는 것들을 연결하면 됩니다.

예를 들어, 직원은 어느 특성 부서에 속하게 됩니다.

이것을 관계로 나타내면, EMPLOYEE 엔티티는 DEPARTMENT 엔티티에 대해 “소속된다”는 관계를 가지고 있습니다.

[그림 3] EMPLOYEE와 DEPARTMENT의 관계

[그림 3]은 관계에 대해 2개의 엔티티가 참여하고 있기 때문에 이진 차수입니다.

3개가 참여하게 된다면 3진 차수가 됩니다.

프로그래밍 언어의 재귀함수처럼, 순환적 구조를 가진 관계를 설계할 수 있습니다.

상사 – 부하 관의 관계를 설정할 때 순환적 구조를 이용합니다.

관계 인스턴스에 참여하는 엔티티의 개수의 비율을 카디날리티 비율이라고 합니다.

[그림 3]에서는 EMPLOYEE는 엔티티가 각각 참여하고, DEPARTMENT는 여러 직원들을 받을 수 있으니 1:N 비율이 됩니다.

EMPLOYEE의 경우 부서에 소속되지 않는 경우도 있을 수 있기 때문에 부분 참여 제약조건을 가지며,

DEPARTMENT의 경우 부서에 사람이 없으면 돌아가지 않기 때문에 전부 참여 제약조건을 가집니다.

---

약한 엔티티 타입은 자신의 키 애트리뷰트가 없는 엔티티를 말합니다.

부양가족의 경우가 그렇습니다. DEPENDENT는 EMPLOYEE 엔티티로부터 식별되는 식별 엔티티 타입입니다.

즉, EMPLOYEE와의 관계를 끊어버리면 엔티티를 구분할 수가 없습니다.

---

관계를 나타내는 애트리뷰트를 관계 타입으로 변환해 보겠습니다.

1. MANAGES : EMPLOYEE와 DEPARTMENT 사이의 1:1 관계 타입
2. WORKS_FOR : DEPARTMENT와 EMPLOYEE 사이의 1:N 관계 타입
3. CONTROLS : DEPARTMENT와 PROJECT 사이의 1:N 관계 타입
4. SUPERVISION : EMPLOYEE(상사역할)와 EMPLOYEE(사원역할) 사이의 1:N 관계 타입
5. WORKS_ON : EMPLOYEE와 PROJECT 사이의 M:N 관계 타입
6. DEPENDENTS_OF :EMPLOYEE와 DEPENDENT 사이의 1:N 관계 타입

이를 이용해 다음과 같은 ER 모델링을 작성할 수 있습니다.

[그림 4] ER 모델링이 완성된 모습