[DB] ER 다이어그램

eeeeu·2023년 8월 25일

데이터베이스

데이타베이스

목록 보기

7/11

🌝 목표 : Entity-Relationship(ER)모델에 대해 알아보자.

Data Models, Schemas, Instances 에 대해 짚고 넘어가기

DB 디자인 과정을 간단히 하면 다음과 같다.

요구사항 수집 및 평가
conceptual design
1. conceputal Schema
Logical design(data model mapping)
1. conceptual Schema
physical design

ER 모델은 위의 2번 과정에 해당된다.

ER모델은 데이터를 Entity, Attribute, Relationship 로 나타낸다.

ENTITY(엔터티)

구체적인 객체 혹은 물체를 뜻한다.

물리적으로 존재하는 것들(학생, 차, 집) 뿐만 아니라 개념적으로 존재하는 것들(회사,직업)을 예로 들 수 있다.

Entity type and Entity sets

Entity type(intension)
- 같은 속성을 가지는 entity의 모음 /자바의 class 같은 것
Entity set(extension)
- 실제로 데이터베이스에 저장된 entity를 뜻함.

Attribute(속성)

entity 를 설명하는 특성을 나타냄

attribute는 각각 값과 타입을 가짐

학생(entity) 을 예로 들면, attritbute 로 이름,나이,성별 등이 있음

Types:

Simple: Atomic한 값(원자값)
Composite: 속성이 여러 구성 요소들로 이루어져 있을 수 있다.
Multi-valued: 한 속성에 대해 다중 값 가지기 가능

Stored attribute: 저장된 값
Derived attribute: 저장된 값으로부터 도출될 수 있는 값. (예를 들어, 생년월일을 알면 나이를 알 수 있다.)

Example

  학위 {PreviousDegrees(College, Year, Degree, Field)}
    
  학위라는 것은 Multi value를 가질 수 있고 학위라는 정보 자체가 여러개의 정보들로 구성된다.

Key Attributes(키 속성)

각각의 entity가 고유한 값을 가지는 attributes
한 개 이상의 key value 가지는 것이 가능하다.

e.g 사람(주민번호) 학생(학번)

WEAK ENTITY : 자기 자신을 위한 키 속성을 갖지 않는 entity type
child or subordinate entity type이라고 불림( c.f strong, regular entity type)
자기 자체만으로는 존재 불가능하다.

다른 entity와의 관계로 인해 식별될 수 있다. 이때 관계를 갖는 entity를 부모, 자신을 자식으로 볼 수 있다. 이 관계를 ‘Identifying Relationship’이라고 한다.

Weak entity type의 entity는 자신의 partial key와 부모 entity에 의해 식별된다.

Weak entity type은 항상 total participation constraint를 가진다.

weak entities 사이에서 식별 가능하게 해주는 키를 partial key 라고 한다.

Relationship

Relationship은 특정한 의미를 가진 둘 이상의 별개의 entity의 연관을 나타낸다.

e.g. EMPLOYEE 홍길동 ‘works on’ the SpaceX PROJECT

Relationship type R (관계 유형) : 관계의 스키마에 대한 설명. 관계의 이름, 참여하는 entity 타입, 제약조건등을 나타낸다. ex) WORKS_ON ‘관계의 degree’: 관계에 참여하는 entity의 타입 수
Relationship set R (관계 집합) among nn entity types E_1, E_2, ..., E_nE1,E2,...,En: 실제 DB에 있는 관계 인스턴스들의 집합

Relationship도 속성을 가질 수 있다. 보통 M:NM:N 관계에서 사용된다.

1:N1:N 관계에서는 NN에 해당하는 entity에 relationship의 속성을 합칠 수 있다.

Role Name (역할 이름)

어떤 관계에 참여하고 있는 entity에게 이 관계에서의 역할에 따라 이름을 부여하는 것이다. 보통은 ‘entity type name = role name’이다. 하지만 하나의 entity가 둘 이상의 역할로 관계에 참여한다면 이름을 붙일 필요가 있다.

예를 들어, 종업원은 주 역할인 ‘종업원’과 부 역할인 ‘매니저’를 가질 수 있다.

Recursive Relationship

같은 entity 타입에 있는 entity와 관계가 있는 것. 관계의 참여자는 같은 entity type이지만 다른 역할을 한다.

Notation

Cardinality ratio

관계형 모델 이해하기(1:N, 1:1, N:M)

Cardinality ratio vs Participation constraint

Cardinality(카디널리티) ratio는 하나의 entity가 최대 몇번 해당 relationship에 참여할 수 있는지를 표현한다.
반면에, Participation constraint는 같은 entity가 최소 몇 번 최대 몇번 relationship에 참여 할 수 있는지를 나타낸다.

EMPLOYEE works_for DEPARTMENT

즉, Cardinality ratio에서는 (D) 1:N (E)의 관계라는 것은 1개의 D가 (서로 다른) E와 최대 N번 관계할 수 있다는 것이다.
반면 participation(파티시페이션) constraint에서는 예를 들어 (D) (0, N) : (1, 1) (E)와 같이 동일한 D가 최소 0번 최대 N번, 동일한 E는 최소 1번, 최대 1번, 해당 relationship에 참여 가능하고 그것을 나타내는 relationship instance로 나타날 수 있다는 것이다.
그래서 위의 두 방식이 서로 다른 형태로 엔티티 들 간의 relationship 제약 조건을 기술한다.
서로 동등한 개념으로 이해하면 안된다. (물론 억지로 같게 표현시킬 수도 있겠지만..)