[DB04] ER model

* 10.24 업데이트

 

해당 게시물은 한양대학교 컴퓨터소프트웨어학부 김상욱 교수님 데이터베이스시스템 온라인 강의를 듣고 정리한 자료입니다.

오류가 있다면 언제든 알려주세요!

● 해당 강의의 학습 목표

1. Entity-Relationship (ER) model을 통해서 conceptual modeling을 어떻게 하는지 배운다.

· Concepts of the entity-relationship model

· Entity-relationship diagram

· Conceptual data modeling

 

◆ Constraints on Relationship Types (Binary Relationship Type)

Relationship: Entity와 Entity간의 연관관계

Relationship instance: 하나의 entity instance와 다른 entity instance와의 관계

Relationship type: 그러한 relationship instance들이 모여있을 때 같은 형식의 relationship instance들을 abstract하게 표현한 것

 

1. Cardinality ratio constraint

 

· 하나의 entity가 가질 수 있는 relationship instance들의 최대 개수가 존재한다.

· Binary relationship에 대해 총 세 가지 종류가 있다.

 - 1:1 (최대 하나)  ex. 결혼

 - 1:N (최대 N개와 연관을 맺을 수 있다.)  ex. 지도 교수 관계 (N:1도 있으나 역할 뒤집은거랑 똑같다.)

 - M:N (양쪽 서로 여러개와 관계를 맺을 수 있다.)  ex. 수강하는 관계 (한 명의 교수도 여러 학생을 가르치고, 한 명의 학생도 여러 교수의 수업을 듣는다.)

 

최대 몇 개까지 가능하냐의 문제이지 아무 관계를 맺지 않아도 상관없다. 모두 관계를 맺지 않아도 된다.

 

아무도 2개 이상 관계를 맺지 않았네 -> 1:1이구나! 로 결정되는 것이 아니라

그 어플리케이션의 특징, 요구사항이다. 즉, System analyst가 사용자를 대상으로 인터뷰를 했을 때 '아, 이 조직에서는 한 사람이 두 개 이상의 department를 관리하지 못하도록 하는구나. 하나의 department는 두 명 이상의 employee한테 관리받지 않는구나' 라는 것을 알고 1:1로 정하는 것이다.

 

1:1 Cardinality ratio

하나의 employee는 단 하나의 department만 manage할 수 있다.

하나의 department는 단 하나의 employee에게만 manage 받을 수 있다.

따라서 1:1 관계이다.

단, 관계를 맺지 않는 employee entity도 있다. 신입사원이 관리자가 될 수 없기 때문이다.

1:N Cardinality Ratio

하나의 department는 여러 employee가 일할 수 있다.

하나의 employee는 단 한 개의 department에서만 일할 수 있다.

따라서 1:N 관계이다. 

M:N Cardinality Ratio

하나의 employee가 여러 projecet에서 일할 수 있다.

하나의 project는 여러 명의 employee가 일할 수 있다.

하나의 employee가 project를 하나도 하지 않아도 된다. 

 

2. Participation constraint

 

· 어떤 엔티티의 존재가 바로 다른 엔티티와의 연관됨에 종속된다. 즉, 엔티티가 존재하면 다른 쪽 엔티티와 관련이 있어야 되는지 아닌지 나타내는 constraint이다.

· 두 가지 종류로 나뉜다.

 1) total participation: 모든 엔티티가 다른 쪽 엔티티와 반드시 관련이 있어야한다. 모든 엔티티가 관계에 참여해야한다.

     ex) 학생과 학과 

 2) partial participation: 모든 엔티티가 참여하지 않아도 가능하다.

 

모든 employee가 department를 manage할 수 없으므로 parital participation이다.

모든 department는 employee에 의해 관리되어야하므로 total participation이다.

이 또한 해당되는 어플리케이션의 특성, 요구사항에 의해 결정되는 것이다.

 

◆ Attributes of Relationship Types

 

· relationship types 또한 attributes(relationship types를 describe하는 속성)를 갖는다.

 - relationship에 참여하는 엔티티의 조합에 어떤 특성이 부여될 때 그때 attribute가 결정된다.

 - 각각의 relationship instance의 특징으로 표현한다. 주어지지 않는 경우도 있다.

 - 두 entity간의 관계에 의해 생긴 attribute이 entitiy type의 attribute으로 적합하지 않을 때 사용된다.

 

· M:N relationship type에서 적합하다.

 - 1:1 이나 1:N relationship type에서는 하나의 entity type의 attribute로 밀어 넣을 수 있다.  

 

1) 1:N cardinality ratio일 때 relationship type의 attribute

1:N Cardinality Ratio's attribute

employee가 본인의 department에서 언제부터 일했는가에 대한 attribute를 주려고 한다. 

이는 entity하나가 다른 entity가 관계를 맺음으로써 나타난 attribute이다. 따라서 works_for의 attribute에 해당된다.

다만, 이 관계가 1:N이기 때문에 N side entity의 attribute로 넣어주어도 된다. 

ex) 1 side인 department에 해당 attribtue를 넣으면 한 누가 언제부터 일한지 표현할 수가 없다. 여러 명이 해당 department에서 일하고 있기 때문이다. 따라서 N side에 attribute를 넣어줘야한다.

 

 

2) 1:1 cardinality ratio일 때 relationship type의 attribute

1:1 Cardinality Ratio's attribute

empolyee가 department를 언제부터 manage했는지 나타내는 특성을 MgrStartDate라 하자.

employee와 department가 만났을 때의 특징이라서 relationship type attribute이다.

1:1 관계이기 때문에 둘다 1 side라 department의 attribute 혹은 employee의 attribute으로 넣을 수 있다.

하지만 employee는 parital participation이기 때문에 manage하고 있는 department 자체가 없을 수 있어 MgrStartDate는 NULL값이 많을 것이다. 이는 바람직하지 않고 total participation에 넣는 것을 지향한다.

 

 

3) N:M cardinality ratio일 때 relationship type의 attribute

M:N

works_on은 두 개가 만났을 때 생겼고 hours도 생겼다. 양쪽의 entity가 N:M 관계이기 때문에 hours는 어느 한 쪽의 entity의 속성이 될 수 없다. employee의 attribute로 들어가려고 하면 한 employee가 어떤 project를 몇시간 일했는지 알 수 없고, project의 attribute로 들어가려고 하면 여러 employee 중 누가 해당 시간만큼 일했는지 알 수 없기 때문이다. 

따라서 relationship type에 해당되는 attribute는 entity attribute이 될 수 없다. 

 

◆  Weak Entity Types

· entity type 내부에 key attribute이 없는 경우

  내부에 있는 attribute만으로는 key가 형성될 수 없는 entity type이다.

 

· ex) DEPENDENT entity type

 - (DependentName, BirthDate, Sex, Relationship)

 - A's son (Gildong, 1/1/14, M, son)

 - B's son (Gildong, 1/1/14, M, son)

 

자신의 attribute만으로 key를 형성할 수 없다. 모두 같기 때문에! 따라서 dependent는 weak entity type이다.

이를 식별하려면 다른 entity와 엮여있다는 것을 추가적으로 사용해야된다.

이를 Identifying owner라고 한다.

 

· Identifying owner

 - weak entity type을 식별하기 위해서 사용하는 entity type이다.

 - 위의 예시에서는 Employee entity type이 identifying owner이다.

 

· Identifying relationship type

 - weak entity type과 idenfiying owner를 엮어주는 데 필요한 relationship type (dependent와 employee 사이의 관계)

 - 항상 total participation constraint를 가진다. weak entity type은 반드시 idenfiying owner와 엮여서 식별이 되기 때문에 이 둘이 관계를 맺지 않으면서 존재할 수는 없다.

 

· ex) DEPENDENTS_OF

 - A's son (Gildong, 1/1/14, M, son): linked to A

 - B's son (Gildong, 1/1/14, M, son): linked to B

 

· Partial key(부분 키)

 - 같은 identifying owner와 관련된 weak entity들을 구분한다. 

identifying owner에 해당되는 한 entity와 그 밑의 weak entity에 속하는 여러 entity가 다 관계를 맺을 수 있다. 

identifying owner인 employee의 부양가족이 여러 존재할 수 있다. 이 부양가족들을 식별할 수 있는 attribute가 partial key이다.

 

· ex) dependentName attribute of DEPENDENT entity type

 

◆  Refining the Conceptual Design for a COMPANY Database

파란색들은 모두 attribute이 아니라 relationship type이다. 

ex) Manager의 정보는 employee에 있다. 이는 attribute처럼 되어있지만 relationship type이다. 

 

entity type의 이름은 명사, relationship type의 이름은 동사!

 

◆ Add Relationship Types(Binary relationship type)

1. MANAGES:

 - 1:1 relationship type between EMPLOYEE and DEPARTMENT

 - EMPLOYEE participation is partial

 - DEPARTMENT participation is total (모든 department는 관리 받아야함)

 - Has MgrStartDate attribute (entity type의 attribute는 아니나 1:1이니까 한 쪽에 밀어넣을 수 있다. 보통은 total 쪽에 넣는다.)

 

2. WORKS_FOR:

 - 1:N relationship type between EMPLOYEE and DEPARTMENT

 - Both participations are total

 

3. CONTROLS:

 - 1:N relationship type between DEPARTMENT and PROJECT

 - PROJECT participication is total

 - DEPARTMENT participication is partial (어떤 department가 project를 안하면 control이 없는 경우도 있다.)

 

4. SUPERVISON(supervises):
 - 1:N relationship type between EMPLOYEE(supervisor) and EMPLOYEE (supervisee) (recursive relationship type -> 하나의 entity type이 관계에 다른 역할로 두 번 참여하는 것)

 - Both participations are partial (supervisor: 신입사원은 못됨. supervisee: 회장님은 감독받지 않음.)

 

5. WORKS_ON:

 - M:N relationship type between EMPLOYEE and PROJECT

 - Both participations are total (project하지 않는 employee 없고, 모든 project는 employee 한 명 이상에 의해 수행되어야한다.)

 - Has Hours attribute (attribute of relationship type)

 

6. DEPENDENTS_OF(identifying relationship):

 - 1:N relationship type between EMPLOYEE(identifying owner) and DEPENDENT(weak entity type) 

 - Identifying relationship for DEPENDENT

 - EMPLOYEE participation is partial (어떤 employee는 부양가족이 없다)

 - DEPENDENT participation is total 

 

◆  Entity-Relationship Diagram

- entity-relationship model을 통한 conceptual design의 결과인 conceptual schema를 그림으로 표현한 것 (ER diagram)

 

 

한 줄은 partial participation 두 줄은 total participation이다.

ER schema를 그림으로 표현한 것.

요구사항을 보고 ER Diagram을 그릴 수 있어야하고 반대로 ER Diagram을 보고 요구사항을 말할 수 있어야한다.

 

 

Summary

- Basic ER model concepts of entities and their attributes

   Structural constraints on relationships

   Attributes on relationships

- ER diagrams represent E-R schemas in a simple diagram