📕 목차
1. 개요
2. 하위 클래스와 상위 클래스
3. 특수화와 일반화
4. Union Type
5. 예시
1. 개요
📌 Extended(Enhanced) Entity Relationship Model
- ER 모델의 모든 모델링 개념들을 포함한다.
- 추가적으로 지원하는 개념 (Object Oriented Concept)
- 하위 클래스(Sub class)와 상위 클래스(Super class)
- 특수화(Specialization)와 일반화(Generalization)
- Union Type
- 계승(Inheritance)
- ER 모델보다 데이터베이스 응용을 보다 정확히, 효과적으로 표현하기 위해 사용한다.
2. 하위 클래스와 상위 클래스
📌 Concept
- Entity를 다시 여러 개의 세부 Entity로 분할
- 사원(Employee) 개체
- 비서, 기사(Engineer), 기술자(Technician) 등 (사원 작업 내용에 따라 분류)
- 관리자 (사원 중 역할이 관리자인 사람)
- 월급 사원, 시급 사원
- 각 Entity는 Employee의 하위 클래스로 정의
- 하위 클래스 == 하위 Entity (Type)
- Employee는 이러한 하위 클래스들의 상위 클래스
- 개체 간에 상위 클래스/하위 클래스 관계(IS-A)가 존재
- 사원(Employee) 개체
- "하위 ⊂ 상위"라면 상위 속성들을 하위 Entity가 가지고 있다.
📌 IS-A 관계
- 하위 클래스의 원소는 반드시 상위 클래스의 원소다. (역은 성립하지 않는다.)
- 한 클래스에 다양한 종류의 하위 클래스들이 존재할 수 있다.
- 하위 클래스 Entity는 상위 클래스 Entity의 속성과 관계를 모두 상속 받는다.
- 하위 클래스가 갖는 자신만의 속성을 지역 속성(local attribute) 혹은 특수 속성(specific attribute)이라 한다.
- 하위 클래스 속성 = 상속받은 속성 + 지역 속성
🟡 Overriding
- 만약 같은 속성이 재정의 되면, 재정의한 하위 속성이 우선된다.
3. 특수화와 일반화
📌 특수화(Specialization)
- 상위 클래스의 특수한 경우로 하위 클래스들을 정의
- 상위 클래스의 속성값에 따라 특수화가 진행된다.
- Employee의 job type에 따른 특수화 : Secretary, Engineer, Technician
- Employee가 담당하는 role을 기준 : Manger
- 급여지급 방식에 따른 특수화 : 월급 사원, 시급 사원
- 주의 사항
- 하나의 상위 클래스에 대해 여러 개의 특수화 가능
- 하위 클래스는 자신만의 속성(지역 속성)뿐 아니라 관계 또한 가질 수도 있음.
📌 일반화(Generalization)
- 특수화의 역순으로 클래스를 정의
- 하위 클래스들의 공통 속성들을 묶어 상위 클래스를 만든다.
📌 표현 방법
별의 별 방법이 다 있는데, 수업 시간엔 주로 (i)나 (vi)만 사용했다.
📌 특수화의 종류
- 조건 기반(predicate-defined) 하위 클래스
- 상위 클래스에서 특정 조건을 만족하는 Entity들을 하위 클래스로 정의하는 경우
- 정의 조건(defining predicate) : Secretary 클래스는 특정 Job_type을 만족하는 entity, 여기서 Job_type이 정의 조건에 해당한다.
- 2가지 종류의 특수화
- 속성 기반(attribute-defined) 특수화
- 상위 클래스의 특정 속성 값에 따라 하위 클래스들이 정의되는 경우
- 정의 조건이 JobType이라면, 해당 속성에 따라 하위 Entity(Secretary, Engineer, Technician) 생성
- 사용자 정의(user-defined) 특수화
- 각 하위 클래스에 포함되는 Entity는 사용자가 정의
- 속성 기반(attribute-defined) 특수화
🟡 속성 기반 특수화의 예
- 여기서 주의할 건, Job_type이 겹선이 아닌, 홑선이므로 모든 직원이 {Secretary, Technician, Engineer}에 해당되는 것은 아니다.
📌 제한 조건
💡 서로소 조건 * 완전성 조건의 조합으로 총 4가지 경우가 존재한다.
- 서로소 조건(disjoint constraint)
- disjoint(d): 하위 클래스들이 서로소인 경우 (ex. 사원 → {월급 사원, 시급 사원})
- overlapping(o): 겹치는 부분이 있을 경우 (ex. 사람 → {사원, 학생, 동창})
- 이해가 안 가서 찾아보니, disjoint는 하나의 인스턴스가 하나의 sub class entity 값만 가져야 하고, overlapping은 하나의 인스턴스가 여러 개의 sub class entity에 속할 수 있다는 것이다. (직업 중복 선택 허용 여부에 따라 달림)
- 완전성 조건(completeness constraint)
- total(겹선): 상위 클래스의 모든 원소가 하위 클래스 중 하나에 포함
- partial(단선): 하위 클래스에 포함 안 되는 원소가 존재
🟡 overlapping 서로소 조건 & total 완전성 조건 예시
📌 특수화/일반화 계층과 격자 구조
- 일반화 계층(Generalization Hierarchy)
- 하위 클래스가 하나의 상위 클래스만 갖는 트리 구조
- 일반화 격자(Generalization Lattice)
- 여러 개의 상위 클래스가 존재하는 구조 (공유 하위 클래스(shared subclass))
- 다중 상속(multiple inheritance)를 지
계층 혹은 격자가 특수화/일반화 인지를 따지는 건, 보는 관점(Top-down/Bottom-up)에 따라 다르다.
🟡 특수화/일반화 격자 예시
4. Union Type
- 서로 딱히 관련은 없으나, 필요에 의해 entity type들을 묶는 개념 (그래서 Category라고도 한다.)
- 위의 예시처럼 자동차가 개인 차량일 수도, (은행에 압류 당해서)은행 소유일 수도, 회사 소유일 수도 있는데, 소유자라는 Union Type을 사용해서 하나로 묶어버리는 전략
- Shared Sub class와는 다르다.
- 여러 개의 상위 클래스를 갖는 것은 동일
- Shared subclass: Entity는 모든 상위 클래스의 Entity (ex. 학생 조교는 학생이자 사원인 entity)
- Union type: Entity는 상위 클래스 중 하나에 소속
5. 예시
📌 University 데이터베이스
- 사람(Person)
- 사람의 하위 클래스로 교수(Faculty)와 학생(Student)
- 교수와 학과 사이에는 소속 관계, 학과장 관계가 존재
- 학생과 학과 사이에는 주전공, 복수전공 관계가 존재
- 대학원생(Grad_Student)은 학생의 하위 클래스
- 정의 조건: (Class = 5 or Class = 6)
- 대학원생과 교수 사이에는 지도 관계, 논문 심사위원 관계 존재
- 학과(Department)
- 과목(Course), 강좌(Section)
- 강사(Instructor_Researcher)는 교수와 대학원생의 Union Type => 이거 없으면 교수-강사, 대학원생-강사로 2개의 Relationship 필요, 하지만 지금은 강사와 강좌 사이의 관계로 합침
- 연구비(Grant)
- 한 명의 교수가 연구 책임자
- 여러 명의 교수와 대학원생들이 연구원으로 참여
📌 특수화/일반화 설계 고려사항
- 개념적 설계 단계는 반복적인 정제 과정 (rough → 다듬어 가자)
- 특수화를 지나치게 반복하면, 클래스 수가 많아지고 모델이 혼란스러워진다. 꼭 필요한 하위 클래스만 생성하라!
- 하위 클래스가 지역 속성이 거의 없고, 관계에도 참여하지 않으면 상위 클래스와 합쳐라
- 상위 클래스에 타입 속성을 두어 표시할 수 있다.
- ex. 월급 사원/시급 사원이 아닌, Employee entity에 급여 방법이라는 속성으로 월급/시급 표현
- Union type은 지원되지 않은 경우가 많으므로 가급적 특수화/일반화 등으로 대체할 필요가 있다.
- 서로소/완전성 조건은 응용 분야의 요구에 따라 결정한다. 특별한 요구 사항이 없다면, overlapping & partial을 기본 조건으로 갖는 게 좋다.