▣ E-R 모델을 관계 데이터 모델로 사상_관계, 강한개체, 전체참여, 참조외래키
| ER 모델 | 관계 스키마 | |
| 2진 관계 |
1:1양방향 완전관계 | 두 릴레이션을 하나로 통합(일반적인 경우) 두 엔티티타입과 관계타입을 하나의 릴레이션 스키마로 생성하며, 외래키는 없다 |
| 1:1 단방향 완전관계 | 부분 관계 릴레이션의 PK를 완전 관계 릴레이션의 FK로 적용 | |
| 1:1 양방향 부분관계 | 두 릴레이션의 PK만으로 구성된 릴레이션을 생성 (신규)한쪽 개체의 키 애트리뷰트를 키값으로, 다른쪽의 키 애트리뷰트를 외래키로 (2개 외래키) |
|
| 1:N N측 완전관계 | 1측의 PK를 N측의 FK로 설정 | |
| 1:N 1측 완전관계 | 두 릴레이션의 PK로 구성된 릴레이션을 생성 (신규) n-side의 기본키 + 1-side의 기본키를 외래키로 (2개 외래키) |
|
| M:N 관계 | 두 릴레이션의 PK로 구성된 릴레이션을 생성 새로운 릴레이션의 PK는 두 릴레이션의 PK를 결합하여 사용 (Composite Key 구성) |
|
| 순환 | 1:1 | (신규) 기본키 + 기본키를 외래키로 내장 (예) 결혼 |
| 1:N | 기본키를 외래키로 생성하여 자체 참조 (예)사원-상관 | |
| 기타 | 다중값 애트리뷰트 (다치 속성) |
(신규) 원 릴레이션의 기본키와 다중값 애트리뷰트를 복합키로 원 릴레이션의 기본키는 외래키로 내장됨 |
| 식별관계타입 (1:N) | 강한개체의 기본키와 약한 개체의 부분키를 복합키로 | |
* 전체 참여는 완전관계, 부분참여는 부분관계
2012년 67번
정답 : 4번
* 관계(Relationship)스키마 변환 방법
1. 1:1 참여관계 판단, 1:N->N쪽으로 이관, M,N->별도 Table 생성
다중(다치)속성 -> 별도 테이블 생성
위그림) EMPLOYEE, DEPARTMENT, TEL(다치속성) 3개 테이블
2. 두릴레이션 관계 1:N N쪽(다쪽) 외래키(FK)로 삽입
-> EMPLOYEE(X,X,DNO)
3. 순환관계
1:N 순환관계 - 기본키를 외래키로 생성하여 자체 참조
-> 기본키를 외래키 참조 속성으로 추가 (Supervisor_ENO)
4. 다치속성 테이블 새성, 기존에 포함된 테이블 기본키 포함
복합키 사용(DNO, TEL)
2013년 56번
정답 : 3번
* 관계(Relationship) 스키마 변환 방법
용어 : 강한개체(독자적존재), 약한개체(독자존재 X, 상위 개체 타입 가짐)
식별관계(강한개체 기본키 상속 받아 사용)
1. 테이블 생성 -> 3개 위 그림) 부서, 직원 가족
2. 두 릴레이션 관계 1:N N쪽(다쪽) 외래키(FK) 삽입
-> 직원(직원번호, 연봉, 부서번호)
3. 두 엔터티 타입 부서와 직원이 서로 병렬(다중) 관계("소속", "관리")로 참조
부서는 "관리"관계에서 전체참여, 직원은 부분 참여 경우
1:1(단방향 전체참여)
부분 관계 릴레이션(테이블)의 기본키(PK)를 완전 관계 릴레이션이 외래키(FK)로 선정
-> 부서(부서번호, 예산, 직원번호)
4. 가족 릴레이션(테이블) 약한개체 이므로 강한개체 기본키(PK) 상속
-> 가족(직원번호, 이름, 나이)
2013년 58번
정답 : 2번
사원은 여러 피부양자를 갖으므로 일대다 관계(1:N relationship set)
'모든 사원의 사원번호를 서로 다른 값을 갖고, 한 사원의 부양가족 중에는 같은 이름을 가진 사람이 없다. 그러나 서로 다른 사원의 부양가족의 이름이 같을 수는 있다.'
피부양자 : 약한 엔티티 집합(weak entity set)
피부양자의 이름 : 부분키(partial key)
관계 타입의 키(key of relationship type)가 다이어그램에 포함될 가능성이 가장 낮음
2013년 74번
정답 : 4번
* 관계(Relationship)스키마 변환 방법
1. M,N->별도 Table 생성
-> WORKS_ON(ENO, PNO, Hours)
2014년 70번
정답 : 4번
* 관계(Relationship)스키마 변환 방법
1. 1:N 관계이고, Dependents가 전체 참여 -> Employee의 기본키 ssn를 Dependents의 외래키로 사용함.
2. 식별관계 타입 -> 강한 개체의 기본키와 약한 개체의 부분키를 복합키로 사용
2015년 71번
정답 : 2번
* 관계(Relationship)스키마 변환 방법
1. 순환관계
-> 기본키를 외래키 참조 속성으로 추가 (Supervisor_ENO)
1) 직원(EMPLOYEE)은 전체참여(Total participation, 이중선 표기)이므로 모든 직원은 하나의 부
서에 소속됨 따라서, ①번은 틀린 내용임
부서(DEPARTMENT)는 부분참여(Partial participation, 단일선 표기)이므로 직원 없는 부서가 존재할 수 있음
2) 부서(DEPARTMENT)와 직원(EMPLOYEE)이 1:N 관계이므로 릴레이션으로 변환하면
DEPARTMENT(DNO, DName), EMPLOYEE(ENO, Name, DNO)와 같음. 이때, 릴레이션
EMPLOYEE의 이탤릭체 DNO는 DEPARTMENT와의 참조 외래키임 따라서, ④번도 틀린 내용임
2017년 52번
- 문제 풀이
직원(사원번호, 이름, 성별, 생년월일, 급여, 근무부서번호, 감독사원번호)
부서(부서번호, 부서명, 지휘사원번호)
위치(부서번호, 위치)
부양가족(사원번호, 가족이름, 성별, 생년월일, 관계)
프로젝트(과제명, 진행율, 수행부서번호)
참여(사원번호, 과제명, 참여율)
2018년 53번
정답 : 3번
Supplier(SuNo)
Project(PrNo)
Part(PaNo)
Supply(Quty,SuNo(FK),PrNo(FK),PaNo(FK))
2018년 57번
57. 개체-관계도로부터 관계형 데이터베이스를 설계하는 과정에 대한 설명 중 가장 적절하지 않은 것은?
① 소유(owner) 엔터티 타입 E를 갖는 약한(weak) 엔터티 타입 W의 경우, W의 모든 속성과 E에 해당하는
릴레이션의 기본키를 외래키로 가지는 릴레이션으로 설계한다.
② 이진 1:1 관계에 참여하는 엔터티 타입 S와 T의 경우, S의 기본키에 대한 외래키를 T에 추가하여 릴레이션을
설계하며, 이때 완전 참여여부를 고려할 필요가 있다.
③ 이진 M:N 관계 타입이면서 관계 인스턴스가 많지 않은 경우에는 1:N 관계처럼 하나의 릴레에션에만 외래키를
포함시킬 수 있다.
④ 엔터티 타입 S의 속성 A가 다치 속성값을 갖는 경우, S에 해당하는 릴레이션의 기본키와 A를 속성으로 갖는
별도의 릴레이션으로 설계한다.
정답 : 3번
두 릴레이션의 PK로 구성된 릴레이션을 생성
새로운 릴레이션의 PK는 두 릴레이션의 PK를 결합하여 사용
(Composite Key 구성)
2019년 60번
정답 : 2번
"감독"관계 타입은 직원 간에 서로 부분참여하는 관계이므로 외래키인
'직원.상사_직원번호'는 NULL을 허용하는 속성임
2019년 63번
정답 : 3번
생성되는 테이블 수는 4개
EMPLOYEE, PROJECT, LOCATION, WORKS_ON
M,N->별도 Table 생성
다치속성 테이블 새성, 기존에 포함된 테이블 기본키 포함
2020년 73번
정답 : 2번
관계 타입 WORKS_FOR는 양쪽 모두 전체 참여이므로,
EMPLOYEE테이블의 외래키 DNO는 필수 입력, 즉
NOT NULL 제약 조건 설정이 필요함
1) 1:N 관계를 반영하기 위하여 EMPLOYEE 테이블에 외래키 DNO를 추가한다. (1번 맞음)
1:N N측 완전관계 1측의 PK를 N측의 FK로 설정
2) 1:N 관계를 반영한 EMPLOYEE 테이블의 외래키 DNO에 대해서는 NULL값을 허용할 수 있다.
두줄 관계는 전체 참여 이므로 NULL값 허용할 수 없음 (2번 틀림)
3) 1:1 MANAGES 관계 반영의 경우 DEPARTMENT 테이블에 외래키 ENO를 추가하는 것이
EMPLOYEE 테이블에 외래키 DNO를 추가하는 것보다 더 좋다.
1:1 단방향 완전관계(전체참여) 에서는 부분 관계 릴레이션의 PK를
완전 관계 릴레이션의 FK로 적용 (3번 맞음)
4) EMPLOYEE 테이블에서 ENO를 기본키로 설정할 경우, Email은 대체키로 UNIQUE제약을 설정한다. (4번 맞음)
2021년 52번
정답 : 4번
두 엔터티 타입 DEPARTMENT, EMPLOYEE 관계 타입 MANAGES를 기준으로 1:1 관계 양방향 부분 참여로 연결된 구조이므로, 각각의 엔터티 타입을 테이블로 도출하고 관계 타입도 별도 관계 테이블로 스키마 변환하는 것이 일반적임
1:1 관계이지만 양쪽 모두 부분적으로 참여하는 느슨한 관계이기 때문에 별도로 관계 테이블을 생성하여 관리하는 것이 효율적임
DEPARTMENT, EMPLOYEE 중 하나의 엔티티로 외래키(FK)를 생성해서 관리할 수 있음
이때 관계 타입 속성 StartDate도 보기 1), 2)번 처럼 외래키가 있는 엔티티 쪽에 관리할 수 있음
(이 경우 외래키가 있는 엔티티에서 관계에 참여하지 않는 레코드 대부분은 외래키와 StartDate속성이 Null값을 가지게 되어 비효율적인 구조가 될 수 있으므로 관계 참여 비율과 방향을 잘 따져보고 결정해야 함)
4번) 처럼 1:1 관계 타입 속성을 양쪽 엔티티 모두 관리하면 데이터가 중복되고 데이터 무결성을 유지하기 어렵게 됨