[데이터베이스] ER 모델의 전문화와 일반화

전문화

엔티티 집합을 잘 이해하기 위해 하위 계층으로 상속하여 구체화.

즉 Top-Down design.

 

하위 계층의 엔티티 집합은 자신이 상속받은 엔티티 집합의 속성을 모두 상속받음

disjoint 전문화를 하나의 엔티티 세트로 함.
(instructor와 secretary. 한 entity가 여러 entity집합에 속할 수 없다. 교수이면서 비서인 경우는 없다는 의미)

 

overlapping 전문화를 여러개의 엔티티 세트로 함

(employee, student. 한 entity가 여러 entity집합에 속할 수 있다. 학생이면서 직원일 수 있다.)

 

스키마로 전문화를 표현

1번째 방법 : 최상위 계층은 모든 속성 표현하고, 하위는 꼭 필요한 것(최상위의 기본키, 자신의 로컬키)만 표현하기

1번째 방법은 저장공간 효율은 좋으나 표현식이 복잡해짐(여러 테이블을 참고해야 되는 경우 발생)

 

2번째 방법 : 전부다 표현하기

2번째 방법은 데이터 중복이 발생가능, 데이터 불일치가 발생할 수도.

 

일반화

요구 사항을 높은 수준에서 설계하는 데 도움이되는 상향식 접근 방식

 

완전성 제한조건 completeness constraint

상위 레벨의 entity set이 하위 레벨의 entity set에 반드시 포함되어야 하는가?

total : 반드시 포함(상위가 반드시 하위로 전문화)

partial : 반드시 x(디폴트)

 

aggregation

여러 엔티티 집합이 참여하는 관계일 때, ER 다이어그램은 관계끼리 관계를 생성하지 못한다.

aggregation은 한 관계를 하나의 엔티티 집합 취급하여 다른 관계와 관계 가능하게 한다.

proj_guide와 eval_for는 overlapping 관계임.(eval_for는 모두 proj_guide와 관련있지만, proj_guide는 모두 eval_for과 관련있지는 않음. 따라서 pro_guide를 지울 수 없음. pro_guide를 aggregation

aggregation은 중복을 제거할 수 있고, 관계 간의 관계를 가능하게 함.

 

aggregation을 하려면,

참여하는 엔티티 집합의 기본키,

aggregation과 관계맺는 엔티티 집합의 기본키,

관계의 속성

을 포함한 스키마를 만들어서 활용

 

위 예시에는 eval_for(s_ID, project_id, i_ID, evaluation_id)로 스키마를 만들 수 있다.

이때 proj_guide는 스키마로 만들 필요가 없다.