[DB] Chapter 3 : Data Modeling Using the Entity-Relationship(ER) Model

Overview of Database Design Process

Database application : 특정 데이터 베이스를 가지고 있으며 queries와 update와 관련된 어플리케이션으로 application design과 database design 으로 나눌 수 있다. 

• application design
  프로그램과 DB의 접근 인터페이스에 집중하는 것 => 소프트웨어 설계에서 배우는 것
• Database design
  Conceptual, Logical, Physical

위 그림이 Database design 의 주요 단계를 도식화 한 것이다. 수업에서는 왼쪽의 세로선을 따라가는 과정에 집중해서 학습을 할 것이다. 

 

Entity Types, Entity Sets, Attributes and Keys

Entities and Attributes

Entity : 특정한 물건이나 객체

attirbutes : 엔티티를 나타내는 특정한 특성 -> 각각의 특성은 value set(data type)을 가져야한다.

attribute의 종류

• simple (atomic) 
• Composite : 여러개의 요소로 구성된 속성으로 합성된 요소는 계층적으로 표현된다.
  ex)Name(FirstName, LastName)
• Multi-valued : 한 개체가 여러개의 속성을 가진 상황
  ex) 자동차의 color 속성 -> 검정색, 흰색 등 다양한 속성을 가질 수 있음.  
• Composite and multi-valued : 한 개체가 여러개의 속성을 가진 요소가 합성된 상태.
   위 상황은 매우 드문 상태이며 보통 잘 사용하지 않는다.

Stored attribute vs Derived attribute
Stored는 말그대로 기록된 속성을 의미하고 Derived는 Stored 된 속성에서 얻어질 수 있는 속성이다.
ex ) birth_date 에서 age를 유도할 수 있기 때문에 age는 derived attribute라고 할 수 있다.

Complex attribute
합성 attribute가 섞인 attribute

 

Entity Types and Entity Sets

• Entity Types (intension)
  같은 기본 속성을 가진 엔티티 그룹
• Entity Set (extension)
  한 시간에 데이터베이스에 저장된 특정한 엔티티 속성의 모든 엔티티 모음

entity type은 schema와 entity set은 DB state와 비슷한 느낌의 개념이라고 생각하면 쉽다.

 

Key Attributes of an Entity Type

각각의 엔티티가 유일하기 위해서 정의된 속성으로 한 엔티티 타입에는 한 개 이상의 key attribute가 있어야한다.

Value Sets (Domains) of Attributes

각 속성은 value set ( 값의 domain ) 과 연관되어 있다. value set는 언어의 기본 데이터 타입과 유사하다.

 

Notation and Example for Entitty & Attribute in Entity-Relationship (ER Diagrams)

 

Relationship Types, Relationship Sets, Roles and Sturctural Constraints

• relationship : 특정한 의미를 가진 entity 사이의 관련성
  ( 이때 entity는 물리적이지 않아도 된다 = 같은 entity 끼리의 relation도 존재함)
• A relationship type R (관계 유형)
  n 개의 entity간의 연결 유형으로 degree는 연결된 엔티티 타입의 개수이다. 

degree

• A relationship set R (관계 집합)
  relationsip instance들의 현재 상태를 의미한다.

 

• Role Name
  각 엔티티 타입으로부터 엔티티가 참가할 때의 역할을 주는 것으로 엔티티 타입이 구분되면 기술적으로 필수적인 것은 아니다. 그러나, 같은 엔티티 타입이 하나 이상 참여하면 다른 역할을 하니 적어주어야한다.

 

• Recursive Relationship(Self-Referencing Relationship)
  같은 entity type 간의 관계가 있을 수 있다. 

 

Structural Constraints on Binary Relationship Types

1. Cardinality Ratio
   관계에 대한 제약 조건을 가하는 방식으로 entity가 몇 개 참여할 수 있는지 나타낸다.
   1:1, 1:N, M:N이 있다.

1:1

 

M:N

 

2. Participation constraint
엔티티가 존재하려면 다른 엔티티와 관계되어야한다. entity가 최소 몇 번 발생해야하는지에 대해 표현한다.

• total participation : 모든 entity1은 entity2에 관계가 있다. -> 두 줄로 연결
• partial participation : 모든 entity1이 entity2에 관계가 있는 것은 아니다. -> 한 줄로 연결

 

relationship attributes
relation도 속성을 가지고 있다. 보통 N:M 관계일 때 relation attirbute를 사용한다. 1:N인 경우 relationship attribute를 1쪽에 붙일 수 있다. 

 

 

Weak Entity Types

자기 자신만의 key attribute를 갖지 않는 엔티티 타입이다. 
자기 자체로 존재가 불가능해서 의존적이다. weak entity type은 항상 total participation 이다. 

 

아래 두가지의 조합으로 엔티티를 식별할 수 있다. 

• partial key : 독립적으로 존재할 수 없기 때문에 partial key를 가지게 된다.
• particular(parent) entity : 식별 관계 유형과 관련이 있는 엔티티

 

ER Diagrams, Naming Conventions, and Design Issues

Notation for Relationships in ER Diagrams

ER notation을 structural constraints로 표현하는 방법도 있다. (위 사진 맨 마지막)
cardinalrity ratio를 (min, max) 형태로 바꿀 수 있다. 
min = 0 이면 total participation이라는 의미로 해석할 수 있다. ( 한 relation에 최소 하나 이상 연결되어야하니까 total )
무한대가 연결될 수 있으면 max = n을 부여하면 된다.

 

 

ER Diagram 예제

+) 사실 교과서 중간중간에 위 Diagram를 예제로 보여주고 있었는데, 개념을 정리하는 거라 적지 않았다. 응용 측면이나 실용적인 측면은 시험공부하다가 시간이 나면 따로 정리해보겠다.