Extended E-R model

상위 문서: Entity Relationship Model

개요

기본적인 E-R(Entity-Relationship) 모델은 대부분의 데이터베이스 특징을 모델링할 수 있지만, 더 정교한 개념을 표현하기 위해 확장된 개념이 필요할 때가 있다. Extended Entity-Relationship Model(EER)은 이러한 한계를 보완하기 위해서 사용된다. 이러한 EER은 아래의 개념들을 통해서 더욱 정교한 데이터베이스를 구축할 수 있도록 한다.

• Specialization
• Generalization
• Higher- and Lower-Level Entity Sets
• Attribute Inheritance
• Aggregation

위 개념들을 아래에서 설명하기 위해서 University 데이터베이스를 중심으로 설명한다. 대학교 내 다양한 사람들을 모델링하기 위해 person entity를 정의하며, 해당 entity에는 ID, name, street, city와 같은 attribute(속성)들이 포함된다.

Specialization

Specialization and generalization.

Specailization이란, 하나의 entity set을 보다 세부적인 하위 그룹들로 나누는 것을 의미한다. 이때, 하위 그룹들로 나누기 위해서는 entity set 내의 일부 entity가 특정 속성을 가지지만 다른 entity들은 해당 속성을 가지지 않아야 한다. 이를 통해서 같은 범주들에 속하는 entity들 사이의 차이를 명확하게 기술할 수 있다.

예를 들어서 person entity set을 살펴보자. 대학교의 person은 student와 employee라는 두개의 하위 그룹으로 구분될 수 있을 것이다. employee는 person의 속성에 더하여 salary 속성이 추가로 부여된다. 또한 student는 person의 속성에 추가로 tet_cred라는 속성이 추가로 부여된다. 이와 같이 specialized된 entity set이 원래의 entity set의 모든 속성들과 모든 relationship participation을 상속받는 것을 attribute inheritance라고 한다.

이때 secialization은 계층적으로 적용되어 이미 specailized된 entity set에도 다시 적용될 수 있다. 예를 들어서 employee entity set은 instructor과 secretary로 다시 specialized될 수 있다. 이때 instructor는 추가로 rank 속성을 가지며, secretary는 추가로 hours_per_week 속성을 가진다. 이렇게 specialized된 entity은 다른 entity set과 추가적인 relationship을 가질 수 있다. 예를 들어 각각의 secretary는 특정한 instructor를 보조하는 relationship을 가질 수 있다.

specialization은 오른쪽 그림과 같이 hollow arrow head로 표현된다. 이때 해당 화살표는 specialized된 entity에서 상위의 entity로 향하며, 이 관계를 ISA관계라고 한다. 예를 들어, 'instructor "is a" employee'와 같이 표현한다.

이때, specialization은 두가지 유형으로 나뉜다. Overlapping Specialization과 disjoint specialization이 바로 그것이다. Overlapping specialization은 한 entity가 여러개의 하위 그룹에 속할 수 있는 경우이다. 예를 들어 person에서 specialized된 employee와 student이 바로 그것이다. 그 이유는 어떤 person이 student이지만, 근로나 조교 활동 등을 통해서 employee에도 동시에 소속될 수 있기 때문이다. 이 경우, 다중 화살표를 사용하여 이를 표현한다.
Disjoint specialization은 한 entity가 여러개의 하위 그룹 중 단 하나에만 속할 수 있는 경우이다. 예를 들어 employee에서 specialized된 scretary와 instrouctor이 바로 그것이다. 그 이유는 instructor는 scretary가 될 수 없으며, 그 반대도 마찬가지이기 때문이다. 이 경우, 단일 화살표를 사용하여 이를 표현한다.

Representing Secialization via Schema

두가지 방법이 존재한다.

1. 상위 엔터티와 하위 엔터티 각각 스키마 분리
   1. 상위 entity set에 대해 하나의 schema를 만든다.
      • person(ID, name, street, city)
   2. 하위 entity set마다 별도의 schema를 만들고, 상위 entity set의 primary key와 local attribute를 포함시킨다.
      • student(ID, tot_cred), employee(ID, salary)
   • 장점: data redundancy가 없다.
   • 단점: specialized된 entity set을 조회하기 위해서는 상위 entity set의 속성까지 참조해야 하므로 복잡성과 조회 시간이 증가한다.
     예를 들어, employee에 대한 정보를 조회할 때, person과 employee 두 테이블을 조인해야 한다.
2. 모든 entity마다 완전한 schema를 만든다.
   1. 각 entity set마다 스키마를 만들고, 상속된 속성까지 포함시킨다.
      • person(ID, name, street, city)
        student(ID, name, street, city, tot_cred)
        employee(ID, name, street, city, salary)
   • 장점: specialized된 entity set을 조회할 때에도 해당 entity set의 schema만을 조회하면 된다.
   • 단점: data redundancy가 발생한다. 예를 들어, student이자 employee인 경우 name, street, city가 중복 저장된다.

Generalization

Specialization은 하나의 entity set을 하위 수준의 entity set으로 세분화하며 설계하는 top-down 설계방식이다. 이에 반대되는 개념이 Generalization이며, bottom-up 설계 방식이 사용된다. 이 방식에서는 여러 entity set들을 공통된 특성을 기반으로 더 높은 수준의 entity set으로 통합하면서 설계를 한다.

예를 들어, 초기에 instructor entity set과 student entity set이 존재한다고 하자. 이때 instructor는 ID, name, street, city, salary을 속성으로 가지고, studnet는 ID, name, street, city, tot_cred를 속성으로 가진다. 이 두 entity set은 공통적으로 ID, name, street, city 속성을 가지고 있다는 점에서 유사성이 있다. 이러한 유사성을 바탕으로 student와 employee entity set을 person이라는 entity set으로 geralize할 수 있다.

위의 예시를 통해 알 수 있듯이, gernerlization은 specialization과는 inversion의 관계를 가지고 있다. 하지만, 반대되는 개념일지라도 E-R diagram상에서는 동일하게 표현된다. 따라서 두 용어는 서로 바꿔서 사용될 수 있으며, 실제 설계나 표현에서는 specialization과 generalization을 엄격히 구분하지 않고 상황에 따라 유연하게 사용한다.

Completeness constraint

데이터베이스를 더 정확하게 모델링하기 위해, 데이터베이스 설계자는 특정한 specialization/generlization에 대한 일정한 제약 조건을 설정할 수 있다. 우리가 앞서 본 specialization 제약 조건의 한 종류는, specialization가 disjoint인지 또는 overlapping인지 여부를 명시하는 disjointness constraint이다. 또 다른 유형의 제약 조건은 completeness constraint으로, 이는 specialization/generlization 내에서 상위 entity set의 entity가 반드시 하나 이상의 하위 entity set에 속해야 하는지 여부를 지정한다.

이때 completeness constraint는 다음 중 하나에 속한다.

• Total specialization/generalization: 모든 상위 entity는 반드시 하나의 하위 entity set에 속해야 한다.
• Partial specialization/generalization: 일부 상위 entity는 어떤 하위 entity set에 속하지 않을 수 있다.

Total(disjoint) generation

예를 들어, person을 student 또는 employee로 특수화하는 경우, 만약 학교가 student도 아니고 employee도 아닌 person을 표현할 필요가 없다면, total specialization에 속한다. 그러나 만약 어디에도 속하지 않는 person을 표현할 필요가 있다면, partial specialization에 속한다.
이때 partial specialization이 기본 상태이다. total specialization을 따로 표시하기 위해서는 오른쪽 그림과 같이 다이어그램에 “total”이라는 키워드를 추가하고, 해당 키워드에서 점선을 적용되는 hollow arrowhead 또는 여러 개의 화살표 집합으로 연결한다.

이러한 제약 조건에 따라, entity의 삽입 및 삭제 시 특정 요구사항이 따라온다. 예를 들어, total completeness constraint이 적용된 경우, 상위 entity set에 entity를 삽입할 때는 반드시 하나 이상의 하위 entity set에도 삽입해야 한다. 상위 entity set에서 entity가 삭제될 경우에는, 그 entity가 속해 있던 모든 하위 entity set에서도 삭제되어야 한다.

이때 disjointness constraint와 completeness constraint는 서로 독립적인 제약조건이다. 따라서 특수화는 다음과 같은 조합이 가능하다.

• partial-overlapping
• partial-disjoint
• total-overlapping
• total-disjoint

Aggregation

기존의 E-R 모델의 한계 중 하나는 관계와 관계 사이의 관계를 표현할 수 없다는 것이다. 이것이 어떤 문제 상황인지는 다음 예시를 통해 이해할 수 있다.

위 그림과 같이 instructor(강사), student(학생), project(프로젝트) 사이에 삼항 관계인 proj_guide가 있다. 이는 "어떤 강사가 어떤 학생을 어떤 프로젝트에 대해서 지도한다"라는 것을 의미한다. 이때 "해당 지도에 대해 evaluation(평가)를 작성해야 한다"는 새로운 요구 사항이 대학교에 의해서 생겼다고 가정하자. 즉, (instructor, student, project) 조합에 대해 매달 평가가 생긴다.

이를 해결하는 첫번째 방법은 단순하게 relationship을 하나 더 만드는 것이다. 이는 evaluation이라는 새로운 entity를 만들고, 첫 사진과 같이 instructor, student, project, evaluation 간의 4항 관계 eval_ford을 만듦으로서 수행될 수 있다. 이를 통해서 "누가 누구를 어떤 프로젝트에 대해 지도했고, 그에 대한 평가가 어떤지"를 표현할 수 있다. 하지만 eval_ford라는 관계는 proj_quide라는 관계와 상당 부분 겹치는데, val_for에 존재하는 모든 (instructor, student, project) 조합은 반드시 proj_guide에도 존재해야 하기 때문이다. 즉, eval_ford와 evaluation은 서로 redundant하다.

또다른, 이를 해결하는 방식은 evalution을 proj_guide의 multivalued composite attribute으로 취급하는 것이다. 하지만 이경우에는 evaluation이 다른 entity와 관계될 수 있기 때문에 적절하지 않다.

이를 완전히 해결할 수 있는 방법은 aggreation이라하고, 이는 relation을 하나의 entity처럼 추상화해서 사용하는 것이다. 위의 예시에 aggregation을 적요하면, 3항 관계 proj_guide를 하나의 entity처럼 추상화할 수 있다. 이제, proj_quide를 위 그림과 같이 evaluation과 2항 관계로 연결할 수 있다. 즉, E-R 다이어그램에서는 [proj_guide]와 evaluation 간의 2항 관계가 존재하며, proj_guide는 여전히 instructor, student, project의 조합을 내부적으로 가지고 있다.

aggregation의 장점은 proj_guide에 대한 rudundancy 없이 evaluation entity와의 관계를 형성할 수 없다는 것이다. 또한 evaluation이 secretary entity들과도 추가적으로 연결될 수 있다는 점에서 유연성이 증가된다. 마지막으로 evaluaiton이 어떤 지도 활동에 대한 것인지 명확하게 표현된다는 점에서 모델링의 명확성 또한 올라간다는 장점을 지닌다.

Reduction to Relation Schemas

Generalization의 표현

Generalization이 포함되는 E-R 다이어그램을 위한 relation schema를 설계하는 두가지 방법이 존재한다. 이를 설명하기 위해 specialization에서 설명된 person entity set과 specialized된 entity set student와 employee를 예를 들어 설명할 것이다. 이때 person의 primary key는 ID이다.

첫번째 방법은 상위 수준의 entity set을 위한 schema를 생성하고, 각각의 secialized된 entity set마다 해당 집합의 모든 attribute와 상위 수준 entity set의 primary key를 포함하는 schema를 생성하는 것이다. 이를 person과 student, employee에 적용하면 다음과 같다.

person(ID, name, street, city)
employee(ID, salary)
student(ID, tot_cred)

이때 상위 수준 entity set의 primary key(ID)는 하위 수준 entity set에 대해서도 primary key가 된다. 또한 specialized된 entity set에 대해 foreign-key constraint를 설정한다. 즉, specialized된 entity schema의 ID는 상위 schema의 primary key(person.ID)를 참조하게 된다.

두번째 방법은 generalization이 disjoint이고 complete일 경우에 사용된다. 이 경우에는 상위 수준의 entity set에 대한 schema를 제공하지 않고 각 하위 수준의 entity set마다 해당 집합과 상위 entity set의 모든 속성들을 포함하는 schema를 생성한다. 예를 들면 다음과 같다. employee(ID, name, street, city, salary) student(ID, name, street, city, tot_cred)

Aggregaion의 표현

Aggreation을 포함한 E-R 다이어그램의 스키마를 설계하는 것은 직관적이다. aggreation을 설명할 때 사용했던 예시를 바탕으로 설명을 하면, 집합화된 관계 proj_guide와 evaluation 사이의 관계 집합 eval_for를 위한 스키마는 다음을 포함한다:

• 집합화된 관계의 Primary Key
  • evaluation 엔터티의 primary key 속성들(evaluaiotn_id)
• 관련 엔터티의 Primary Key
  • 관계 집합 proj_guide의 기본 키 속성들
• 관계 eval_for의 decriptive attributes (존재한다면)

이에 따라 eval_for는 아래와 같이 schema화 된다.

eval_for (s_ID, project_id, i_ID, evaluation_id)

그런 다음 집합화된 엔티티 집합(proj_guide) 내의 관계와 엔티티 집합들은 기존 규칙들에 따라 변환된다.
하지만 주의할 점이 있는데, aggregation으로 인해 추상화되어 만들어진 proj_quide에 대한 별도의 상위 수준의 엔티티 집합 schema는 만들 필요가 없다. proj_guide는 실제로는 관계 집합이고, 집합화가 된다고 해서 진짜 테이블처럼 분리할 필요는 없다는 의미이다. 이미 eval_for에서 proj_guide의 primary key들을 포함하고 있기 때문이다.