2장. E/R 데이터 모델 엔티티-관계성 (Entity-Relationship) 모델의 요소 설계 원칙

Slides:



Advertisements
Similar presentations
The 3rd Amado Photography Award
Advertisements

ER Schema (추가)
데이터베이스 9주차 : 데이터베이스 설계 2교시 : 데이터베이스 설계(3)
Chapter 7: Entity-Relationship 모델
소프트웨어시스템 실험 Software Systems Lab. (2012년 2학기) 강의 소개
데이터 모델링 방법론 2003년 03월.
4. 데이터 기능 유형.
데이터베이스 시스템.
실전 데이터모델링 & 데이터베이스 설계와 구축
제약 조건 부모 테이블 자식 테이블 입 력 수 정 삭 제  관계형성을 통한 참조 무결성
Chapter 02. 데이터 모델링.
관계 대수와 SQL.
Chapter 5 SQL: 확장된 질의, 주장, 트리거, 뷰.
4장. 관계 대수와 SQL SQL 관계 데이터 모델에서 지원되는 두 가지 정형적인 언어
SQL-99: 스키마 정의, 기본제약조건, 질의어 충북대학교 구조시스템공학과 시스템공학연구실
DBMS실습(I) 데이터베이스 기본개념 2015년 1학기 동서울대학교 컴퓨터소프트웨어과.
Overview : XML과 Database
SQL 개요 SQL 개요 - SQL은 현재 DBMS 시장에서 관계 DBMS가 압도적인 우위를 차지하는 데 중요한 요인의 하나
10장. 데이터베이스 보안과 권한 관리 데이터베이스 보안과 권한 관리
SAP FI – Financial Accounting.
질의처리 최적화 충북대학교 정보통신공학부 복경수
제 3 장 엔티티-관계(ER) 모델을 사용한 데이타 모델링
1 PROJECT TITLE 기획 PAGE NO. 웹 페이지 구성 화 면 번호 화 면 설 명 연 결 화 면 L1 L4 L7
에어로플랜에 가입하기 1. Title Title을 입력한다. 성과 이름을 잘 구분하여 입력한다. 생년월일을 기입한다.
 DBMS의 발전 배경(1) 화일 중심 자료처리(DP)시스템의 한계 ☞ Note
12. 데이터베이스 설계.
관계 데이터 모델과 제약조건 개념, 특성, 키, 무결성 제약조건.
화면(UI) 기반 도메인모델 작성 2014년 8월.
데이터베이스 설계와 ER 모델 설계, ER 모델링.
Data Modeling Database 활용을 위한 기초 이론 Database의 개요 Data Modeling
4.2 SQL 개요 SQL 개요 SQL은 IBM 연구소에서 1974년에 System R이라는 관계 DBMS 시제품을 연구할 때 관계 대수와 관계 해석을 기반으로, 집단 함수, 그룹화, 갱신 연산 등을 추가하여 개발된 언어 1986년에 ANSI(미국 표준 기구)에서 SQL.
ER-Win 사용 방법.
2장. 관계 데이터 모델과 제약조건 관계 데이터 모델은 지금까지 제안된 데이터 모델들 중에서 가장 개념이 단순한 데이터 모델의 하나 IBM 연구소에 근무하던 E.F. Codd가 1970년에 관계 데이터 모델을 제안함 관계 데이터 모델을 최초로 구현한 가장 중요한 관계 DBMS.
Database 소개.
UML exercise in Class.
제 3 장 관계 데이타 모델과 관계 데이타베이스 제약조건
Chapter 3: Introduction to SQL
제 7 장 엔터티-관계를 사용한 개념적 데이타 모델링
설계 단계 개념적 설계 ER 다이어그램 논리적 설계
정보처리기사 8조 신원철 양진원 유민호 이기목 김다연 윤현경 임수빈 조현진.
4. 관계 데이터베이스 (Relational Database)- 7, 8장
ER-Win 4.0 Database Modeling Ⅰ. Logical Design
2장. 관계 데이터 모델과 제약조건 관계 데이터 모델은 지금까지 제안된 데이터 모델들 중에서 가장 개념이 단순한 데이터 모델의 하나 IBM 연구소에 근무하던 E.F. Codd가 1970년에 관계 데이터 모델을 제안함 관계 데이터 모델을 최초로 구현한 가장 중요한 관계 DBMS.
Copyright © 2012 Pearson Education, Inc. Publishing as Prentice Hall
데이터베이스 (Databases) 데이터베이스 소개 문양세 강원대학교 IT대학 컴퓨터과학전공.
1조 김성수 백현기 석광우 김지원 박광연.
ER-관계 사상에 의한 관계 데이터베이스 설계
소프트웨어 공학 Lecture #7: 상세 설계
4. 관계 데이터 모델.
데이터베이스 (Database) 데이터베이스와 데이터베이스 사용자 문양세 강원대학교 IT대학 컴퓨터과학전공.
관계 데이타 모델과 관계 데이타베이스 제약조건 충북대학교 구조시스템공학과 시스템공학연구실
학습목표 학습목표 본 장은 데이터베이스를 구성하는 개체, 속성, 관계 등을 다룬다. 특별히 데이터베이스의 구조를 테이블에 기초하여 조직하는 관계 데이터 모델은 개체(entity)와 관계(relationship) 들이 테이블의 집합 형태로 되어 간단하고 이해하기 쉬우며.
데이터베이스 개발 단계.
                              데이터베이스 설계 및 실습 #8 - ER-Win 한국외국어대학교 DaPS 연구실                              
생체현상계측 ․ 기록장비 이봉준.
제 11 장 자바빈즈를 이용한 JDBC 프로그래밍 학기 인터넷비즈니스과 강 환수 교수.
제 8 장 ER-관계 사상에 의한 관계 데이타베이스 설계
상세 개념적 모델링. 상세 개념적 모델링 정규화를 하는 이유 데이터의 중복성 제거 데이터 모형의 단순화 Entity, Attribute의 누락 여부검증 데이터 모형의 안전성 검증.
1. 관계 데이터 모델 (1) 관계 데이터 모델 정의 ① 논리적인 데이터 모델에서 데이터간의 관계를 기본키(primary key) 와 이를 참조하는 외래키(foreign key)로 표현하는 데이터 모델 ② 개체 집합에 대한 속성 관계를 표현하기 위해 개체를 테이블(table)
데이터베이스 (Database) 관계 대수와 관계 해석 (Part 1) 문양세 강원대학교 IT대학 컴퓨터과학전공.
1장. 서 론 데이터베이스의 개요 모델의 종류 관계형 모델과 객체 지향형 데이터베이스 SQL이란 무엇인가?
4. 데이타베이스 시스템의 구성.
ER-관계 사상에 의한 관계 데이터베이스 설계
IYF ENGLISH VILLAGE Name (이름) English: 한글: Address (주소): Mobile:
ㅎㅎ DTD DTD 개념 DTD 문법 [실습] DTD 활용.
ER-관계 사상에 의한 관계 데이터베이스 설계
2장. 데이터베이스 시스템 개념과 아키텍처 2.1 데이터 모델, 스키마, 인스턴스
CHAPTER 4 관계 데이터 모델과 관계 데이터베이스 제약조건. CHAPTER 4 관계 데이터 모델과 관계 데이터베이스 제약조건.
엔티티-관계(ER) 모델을 사용한 데이터 모델링
Presentation transcript:

2장. E/R 데이터 모델 엔티티-관계성 (Entity-Relationship) 모델의 요소 설계 원칙 제약(constraint)의 모델링 약 엔티티 집합(weak entity set)

데이터베이스 모델링 개요 데이터 모델(data model) 데이터베이스 모델링과 구현 과정 데이터와 데이터들간의 관계를 기술하는 개념적 도구 데이터베이스의 논리적 구조를 명시 데이터베이스 모델링과 구현 과정 E/R 설계 관계 DBMS 릴레이션 스키마 Ideas (개념적 설계) (구현 설계) DBMS 가 E/R 모델을 직접 사용하지는 않음

E/R 모델의 요소 엔티티-관계성(Entity-Relationship:E/R) 다이어그램 E/R 다이어그램의 세 가지 구성요소 데이터베이스 모델링을 그래피컬하게 표현 E/R 다이어그램의 세 가지 구성요소 엔티티 집합(entity set) 유사한 엔티티들의 집합, 엔티티는 객체에 해당 애트리뷰트 (attribute) 엔티티의 특성을 기술하는 값 관계성(relationship) 둘 이상 엔티티 집합들간의 연결

E/R 모델의 요소 (계속) 영화 데이터베이스를 위한 E/R 다이어그램 name address title year Stars-in Stars Movies name Owns length filmType Studios address 영화 데이터베이스를 위한 E/R 다이어그램

E/R 모델의 요소 (계속) E/R 다이어그램의 인스턴스 (instance) 인스턴스: 스키마에 특정 값들이 배정 데이터베이스의 구조 기술: 스키마 인스턴스: 스키마에 특정 값들이 배정 (예) Stars-in 관계성의 한 인스턴스 Movies Stars Basic Instinct Sharon Stone Total Recall Arnold Schwarzenengger Total Recall Sharon Stone

E/R 모델의 요소 (계속) E/R 관계성의 다중연관성(multiplicity) 다대다(many-many) 관계성 다대일(many-one) 관계성 일대일(one-one) 관계성 Movies Stars Stars-in n n Movies Studios Owns n 1 Studios Presidents Runs 1 1

E/R 모델의 요소 (계속) 다중방향(multiway) 관계성 세 개 이상의 엔티티 집합들이 참여하는 관계성 (예) 관계성 Contracts: 영화사가 제작하는 영화에 출연하는 스타와의 계약 Studios Stars Movies Contracts 다중방향 관계성은 그리 흔치는 않다. 이진(binary) 관계성이 일반적

E/R 모델의 요소 (계속) 화살표의 의미 엔티티 E 로 화살표가 있다고 하자. 다른 엔티티 집합들로부터 엔티티를 각각 하나씩 선정하면, E 에는 이들에 대응하는 엔티티가 많아야 하나 존재 이진 관계성에서도 위와 같은 의미

E/R 모델의 요소 (계속) 관계성에서의 역할(role) 한 엔티티 집합이 한 관계성에서 두 번 이상 사용 가능 엔티티는 각 라인(즉, 관계성에의 참여)에 대해 서로 다른 역할 Original (예) 영화의 후속편을 나타내는 관계성 Sequel-of Sequel-of Movies Sequel 관계성에서 두 영화들을 구별하기 위하여, 한 선에는 역할 Original 이 표기, 다른 선에는 역할 Sequel 이 표기

E/R 모델의 요소 (계속) (예) 관계성 Contracts 스타가 소속된 스튜티오는 그 스타가 (다른 스튜디오에서 제작되는) 특정 영화에 출연할 수 있도록 다른 스튜디오와 계약 가능 Studios Contracts Studio of star Producing studio Stars Movies 스타가 소속된 스튜디오 영화를 제작하는 스튜디오 관계성을 나타내는 튜플: (studio1, studio2, star, movie)

E/R 모델의 요소 (계속) 관계성에 있는 애트리뷰트 관계성이 애트리뷰트를 가질 수도 있다 (예) 스타가 영화에 출연할 때 받는 salary 를 표시 Stars Contracts Studios Movies salary 애트리뷰트 salary 는 Studios, Movies, Stars 어느 것의 애트리뷰트도 아님

E/R 모델의 요소 (계속) 애트리뷰트를 반드시 관계성에 위치시키지 않아도 됨 Stars Contracts Studios Movies salary Salaries

E/R 모델의 요소 (계속) 다중방향 관계성을 이진 관계성으로 변환 연결(connecting) 엔티티 집합 생성 다중방향 관계성은 여러 개의이진(binary) 다대일 관계성들로 변환 가능 연결(connecting) 엔티티 집합 생성 다중방향 관계성을 엔티티로 모델 연결 엔티티 집합과 기존 엔티티 집합을 다대일 관계성들에 의한 연결로 모델

E/R 모델의 요소 (계속) (예) 관계성 Contracts: 다중방향 관계성 ® 여러 이진 관계성들 Movies Stars Stars Movies Star-of Movie-of (st1, ct1) (mv1, ct1) Contracts Contracts Studio of star Producing studio Producing studio Studio of star (ct1, sd1) Studios (ct1, sd2) Studios Contracts 관계성: (sd1, sd2, st1, mv1)

E/R 모델의 요소 (계속) 연결 엔티티 집합이 더 적합한 경우 (예) 영화 제작에 임의의 여러 스튜디오들이 참여할 수 있다고 하자. (예) 제작, 특수 효과, 배포 담당 회사 등 Contracts 에 스튜디오들의 집합이 대응 (star, movie, set-of-studios) Contracts 를 다중방향 관계성으로 모델 하면, Contracts 관계성의 한 인스턴스에 대해 studio 들의 집합이 대응 즉, “studio 집합이 하나의 엔티티”인 엔티티 집합이 필요 Contracts 를 연결 엔티티 집합으로 모델 하는 것이 더 적절

E/R 모델의 요소 (계속) Star-of Contracts Stars Movie-of Movies Studios Studios-of Contracts 와 Studios 사이의 관계성은 Many-many

E/R 모델의 요소 (계속) E/R 모델에서의 서브클래스 서브클래스(subclass) isa 관계성 일부 엔티티들이 그 엔티티 집합의 모든 멤버들이 가지고 있지는 않은 특별한 특성을 가질 수도 있음 서브클래스(subclass) 이러한 일부 엔티티들을 별도로 모델 isa 관계성 클래스-서브클래스 관계성 삼각형으로 표시 isa 관계성은 one-one

E/R 모델의 요소 (계속) (예) Cartoons 와 MurderMysteries 를 Movies 엔티티 집합의 서브클래스로 모델 length title year filmType To Stars Movies Voices isa isa weapon Cartoons MurderMysteries

설계 원칙 충실성(faithfulness) 설계는 다루고자 하는 상황을 충실하게 나타내야 함 (예) 관계성 Stars-in 엔티티 집합: Stars, Movies 다중 연관성: many-many 관계성이 적절 (예) 관계성 Teaches 엔티티 집합: Courses, Instructors 다중 연관성: many-one 또는 many-many 학교의 정책에 따라 결정

설계 원칙 (계속) 중복(redundancy) 회피 하나의 사실을 나타내기 위해, 가능한 하나의 정보만을 유지 중복이 있으면, 저장공간 낭비 정보의 비일관성(inconsistency) (예) 영화의 소유권을 가지고 있는 스튜디오 관계성 Owns: 엔티티집합 Movies 와 Studios 애트리뷰트 studioName: 엔티티집합 Movies 의 애트리뷰트

설계 원칙 (계속) 단순화(simplicity) 필요 이상의 요소는 설계에 포함시키지 않음 (예) 특정 영화의 소유권을 나타내는 Holdings 라는 엔티티 집합을 가정해 보자. Movies Repre- sents Holdings Owns Studios 기술적으로 잘못된 점은 없으나, Holdings 는 불필요하게 복잡도만 높임

설계 원칙 (계속) 올바른 관계성의 선택 존재하는 모든 관계성을 모델 하는 것은 부적절 정보 표현의 중복 발생

설계 원칙 (계속) (예) 아래 E/R 다이어그램을 고려해보자. Stars-in title year Stars name address Movies length Contracts filmType Owns Studios address name

설계 원칙 (계속) Owns 관계성이 필요한가 ? 다음의 경우 불필요 Stars-in 관계성의 경우도 이와 유사 각 movie 에는 contract 관계성이 반드시 존재한다. Owns 관계성을 만들어 낼 수 있음 다음의 경우 필요함 movie 에 따라 contract 관계성이 없을 수도 있다고 하자. 예를 들어, 출연하는 스타가 정해지지 않은 경우 Owns 관계성을 만들어 낼 수 없음 관계성의 필요 여부는 예상되는 실제 상황에 따라 결정 Stars-in 관계성의 경우도 이와 유사

설계 원칙 (계속) (예) 아래 E/R 다이어그램을 고려해보자. Stars Stars-in Works- Movies for Owns Studios

설계 원칙 (계속) Works-for 관계성이 필요한가 ? 다음의 경우 불필요 다음의 경우 필요함 Works-for 의 의미 스타가 이 스튜디오의 영화에 출연 Stars-in 과 Owns 로 부터 Works-for 관계성을 만들어 짐 다음의 경우 필요함 영화 출연과 무관

설계 원칙 (계속) 올바른 요소의 선택 실세계의 개념을 모델 애트리뷰트로 표현 ??? 엔티티 집합 / 관계성으로 표현 ???

설계 원칙 (계속) a (예) 아래 E/R 다이어그램에서, 스튜디오 엔티티 집합 대신, 스튜디오의 이름과 주소를 영화의 애트리뷰트로 만들면, title year name length Movies title year filmType name addr Owns a Movies Studios length filmType addr 주소의 반복 (각 영화마다) 어떤 스튜디오가 소유하는 영화가 하나도 없으면, 그 스튜디오의 주소도 잃어 버리게 됨.

설계 원칙 (계속) 스튜디오의 이름뿐만 아니라 주소 등과 같이 좀 더 많은 정보를 필요로 한다면 엔티티 집합으로 만드는 것이 바람직하다. 그러나, 단지 스튜디오 이름만 필요하다면, 애트리뷰트로 만드는 것이 더 좋다.

설계 원칙 (계속) 애트리뷰트로 모델 하는 것이 바람직한 조건 E 와 연관된 관계성은 모두 E 로 부터 one-many (예) Studios 엔티티 집합에서, address 는 name 과 독립 아님, 따라서 조건을 만족하지 않음 E 가 두 번 이상 참가하는 관계성은 없음 (예) Sequel-of 와 같은 관계성이 E 에 있으면 조건 만족 안 함 위 조건들을 만족하면, 엔티티 집합을 애트리뷰트로 대치 가능 many-many 관계성이 있을 때 애트리뷰트로 할 경우, 다중값 발생 애트리뷰트로 할 경우, 정보의 중복 현상 애트리뷰트로 할 경우, 관계성 정보 유실

설계 원칙 (계속) a 엔티티 집합 E 를 애트리뷰트로 대치 관계성 R 이 이진 관계성인 경우 E 의 애트리뷰트를, R 과 연관된 다른 엔티티 집합 F 로 이동 f1 e1 F f1 e1 a R F E

설계 원칙 (계속) a 관계성 R 이 다중방향 관계성인 경우 엔티티 집합 E 를 제거 E 의 애트리뷰트를 관계성 R 의 애트리뷰트로 이동 salary Salaries salary a Contracts Contracts Movies Stars Stars Movies Studios Studios

제약(constraint) 모델링 제약의 분류 제약(constraint) 키(key) 단일 값 (single-value) 제약 실 세계를 올바르게 나타낼 수 있도록 데이터베이스를 유지 제약의 분류 키(key) 엔티티 집합에서 엔티티를 유일하게 구별할 수 있는 하나 또는 둘 이상 애트리뷰트들의 집합 단일 값 (single-value) 제약 중복된 값이 나타나면 안됨

제약 모델링 (계속) 참조 무결성(referential integrity) 제약 도메인(domain) 제약 어떤 다른 객체에 의해 참조되는 값이 데이터베이스에 반드시 존재해야 한다. 도메인(domain) 제약 애트리뷰트의 값이 특정 값의 집합에 속해야 한다. 일반(general) 제약 데이터베이스에서 지켜져야 할 임의의 무결성 단정(assertion)을 말한다.

제약 모델링 (계속) 키(key) E: 엔티티 집합 키: 하나 이상 애트리뷰트의 집합 K E 에 있는 엔티티 e1과 e2 는 키 K를 구성하는 모든 애트리뷰트에 동일한 값을 가질 수 없다. (예) Movies: (title, year), Studios: name, Stars: (name, address) 설계자가 유일한 ID 를 생성해서 사용하기도 함 (예) student-ID, employee-ID

제약 모델링 (계속) 한 엔티티 집합에 둘 이상의 키들이 존재 가능 isa 계층 구조에서 (예) Students 엔티티 집합을 가정해 보자 키: student-ID 와 social-security-number 각각이 키 가능 isa 계층 구조에서 키를 구성하는 모든 애트리뷰트는, 모두 root 엔티티 집합에 존재

제약 모델링 (계속) E/R 모델에서 키의 표현 키에 속하는 애트리뷰트에 밑줄 title year Stars name address Stars-in Movies length filmType E/R 모델은 키가 두 개 이상 존재하는 것을 나타내는 표기법은 제공하지 않는다. 주석 등으로 처리하기도 한다.

제약 모델링 (계속) 단일 값 제약 단일 값을 가지는 애트리뷰트 많아야 하나의 값만 가질 수 있다는 제약 애트리뷰트의 값이 반드시 존재해야 하는 경우 키에 속하는 애트리뷰트 애트리뷰트의 값이 있을 수도 있고, 없을 수도 있는 경우 널(null) 값이 사용될 수도 있음 널 값은 애트리뷰트에 대한 유효한 정보가 없을 때 사용

제약 모델링 (계속) E/R 모델에서 단일 값 제약 표현 각 애트리뷰트는 단일 값을 갖는다고 간주 각 애트리뷰트는 단일 값을 갖는다고 간주 값이 NULL 이 될 수 없다는 표기법은 별도로 없음 many-one 관계성 엔티티 집합 E 로 부터, 엔티티 집합 F 로, (E  F) E 에 있는 엔티티 e 는 단일 값 제약

제약 모델링 (계속) 참조 무결성 제약 관계성에서 참조되는 엔티티는 반드시 존재해야 한다. (예) 관계성 Owns 엔티티 집합 Movies 로 부터 Studios 로 Movie 를 소유하는 studio 가 반드시 존재해야 하는가? 단순한 many-one 관계성은 이 제약을 나타내고 있지는 않음

제약 모델링 (계속) 참조 무결성 제약이 지켜지도록 하기 위한 방법 참조되는 객체의 삭제를 금지 참조되는 객체가 삭제되면, 이 객체를 참조하고 있던 모든 객체도 같이 삭제 관계성의 연결이 변경되면, 새로 연결되는 객체는 반드시 이미 존재하는 객체 참조하는 객체가 새로 만들어 지면, 기존에 존재하는 객체가 관계성으로 연결

제약 모델링 (계속) E/R 다이어그램에서의 참조 무결성 표현 둥근 화살표는 다음을 표시 둥근 화살표 사용 참조 무결성 제약 Owns Runs Movies Studios Presidents

제약 모델링 (계속) 도메인 제약 애트리뷰트의 값은 어떤 제한된 집합에 있어야 함 (예) 애트리뷰트 타입 선언 (예) 0 £ length £ 240

제약 모델링 (계속) 관계성의 차수(degree)에 대한 제약 관계성에 참여하는 엔티티의 수를 제한 에지에 숫자를 기입하여 표시 £ 10 Movies Stars-in Stars 화살표는 “£ 1” 제약 둥근 화살표는 “= 1” 제약

약 엔티티 집합 약 엔티티 집합(weak entity set) 키의 일부 또는 전부가 다른 엔티티 집합에 있는 애트리뷰트들로 만들어진 엔티티 집합 오너(owner) 엔티티 없이는 식별될 수 없음 (예) Studios 의 하부 조직인 Crews 약 엔티티 집합: 지원(supporting) 관계성: Unit-of Studios Crews number name address

약 엔티티 집합 (계속) 약 엔티티 집합의 요인 분류 관점에서 계층구조 상의 하부 조직/분류 (예) Studios 와 Crews (예) “종(species)” 은 “속(genus)” 의 하부 분류 name name Belongs-to Species Genus

약 엔티티 집합 (계속) 연결 엔티티 집합 (예) Contracts: 다중방향 관계성과 연결 엔티티 집합 연결 엔티티 집합의 키 연결시키는 엔티티 집합의 키들이 모여 구성 또는, 설계자가 별도로 키 애트리뷰트 생성 (예) Contracts: 다중방향 관계성과 연결 엔티티 집합 salary Salaries Contracts Movies Studios Stars

약 엔티티 집합 (계속) Contracts Star-of Movie-of Movies Stars Studios salary Studio-of Movie-of length Movies Stars Studios filmType name addr name addr title year

약 엔티티 집합 (계속) 약 엔티티 집합에 대한 요구사항 약 엔티티 집합 W 의 키 약 엔티티 집합 W 관계성 R: 지원 관계성 (supporting relationship) many-one 엔티티 S: 강 엔티티 집합 (strong entity set) 약 엔티티 집합 W 의 키 자신의 애트리뷰트 (종종 없는 경우가 많음) + W 로 부터 관계성 R 로 연결된 엔티티 집합 S 의 키 애트리뷰트

약 엔티티 집합 (계속) 지원 관계성 R 의 조건 R : W 로 부터 S 로 이진 many-one 관계성 one-one 은 many-one 의 특별한 경우 R : W 로 부터 S 로 참조무결성 제약을 가짐 W 의 키의 일부로 사용된 S 의 애트리뷰트는, S 의 키 애트리뷰트 S도 약 엔티티 집합이면, 위의 (1), (2), (3)과정이 S 에 같은 요령으로 적용

숙제 - E/R modeling requirements 회사(Company)의 데이타베이스 요구사항 회사는 여러 부서(DEPARTMENT)들로 구성. 각 부서는 부서명(name), 번호(number), 부서장을 가진다. 부서장의 부임 날짜(start date)도 유지한다. 한 부서는 여러 개의 프로젝트(PROJECT)들을 관리한다. 각 프로젝트는 이름(name)과 번호(number)를 가지며 한 곳(location)에 위치한다. 각 사원(EMPLOYEE)의 주민등록번호(social security number), 주소(address), 월급(salary), 성별(sex), 생년월일(birthdate)을 저장한다. 각 사원은 한 부서에서 근무하며(works for) 여러 프로젝트에 관여한다(work on). 각 사원이 각 프로젝트를 위해 주당 근무 시간을 저장한다. 또한, 각 직원의 직속 상사(direct supervisor)도 유지한다. 각 사원은 여러 명의 부양가족(DEPENDENT)들을 가진다. 각 부양가족에 대해 이름(name), 성별(sex), 생년월일(birthdate), 직원과의 관계(relationship)를 저장한다.