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)를 저장한다.