[Lecture 04] ER model, ER diagram

Objectives

• Relationship Types에 대한 전반적인 개념
• Weak entity type과 Identifying relationship type
• Entity-Relationship diagram

---

Constraints on Relationship Types

Cardinality ratio constraint

cardinality ratio란?

하나의 entity가 relationship instance에 참여할 수 있는 최대 개수

 

Three types of cardinality ratios for a binary relationship

• 1:1
  • 최대 1개의 relationship  
  • ex) 결혼
• 1:N
  • 한 entity가 여러 entity와 relationship
  • ex) 한 명의 지도교수와 여러 명의 학생. 학생 입장에서는 지도교수를 1명만 가지고, 지도교수 입장에서는 여러명의 학생을 가질 수 있음.
• M:N 
  • 양쪽 entity에서 모두 여러 entity와 relationship
  • ex) 강의를 수강하는 상황. 교수도 여러 명의 학생을 가르칠 수 있고, 학생도 여러 명의 교수의 강의를 들을 수 있음.

1:1 Cardinality Ratio

하나의 employee는 최대 1개의 department를 관리할 수 있다.

하나의 department가 하나의 employee로부터 관리를 받는다.

Cardinality Ratio역시 요구사항에서부터 정해지는 부분이다. application의 특징으로부터 정해진다.

 

1:N Cardinality Ratio

한 employee가 하나의 department에 소속된다.

department하나에는 여러 사람이 일할 수 있다.

 

M:N Cardinality Ratio

한 employee가 여러 개의 project에서 일할 수 있다.

한 project는 여러 명의 employee에 의해 수행될 수 있다.

 

Pariticipation constraint

Types: total, partial

employee는 department를 관리할 수도 있고, 아닐 수도 있다. -> partial participation

department는 반드시 누군가에 의해 관리 받아야한다. -> total participation

---

Attributes of Relationship Types

relationship type역시 attribute를 가질 수 있다.

relationship type의 attribute란 entity간의 어떤 relationship이 맺어질 때 생기는 attribute을 의미한다.

이 예시에서 employee와 department가 works_for 라는 relationship type으로 맺어질 때, employee가 해당 department에서 언제부터 일했는지를 나타내는 StartDate이라는 속성이 생기게 된다.

이 경우에는 cardinality ratio가 1:N이라서 employee entity의 attribute으로 넣어도 크게 문제가 되지는 않는다.

이 예시에서는 employee와 department가 manages라는 relationship type으로 맺어질 때, employee가 해당 department를 언제부터 manage 했는지를 나타내는 MgrStartDate라는 속성이 생기게 된다.

이 경우는 cardinality ratio가 1:1이라서 어느쪽의 attribute에 넣어도 문제가 되지 않는다.

이 예시는 employee와 project가 works_on이라는 relationship type으로 맺어질 때, 그 프로젝트에서 몇 시간 일했는지를 나타내는 Hours라는 속성이 생긴다.

이 경우는 cardinality ratio가 M:N이라서 어느 한 쪽의 속성으로 집어 넣을 수가 없다. 만약 employee에 넣게되면, 그 사람이 어느 프로젝트에서 일한 시간인지 알 수가 없고, project에 넣게되면, 그 프로젝트에 일한 사람 중 누가 일한 시간인지 알 수가 없게 된다.

---

Weak Entity Types

entity type내부에 key attribute가 없는 entity type을 뜻한다.

ex) DEPENDENT entity type

• (Dependent's Name,BirthDate, Sex, Relationship)
• A's son(Gildong, 01/01/2014, M, son)
• B's son(Gildong, 01/01/2014, M, son)

이렇게 누구의 dependent인지 명시를 하지 않으면 알 수가 없다.

이럴 때, Dependent entity type을 weak entity type이라고 한다.

 

Identifying owner

누구의 dependent인지 명시할 때, '누구의'에 해당하는 부분을 identifying owner라고 한다.

ex) EMPLOYEE entity type

• A's son(Gildong, 01/01/2014, M, son) -> linked to A
• B's son(Gildong, 01/01/2014, M, son) -> linked to B

Identifying relationship type

weak entity type과 그것의 identifying owner를 이어주는 relationship type이다.

항상 total participation constraint를 가진다.

ex) DEPENDENTS_OF

 

Partial Key

같은 owner entity를 가질 때, 유일하게 식별할 수 있는 weak entity type내의 attribute를 의미한다.

ex) DependentName attribute of DEPENDENT entity type

예를 들어, 홍길동의 dependent들 중에서는 이름이 겹치지 않는다고 할 때, 그 이름이 key attribute가 될 수 있다.

다만, 이름이 겹치지 않는다 등의 조건은 특정 시점의 DB 상태를 보고 판단하는 게 아니라, 이미 요구사항 단계에서 정해져야 하는 것이다.

---

Refining Conceptual Design for the COMPANY Database

이 사진은 [Lecture03]에서 intial conceptual design 했던 것에서 일부 attribute를 파란색으로 칠한 모습이다. 파란색으로 칠한 attribute은 relationship을 적용할 수 있는 여지가 있는 것을 의미한다. 이제부터 하나씩 relationship type으로 추가하는 과정을 살펴보자.

 

Manager -> MANAGES:

EMPLOYEE와 DEPARTMENT는  1:1 의 관계이다. 

EMPLOYEE participation은 partial, DEPARTMENT participation은 total.

MgrStartDate attribute를 갖는다.

 

Department -> WORKS_FOR:

EMPLOYEE 와 DEPARTMENT는 1:N의 관계이다.

둘 다 participation이 total 이다.

employee는 무조건 department에 소속되어야 하고, department는 employee가 없이 존재할 수 없다.

 

ControllingDepartment -> CONTROLS:

DEPARTMENT와 PROJECT가 1:N의 관계이다.

PROJECT participation은 total, DEPARTMENT participation은 partial이다.

모든 프로젝트는 무조건 departement에 소속되어야 하고, 하나의 department에서 control하고 있는 project이 없을 수 있다.

요구사항이 모호한 부분은 클라이언트와의 interview를 통해 확실히해야 한다.

 

Supervisor -> SUPERVISON(or SUPERVISES):

EMPLOYEE(supervisor)와 EMPLOYEE(supervisee)는 1:N의 관계이다.

둘 다 participation이 partial이다.

신입사원은 supervisor가 될 수 없고, 회사 대표는 supervisee가 필요 없다.

 

WorksOn(Project, Hours) -> WORKS_ON:

EMPLOYEE와 PROJECT는 M:N의 관계이다.

둘 다 participation은 total이다. 

Hours attribute를 갖는다.

 

EMPLOYEE -> DEPENDENTS_OF:

EMPLOYEE와 DEPENDENT는 1:N의 관계이다.

EMPLOYEE가 DEPENDENT를 identify한다.

EMPLOYEE participation은 partial이고, DEPENDENT participation은 total이다. (weak entity type)

---

Entity-Relationship Diagram

ER model을 통해서 conceptual design한 결과를 그림으로 나타낸 것이다. 

최종 결과는 다음 사진과 같다.