제 3 장 개체 - 관계 (ER) 모델을 사용한 데이타 모델링 Fundamentals of Database Systems R. A. Elmasri and S. B. Navathe Copyright© 2002 황규영 홍의경 음두헌 박영철 김진호 조완섭.

Presentation on theme: "제 3 장 개체 - 관계 (ER) 모델을 사용한 데이타 모델링 Fundamentals of Database Systems R. A. Elmasri and S. B. Navathe Copyright© 2002 황규영 홍의경 음두헌 박영철 김진호 조완섭."— Presentation transcript:

1 제 3 장 개체 - 관계 (ER) 모델을 사용한 데이타 모델링 Fundamentals of Database Systems R. A. Elmasri and S. B. Navathe Copyright© 2002 황규영 홍의경 음두헌 박영철 김진호 조완섭

2 Ch32Fundamentals of Database Systems 3.1 데이타베이스 설계를 위한 고수준 개념적 데이타 모델의 사용 3.2 데이타베이스 응용 예제 3.3 개체 타입, 개체 집합, 애트리뷰트, 키 3.4 관계, 관계 타입, 역할, 구조적 제약조건 3.5 약한 엔티티 타입 (Weak Entity Type) 3.6 COMPANY 데이타베이스에 대한 ER 설계의 개선 3.7 ER 다이어그램, 명명에 관한 규칙, 설계에 관한 사항 3.8 요약 목 차목 차 목 차목 차

3 Ch33Fundamentals of Database Systems 개념적 모델링은 데이타베이스 설계에 있어 중요한 단계임 이 장에서는 개체 - 관계 (Entity-Relationship: ER) 모델을 사용한 개념적 모델링 기법 소개함 개 요개 요 개 요개 요

4 Ch34Fundamentals of Database Systems 3.1 DB 설계를 위한 고수준의 개념적 데이타 모델 사용 [ 그림 3.1] 데이타베이스 설계의 단계들 작은 세계 요구사항들의 수정과 분석 데이타베이스 요구사항들 개념적 설계 개념 스키마 ( 데이타 모델 사상 ) LOGICAL DESIGN (DATA MODEL MAPPING) Logical (Conceptual) Schema (In the data model of a specific DBMS) PHYSICAL DESIGN Internal Schema (For the same DBMS) Functional Requirements FUNCTIONAL ANALYSIS APPLICATION PROGRAM DESIGN TRANSACTION IMPLEMENTATION High-level Transaction Specification DBMS-independent DBMS-specific Application Programs

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

6 Ch36Fundamentals of Database Systems 개념적 설계의 결과

7 Ch37Fundamentals of Database Systems ER 모델은 데이터를 엔티티 ( 개체 ), 관계, 에트리뷰트 ( 속성 ) 로 모델링함 엔티티와 애트리뷰트 – 엔티티 : 실세계에서 독립적으로 존재하는 실체 – 애트리뷰트 : 엔티티를 기술하는 속성 3.3 개체 타입, 개체 집합, 애트리뷰트, 키 [ 그림 3.3] 두 개의 엔티티 ( 직원 e 1 과 회사 c 1 ) 와 애트리뷰트 및 값 Name = John Smith Address = 2311 Kirby, Houston, Texas 77001 Age = 55 HomePhone = 713-749-2630 e1e1 Name = Sunco Oil Headquarters = Houston President = John Smith c1c1

8 Ch38Fundamentals of Database Systems 애트리뷰트 유형 – 복합 애트리뷰트 – 단순 애트리뷰트 [ 그림 3.4] 복합 애트리뷰트의 계층구조 – 단일 값 애트리뷰트 – 다치 애트리뷰트 – 저장된 애트리뷰트 – 유도된 애트리뷰트 Address StreetAddress City State Zip Number Street ApartmentNumber 3.3 개체 타입, 개체 집합, 애트리뷰트, 키

9 Ch39Fundamentals of Database Systems 널 값 – 두가지로 사용됨 ; ‘ 적용할 수 없음 ’ 이라는 의미와 ‘ 알려지지 않음 ’ 의 의미 복합 (composite) 애트리뷰트 {AddressPhone({Phone (AreaCode, PhoneNumber)}, Address(StreetAddress(Number, Street,ApartmentNumber), City, State, Zip ) } [ 그림 3.5] 다치와 복합 구성요소를 가지는 복합 애트리뷰트 AddressPhone 3.3 개체 타입, 개체 집합, 애트리뷰트, 키

10 Ch310Fundamentals of Database Systems 개체 ( 엔티티 ) 타입 : 개체집합 [ 그림 3.6] 두 개체 타입과 이에 속하는 개체들 개체 타입의 이름 : 애트리뷰트 이름 개체 집합 ( 외연 ) 애트리뷰터 값 e1 (John Smith, 55, 80k) e2 (Fred Brown, 40, 30K) e3 (Judy Clark, 25, 20K) : c1 (Sunco Oil, Houston, John Smith) c2 (Fast Computer, Dallas, Bob King) : EMPLOYEE COMPANY Name, Age, Salary Name, Headquarters, President 3.3 개체 타입, 개체 집합, 애트리뷰트, 키

11 Ch311Fundamentals of Database Systems [ 그림 3.7] CAR 개체 타입 CAR Registration(RegistrationNumber, State), VehicleID, Make, Model, Year, {Color} car1 ((ABC 123, TEXAS), TK629, Ford Mustang, convertible, 1989, {red,black}) car2 ((ABC 123, NEW YORK), WP9872, Nissan Sentra, 2-door, 1992, {blue}) car3 ((VSY 720, TEXAS), TD729, Chrysler LeBaron, 4-door, 1993, {white, blue}) : 3.3 개체 타입, 개체 집합, 애트리뷰트, 키

12 Ch312Fundamentals of Database Systems 키 애트리뷰트 – 각 엔티티마다 서로 다른 값을 가지는 애트리뷰트 – 그림 3.2 에서 COMPANY 엔티티 타입에서 키 애트리뷰트는 Name PERSON 엔티티 타입의 키 애트리뷰트는 SocialSecurityNumber – 복합키 두 개 이상의 애트리뷰트들이 모여서 하나의 키 애트리뷰트 역할을 하는 키 값 집합 ( 도메인 ) – 각 엔티티에서 애트리뷰트가 가질 수 있는 값들의 집합 EMPLOYEE 의 Age 애트리뷰트의 값 집합은 ? (16 부터 70 사이의 정수 집합 ) 3.3 개체 타입, 개체 집합, 애트리뷰트, 키

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

14 Ch314Fundamentals of Database Systems 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 절의 데이타베이스를 위한 엔티티 타입들의 초기 설계

15 Ch315Fundamentals of Database Systems 관계 타입과 관계 인스턴스 – 관계 타입 ( 관계 집합 ) R 은 엔티티 간의 연관들의 집합임 : 그림 3.9 에서 WORKS_FOR –[ 그림 3.9] 관계 WORKS_FOR 에서 관계 인스턴스 : 7 개 (r1 ~ r7) 3.4 관계, 관계 타입, 역할, 구조적 제약조건 e1 e2 e3 e4 e5 e6 e7. r1 r2 r3 r4 r5 r6 r7 : d1 d2 d3. EMPLOYEE WORKS_FOR DEPARTMENT

16 Ch316Fundamentals of Database Systems 관계 타입의 차수 (degree): 관계에 참여하고 있는 엔티티 타입의 수 – 이진 (binary) 차수 : [ 그림 3.9] 의 WORKS_FOR 관계 –3 진 (ternary) 차수 : [ 그림 3.10] 3 진 관계 SUPPLY 3.4 관계, 관계 타입, 역할, 구조적 제약조건 r1 r2 r3 r4 r5 r6 r7 : s1 s2. p1 p2 p3. j1 j2 j3. SUPPLIER PART PROJECTSUPPLY [ 그림 3.10] 삼진관계 SUPPLY

17 Ch317Fundamentals of Database Systems 애트리뷰트로서의 관계 : 관계는 참여 엔티티 타입의 속성으로 볼 수도 있음 예 : (EMPLOYEE 의 Department 또는 DEPARTMENT 의 Employees) 역할과 순환적 (recursive) 관계 [ 그림 3.11] Employee 에서의 순환적 관계 SUPERVISION 은 상사 (1) 와 부하 (2) 의 두 역할로 구분할 수 있음 3.4 관계, 관계 타입, 역할, 구조적 제약조건 e1 e2 e3 e4 e5 e6 E7... r1 r2 r3 r4 r5 r6... 2 1 2 1 2 1 2 1 1 1 2 2 EMPLOYEESUPERVISION

18 Ch318Fundamentals of Database Systems 관계 타입에서 제약조건 – 카디날리티 비율 : 관계 인스턴스에 참여하는 엔티티의 개수의 비율 ( 이진 관계 타입에 대한 카디날리티 비율은 1:1, 1:N, M:N) – 참여 제약조건 : 한 엔티티의 존재가 관계 타입을 통해 연관되어 있는 다른 엔티티에 의존하는지의 여부 ( 부분참여와 전부참여 ) –MANAGER 관계 : EMPLOYEE 는 부분 참여하고, DEPARTMENT 는 전부 참여함 e1 e2 e3 e4 e5 e6 e7. r1 r2 r3 : d1 d2 d3 : EMPLOYEE MANAGES DEPARTMENT 3.4 관계, 관계 타입, 역할, 구조적 제약조건

19 Ch319Fundamentals of Database Systems 관계 타입의 애트리뷰트 –1:1, 1:N 관계 타입의 애트리뷰트 MANAGES 의 StartDate [ 그림 3.12], WORKS_FOR 의 StartDate[ 그림 3.9] –M:N 관계 타입 WORKS_ON 의 Hours [ 그림 3.13] –[ 그림 3.13] M:N 관계 WORKS_ON e1 e2 e3 e4. r1 r2 r3 r4 r5 r6 R7. p1 p2 p3 p4. EMPLOYEE WORKS_ON PROJECT 3.4 관계, 관계 타입, 역할, 구조적 제약조건

20 Ch320Fundamentals of Database Systems 자신의 키 애트리뷰트가 없는 엔티티 타입 – 예 : DEPENDENT 엔티티 타입 식별 ( 소유 ) 엔티티 타입과 식별 관계 –EMPLOYEE 와 DEPENDENT 에서 EMPLOYEE 가 식별 엔티티 타입이며, 두 엔티티 타입 사이의 관계를 식별 관계라고 부름 부분 키 – 동일한 소유 엔티티와 연관된 약한 엔티티 집합 내의 서브 집합 ( 예를들어 소유 엔티티 employee e1 의 dependents set) 내에서 서로를 구분할 수 있는 애트리뷰트들의 집합 ( 예를들어, Dependent.name) 약한 엔티티는 소유 엔티티 타입의 복합 속성으로 표현될 수도 있으나 다음의 경우에는 별도의 엔티티 타입으로 표현하는 것이 바람직함 (1) 엔티티가 많은 애트리뷰트들을 가지고, (2) 식별 관계 타입 외에 다른 관계 타입들에 독립적으로 참여하는 경우 3.5 약한 엔티티 타입 (Weak Entity Type)

21 Ch321Fundamentals of Database Systems 그림 3.8 에서 관계를 나타내는 애트리뷰트들을 관계 타입으로 변환하여 발전시킴 생성되는 관계 타입들 1.MANAGES : EMPLOYEE 와 DEPARTMENT 사이의 1:1 관계 타입 2.WORKS_FOR : DEPARTMENT 와 EMPLOYEE 사이의 1:N 관계 타입 3.CONTROLS : DEPARTMENT 와 PROJECT 사이의 1:N 관계 타입 4.SUPERVISION : EMPLOYEE( 상사역할 ) 와 EMPLOYEE( 사원역할 ) 사이의 1:N 관계 타입 5.WORKS_ON : EMPLOYEE 와 PROJECT 사이의 M:N 관계 타입 6.DEPENDENTS_OF :EMPLOYEE 와 DEPENDENT 사이의 1:N 관계 타입 3.6 COMPANY DB 에 대한 ER 설계의 개선

22 Ch322Fundamentals of Database Systems [ 그림 3.14] ER 다이어그램의 표기법 요약 3.7 ER 다이어그램, 명명에 관한 규칙, 설계에 관한 사항 SymbolMeaning Symbol 엔티티 타입 약한 엔티티 타입 관계 타입 식별 관계 타입 애트리뷰트 키 애트리뷰트 다치 애트리뷰트... E1 R E2 E1 R E2 R ( 최대값, 최소값 ) E 복합 애트리뷰트 유도된 애트리뷰트 E1 이 R 에 전체참여 E2 가 R 에 부분참여 R 에서 E1:E2 의 카디날리티 비율이 1:N R 에서 E 의 참여에 대한 구조적 제약조건 ( 최대값, 최소값 ) 1N

23 Ch323Fundamentals of Database Systems 스키마에 사용된 각 구조물에 대해 가능한 한 그 의미를 전달할 수 있는 이름 선택 복수보다 단수 이름 선택 일반적으로 자연어로 기술된 요구 사항에서 명사는 엔티티 타입 이름, 동사는 관계 타입 이름으로 해석하는 것이 도움이 됨 ER 다이어그램은 왼쪽에서 오른쪽, 위에서 아래로 읽기 쉽게 작성함 스키마 설계는 반복해서 개선하는 작업이 필요함 – 한번에 완성하기는 쉽지 않음 다음 TP 에서는 ER 다이어그램의 또 다른 표기법 소개 3.7 ER 다이어그램, 명명에 관한 규칙, 설계에 관한 사항

24 Ch324Fundamentals of Database Systems [ 그림 3.15] 모든 역할 이름들을 포함시키고, 관계에 대한 구조적 제약 조건들을 ( 최소값, 최대값 ) 형식으로 명시한 COMPANY 스키마의 ER 다이어그램

25 Ch325Fundamentals of Database Systems 엔티티 - 관계 (ER) 모델을 사용한 모델링 개념 – 엔티티 ( 개체 ) 와 관계의 정의 스키마 레벨에서 ER 모델 개념 관계 타입의 구조적 제약조건 ER 다이어그램 3.8 요 약