Ch6_ER_Model

20분 분량

Chapter 6. Database Design Using the E-R Model

핵심 요약: ER 모델은 현실 세계를 엔티티 집합(entity set), 관계 집합(relationship set), 속성(attribute) 세 가지 기본 개념으로 모델링하는 데이터베이스 설계 도구다. ER 다이어그램으로 Enterprise schema를 시각화하고, 정해진 규칙에 따라 관계형 스키마로 환원(reduction)한다. 복잡한 속성(합성·다중값·파생), 매핑 카디널리티, 참여 제약, 약한 엔티티 집합, 특수화/일반화(ISA) 등 확장 기능을 통해 의미론을 풍부하게 표현한다.

1. ER 모델 개요

Design Approach — Entity Relationship Model

  • 기업(Enterprise)을 엔티티와 관계의 집합으로 모델링한다.
    • Entity: 기업 내에서 다른 객체와 구별되는 “사물” 또는 “객체”. 속성 집합으로 기술된다.
    • Relationship: 여러 엔티티 사이의 연관(association).
  • **ER 다이어그램(ER diagram)**으로 시각화한다.

ER 모델의 3가지 기본 개념

ER 데이터 모델은 Enterprise schema(DB의 전체 논리 구조)를 표현하기 위해 개발되었으며, 세 가지 기본 개념을 사용한다.

  1. Entity sets — 엔티티 집합
  2. Relationship sets — 관계 집합
  3. Attributes — 속성

2. Entity Sets

  • Entity는 존재하며 다른 객체와 구별되는 객체 (예: 특정 사람, 회사, 이벤트, 식물).
  • Entity set은 같은 타입이면서 같은 속성을 공유하는 엔티티들의 집합.
  • 엔티티는 속성(attribute) 집합으로 표현된다.
    • 예: instructor = (ID, name, salary), course = (course_id, title, credits)
  • Primary key: 엔티티 집합 구성원을 고유하게 식별하는 속성 부분집합.

샘플 데이터

instructor entity set:

IDname
76766Crick
45565Katz
10101Srinivasan
98345Kim
76543Singh
22222Einstein

student entity set:

IDname
98988Tanaka
12345Shankar
00128Zhang
76543Brown
76653Aoi
23121Chavez
44553Peltier

ER Diagram 표기 규칙 — Entity Set

  • **Rectangle(직사각형)**이 entity set
  • 속성은 사각형 안에 나열
  • 밑줄은 primary key 속성

3. Relationship Sets

  • Relationship: 여러 엔티티 간의 연관.
    • 예: 44553 (Peltier) —[advisor]— 22222 (Einstein)
  • Relationship set은 개 엔티티 집합에서 나온 엔티티들의 수학적 관계:
  • 예: (44553, 22222) ∈ advisor

ER Diagram 표기 — Relationship Set

  • **Diamond(다이아몬드)**가 relationship set

3.1 Relationship Set의 속성

관계 집합도 속성을 가질 수 있다. 예: advisor에 date 속성을 붙여 학생이 지도교수와 언제 연결되었는지 추적.

ER 다이어그램에서 관계 집합의 속성은 **점선(dashed line)**으로 다이아몬드와 연결된다.

3.2 Roles

  • 관계의 엔티티 집합들이 서로 다를 필요는 없다(자기 참조 관계).
  • 같은 집합이 관계에서 수행하는 역할을 Role이라고 한다.
  • 예: prereq 관계 — course에서 두 번 참여. course_id(현재 과목)와 prereq_id(선수과목) 라벨이 role.

3.3 Degree of a Relationship Set

  • Binary relationship — 두 엔티티 집합(차수 2). DB 시스템의 관계 대부분은 binary.
  • Ternary 이상 — 드물지만 가끔 필요.
    • 예: proj_guide — 학생이 교수의 지도 하에 프로젝트를 수행 → instructor × student × project ternary relationship.

4. Complex Attributes

속성의 분류

구분유형설명예시
구조Simple더 분할 불가salary
구조Composite부분 속성으로 분할name → (first, middle, last), address → (street, city, state, zip)
중복Single-valued단일 값ID
중복Multivalued여러 값 (중괄호 { }){phone_number}
계산Derived다른 속성에서 계산 (괄호 ( ))age() ← date_of_birth
  • Domain — 각 속성이 가질 수 있는 허용 값의 집합.

Composite Attribute 계층 구조

name
 ├ first_name
 ├ middle_initial
 └ last_name

address
 ├ street
 │   ├ street_number
 │   ├ street_name
 │   └ apartment_number
 ├ city
 ├ state
 └ postal_code

합성 속성은 재귀적으로 더 분할될 수 있다.

5. Mapping Cardinality Constraints

관계 집합을 통해 한 엔티티가 몇 개의 다른 엔티티와 연관될 수 있는지를 표현한다. Binary relationship에서 카디널리티는 4가지:

유형의미
One to OneA 하나당 B 최대 1개, B 하나당 A 최대 1개
One to ManyA 하나당 B 여러 개 가능, B 하나당 A 최대 1개
Many to OneA 하나당 B 최대 1개, B 하나당 A 여러 개 가능
Many to Many양쪽 모두 여러 개 가능

Note: A 또는 B 쪽 일부 원소는 어떤 관계에도 매핑되지 않을 수 있다 (0개 허용).

5.1 ER Diagram에서 카디널리티 표기

  • Directed line (→): “one”
  • Undirected line (—): “many”
예시 관계의미다이어그램
One-to-one advisorstudent ↔ instructor, 각각 최대 1개instructor ←◇→ student
One-to-manyinstructor는 여러 학생 지도, 학생은 1명 지도교수instructor ←◇— student
Many-to-one반대 방향instructor —◇→ student
Many-to-many양쪽 여러 개instructor —◇— student

5.2 Total vs Partial Participation

  • Total participation (이중선): entity set의 모든 엔티티가 관계에 적어도 한 번 참여.
    • 예: 모든 student는 advisor를 가져야 한다 → student-advisor는 total.
  • Partial participation: 일부 엔티티는 관계에 참여하지 않을 수 있다.
    • 예: instructor는 지도학생이 없을 수 있음 → instructor-advisor는 partial.

5.3 더 복잡한 제약 표기 — l..h

  • 최소(l)와 최대(h) 카디널리티를 직접 표기.
    • l = 1 → total participation
    • h = 1 → 최대 1개 관계
    • h = * → 제한 없음
  • 예: instructor 0..*—[advisor]—1..1 student
    • 각 변의 l..h는 그 변에 붙은 엔티티 쪽의 참여 제약.
    • instructor 쪽 0..*: 지도학생이 0명이어도 되고 상한 없음 (partial).
    • student 쪽 1..1: 지도교수를 반드시, 정확히 1명 가짐 (total + many-to-one).
    • 구 표기 대응: instructor ←◇═ student (student 쪽 이중선 + N:1 화살표)와 동치.
  • l..h만 표현 가능한 케이스 (구 표기는 0/1/∞만): student 3..5 —[team_of]— 1..1 team → 팀당 3~5명, 학생은 정확히 한 팀.

6. Primary Key

Primary key는 엔티티와 관계를 구분하는 방법을 제공한다. 세 가지 경우로 나눠 본다.

6.1 Entity Set의 Primary Key

  • 정의상 각 엔티티는 구별된다. 속성 값으로 이 구별을 표현해야 한다.
  • 엔티티 집합의 두 엔티티가 모든 속성에서 같은 값을 가질 수는 없다.
  • Key = 엔티티들을 구분할 수 있는 최소 속성 집합.

6.2 Relationship Set의 Primary Key

  • 관계 집합의 primary key는 참여 엔티티들의 primary key의 조합으로 구성.
  • 관계 이 엔티티 집합 을 포함할 때, 의 primary key는 들의 primary key의 부분집합 조합.
  • 예: advisor의 primary key = instructor.ID ∪ student.ID.
  • 카디널리티에 따른 선택:
카디널리티Primary key 선택
Many-to-Many양쪽 primary key의 합집합
One-to-Many”Many” 쪽의 primary key
Many-to-One”Many” 쪽의 primary key
One-to-One어느 한 쪽의 primary key
→ 결론적으로 큰쪽 혹은 합집합

6.3 Weak Entity Sets

동기: section 엔티티는 (course_id, semester, year, sec_id)로 식별된다고 하자. section이 course와 관계되는 sec_course를 만들면, section 속성에 이미 course_id가 있으므로 정보가 중복된다.

"정보가 중복된다"의 의미

section이 어떤 course에 속하는지는 두 군데에서 동시에 표현된다:

  1. section의 속성 course_id 값 (엔티티 내부)
  2. sec_course 관계 튜플 (section의 key, course의 key) (관계 집합)

즉 “BIO-101의 Fall-2026-1 섹션이 BIO-101에 속한다”는 사실이 section 테이블의 컬럼과 sec_course 테이블의 행 양쪽에 각각 저장된다. 같은 의미를 두 곳에 쓰므로 갱신 이상(update anomaly) 위험 — 한쪽만 바꾸면 일관성이 깨짐.

중복 상태의 릴레이션 예시 (naïve 설계):

course (strong entity):

course_idtitle
BIO-101Intro Biology
CS-101Intro CS

section (course_id를 속성으로 보유):

course_idsec_idsemesteryear
BIO-1011Fall2026
BIO-1012Fall2026
CS-1011Fall2026

sec_course (관계 집합 테이블):

section_ref (course_id, sec_id, semester, year)course_id
(BIO-101, 1, Fall, 2026)BIO-101
(BIO-101, 2, Fall, 2026)BIO-101
(CS-101, 1, Fall, 2026)CS-101

→ sec_course의 오른쪽 course_id 컬럼은 section의 course_id 컬럼을 그대로 복사한 것. 한 섹션을 다른 과목으로 옮기려면 두 테이블을 동시에 고쳐야 함.

중복 제거 옵션 1 — sec_course 관계 삭제:

  • section 테이블에 course_id 속성은 그대로 두고, sec_course 관계(다이아몬드 + 테이블)를 없애는 방안.
  • 결과적으로 section.course_id가 암묵적으로 course를 참조(FK 역할)하게 된다.
  • 왜 바람직하지 않은가:
    1. ER 모델의 원칙 — “엔티티 간 연관은 관계(다이아몬드)로 명시적으로 표현한다.” 속성 값이 다른 엔티티를 가리키는 의미를 가지는 순간, 그 의미는 스키마가 아니라 *“개발자의 머릿속”*에만 존재.
    2. section 테이블에 instructor_id, classroom_id, time_slot_id 등 다른 FK들이 섞이면 어느 것이 “식별용 부모”이고 어느 것이 “그냥 참조”인지 구분 불가.
    3. course 쪽의 참여 제약(total/partial), 관계 속성(있다면) 같은 관계에만 붙일 수 있는 메타정보가 표현 불가.
  • 즉 정보 중복은 해소되지만 모델의 의미론이 빈약해짐 → 교과서가 “바람직하지 않다”고 표현하는 이유.

중복 제거 옵션 2 — section에서 course_id 속성 제거:

  • section 테이블을 (sec_id, semester, year)만으로 구성.
  • 그러나 이 세 속성만으로는 서로 다른 과목의 “Fall 2026 1분반”끼리 구분 불가 → 단독 식별 실패.
  • 이게 바로 weak entity set이 필요한 순간 — 식별을 identifying relationship(sec_course)에 위임.

해결: section을 weak entity set으로 모델링.

  • Weak entity set: 자신만으로는 식별이 불가능하고, 다른 엔티티(identifying entity)에 **존재 의존(existence dependent)**적인 엔티티 집합.
  • Identifying entity: weak entity를 식별해 주는 강한 엔티티. 이 강한 엔티티가 weak entity를 “own”한다.
  • Identifying relationship: weak entity set과 identifying entity set을 잇는 관계.
  • Discriminator(구분자): weak entity 내에서 같은 identifying entity와 연결된 엔티티들을 구별하는 속성.
  • Strong entity set: weak entity set이 아닌 일반 엔티티 집합.

ER Diagram 표기:

  • weak entity set — 이중 직사각형
  • discriminator — 점선 밑줄
  • identifying relationship — 이중 다이아몬드

예시: section의 primary key = (course_id, sec_id, semester, year) — course_id는 identifying entity course에서 가져오고, (sec_id, semester, year)는 discriminator.

7. Redundant Attributes ✅

관계 집합이 표현하는 정보를 엔티티 속성으로 다시 저장하면 redundant attribute(중복 속성)가 된다.

  • 예: student의 dept_name이 stud_dept 관계를 통해 department와 연결되어 있다면, dept_name은 redundant → 삭제해야 한다.
  • 단, 테이블로 환원할 때 many-to-one 관계의 경우 “many” 쪽에 다시 추가될 수 있다(§9 참고).

8. University Enterprise의 ER Diagram

대학 시스템의 전체 ER 구조(주요 엔티티와 관계):

  • Entity sets: department, course, instructor, student, section(weak), classroom, time_slot
  • Relationships:
    • inst_dept(instructor–department), stud_dept(student–department), course_dept(course–department)
    • advisor(instructor–student)
    • teaches(instructor–section), takes(student–section, with attribute grade)
    • sec_course(identifying, section–course, double diamond)
    • sec_class(section–classroom), sec_time_slot(section–time_slot)
    • prereq(course–course, self-referencing)

9. Reduction to Relation Schemas

ER 다이어그램은 일정한 규칙으로 관계형 스키마의 집합으로 환원된다. 각 엔티티 집합 / 관계 집합마다 하나의 스키마가 대응된다.

9.1 Entity Set의 표현

  • Strong entity set: 동일한 속성을 가진 스키마로 환원.
    • student(ID, name, tot_cred)
  • Weak entity set: identifying strong entity의 primary key 컬럼을 포함한 테이블.
    • section(course_id, sec_id, semester, year)

9.2 Composite Attribute의 표현

  • 각 component 속성마다 별도의 컬럼을 만들어 flatten.
  • 예: name = (first_name, middle_initial, last_name) → name_first_name, name_middle_initial, name_last_name. 모호성이 없으면 prefix를 생략할 수 있다.
  • Multivalued 속성은 별도 테이블로 분리하므로 이 단계에서 제외된다.
  • 최종: 
    instructor(ID, first_name, middle_initial, last_name,
           street_number, street_name, apt_number,
           city, state, zip_code, date_of_birth)

9.3 Multivalued Attribute의 표현

  • multivalued 속성 은 별도의 스키마 으로 표현
  • 은 엔티티 의 primary key + 값을 가진다.
  • 각 multivalued 값이 별도의 튜플이 된다.
  • 예: instructor의 {phone_number} → 
    inst_phone(ID, phone_number)
    (22222, 456-7890), (22222, 123-4567) 처럼 각 전화번호가 한 행.

9.4 Relationship Set의 표현

  • Many-to-Many 관계: 두 엔티티의 primary key + 관계의 서술 속성(descriptive attribute)로 구성된 스키마.
  • 예: advisor = (s_ID, i_ID) (필요하면 date 등 추가)

9.5 Redundancy of Schemas — Relationship 스키마의 최적화

  • Many-to-one / One-to-many 관계가 “many” 쪽에서 total이면, 별도 관계 스키마를 만들지 말고 “many” 쪽 엔티티 스키마에 “one” 쪽 primary key를 추가 속성으로 넣는다.
  • 예: 
    department(dept_name, building, budget)
instructor(ID, name, salary, dept_name)   ← dept_name 추가
inst_dept(ID, dept_name)                  ← 삭제
  • One-to-one 관계: 어느 쪽이든 “many” 쪽 역할이 가능 — 한쪽 엔티티 테이블에 추가 속성을 넣는다.
  • Partial participation일 때 extra attribute 방식을 쓰면 null 값이 발생할 수 있다.
  • Weak entity set과 identifying relationship 스키마: weak entity 스키마가 이미 필요한 속성을 모두 포함하므로, identifying relationship의 스키마는 redundant하여 생략한다.

9.6 최종 University 스키마

department(dept_name, building, budget)
instructor(ID, name, salary, dept_name)
student(ID, name, tot_cred, dept_name)
advisor(s_ID, i_ID)
course(course_id, title, credits, dept_name)
prereq(course_id, prereq_id)
section(course_id, sec_id, semester, year, building, room_number, time_slot_id)
classroom(building, room_number, capacity)
time_slot(time_slot_id, day, start_time, end_time)
teaches(ID, course_id, sec_id, semester, year)
takes(ID, course_id, sec_id, semester, year, grade)

10. Extended E-R Features — Specialization / Generalization

10.1 Specialization

  • Top-down 설계: entity set 내에서 다른 엔티티와 구별되는 하위 그룹을 지정.
  • 하위 그룹은 상위 집합에는 적용되지 않는 속성이나 관계를 가진다.
  • 다이어그램에서 “ISA” 레이블이 붙은 삼각형으로 표기 (예: instructor “is a” person).
  • Attribute inheritance(속성 상속): 하위 entity set은 상위 entity set의 모든 속성과 관계 참여를 상속.

10.2 Specialization의 분류

구분유형예시
겹침Overlappingemployee와 student (한 사람이 둘 다 가능)
겹침Disjointinstructor와 secretary
완전성Total상위 집합의 모든 엔티티는 어떤 하위 집합에 속해야 함
완전성Partial일부 엔티티는 하위 집합에 속하지 않아도 됨

예시 계층:

               person(ID, name, street, city)
                        │
              ┌─────────┴─────────┐
        employee(salary)       student(tot_credits)
              │
       ┌──────┴──────┐
  instructor(rank) secretary(hours_per_week)

10.3 Specialization의 스키마 환원

Method 1 — 분리(separate) 방식:

SchemaAttributes
personID, name, street, city
studentID, tot_cred
employeeID, salary
  • 단점: employee 정보 전체를 얻으려면 두 테이블을 join해야 함.

Method 2 — 통합(union) 방식: 각 entity set에 local + inherited 속성을 모두 저장

SchemaAttributes
personID, name, street, city
studentID, name, street, city, tot_cred
employeeID, name, street, city, salary
  • 단점: student이자 employee인 사람은 name, street, city가 중복 저장될 수 있음.

11. E-R Design Issues

11.1 Common Mistakes in E-R Diagrams

  1. Incorrect use of attribute:
    • student에 dept_name 속성을 두면서 동시에 stud_dept 관계도 유지 → 중복. 속성을 삭제해야 한다.
  2. Erroneous use of relationship attributes:
    • stud_section 관계에 assignment_marks 속성. 한 학생–섹션 쌍에 여러 과제 점수가 있으면 관계 속성만으로는 표현 불가.

해결:

  • (c) assignment를 독립 entity(weak)로 승격, marks_in·sec_assign 관계로 연결.
  • (d) 관계 속성으로 multivalued composite {[assignment_marks: assignment, marks]}를 사용.

11.2 Entities vs. Attributes

  • phone_number를 속성으로만 두면 다중 전화번호 표현이 어렵고 추가 정보(location 등)를 붙일 수 없다.
  • phone을 독립 entity로 분리하면 여러 전화번호 + 추가 정보 모두 수용 가능.

11.3 Binary vs Non-Binary Relationships

  • 임의의 n-ary(n > 2) 관계는 여러 binary 관계로 분해 가능하지만, n-ary는 여러 엔티티가 단일 관계에 참여함을 더 명확히 보여준다.
  • 비-binary로 보이는 관계 중 binary로 바꾸는 게 더 나은 경우도 있다.
    • 예: parents(child, father, mother) ternary → father, mother 두 binary 관계.
    • 장점: 부분 정보(어머니만 아는 경우)를 표현 가능.
  • 그러나 본질적으로 non-binary인 관계도 존재(예: proj_guide).

11.4 E-R Design Decisions — 설계 시 결정사항 요약

  • 객체를 속성으로 표현할지 entity set으로 표현할지.
  • 현실 개념을 entity set으로 표현할지 relationship set으로 표현할지.
  • Ternary relationship vs 여러 binary relationship.
  • Strong vs Weak entity set.
  • Specialization/Generalization 사용 — 설계의 **모듈성(modularity)**에 기여.

12. ER Notation Symbols 요약

기호의미
▭ 사각형Entity set
◇ 다이아몬드Relationship set
이중 사각형Weak entity set
이중 다이아몬드Identifying relationship
▭ 안 밑줄Primary key
점선 밑줄Weak entity의 discriminator
— 무방향선Many
→ 방향선One
이중선Total participation
l..h카디널리티 범위
△ ISA 삼각형Specialization / Generalization
---- totalTotal generalization

출처: Database System Concepts, 7th Edition (Silberschatz, Korth, Sudarshan)