📕 목차
1. ERD → Logical Model
2. EERD → Logical Model
1. ERD → Logical Model
📌 7 단계로 진행
- 일반 Entity Type의 변환
- Weak Entity Type의 변환
- 이진 1:1 관계의 변환
- 이진 1:N 관계의 변환
- 이진 M:N 관계의 변환
- 다중치 속성의 변환
- N-ary 관계의 변환
✒️ 변환에서 반드시 지켜야 할 지침
- 테이블 수를 줄여라 (Join의 감소는 곧 속도의 증가)
- Null 속성을 줄여라 (무결성 제약 조건)
1️⃣ 일반 Entity Type의 변환
- 일반 (Strong) Entity Type E는 하나의 테이블 R로 변환
- E의 모든 단순 속성은 R에서도 속성으로 변환
- E의 복합속성은 원소 속성들만 R의 속성으로 변환 (ex. 주소(도시, 거리, 번지) → 도시, 거리, 번지만 저장)
- E의 키가 여러 개일 경우, 그 중 하나를 R의 키로 저장 (나머지 키는 unique 속성으로 유지)
- E의 키가 복합 속성이면, 분해하여 모두 R의 키로 지정
- 예시
- Employee(Ssn, Bdate, Address, Salary, Sex, Fname, Minit, Lname)
- Department(Dnumber, Dname)
- Project(Pnumber, Pname, location)
🟡 복합 속성의 제거
실제로 애플리케이션 개발을 해보면, 클래스는 Address를 따로 만들어서 관리한다.
그런데 Address를 Person 클래스에 embedded하여 실제 DB 상에는 Address의 속성을 Person의 속성으로 취급한다.
2️⃣ Weak Entity Type의 변환
- Weak entity W와 Owner entity E가 주어질 때, W를 아래와 같이 하나의 테이블 R로 변경
- 단계 1처럼 W의 모든 속성들을 R의 속성으로 변환
- E의 키 속성을 R의 외래키로 추가
- (E의 키, W의 구별자) 쌍이 R의 키
- 예시
- Dependent(Essn, Name, Sex, Bdate, Relationship)
3️⃣ 이진 1:1 관계의 변환
- 테이블 S와 T 사이의 1:1 관계 R을 변환하는 3가지 방법 (제일 쉽다.)
- 외래키 사용 (2개의 테이블)
- 완전 참여 테이블(S)에 T의 주키를 외래키로 저장
- 하나의 테이블로 병합 => 1대1이면 일반적으로 이게 가장 낫다.
- S와 T를 하나의 테이블로 병합
- 두 테이블 모두 R에 완전 참여일 경우 가능하다.
- 그렇지 않을 경우, Null 속성 생성
- 관계 테이블 R을 생성 (3개의 테이블)
- S와 T의 키를 외래키로 포함
- 완전 참여 테이블의 키가 R의 키를 갖는다.
- 외래키 사용 (2개의 테이블)
🟡 일대일 관계의 변환
4️⃣ 이진 1:N 관계의 변환
- N에 해당하는 테이블 S에 1에 해당하는 테이블 T의 키를 외래키로 추가
- 관계 속성이 존재할 경우, S의 속성으로 추가한다.
- 관계 테이블 방식으로도 가능하다.
- S와 T의 키를 R의 외래키로 저장
- R의 키는 S의 키가 된다.
- S의 일부 레코드들만 관계에 참여할 때 고려하는 게 좋다. (쓸 데 없이 테이블 많아짐)
🟡 일대다 관계의 변환
5️⃣ 이진 M:N 관계의 변환
- M:N 관계 R에 대한 관계 테이블 S를 생성하는 것이 유일한 방법 (무조건 빼라)
- R에 참여하는 두 테이블의 키를 S의 외래키로 추가
- S의 키는 두 테이블 키의 조합
- R에 관계 속성이 있을 경우, S에 추가
- 참조 무결성 지원을 위해 CASCADE option을 DELETE와 UPDATE에 대해 정의해야 한다.
- 예를 들어, [User] -∈ [Post]에서 유저가 계정을 삭제하면, 유저가 작성한 포스트도 유지할 필요가 없으므로 모두 삭제한다.
🟡 다대다 관계의 변환
6️⃣ 다중치 속성의 변환
- 다중치 속성 A에 대해 새로운 테이블 S를 생성
- S의 구조 = (A를 포함한 테이블의 키, A)
- ex. (key1, ..., {A1, A2, A3})를 S 테이블의 (key1, A1), (key1, A2), (key1, A3)로 저장
- S의 모든 속성이 키를 구성한다.
- 배열을 저장하는 관계형 모델의 경우에는 변환이 불필요하다.
🟡 다중치 속성의 제거
7️⃣ N-ary 관계의 변환
- N > 2인 N-ary 관계는 새로운 테이블 S로 변환
- 관계에 참여하는 모든 Entity type의 키를 S의 외래키로 추가
- 관계 속성들은 S의 속성으로 저장
- S의 키: 모든 외래키들의 조합 (단, Cardinality(최대)가 1인 entity type의 키는 제외한다.)
🟡 N-ary 관계의 변환
📌 ERD를 관계형 모델로 변환한 결과
📌 변환 규칙 요약
2. EERD → Logical Model
📌 ERD 변환 7단계 + 2단계
- 단계 8. 특수화/일반화의 변환
- 8A: 상위 클래스와 하위 클래스를 모두 테이블로 변환
- C에 대한 테이블 L = (k, a1, a2, ..., an) 생성
- 하위 클래스 Si에 대한 테이블 Li = (k, Si의 속성)
- type 필드를 기준으로 join할 하위 테이블 결정 → Join이 증가한다.
- 8B: 하위 클래스만 테이블로 변환
- 하위 클래스 Si에 대한 테이블 Li = (k, a1, a2, ..., an, Si의 속성)
- 8C: 모든 클래스를 하나의 테이블에 통합 + 1 타입 속성
- 하나의 테이블 L = (k, a1, a2, ..., an, m개의 하위 클래스 속성, t)
- t: 해당 레코드가 속한 하위 클래스 표시
- 다른 하위 클래스에 속하는 레코드는 모두 Null 허용
- 8D: 모든 클래스를 하나의 테이블에 통합 + m 타입 속성
- 하나의 테이블 L = (k, a1, a2, ..., an, m개의 하위 클래스 속성, t1, ..., tm)
- ti: boolean 타입으로 레코드가 Si에 속할 경우 true
- Overlapping constraint로 인해, 하위 클래스에 중복 소속 가능한 경우
- 8A: 상위 클래스와 하위 클래스를 모두 테이블로 변환
- 단계 9. Union Type의 변환
📌 특수화/일반화 변환의 예
1️⃣ 8A : 상위 클래스 & 하위 클래스
2️⃣ 8C : 타입 하나만으로 하나의 클래스로 통합
3️⃣ 8B : 하위 클래스로 모두 분리
4️⃣ 8D : 타입 여러개로 Overlapping 대응 가능한 하나의 클래스로 통합
📌 공유 하위 클래스(다중 상속)의 변환
- 단계 8의 모든 option들을 적용 가능하다.
- 단, 상위 클래스들은 동일한 key를 가져야 한다.
- 만약 key가 다를 경우 union type의 규칙을 적용한다.
🟡 다중 상속 변환의 예
📌 Union Type의 변환
- 대리키(surrogate key)를 이용하여 상위 클래스의 키를 통합한다.
- {Person, Bank, Company}의 unique key를 받아 Owner가 참조
- {Car, Truck}의 unique key를 받아 Registered_Vehicle이 참조
- Owns가 Owner와 Registered_Vehicle이 참조하는 키를 복합키로 사용
🟡 예시
