1 3 장. 개체 - 관계 (ER) 모델을 사용한 데이타 모델링 3.1 데이타베이스 설계를 위한 고수준의 개념적 데이타 모델의 사용 3.2 예 3.3 ER 모델의 개념 3.4 개체 - 관계 ( ER ) 다이어그램에 대한 표기법 3.5 스키마 구조물들에 대한 적절한 이름.

Presentation on theme: "1 3 장. 개체 - 관계 (ER) 모델을 사용한 데이타 모델링 3.1 데이타베이스 설계를 위한 고수준의 개념적 데이타 모델의 사용 3.2 예 3.3 ER 모델의 개념 3.4 개체 - 관계 ( ER ) 다이어그램에 대한 표기법 3.5 스키마 구조물들에 대한 적절한 이름."— Presentation transcript:

1 1 3 장. 개체 - 관계 (ER) 모델을 사용한 데이타 모델링 3.1 데이타베이스 설계를 위한 고수준의 개념적 데이타 모델의 사용 3.2 예 3.3 ER 모델의 개념 3.4 개체 - 관계 ( ER ) 다이어그램에 대한 표기법 3.5 스키마 구조물들에 대한 적절한 이름 지정 3.6 3 진 이상의 관계 타입 3.7 요약

2 2 3.1 데이타베이스 설계를 위한 고수준의 개념적 데이타 모델의 사용 [ 그림 3.1] 데이타베이스 설계의 단계들 작은세계 요구사항들의 수집과 분석 데이타베이스 요구사항들 개념적 설계 개념 스키마 ( 고수준 데이타 모델로 표현됨 ) 논리적 설계 ( 데이타 모델 사상 ) 논리적 ( 개념 ) 스키마 ( 특정 DBMS 의 데이타 모델로 표현됨 ) 물리적 설계 내부 스키마 ( 같은 DBMS 에 대한 ) 기능적 요구사항들 기능적 분석 응용 프로그램 설계 트랜잭션 구현 고수준의 트랜잭션 명세 DBMS 에 독립적 DBMS 에 의존 응용 프로그램들

3 3 3.2 예 COMPANY 데이타베이스의 작은 세계 – 회사는 여러 부서들로 구성된다. 각 부서마다 고유한 이름, 고유한 번호, 부서를 관리하는 특정 사원이 있다. 사원이 부서를 관리하기 시작한 날짜도 유지한다. 한 부서는 여러 위치를 가질 수 있다. – 한 부서는 여러 프로젝트들을 관리한다. 각 프로젝트는 고유한 이름, 고유한 번호, 한 개의 위치를 갖는다. – 각 사원에 대해서 이름, 주민등록번호, 주소, 급여, 성별, 생년월일을 저장한다. 한 사원은 한 부서에만 속해 있지만, 여러 프로젝트에서 일할 수 있다. 한 사원이 근무하는 프로젝트들은 그 사원이 소속된 부서가 관리하는 프로젝트가 아니어도 무방하다. 반드시 그 부서의 각 사원이 각 프로젝트를 위해 일하는 주당 근무 시간을 기록한다. 또한 각 사원의 직속 상사도 유지한다. – 보험 목적을 위해서 각 사원의 부양가족들을 기록한다. 각 부양가족에 대해서 이름, 성별, 생년월일, 사원과의 관계를 기록한다.

4 4 FnameMinitLname NameAddress SexSalary Ssn Bdate EMPLOYEE WORKS_FOR StartDate NumberOfEmployees MANAGES SUPERVISION Number Name Locations DEPARTMENT CONTROLS PROJECT Name Location Number Hours WORKS_ON DEPENDENTS_OF DEPENDENT SexNameBirthDateRelationship supervisor 1N supervisee N 1 MN N 1 N 1 11 [ 그림 3.2] COMPANY 데이타베이스를 위한 ER 스키마 다이어그램

5 5 3.3 ER 모델의 개념 3.3.1 엔티티와 애트리뷰트 3.3.2 엔티티 타입, 값집합, 키 애트리뷰트 3.3.3 관계, 역할, 구조적 제약조건 3.3.4 약한 엔티티 타입 ( weak entity type ) 3.3.5 COMPANY 데이타베이스에 대한 ER 설계 개선

6 6 3.3.1 엔티티와 애트리뷰트 사원 엔티티 e 1 과 회사 엔티티 c 1 Name = John Smith Addres = 2311 Kirby, Houston, Texas 77001 Age = 55 HomePhone = 713-749-2630 e1e1 Name = Sunco Oil Headquarters = Houston President = John Smith [ 그림 3.3] 두개의 엔티티와 애트리뷰트들의 값 c1c1

7 7 3.3.1 엔티티와 애트리뷰트 (cont.) 애트리뷰트 유형 – 복합 애트리뷰트 – 단순 ( 원자 ) 애트리뷰트 – 단일값 애트리뷰트 ( 예, 나이 ) – 다치 애트리뷰트 ( 예, 취미 ) – 유도된 애트리뷰트 – 저장된 애트리뷰트 Address StreetAddress City State Zip Number Street ApartmentNumber [ 그림 3.4] 복합 애트리뷰트들의 계층 구조

8 8 3.3.2 엔티티 타입, 값집합, 키 애트리뷰트 n 엔티티 타입 : [ 그림 3.5] 두 엔티티 타입과 이에 속하는 일부 엔티티들 EMPLOYEE Name, Age, Salary COMPANY Name, Headquarters, President 엔티티 타입의 이름 : 애트리뷰트들 : 엔티티 집합 : ( 외연 ) e 1 (John Smith, 55, 80k) e 2 (Fred Brown, 40, 30k) e 3 (Judy Clark, 25, 20k) c 1 (Sunco Oil, Houston, John Smith) c 2 (Fast Computer, Dallas, Bob King)

9 9 키 애트리뷰트 – 그림 3.2 의 COMPANY 엔티티 타입의 Name 애트리뷰트 PERSON 엔티티 타입의 주민등록번호 – 두개 이상의 키 애트리뷰트를 갖는 엔티티 타입 3.3.2 엔티티 타입, 값집합, 키 애트리뷰트 (cont.) CAR Registration(RegistrationNumber, State), VehiclelD, Make, Model, Year, {Color} car 1 ((ABC 123, TEXAS), TK629, Ford Mustang, convertible, 1989, {red, black}) car 2 ((ABC 123, NEW YORK), WP9872, Nissan Sentra, 2-door, 1992, {blue}) car 3 ((VSY 720, TEXAS), TD729, Chrysler LeBaron, 4-door, 1993, {white, blue}) [ 그림 3.6] CAR 엔티티 타입, 다치 애트리뷰트들은 중괄호 { } 안에 나타내고 복합 애트리뷰트의 구성요소 애트립트들은 ( ) 안에 나타냈다.

10 10 값집합 ( 도메인 ) – 각 엔티티에서 해당 애트리뷰트가 가질 수 있는 값들의 집합 – 복합 애트리뷰트와 다치 애트리뷰트의 중첩 {AddressPhone({Phone(AreaCode, PhoneNumber)}, Address(StreetAddress(Number, Street, ApartmentNumber), City, State, Zip) ) } [ 그림 3.7] 다치 애트리뷰트와 복합 애트리뷰트들을 구성요소로 갖는 다치 복합 애트리뷰트 AddressPhone 3.3.2 엔티티 타입, 값집합, 키 애트리뷰트 (cont.)

11 11 COMPANY 데이타베이스의 초기 개념적 설계 – 엔티티 타입 DEPARTMENT 는 Name, Number, Location, Manager, ManagerStartDate 애트리뷰트를 가진다. Location 은 유일한 다치 애트리뷰트이다. Name 과 Number 는 각 부서마다 유일하다고 명시했기 때문에 각각 키 애트리뷰트로 지정할 수 있다 – 엔티티 타입 PROJECT 는 Name, Number, Locations, ControllingDepartment 애트리뷰트들을 가진다. Name 과 Number 가 각각 키 애트리뷰트이다. – 엔티티 타입 EMPLOYEE 는 Name, SSN, Sex, Address, Salary, BirthDate, Department, Supervisor 애트리뷰트들을 가진다. 사용자가 사원 Name 의 각 구성요소 ( FirstName, MiddleInitial, LastName) 와 Address 의 각 구성요소를 참조할 것인지의 여부를 알기 위해서 사용자와 다시 협의해야 한다. – 엔티티 타입 DEPARTMENT 는 Employee, DependentName, Sex, BirthDate, Relationship ( 사원과의 관계 ) 애트리뷰트들을 가진다. 3.3.2 엔티티 타입, 값집합, 키 애트리뷰트 (cont.)

12 12 DEPARTMENT Name, Number, {Locations}, Manager, ManagerStartDate PROJECT Name, Number, Location, ControllingDepartment EMPLOYEE Name(Fname, Minit, Lname), SSN, Sex, Address, Salary, BirthDate, Department, Supervisor, {WorksOn (Project, Hours)} DEPENDENT Employee, DependentName, Sex, BirthDate, Relationship [ 그림 3.8] 3.2 절에서 설명한 데이타베이스를 위한 엔티티 타입들의 초기 설계 다치 애트리뷰트들은 중괄호 { } 안에 나타내고 복합 애트리뷰트들의 구성요소 애트리뷰트들은 ( ) 안에 나타냈다.

13 13 3.3.3 관계, 역할, 구조적 제약조건 n 관계 타입과 관계 인스턴스 관계 타입 R 은 엔티티 타입들에 속하는 엔티티들 간의 연관들의 집합 e1e1 e3e3 e4e4 e5e5 e6e6 e7e7 e2e2 r5r5 r4r4 r3r3 r2r2 r1r1 r6r6 r7r7 r7r7 r7r7 r7r7 EMPLOYEE WORKS_FOR DEPARTMENT [ 그림 3.9] WORKS_FOR 관계의 일부 인스턴스들

14 14 관계 타입의 차수 ( degree ) : 참여하고 있는 엔티티 타입들의 개수 – 이진 ( binary ) 차수 : [ 그림 3.9] 의 WORKS_FOR 관계 –3 진 ( ternary) 차수 3.3.3 관계, 역할, 구조적 제약조건 (cont.) r5r5 r4r4 r3r3 r2r2 r1r1 r6r6 r7r7 j1j1 j2j2 j3j3 s1s1 s2s2 p1p1 p2p2 p3p3 [ 그림 3.10] 3 진 관계 SUPPLY

15 15 애트리뷰트로서의 관계 : 애트리뷰트의 관점에서 관계 타입을 생각하는 것이 편리 역할 이름과 순환적 ( recursive ) 관계 3.3.3 관계, 역할, 구조적 제약조건 (cont.) e5e5 e4e4 e3e3 e2e2 e1e1 e6e6 e7e7 r5r5 r4r4 r3r3 r2r2 r1r1 r6r6 EMPLOYEESUPERVISION 2 1 2 1 2 1 2 1 1 2 1 2 [ 그림 3.11] 순환적 관계 SUPERVISION:EMPLOYEE 는 상사 (1) 와 부하 (2) 의 두 역할을 함

16 16 관계 타입에서 제약조건 – 카디날리티 비율 : 엔티티가 참여할 수 있는 관계 인스턴스들의 수 ( 이진 관계 타입에 대한 카디날리티 비율은 1:1, 1: N, M:N ) – 참여 제약조건 : 한 엔티티의 존재가 관계 타입을 통해 연관되어 있는 다른 엔티티에 의존하는지의 여부 EMPLOYEE MANAGESDEPARTMENT e1e1 e6e6 e5e5 e4e4 e3e3 e2e2 e7e7 r3r3 r2r2 r1r1 d1d1 d2d2 d3d3 [ 그림 3.12] EMPLOYEE 가 부분 참여하고 DEPARTMENT 가 전체 참여하는 1:1 관계 MANAGES 3.3.3 관계, 역할, 구조적 제약조건 (cont.)

17 17 관계 타입의 애트리뷰트 –1:1, 1:N 관계 타입의 애트리뷰트 MANAGES 의 StartDate[ 그림 3.12] WORKS_FOR 의 StartDate[ 그림 3.9 ] –M:N 관계 타입 EMPLOYEE WORKS_ON PROJECT r1r1 r2r2 r3r3 r4r4 r5r5 r6r6 r7r7 e1e1 e2e2 e3e3 e4e4 p1p1 p2p2 p3p3 p4p4 [ 그림 3.13] M:N 관계 WORKS_ON 3.3.3 관계, 역할, 구조적 제약조건 (cont.)

18 18 3.3.4 약한 엔티티 타입 (weak entity type) 자신의 키 애트리뷰트가 없는 엔티티 타입 식별 소유자, 식별 관계 EMPLOYEE:DEPENDENT 부분 키 DEPENDENT 의 DependentName

19 19 3.3.5 COMPANY 데이타베이스에 대한 ER 설계 개선 그림 3.8 의 애트리뷰트들을 관계 타입으로 변환하여 개선 관계 타입들 –MANAGES : EMPLOYEE 와 DEPARTMENT 사이의 1:1 관계 타입 –WORKS_FOR : DEPARTMENT 와 EMPLOYEE 사이의 1:N 관계 타입 –CONTROLS : DEPARTMENT 와 PROJECT 사이의 1:N 관계 타입 – SUPERVISION : EMPLOYEE ( 상사역할 ) 와 EMPLOYEE ( 사원역할 ) 사이의 1:N 관계 타입 –WORKS_ON : EMPLOYEE 와 PROJECT 사이의 M:N 관계 타입 –DEPENDENTS_OF :EMPLOYEE 와 DEPENDENT 사이의 1:N 관계 타입

20 20 3.4 개체 - 관계 (ER) 다이어그램에 대한 표기법 기호의미 기호 엔티티 타입 약한 엔티티 타입 관계 타입 식별 관계 타입 애트리뷰트 키 애트리뷰트 다치 애트리뷰트... E1 R E2 E1 R E2 R ( 최소값, 최대값 ) E 복합 애트리뷰트 유도된 애트리뷰트 E 가 R 에 전체 참여 E 이 R 에 부분 참여 R 에서 E:E 의 카디날리티 비율이 1:N R 에서 E 의 참여에 대한 구조적 제약조건 ( 최소값, 최대값 ) [ 그림 3.15] ER 다이어그램의 표기법 요약

21 21 FnameMinitLname Name Address Sex Salary Ssn Bdate EMPLOYEE WORKS_FOR StartDate NumberOfEmployees MANAGES SUPERVISION Number Name Locations DEPATMENT CONTROLS PROJECT Name Location Number Hours WORKS_ON DEPENDENTS_OF DEPENDENT SexNameBirthDateRelationship supervisor supervisee (0,N) employee (4,N) department (0,1) manager (1,1) department- managed controlling- department (0,N) controlled- project (1,1) (1,N) project (0,1) (0,N) employee dependent (1,1) (1,N) worker [ 그림 3.14] 모든 역할 이름들을 포함시키고, 관계에 대한 구조적 제약조건들을 ( 최소값, 최대값 ) 형식으로 명시한 COMPANY 스키마의 ER 다이어그램 (1, 1)

22 22 3.5 스키마 구조물에 대한 적절한 이름 지정 스키마에 사용된 각 구조물에 대해 가능한 한 그 의미를 전달할 수 있는 이름 선택 복수보다 단수 이름 선택 일반적으로 요구사항들의 명사는 엔티티 타입 이름, 동사는 관계 타입 이름으로 ER 다이어그램의 왼쪽에서 오른쪽, 위에서 아래로 읽기 쉽게

23 23 3.6 3 진 이상의 관계 타입 (a) (b) SName SUPPLIER SUPPLYPROJECT PART PartNo QuantityProjName SName SUPPLIERSUPPLIESPROJECT CAN_SUPPLY PartNo PART USE ProjName M N MN M N [ 그림 3.16] 3 진 관계 타입들 (a) 3 진 관계 타입 SUPPLY (b) 3 진 관계 타입 SUPPLY 와 동치가 아닌 세 개의 이진 관계 타입

24 24 (c) SName QuantityProjName PartNo SUPPLIERSS SUPPLYSPJPROJECT SP PART 1 NN 1 N 1 [ 그림 3.16] 3 진 관계 타입들 ( cont.) (c) 약한 엔티티 타입으로 표현된 SUPPLY

25 25 IName SemesterYear Sem_Year CNumber INSTRUCTOR TAUGHT_DURING OFFERS SEMESTER CAN_TEACH COURSE OFFERED_DURING [ 그림 3.17] 3 진 대 이진 관계 타입들의 또 다른 예

26 26 Name CName Department Date Dept/Date CANDIDATECCICOMPANY INTERVIEW RESULTS_INJOB_OFFER [ 그림 3.18] 3 진 식별 관계 타입을 갖는 약한 엔티티 타입 INTERVIEW

27 27 3.7 요약 엔티티 - 관계 (ER) 모델을 사용한 모델링 개념 스키마 레벨에서 ER 모델 개념 ER 다이어그램 3 진 관계와 그 이상 차수의 관계 타입