Entity-Relationship Model

ER(Entity-Relationship) model은 데이터베이스 개념 설계 단계에서 사용자 요구사항을 구조화하는 개념적 데이터 모델이다. 3-schema architecture의 개념 스키마를 표현하는 데 주로 쓰이며, 현실 세계를 Entity, Attribute, Relationship 세 가지 핵심 개념으로 표현한다.

flowchart LR
  Entity["Entity
실제/개념적 객체"]
  Attribute["Attribute
엔티티 기술 속성"]
  Relationship["Relationship
엔티티 간의 연관"]
  Entity --> Attribute
  Entity --- Relationship
  Relationship --- Entity

ER Model 주요 개념 3가지

ER model의 주요 개념은 Entities, Attributes, Relationships 세 가지이며, 원문은 이 중 Relationships를 별표(⭐)로 강조한다.[1]

특정 Entity는 attribute들에 대한 값을 가지며, 각 attribute는 값의 집합 또는 데이터 타입을 가진다.[3] 원문은 개념 설계 방법론으로 ER Diagram과 Design Tools를 들고, UML의 Class Diagram이 인기 있다고 적는다.[4]

Attribute 유형

유형 설명 비고
Simple atomic value. 쪼갤 수 없는 값[5] -
Composite (복합) 더 작은 구성 요소로 나눌 수 있음[5:1] -
Multi-valued 하나의 attribute가 여러 값을 가짐[5:2] -
일반적으로 composite과 multi-valued는 잘 안 씀[5:3] 정규화 과정에서 걸리기 때문에 테이블에서 안 쓰임[5:4]

Entity Types와 Key Attributes

Entity Set

Entity Set은 각 entity type이 가지는 entity들의 모음(collection of entities)이다. Entity set은 엔티티들의 현재 상태에 해당한다.[7] 이를 database state(특정 시간의 실제 데이터)와 비슷한 개념으로 보는 것은 이 page의 해석이다.

Value Sets (Domains) of Attributes

Value set은 attribute가 가질 수 있는 값의 범위(domain of values)다.[8]

Relationship에 대한 제약

제약 설명
Cardinality Ratio 최대 참가 명시. 1:1, 1:N, N:1, M:N[9]
Existence Dependency (=Participation constraint) zero = 옵션적 참여, one or more = 무조건 참여[9:1]

Recursive Relationship Type (self-referencing)

Recursive Relationship은 명시된 역할에서 같은 엔티티 타입 사이에서의 관계 타입이며, 각 역할 기술이 필요하다.[10] 예를 들어 Employee entity 안의 Supervises relationship에서 supervisor와 supervisee는 같은 Employee 타입의 두 역할이다.

Weak Entity Type

특성 설명
정의 다른 엔티티 타입에 의존적. key attribute가 없는 엔티티 타입[11]
식별 다른 엔티티 타입의 엔티티들과 연계됨으로써 식별 가능[11:1]
Partial key 원문 노트는 "다른 엔티티 타입에 있는 속성 중 키로 약한 엔티티타입의 키로 사용하는 속성을 말하는 듯"이라고 추측으로만 적었으며, 확인된 정의가 아니다.[11:2]
Identifying relationship 약한 엔티티 타입과 의존하는 엔티티 타입의 관계 타입[11:3]

Weak entity는 자체 key가 없으므로, identifying relationship과 결합해야만 개별 인스턴스를 식별할 수 있다고 볼 수 있다.[12]

Relationship Type의 속성

대부분의 관계 속성은 M:N 관계에서 사용된다.[13] 예를 들어 학생이 과목을 수강하는 relationship에 "수강 학기", "성적" 속성을 두는 경우다.

Relationships of Higher Degree

Degree 이름 비고
2 binary -
3 ternary -
n n-ary -

n-ary relationship은 n개의 binary relationship과 같지 않다.[14] n-ary 한 개가 n개 binary로 정확히 분해되지 않는 이유를 의미와 제약의 차이로 보는 것은 이 page의 해석이다.[12:1]

이 제약이 중요한 이유는, "한 트랜잭션에서 3개 엔티티가 동시에 참여해야 의미가 있는 관계"를 binary 3개로 쪼개면 원래 의미를 잃기 때문이다. 예를 들어 "특정 supplier가 특정 project에 특정 part를 공급"하는 관계를 supplier-part, part-project, supplier-project라는 binary 3개로 쪼개면 "공급"이라는 ternary 의미를 살릴 수 없다고 볼 수 있다.[12:2]

Relational Algebra (개념 연계)

Relational Algebra의 UNION, INTERSECT, DIFFERENCE 연산은 type compatible(두 relation의 타입이 같고 attribute 수가 같아야 함)이어야 한다.[15] 원문에는 COMMUTATIVE(교환)라는 제목만 있고, 어떤 연산이 교환 성질을 가지는지는 적혀 있지 않다.[15:1]

SQL 중첩이 가능한 이유가 이 닫힌 성질 — 연산 결과가 다시 relation이 되는 성질 — 때문이라는 점은 Database System Foundation에서 다뤘다.

종합

ER model의 본질은 현실을 Entity·Attribute·Relationship 세 개념으로 구조화하는 데 있다고 볼 수 있다. 설계 시 주의할 지점은 다음과 같다.

  1. Relationship이 가장 중요한 개념이다 — Entity/Attribute는 직관적이지만, Relationship이 데이터의 의미를 결정한다.
  2. M:N 관계에서 relationship attribute가 자주 쓰인다 — 반대로 1:N/1:1에서는 보통 attribute를 entity로 올려서 다루는 편이 단순하다.
  3. Weak entity는 자체 key가 없으므로 identifying relationship과 결합해 식별한다.
  4. n-ary relationship을 무조건 binary로 분해하면 안 된다 — 의미론적 정보가 손실되므로, ternary는 ternary 그대로 다루는 것이 정확하다.

정규화 단계로 넘어가면 composite/multi-valued attribute는 걸러지고 테이블로 정리되며, 그 뒤 relational schema가 된다. 따라서 ER model은 개념적 설계에서 논리적 설계(relational schema)로 가는 중간 단계의 표현 도구로 볼 수 있다.[12:3]

흔히 놓치는 지점

관련

출처

테스트 질문

  1. 개념정리.md — (L261-264) "ER model의 주요 개념 3가지", "Entities", "Attributes", "Relationships⭐" ↩︎

  2. 개념정리.md — "Entity는 실제로 또는 개념적으로 존재하는 객체", "Attribute는 엔티티를 기술하는 속성" ↩︎ ↩︎

  3. 개념정리.md — "특정 Entity는 attribute들에 대한 값을 가짐", "각 attribute는 값의 집합 또는 데이터 타입을 가짐" ↩︎

  4. 개념정리.md — (L197-200) "Methodologies for Conceptual Design(개념 설계 방법론)⭐", "Entity Relationship (ER) Diagrams", "Design Tools", "UML의 Class Diagram이 인기" ↩︎

  5. 개념정리.md — "Simple: atomic value", "Composite(복합): 더 작은 구성 요소로 나눌 수 있음", "Multi-valued: 하나의 Atrribute가 여러 값을 가짐", "composite와 multi-valued는 잘 안씀, 정규화 과정에서 걸리기 때문에 테이블에서 안 쓰임" ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  6. 개념정리.md — "entity type 중 하나의 attribute가 unique value(구별가능한 값)여야 함", "composite가 key가 될 수 있음", "각 key는 밑줄(Relational schema의 primary key의 밑줄과 다름)", "entity type은 한개 이상의 key를 가질 수 있음" ↩︎ ↩︎ ↩︎ ↩︎

  7. 개념정리.md — "Each Entity type will have collection of entities", "Entity set is the current state of the entities" ↩︎

  8. 개념정리.md — "Value set = domain of values, 범위를 정할 수 있다" ↩︎

  9. 개념정리.md — "Cardinality Ratio: 최대 참가 명시, ex) 1:1, 1:N, N:1, M;N", "Existence Dependency Constraint(=Participation constraint): zero = 옵션적 참여, one or more = 무조건 참여" ↩︎ ↩︎

  10. 개념정리.md — "Recursive Relationship(self-referencing relationship): 명시된 역할에서 같은 엔티티 타입 사이에서 관계 타입, 각 역할 기술 필요" ↩︎

  11. 개념정리.md — (L282-291) "다른 엔티티 타입에 의존적", "key attribute가 없는 엔티티 타입", "다른 엔티티 타입의 엔티티들과 연게됨으로써 식별 가능", "partial key", "다른 엔티티 타입에 있는 속성 중 키로 약한 엔티티타입의 키로 사용하는 속성을 말하는 듯", "Identifying reationship", "약한 엔티티 타입과 의존하는 엔티티 타입의 관계 타입" ↩︎ ↩︎ ↩︎ ↩︎

  12. 출처 매핑 미확인 — "weak entity는 identifying relationship과 결합해야만 식별 가능하다는 결론", "n-ary가 n개 binary로 분해되지 않는 이유를 의미와 제약의 차이로 보는 설명", "ternary를 binary 3개로 쪼개면 '공급' 의미를 살릴 수 없다는 supplier-part-project 예시 해석", "ER model이 개념적 설계에서 논리적 설계로 가는 중간 단계 표현 도구"라는 종합은 source 개별 사실을 엮은 Wiki 차원의 해석이며 source에 이 문장 그대로는 없다. ↩︎ ↩︎ ↩︎ ↩︎

  13. 개념정리.md — "대부분의 관계 속성은 M:N 관계에서 사용됨⭐" ↩︎

  14. 개념정리.md — "n-ary relationship != n binary relationships⭐" ↩︎

  15. 개념정리.md — (L314-318) "UNION, INTERSECT, DIFFERENCE", "type compatible = 두개의 타입이 같아야함", "애트리뷰트 수 같아야함", "COMMUTATIVE(교환)" (L318 제목 아래 내용 없음) ↩︎ ↩︎