5. E-R model

디자인 단계

 

1. 데이터베이스 사용자의 관점에서 필요한 데이터들을 구체화하기

 

2. 디자인 모델 고르기

• 고른 데이터 모델의 콘셉트 선택
• 요구사항들을 데이터베이스의 스키마 콘셉트에 맞게 옮기기

 

3. 논리적 디자인 - 스키마 결정

• 어떤 속성이 데이터베이스에 기록되어야 하나?
• 어떤 스키마가 필요하고 어떻게 속성을 다른 스키마와 구별할 수 있을까?

물리적 디자인 - 물리적 배치 결정

 

 

* 스키마를 디자인할 때 두 가지를 피해야 한다.

• Redundancy(중복) : 여러 곳에 반복되어 저장되는 정보들 -> 일관성을 헤침
• Incompleteness(불완전성) : 새로운 걸 넣기 어렵거나 불가능.

 

---

entity: 다른 객체와 구별가능한 존재하는 객체  예) 구체적 사람, 회사 등

entity set: 같은 특징을 공유하는 entity의 집합  예) 사람들, 회사들 등

 

entity는 속성의 집합으로 표현 가능

예) instructor=(ID, name, salary)

 

 

E-R Diagram

 

1. Entity sets

• 직사각형으로 표현
• 속성들은 안에 작성
• primary key 속성은 밑줄로 표시

 

 

2. Relationship sets

: 엔티티들 사이의 관계

예)

 

 

• 다이아몬드로 표현

• 속성을 가진 Relationship Sets는 위와 같이 표현

 

 

• 하나의 엔티티가 관계를 맺을 경우 위와 같이 표현
  예) 후수과목, 선수과목

 

 

Degree: 차수, 관계를 기준으로 엔티티와 연결된 선의 개수.

Degree가 2라면 Binary relationship이라 한다.

-> 두개의 엔티티 집합을 가짐.

 

 

 

3. 속성

• simple attributes: 속성이 1개
  composite attiributes: 속성이 여러 개
  
  

 

• single-valued attirbutes: 속성값이 1개
  multivalued attributes: 속성값이 여러 개
• derived attributes: 파생 속성, 다른 속성들로부터 계산할 수 있는 속성
  예) 나이

도메인: 각 속성에 허용되는 값의 집합

 

 

• name, address는 composite 속성
• phone_number는 multivalued 속성
• age는 파생 속성

 

---

 

Mapping Cardinality

 

• one to one
• one to many
• many to many

* many라고 해서 무조건 여러 개가 아님. 0개이거나 1개일 수 있음.

 

 

many는 그냥 실선으로 표시.

one은 화살표로 표시.

 

 

 

Total participation : 필참(무조건 1개 이상)

 

필참은 실선 두줄로 표시.

 

 

 

 

instructor는 0개부터 무한개까지 가능

student는 1개부터 1개까지 가능 -> 즉 1개 필참

many to one 관계.

 

 

 

primary key

• many-to-many는 양쪽에 primary key가 무조건 있어야 함
• one-to-many는 many 쪽에 primary key가 무조건 있어야 함
• one-to-one은 어디 있든 상관없음

* many 쪽엔 무조건 있어야 구별 가능하므로

 

 

 

 

Weak Entity Sets

section 엔티티에도 course_id가 있어서 중복이 발생.

중복을 제거하기 위해 course_id 속성 제거.

이때 남은 속성들만으로는 특정 section을 고유하게 식별할 수 없는 문제 발생.

이를 해결하기 위해 section은 weak entity로 정의 -> 두 줄 직사각형

course는 identifying entity로 정의

관계 sec_course는 identifying relationship(식별 관계)로 정의 -> 두 줄 마름모

이렇게 함으로써 중복을 피하면서도 section 엔티티 자체로 부족한 식별 능력을

course 엔티티가 보완해 주는 방식이다. 

* 후에 관계형 스키마를 만들 때는 section 엔티티에 course_id 속성이 부활하게 됨.

이유는 나중에.

 

 

 

이런 경우는 예외다.

 

student 엔티티의 dept_name 속성이 없다 해도 고유하게 식별 가능하다.

-> ID 속성으로.

이런 경우는 weak entity가 아니다.

weak entity가 아닌 건 다 strong entity이다.

 

 

---

 

<스키마로 변환하기>

 

• weak entity는 스키마로 변환할 때
  identifying entity의 primary key가 추가돼서 생성된다.
  예) section(course_id, sec_id, semester, year)
• composite attribute(복합 속성)은 하위 속성들로만 생성된다.
  또한 multivalued attribute(다중 속성)은 무시된다.
  -> 별도의 스키마로 생성된다.
  
  

예) 

 

instructor(ID,
first_name , middle_initial , last_name
street_number , street_name ,apt_number,
city, state, zip_code ,
date_of_birth)

 

inst_phone ( ID , phone_number)

 

 

• many-to-many 관계 집합은 두 엔티티의 primary key들로 이루어진다.

예)

 

 

• many-to-one 관계 집합은 별도의 스키마를 생성하지 않아도 된다.
  -> 대신 many 쪽 엔티티에 one 쪽 기본키를 속성으로 추가
• one-to-one 관계 집합도 마찬가지로 별도 생성하지 않아도 됨
  -> 어느쪽이든 many 쪽 엔티티 역할을 맡아서 one 쪽 기본키를 속성을 추가
  * 그러나 만약 many 쪽 엔티티 역할을 맡은 엔티티의 값이 부분적(null 값이 있음)이라면
  별도의 스키마를 만들어도 된다.

 

 

표기법

 

 

 

 

설계 이슈

1. 엔티티와 속성의 구분

• 엔티티와 속성을 적절히 구분하는 것이 중요하다.
• 예를 들어 전화번호는 속성이 아닌 별도의 엔티티로 모델링하는 것이 좋다.

전화번호는 multivalued 속성이므로

 

 

2. 관계와 속성의 구분

• 관계와 속성을 구분하는 것이 중요하다. 예를 들어 학생과 지도교수의 관계에서 관계 속성인 "지도일자"는
  관계 엔티티로 모델링하는 것이 좋다.

 

 

 

3. 강엔티티 vs 약엔티티

• 약 엔티티 집합을 사용하면 중복을 피할 수 있고 관계 모델링이 더 자연스러워진다.