[데이터베이스] E-R modeling

본 게시물은 데이터베이스 과목의 강의영상과 강의자료를 바탕으로 작성한 학습용 게시물입니다.

---

데이터베이스 설계 순서 (database design phases)

1. 개념적 데이터 모델링 (conceptual data modeling)

• E-R modeling
• E-R 다이어그램 

2. 논리적 데이터베이스 설계 (logical database design)

• 관계형 데이터베이스 설계 (relational database design)
• 테이블 스키마 (tabla schemes)

3. 물리적 데이터베이스 설계 (physical database design)

• 성능 관점 : 데이터를 효과적으로 저장하고 인덱싱하는 방법
• 저장 구조(storage scheme)
• 테이블 인덱스 (table indexes)

---

E-R model

• 개념의 집합 (a set of concepts) 
  - 개념 : 엔티티, 관계, 속성
• 개념적 스키마를 만드는 데 사용할 수 있는 그래픽 기호 
  - 그래픽 기호 : E-R 다이어그램
• original E-R model - Peter Chen (1976)
• Crow's foot notanion - Gordon Everest (1976)

E-R diagram by Peter Chen

---

Crow's foot Notation

< 개체 표현 >

< 관계 표현 >

---

Entities (개체)

• 식별 가능(can be indentified)하고, 유저가 추적하고자 하는 것
• Enitity class
  : 주어진 유형의 entity 모음 (a collection of entities of a given type)
• Entity instance
  : 특정 entity의 발생 (the occurence of a paticulat entity)
• 일반적으로 entity class에는 많은 entity instance

---

Identifiers (식별자)

• entity instance의 이름을 지정하거나 식별하는 속성
• entity instance의 식별자는 entity의 애트리뷰트 중 하나 이상으로 구성
• 데이터 모델에서의 식별자는 데이터베이스 설계에서의 key가 된다. ( 특히, 기본키)
  - entitys have identifiers
  - tables (or relations) have keys

---

Relationships (관계)

• 개체는 관계에서 서론 연관 될 수 있다.
• 원래 E-R 모델에서 관계는 애트리뷰트를 가질 수 있었지만, 최근에는 더 이상 수행 x
• 관계 클래스에는 둘 이상의 개체 클래스 포함가능
• degree : 관계의 개체 클래스 수
  - degree 2 : 두 개체가 이진 관계 
  - degree 3 : 세 개체가 삼항 관계
• 개체와 테이블(관계)의 주요 차이점은 외래 키를 사용하지 않고도 개체 간 관계 표현가능 
  - 개체의 존재와 개체 간의 관계가 불확실한 초기 설계 프로세스에서 개체 작업이 더 쉬워짐

---

Cardinality in Relationship 

• cardinality : 개수, 숫자로 표현됨
• Maximum cardinality : 관계에 참여할 수 있는 최대 entity instance 수
  - One-to-One [1:1]  ex) 직원 한 명당 하나의 명찰
  - One-to-Many [1:N]  ex) 직원 한 명이 여러 대 컴퓨터  (현실에서 가장 많음)
  - Many-to-Many [N:M]  ex) 직원 여러명의 여러 능력
• Minimum cardinality : 관계에 참여해야하는 최소 entity instance 수
  - zero(0) : entity에 의한 관계 참여는 선택 사항, 관계에 참여하는 entity instance가 없어도 o
  - one(1) : 적어도 하나의 entity instance가 관계에 참여해야함

모든 EMPLOYEE는 반드시 BADGE 있어야함

직원 중 컴퓨터 없는 직원 있을 수 있음 / 컴퓨터 중 연결된 직원 없는 컴퓨터 있을 수 있음 

직원 중 SKILL 없는 직원 있을 수 있음 

Parent and Child Entites

• parent entity / parent : 일 대 다(one-to-many) 관계에서 일(one)에 속하는 entity 
• child entity / child : 일 대 다(one-to-many) 관계에서 다(many)에 속하는 entity 

EMPLOYEE : parent, COMPUTER : child

---

ID-Dependent Entites

• 식별자에 다른 entity(parent)의 식별자가 포함된 entity(child)
• parent가 없다면 child 생성 x 
• parent의 논리적 확장 (logical extension)이나 서브 유닛(sub-unit)
• 반드시 parnet 있어야함 (minimum cardinality : 1 )

식별관계 표현

비식별관계 표현

1대 n 어떤 BUILDING은 APARTMENT 연결 x	1대 n 어떤 PAINTING은 PRINT 연결 x	1 대 n 모든 환자는 진료 반드시 연결

 

---

Weak Entities (약한 개체)

• 다른 개체에 의존하여 존재하는 개체
• 모든 ID-Dependent entity는 weak entity
• non-ID-dependent entity 중 weak entity 있음 
• parnet의 식별자는 weak child entity의 식별자에 나타나지 x
• 특정 표기법 x

AUTO는 weak & non ID_dependent 

---

Strong Entity Patterns

1대 1 / 비식별관계
1대1 / 비식별 LOCKER 연결 안 된 MEMBER 존재가능 MEMBER 연결 안 된 LOCKER 존재가능	일 대 다 . 비식별  DEPARTMENT 연결 안 된 COMPANY 존재 가능	다 대 다 / 비식별 DEPARTMENT 연결 안 된 COMPANY 존재 가능  PART 연결 안 된 COMPANY 존재 가능

---

ID-Dependent Relationships : The Association Pattern 

• PART와 COMPANY의 연결에 따라 달라지는 price 속성
• price 속성을 PART에 추가할 것인가? COMPANY에 추가할 것인가?

• PART와 COMPANY를 식별 상속 해 새로운 개체 생성
• 연관패턴에 대한 ID 종속 개체의 생성

---

ID-Dependent Relationships : The Mulivalude Attribute Pattern

• 여러개가 존재 가능한 PhoneNumber 속성
• PHONE 개체 따로 생성

COMPANY는 각진 사각형 PHONE은 둥근 사각형 

• 여러개가 존재 가능한 PhoneNumber와 CONTACT 속성
• PHONE과 CONTACT 개체 따로 생성

COMPANY는 각진 사각형 PHONE과 CONTACT는 둥근 사각형

 

---

D-Dependent Relationships : The Archetype/Instance Pattern

• 원형 / instance
• ID-dependent child 개체가 추상 또는 논리적 parent의 물리적 표현(instance)일 때 발생 

식별의존 관계  : 과목-분반 / 요트디자인-요트 / 모델하우스-집 

비식별 의존 : 과목-분반 / 요트디자인-요트 / 모델하우스-집

---

Recursive Relationships 

• 자기자신과의 관계를 갖는 개체가 존재
• boxcar 개체 간 1:1 재귀 관계 존재 

1:1 Recursive Relationship

• EMPLOYEE 개체 간 1:n 재귀 관계 존재 

1:n Recursive Relationship 

• PART 개체 간 n:m 재귀 관계 존재

n:m Recursive Relationship