ER 모델 릴레이션 변환
IT위키
더 많은 작업
ER-to-Relational Mapping
ER 모델 릴레이션 변환은 개체-관계(ER) 모델을 관계형 데이터베이스로 변환하는 일련의 과정을 말한다. 각 단계는 ER 모델에서 사용된 다양한 개체와 관계들을 관계형 데이터베이스의 테이블로 적절히 매핑하는 방법을 정의한다.
ER-to-Relational Mapping Algorithm
- Step 1: Mapping of Regular Entity Types
- Step 2: Mapping of Weak Entity Types
- Step 3: Mapping of Binary 1:1 Relation Types
- Step 4: Mapping of Binary 1:N Relationship Types. » Step 5: Mapping of Binary M:N Relationship Types. » Step 6: Mapping of Multivalued attributes.
- Step 7: Mapping of N-ary Relationship Types.
Mapping EER Model Constructs to Relations
- Step 8: Options for Mapping Specialization or Generalization.
- Step 9: Mapping of Union Types (Categories).
Step 1: Regular Entity Types
- ER 모델의 일반 개체는 관계형 데이터베이스의 테이블로 변환된다.
- 개체의 속성들은 테이블의 컬럼으로 변환되며, 기본 키는 개체의 식별자 역할을 한다.
예시:
- `Student`라는 개체는 `StudentID`, `Name`, `Major` 등의 속성을 가진 테이블로 변환된다.
Step 2: Weak Entity Types
- 약한 개체(Weak Entity)는 강한 개체(Strong Entity)에 의존해 존재한다. 따라서 약한 개체는 강한 개체의 기본 키를 자신의 기본 키 또는 외래 키로 포함하여 테이블로 변환된다.
- 약한 개체의 식별 관계는 부모 테이블의 키와 함께 변환된다.
- 약한 개체 E2 의 릴레이션은 E2 의 속성 전부와 소유 개체(강한 개체)의 기본 키를 외래 키로 가진다. 기본 키는 소유 개체의 기본 키 + 약한 개체의 부분 키(점선 밑줄로 표시한 판별자)를 합친 것이다.
- 식별 관계(이중 마름모) 자체는 별도 릴레이션으로 만들지 않는다. 약한 개체 릴레이션에 들어간 외래 키가 그 관계를 나타낸다.
- 예: E1(PK1, A1) 과 1:N 식별 관계 R 로 이어진 약한 개체 E2(부분 키 K, 속성 A2) 는 E1(PK1, A1), E2(PK1, K, A2) 로 사상한다. 두 개체를 한 릴레이션으로 합치거나, E2 의 기본 키를 부분 키 K 만으로 두거나(K 만으로는 유일하지 않다), R 을 따로 만드는 것은 맞지 않다.
예시:
- `Order`와 그에 속한 약한 개체 `OrderItem`은 `OrderID`를 외래 키로 포함하는 방식으로 매핑된다.
Step 3: Binary 1:1 Relationship Types
- 1:1 관계는 두 개의 테이블 중 한 테이블에 외래 키를 추가하여 표현한다.
- 외래 키는 관계된 두 개체 간의 연결을 나타내며, 제약 조건으로 UNIQUE 속성을 설정해 1:1 관계를 유지한다.
예시:
- `Employee`와 `ParkingSpace`가 1:1 관계에 있다면, `Employee` 테이블에 `ParkingSpaceID`라는 외래 키를 추가한다.
1:1 관계를 사상하는 세 가지 방법
- 외래 키 방식 - 어느 한쪽 릴레이션에 상대의 기본 키를 외래 키(UNIQUE)로 넣는다. 양쪽 어느 쪽에 넣어도 되며, 관계에 전체 참여하는 쪽에 넣으면 NULL 이 생기지 않는다. 관계의 속성도 그 릴레이션에 함께 둔다
- 병합 방식 - 두 개체와 관계를 하나의 릴레이션으로 합친다. 양쪽이 모두 전체 참여해 늘 짝을 이룰 때 알맞다
- 관계 릴레이션 방식 - 두 기본 키를 외래 키로 가진 별도 릴레이션을 만든다. 참여하는 투플이 적어 외래 키에 NULL 이 많이 생길 때 쓴다
- 두 개체를 각각 릴레이션으로 만들면서 어느 쪽에도 외래 키를 두지 않으면 관계 R 이 사라져 어떤 E1 이 어떤 E2 와 짝인지 알 수 없다. 1:1 사상으로 맞지 않다
1:1 관계의 속성을 어디에 두나
- 1:1 관계에서는 각 개체가 관계 인스턴스에 많아야 하나 참여하므로, 관계의 속성을 참여하는 어느 한쪽 개체로 옮길 수 있다. 외래 키를 넣는 쪽 릴레이션에 관계 속성도 함께 둔다. 전체 참여하는 쪽을 고르면 NULL 이 줄어든다[1][2]
- 예: EMPLOYEE 와 DEPARTMENT 사이의 1:1 관계 MANAGES 에 관리 시작일 StartDate 가 있으면, StartDate 는 EMPLOYEE 로 옮겨도, DEPARTMENT 로 옮겨도(부서마다 관리자가 꼭 있으면 이쪽이 낫다), MANAGES 관계의 속성으로 그대로 두어도 된다
- 그러나 양쪽 개체 모두에 유지해야 하는 것은 아니다. 같은 값을 두 곳에 두면 중복이 생겨 한쪽만 고쳐질 때 불일치가 생긴다
- 1:N 관계의 속성은 N 쪽 개체로만 옮길 수 있고, M:N 관계의 속성은 어느 개체로도 옮길 수 없어 교차 릴레이션에 둔다
Step 4: Binary 1:N Relationship Types
- 1:N 관계는 N 측에 외래 키를 추가하여 표현한다.
- 1 측의 기본 키가 N 측의 외래 키로 포함되며, 이를 통해 두 테이블 간의 관계를 유지한다.
예시:
- `Department`와 `Employee`가 1:N 관계일 때, `Employee` 테이블에 `DepartmentID` 외래 키가 추가된다.
참여 제약과 NOT NULL
- N 쪽 개체가 관계에 전체 참여(ER 도에서 이중선)하면 N 쪽의 모든 투플이 반드시 1 쪽 투플 하나와 이어져야 하므로, 외래 키에 NOT NULL 을 건다. 부분 참여(단일선)일 때만 외래 키에 NULL 을 허용할 수 있다
- 예: DEPARTMENT(DNO, DName) 1 : N EMPLOYEE(ENO, Name, Email) 의 WORKS_FOR 에 EMPLOYEE 가 전체 참여하면 EMPLOYEE 에 외래 키 DNO 를 두고 NOT NULL 로 선언한다. 같은 두 개체의 1:1 관계 MANAGES 에 DEPARTMENT 가 전체 참여하면 관리자 사번 ENO 를 DEPARTMENT 쪽 외래 키(UNIQUE, NOT NULL)로 두는 것이 EMPLOYEE 쪽에 두는 것보다 낫다(관리자가 아닌 사원 행에 NULL 이 생기지 않는다)
- 기본 키로 고르지 않은 고유 속성(예: ENO 를 기본 키로 둔 EMPLOYEE 의 Email)은 대체 키로 UNIQUE 제약을 건다 → 데이터베이스 키
재귀(순환) 관계
- 한 개체 타입이 자기 자신과 맺는 관계도 같은 규칙으로 옮긴다. 1:N 재귀 관계는 같은 릴레이션에 자기 기본 키를 가리키는 외래 키를 하나 더 둔다
- 예: EMPLOYEE(ENO, Name) 의 SUPERVISION(감독자 1 : 피감독자 N)은 EMPLOYEE 에 감독자의 사번(SuperENO)을 외래 키로 추가해 EMPLOYEE(ENO, Name, SuperENO) 가 된다. N 쪽인 피감독자 각자의 행에 1 쪽인 감독자의 키를 넣는 것이다. 피감독자의 사번을 넣으면 한 감독자의 여러 부하를 한 행에 담을 수 없다
- M:N 재귀 관계(예: 부품이 다른 부품으로 구성됨)는 같은 개체의 키를 두 번 가진 교차 릴레이션을 만든다
테이블 수 세기
- 일반 개체 타입과 약한 개체 타입은 하나씩, M:N 관계·다중 값 속성·N 항 관계도 하나씩 릴레이션이 된다. 1:1·1:N 관계(재귀 포함)는 외래 키로 흡수되어 따로 생기지 않는다
- 예: 직원·부서·프로젝트 개체, 직원에 딸린 약한 개체 부양가족, 직원-프로젝트 M:N 참여 관계가 있고 나머지 관계(근무 1:N, 지휘 1:1, 감독 재귀 1:N, 수행 1:N, 부양 식별 관계)가 1:1·1:N 이면 직원, 부서, 프로젝트, 부양가족, 참여의 5개 다
- M:N 관계에 딸린 속성(예: 참여율, WORKS_ON 의 Hours)은 양쪽 개체가 아니라 그 교차 릴레이션에 둔다
Step 5: Binary M:N Relationship Types
- M:N 관계는 새로운 교차 테이블을 생성해 매핑한다.
- 이 교차 테이블은 두 테이블의 기본 키를 외래 키로 가지며, 이 외래 키들이 복합 키를 형성해 관계를 유지한다.
- 관계에 딸린 속성(예: 수강 관계의 성적 Grade)은 어느 한 개체 쪽이 아니라 교차 테이블에 둔다. STUDENT(SNO, Name)와 COURSE(CNO, CName) 사이의 M:N 관계 ENROL 은 ENROL(SNO, CNO, Grade) 가 되고, (SNO, CNO) 가 기본 키이자 각각 외래 키다.
- 한쪽 개체 릴레이션에 상대의 키를 외래 키로 넣는 방식(STUDENT 에 CNO, 또는 COURSE 에 SNO)은 1:N 사상이다. M:N 관계에 쓰면 한 학생의 여러 과목, 한 과목의 여러 학생을 한 행에 담을 수 없다. 교차 테이블에 키 없이 Grade 만 두면 누구의 어느 과목 성적인지 식별할 수 없다.
예시:
- `Student`와 `Course`가 M:N 관계에 있다면, `Enrollment`라는 교차 테이블을 만들어 `StudentID`와 `CourseID`를 외래 키로 설정한다.
Step 6: Multivalued Attributes
- 다중 값 속성은 하나의 개체가 여러 개의 값을 가질 수 있는 경우를 의미한다.
- 이를 매핑하기 위해서는 새로운 테이블을 생성하여 다중 값을 표현한다. 이 테이블은 원래 개체의 기본 키와 속성 값을 포함한다.
예시:
- `Employee` 개체가 여러 개의 전화번호를 가질 수 있다면, `PhoneNumbers`라는 테이블을 추가하여 `EmployeeID`와 `PhoneNumber`를 함께 저장한다.
Step 7: N-ary Relationship Types
- N-ary 관계는 N개의 개체 간의 관계를 나타내며, 새로운 교차 테이블로 변환된다.
- 이 테이블은 관련된 모든 개체의 기본 키를 외래 키로 가지며, 복합 기본 키로 설정한다.
예시:
- `Project`, `Employee`, `Department` 간의 3-항 관계는 이를 나타내는 교차 테이블을 생성하여 각 테이블의 기본 키를 외래 키로 사용한다.
Step 8: Options for Mapping Specialization or Generalization
- 특수화(Specialization)와 일반화(Generalization)는 부모-자식 관계를 표현한다.
- 이를 매핑하는 데에는 몇 가지 옵션이 있는데, 다음과 같다:
- 각 서브타입마다 테이블을 생성: 서브타입에만 해당하는 속성들을 개별 테이블로 나누고, 부모 테이블과 연결한다.
- 상위 개체만을 테이블로 생성: 모든 속성을 하나의 테이블에 포함시킨다.
- 하위 개체만을 테이블로 생성: 각 하위 개체가 독립적으로 존재하며, 상위 개체의 속성까지 포함한다.
예시:
- `Person`이 상위 개체고 `Student`와 `Professor`가 하위 개체라면, 각 하위 개체마다 테이블을 생성할 수 있다.
Step 9: Mapping of Union Types (Categories)
- 유니온 타입(카테고리)은 여러 개체를 하나의 유형으로 통합하는 개념이다.
- 이를 매핑할 때는 유니온 타입의 모든 개체가 공유하는 기본 키를 가진 테이블을 생성하거나, 각 개체에 대해 별도의 테이블을 만들 수 있다.
예시:
- `Owner`라는 유니온 타입이 `Person`과 `Company`에 적용된다면, `Owner` 테이블에 `PersonID`와 `CompanyID`가 외래 키로 포함된다.
- ↑ Olaf Hartig, 「Database Technology Topic 5: Mapping of EER Diagrams to Relational Databases」 TDDD37 강의 자료, Linköping University, 2021, https://www.ida.liu.se/~TDDD37/fo/DBTechnology05-2021.pdf, 확인일: 2026-11-05.
- ↑ Ramez Elmasri, Shamkant B. Navathe, 『Fundamentals of Database Systems』 7판, Pearson, 2016, 3장 Attributes of Relationship Types, 9장 Relational Database Design by ER-to-Relational Mapping.