[기초데이터베이스] 02. The Entity-Relationship Model

❖ Steps of ER Modeling
❖ Attribute
❖ Instance
❖ Key
❖ Integrity Constraints
❖ Participation Constraints
❖ Weak Entities
❖ Class Hierarchy
❖ Aggregation
❖ Diagrams (Class, Database, Component)
❖ N-Tuples

---

ER Model

개체-관계(Entity-Relationship:ER) 데이터 모델은 실세계 조직체에 관한 데이터를
객체들과 그들간의 관계에 의하여 묘사하는 것

개체 (Entity)

속성(attribute)의 집합

개체집합 (Entity Set) 

개체의 집합(동일한 속성을 가진 객체들의 실제 인스턴스의 모음).
각 애트리뷰트에 대해서, 가능한 값들의 도메인(domain)을 지정해야함.
각 개체집합에 대해서 키(key)를 선택함.

* 키 (key)
 : 한 개체를 유일하게 식별하는 값을 갖는 최소개의 속성(애트리뷰트)들로 이루어진 집합
   후보키(candidate key)는 하나보다 더 많을 수 있는데,
   그럴 경우에는 그 중 하나를 기본키(primary key)로 지정함.

Employees : 개체집합
ssn :속성, 기본키
name : 속성
lot : 속성

 

관계 (Relationship)

둘 이상의 개체들 사이의 관련성.

하나의 관계는 기술적인 애트리뷰트들을 참조하지 않고 참가하는 개체들에 대해서 유일하게 식별되어야 함.
(각 Works_In관계는 직원의 ssn과 부서의 did의 조합에 의하여 유일하게 식별됨)

관계집합 (Relationship Set) 

같은 종류의 관계들을 하나의 관계집합으로 모을 수 있음.
여러 관계집합이 동일한 개체집합을 포함할 수 있음.

Works_In : 관계집합

 

역할 지시자 (Role Indicator)

emp1과 emp2는 모두 Employees에 속한 개체들이지만 서로 다른 역할을 함.
emp1이 emp2에게 보고함.  역할지시자 supervisor와 subordinate로 반영함.

한 개체집합이 여러 역할을 수행한다면,
역할 지시자는 해당 개체집합의 애트리뷰트 이름과 함께 붙여져서
관계집합 내의 각 애트리뷰트에 유일한 이름을 부여함.

 

 

---

ER 모델의 특별 기능

 

키 제약조건 (Key Constraints)

한 직원은 여러 부서를 관리할 수 있지만
각 부서에는 많아야 한 명의 관리자만 있음.(키 제약조건)
즉, Department 개체는 많아야 하나의 Manages 관계에 나타남.

주어진 Department 개체에서 그것이 나타나는 Manages 관계를 유일하게 결정할 수 있다는 것을
D -> M 화살표로 명시함.

- 일-대-다 (one-to-many)
  : 위의 Manages같은 관계집합.
  한 직원이 관리자로서 여러 부서와 관련될 수 있는 반면
  각 부서는 그 부서의 관리자로서 많아야 한 명의 직원과 관련될 수 있음.

- 다-대-다 (many-to-many)
 : Works_In같은 관계집합.
 한 명의 직원이 여러 부서에 근무하는 것이 허용되고
 한 부서에서는 여러 직원들이 근무하는 것이 허용됨.

- 일-대-일 (one-to-one)
 : 한 직원이 많아야 하나의 부서만 관리할 수 있다는 제약을 Manages 관계집합에 추가한다면,
   위의 그림에서 E -> M 화살표도 추가됨.

 

 

참여 제약조건 (Participation Constraints)

각 부서는 모두 관리자가 있음.(참여 제약조건)
관계집합 Manages에 개체집합 Departments의 참여는 전체적임.(D => M)
(각 직원이 모두 하나의 부서를 관리하는 것은 아니므로
 개체집합 Employees의 참여는 부분적임)

각 직원은 적어도 한 부서에서 근무하고 각 부서에는 적어도 한 명의 직원이 근무중임.
즉, Works_In에 있는 Employees와 Department의 참여가 모두 전체적임.(E = W = D)

 

 

약개체 (Weak Entities)

직원들이 그들의 부양자들을 위해 보험증권 구매.
한 직원이 회사를 그만두면, 그 직원이 소유한 어떠한 증권도 종료되고 관련 정보 삭제 필요.
애트리뷰트 pname은 피부양자들을 유일하게 식별하지 않음.
(두 피부양자가 같은 pname 값을 가질 수 있음)

Dependents : 약개체집합(weak entity set)(굵은 선)
Policy : 식별 관계집합(굵은 선)

약개체는 그것의 애트리뷰트 일부와 식별 소유자(Employees)에 해당하는 개체의
기본키를 결합하여야만 유일하게 식별됨.
Dependents 개체는 소유하는 Employees 개체의 키와 Dependents 개체의 pname(부분키)을
취하는 경우에만 유일하게 식별될 수 있음.

주어진 소유자 개체에 대하여 하나의 약개체를 유일하게 식별하는
약개체집합의 애트리뷰트들의 부분집합은 그 약개체집합의 부분키(partial key)(점선 밑줄)라고 함.

소유자 개체집합과 약개체집합은 일-대-다 관계집합으로 참여해야함.
하나의 소유자 개체는 여러 약개체와 연관되지만, 각 약개체는 오직 하나의 소유자를 가짐.
이러한 관계집합을 해당 약개체집합의 식별 관계집합이라고 함.

약개체집합은 식별 관계집합에 전체적으로 참여해야함.

 

 

---

클래스 계층

 

ISA (`is a’) Hierarchies

한 개체집합에 속한 개체들을 서브클래스로 분류하는 것.
서브클래스(부분 집합)는 몇 개의 구별되는 특성을 공유함.

Hourly_Emps에 정의된 애트리뷰트들은
Employees의 애트리뷰트들과 Hourly_Emps의 애트리뷰트들을 합한 것임.
즉, Hourly_Emps ISA Employees
(Employees의 애트리뷰트들은 개체집합 Hourly_Emps에 의해서 상속됨)

Employees(슈퍼클래스) -> 여러 서브클래스(부분 집합) : 특수화(specialization)
Hourly_Emps, Contract_Emps -> Employees : 일반화(generalization)

- 중첩 제약조건(Overlap constraints)
: 두 서브클래스가 같은 개체를 포함하는 것이 허락되면
  Contract_Emps OVERLAPS Senior Emps 로 표기함
  어떤 사람이 Contract_Emps 개체이면서 동시에 Senior Emps 개체일 수 있음.

- 포괄 제약조건(Covering constraints)
 : 모든 서브클래스에 속해 있는 개체들이 집합적으로 슈퍼클래스의 모든 개체들을 포함하는가를 결정.
   Motorboats AND Cars COVER Motor_Vehicle
   Motor_Vehicle 개체는 Motorboats 개체이거나 Cars 개체이어야 함.

 

 

---

집단화

 

집단화 (Aggregation)

Projects 개체는 하나 이상의 부서로부터 자금지원을 받음. (Sponsors 관계집합)
부서에서는 그 프로젝트를 감독할 직원을 지정할 수 있음.
이때, Monitors는 P나 D 개체 대신 Sponsors 관계와 Employees 개체를 연관짓는 관계집합이어야 함.
근데 지금까지 '관계'를 둘 이상의 '개체'들을 관련짓는 것이라고 정의하였음.

집단화는 어떤 관계집합이 다른 관계집합에 참여하는 것을 나타낼 수 있게 함.
즉, 실질적으로 Sponsors를 하나의 개체집합으로 간주할 수 있게 함.

 

 

---

ER 모델을 이용한 개념적 설계

 

개체와 애트리뷰트 간의 선택 (Entity vs Attributes)

ex1.

Address를 E의 애트리뷰트가 아니라 새로운 개체집합으로 뽑아준다면..
- 한 직원에 대해 여러 주소 기록 가능해짐.
- 주소를 시,도, 나라 등의 애트리뷰트들로 이루어진 하나의 개체로 표현함으로써
  '주소가 서울 마포구인 모든 직원을 구하시오'와 같은 질의가 가능해짐.


ex2.

한 직원이 어떤 부서에 여러 기간에 걸쳐 근무하는 것이 가능하다고 가정하자.
하나의 관계는 참여하는 개체들에 의하여 유일하게 식별되므로 위의 ER 다이어그램으로는 불가능.

Works_In4관계의 애트리뷰트들에 여러 값들을 기록하고 싶다면 아래처럼 Duration 도입.

 

 

개체와 관계간의 선택 (Entity vs. Relationship)

관리자는 그가 관리하는 각 부서에 대해 부서별로 별도의 재량예산을 받는다면 아래처럼 됨.

하지만 재량예산액이 그 직원에 의하여 관리되는 모든 부서들의 총 재량예산액이라면
이 직원을 포함하는 Manages2의 각 관계는 dbudget에 같은 값 중복저장함.
그리고 dbudget은 관리자와 관련되어있는데 관계와 관련있는 것으로 그려져있음.

Managers라고 하는 새로운 개체집합을 도입하면 됨.

모든 관리자는 하나의 예산을 가지고 있는 반면,
각 관리자는 부서별로 각기 다른 관리 시작날짜를 가질 수 있음.

 

이진관계와 삼진관계간의 선택 (Binary vs. Ternary Relationships)

ex1.
한 직원은 여러 보험증원을 소유할 수 있고, 각 증권은 여러 직원에 의해 소유될 수 있으며,
각 부양가족은 여러 증권에 의해 보호될 수 있는 상황

요구사항
1. 하나의 보험증권은 두 명 이상의 직원에 의해 함께 소유될 수 없음
2. 각 보험증권은 반드시 어떤 직원에 의해 소유되어야 함
3. 부양가족은 약개체집합이며, 각 부양가족 개체는 pname과
  그 부양가족을 보장하는 보험증원 개체의 policyid와 조합하여 유일하게 식별됨

1.에서 키 제약조건 부여하면, 한 증권이 단 한명의 부양가족만 보장할 수 있다는 의도치않은 부작용 야기함.
2. Policies에 전체참여 제약조건 부여하려면, 각 증권이 적어도 한 명의 부양가족을 보장하는 경우에만 가능.
3.은 이진 식별관계 도입해야함.

 

ex2.
Parts, Suppliers, Departments
하나의 계약은 한 공급자가 특정 부서로 특정 부품을 얼마만큼 공급할 것이라는 것을 명시함.

이 관계는 이진관계들에 의해서는 적절히 표현될 수 없음.
즉, S->P(S가 P를 공급), D->P(D가 P를 필요로 함), D->S(D가 S로부터 구매)로는
D->P<-S(D가 S로부터 P를 구매) 알 수 없음.

 

 

삼진관계와 집단화간의 선택 (Ternary vs Aggregation)

하나의 프로젝트는 여러 부서에 의해 자금지원을 받을 수 있고
한 부서는 여러 프로젝트들을 자금 지원할 수 있으며,
각 자금지원 관계는 한 명 이상의 직원들에 의해 감독될 수 있음.

만약 Moniors의 until을 기록할 필요가 없다면 
아래처럼 Sponsor2라는 삼진관계를 사용할 수 있음.

하지만 이렇게하면
각 자금지원 관계가 많아야 한 명의 직원에 의해 감독된다는 제약조건을 표현할 수 없음.
그럴땐 집단화해서 'Sponsor집단 -> Monitor' 해야 함.