Ch6_ER_Model

19분 분량

Chapter 6. Database Design Using the E-R Model

한 줄 핵심: ER 모델은 현실 세계를 엔티티 집합·관계 집합·속성 세 개념으로 모델링하는 설계 도구이며, 그려진 ER 다이어그램은 정해진 규칙에 따라 관계형 스키마로 환원(reduction)된다.

이 챕터가 답하는 핵심 질문

  • Q1. ER 모델은 무엇을 어떤 개념으로 모델링하나?
  • Q2. Entity set / Relationship set이란? 다이어그램 표기는?
  • Q3. 속성(attribute)에는 어떤 종류가 있나?
  • Q4. Mapping cardinality와 참여 제약(total/partial)은 어떻게 표현하나?
  • Q5. Primary key는 entity/relationship/weak entity별로 어떻게 정하나?
  • Q6. Weak entity set은 왜 필요하고 어떻게 표기하나?
  • Q7. ER 다이어그램을 관계형 스키마로 어떻게 환원하나?
  • Q8. Specialization/Generalization(ISA)이란?
  • Q9. ER 설계에서 흔한 실수와 설계 결정사항은?

Q1. ER 모델은 무엇을, 어떤 기본 개념으로 모델링하나?

A. 기업(enterprise)을 엔티티와 관계의 집합으로 모델링하며, entity set·relationship set·attribute 세 가지 기본 개념을 쓴다.

  • Entity: 기업 내에서 다른 객체와 구별되는 “사물/객체”. 속성 집합으로 기술된다.
  • Relationship: 여러 엔티티 사이의 연관(association).
  • ER 데이터 모델은 Enterprise schema(DB의 전체 논리 구조)를 표현하기 위해 개발되었고, ER 다이어그램으로 시각화한다.

3가지 기본 개념: ① Entity sets ② Relationship sets ③ Attributes.

Q2. Entity set과 Relationship set은 무엇이며 다이어그램에 어떻게 그리나?

A. Entity set은 같은 속성을 공유하는 같은 타입 엔티티들의 집합(사각형), Relationship set은 n≥2개 엔티티 집합 간의 수학적 관계(다이아몬드)다.

Entity Sets

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

표기 — Rectangle = entity set, 속성은 사각형 안에 나열, 밑줄 = primary key.

Relationship Sets

  • Relationship set은 개 엔티티 집합에서 나온 엔티티들의 수학적 관계:

    예: (44553, 22222) ∈ advisor

표기 — Diamond = relationship set.

  • 관계의 속성: 관계 집합도 속성을 가질 수 있다. 예: advisor에 date(지도 시작일). 다이어그램에서 점선으로 다이아몬드와 연결.
  • Roles: 관계의 엔티티 집합이 서로 같아도 된다(자기참조). 같은 집합이 수행하는 역할이 Role. 예: prereq 관계에서 course_id(현재 과목)·prereq_id(선수 과목).
  • Degree(차수): Binary(두 집합)가 DB 시스템 관계의 대부분. Ternary 이상은 드묾 — 예: proj_guide(instructor × student × project).

Q3. 속성(attribute)에는 어떤 종류가 있나?

A. 구조(simple/composite), 값 개수(single/multivalued), 계산 여부(derived)로 분류된다.

구분유형설명예시
구조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).

Q4. Mapping cardinality와 참여 제약은 어떻게 표현하나?

A. 한 엔티티가 몇 개와 연관될 수 있는지를 4가지 카디널리티로, 모든 엔티티가 참여하는지를 total/partial로 표현한다.

Mapping cardinality는 관계를 통해 한 엔티티가 몇 개의 다른 엔티티와 연관될 수 있는지를 표현한다(binary에서 가장 유용).

유형의미
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: 어느 쪽이든 일부 원소는 어떤 관계에도 매핑되지 않을 수 있다(0개 허용).

다이어그램 표기: Directed line (→) = “one”, Undirected line (—) = “many”.

직관 — 화살표는 "이쪽은 최대 1개"를 가리킨다

헷갈리는 핵심: **화살표 머리(→)가 향하는 쪽이 “one”**이다. 즉 “반대쪽 엔티티 하나가 이쪽 엔티티를 최대 한 개만 가진다”는 뜻. 그림으로:

One-to-many (한 instructor가 여러 student를 지도):
    instructor ──◇── student
               ↑      (instructor 쪽에 화살표)
    "student 한 명은 instructor를 최대 1명 가짐"
    "instructor 한 명은 student를 여러 명 가짐(화살표 없는 쪽)"

외우는 법: 화살표 쪽 = 1, 민짜 선 쪽 = 多(many). 화살표가 양쪽이면 1:1, 양쪽 다 민짜면 多:多.

예시 관계의미표기
One-to-one양쪽 모두 최대 1instructor ←◇→ student
One-to-manyinstructor가 여러 studentinstructor ←◇— student
Many-to-onestudent가 여러 instructorinstructor —◇→ student
Many-to-many양쪽 여러 개instructor —◇— student

advisor 관계로 카디널리티 읽기

student와 instructor 사이의 advisor를 생각하자.

  • 한 학생은 지도교수를 최대 1명만 가진다.
  • 한 교수는 여러 학생을 지도할 수 있다.

그러면 student → instructor 방향으로는 many-to-one이다. ER 그림에서는 instructor 쪽에 화살표가 간다. 화살표가 향한 쪽이 “하나만 가능”한 쪽이기 때문이다.

Total vs Partial Participation

  • Total participation (이중선): entity set의 모든 엔티티가 관계에 적어도 한 번 참여. 예: 모든 student는 advisor를 가져야 함.
  • Partial participation: 일부는 참여하지 않아도 됨. 예: 지도학생 없는 instructor.

더 복잡한 제약 — l..h (최소 l, 최대 h, 해당 변에 붙은 엔티티 쪽의 제약):

  • l = 1 → total participation
  • h = 1 → 최대 한 관계
  • h = * → 제한 없음
  • 예: instructor 0..*—[advisor]—1..1 student → instructor는 0명 이상 지도(partial), student는 정확히 1명의 advisor(total + many-to-one).

Q5. Primary key는 entity / relationship / weak entity별로 어떻게 정하나?

A. entity는 구별 가능한 최소 속성 집합, relationship은 참여 엔티티들의 PK 조합(카디널리티에 따라 선택), weak entity는 identifying entity의 PK + discriminator다.

Entity set의 PK: 두 엔티티가 모든 속성에서 같은 값일 수 없다. Key = 엔티티들을 구분하는 최소 속성 집합.

Relationship set의 PK: 참여 엔티티들의 primary key 조합. 카디널리티에 따라 선택:

카디널리티Primary key
Many-to-Many양쪽 PK의 합집합 (minimal superkey)
One-to-Many”Many” 쪽 PK
Many-to-One”Many” 쪽 PK
One-to-One어느 한 쪽 PK

예: many-to-many advisor의 PK = instructor.ID ∪ student.ID.

Q6. Weak entity set은 왜 필요하고 어떻게 표기하나?

A. 자신만으로는 식별이 안 되어 다른 엔티티(identifying entity)에 존재 의존하는 엔티티 집합으로, 중복을 피하면서 식별을 관계에 위임할 때 쓴다.

동기: section은 (course_id, sec_id, semester, year)로 식별된다. 만약 section이 course_id를 속성으로 갖고 동시에 sec_course 관계도 두면 정보가 중복된다(같은 사실이 속성과 관계 양쪽에 저장 → 갱신 이상 위험). 그렇다고 course_id를 빼면 (sec_id, semester, year)만으로는 다른 과목의 같은 분반을 구별할 수 없다.

해결 — 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(구분자): 같은 identifying entity에 연결된 weak entity들을 구별하는 속성.
  • Strong entity set: weak entity가 아닌 일반 엔티티 집합.

ER 다이어그램 표기:

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

예: section의 PK = (course_id, sec_id, semester, year) — course_id는 identifying entity course에서, (sec_id, semester, year)는 discriminator.

직관 — weak entity는 "아파트 동·호수" 비유

“101호”라고만 하면 어느 건물인지 몰라 식별이 안 된다. “래미안 아파트 + 101호”라야 유일해진다. 여기서:

  • 101호(호수) = discriminator — 같은 건물 안에서만 구별해 주는 부분 키.
  • 래미안 아파트(건물) = identifying entity(strong) — 이 weak entity를 “소유”한다.
  • 호수는 건물 없이 혼자 존재할 수 없다 = 존재 의존(existence dependent).
  • 최종 PK = (건물명, 호수) = identifying entity의 PK + discriminator.
ASCII 다이어그램 (section은 course에 존재 의존):

  ┌──────────┐        ╔═══════════╗     ╔═════════════════╗
  │  course  │────────║ sec_course ║─────║     section     ║
  │ ─course_id│        ╚═══════════╝     ║ ┄sec_id ┄semester║
  └──────────┘                            ║ ┄year           ║
  (strong, 단일 사각형)  (이중 다이아몬드)   ╚═════════════════╝
                      = identifying relationship  (이중 사각형 = weak,
                                                   점선밑줄 ┄ = discriminator)

핵심: 이중 사각형(weak) + 이중 다이아몬드(identifying rel) + 점선밑줄(discriminator) 세 표기가 한 세트로 등장한다.

Redundant attribute(중복 속성): 관계가 표현하는 정보를 엔티티 속성으로 다시 저장하면 중복 — 예: student.dept_name이 stud_dept 관계와 겹치면 삭제해야 한다. 단, 테이블 환원 시 many-to-one의 “many” 쪽에 다시 추가될 수 있다(Q7 참고).

Q7. ER 다이어그램을 관계형 스키마로 어떻게 환원하나?

A. 각 entity set·relationship set마다 스키마 하나를 만들되, composite는 flatten, multivalued는 별도 테이블, total인 many-to-one 관계는 “many” 쪽에 흡수한다.

Entity set 환원

  • Strong entity set: 동일 속성을 가진 스키마. 예: student(ID, name, tot_cred)
  • Weak entity set: identifying strong entity의 PK 컬럼 포함. 예: section(course_id, sec_id, semester, year)

Composite attribute: component마다 별도 컬럼으로 flatten. 예: name → name_first_name, name_middle_initial, name_last_name(모호성 없으면 prefix 생략).

instructor(ID, first_name, middle_initial, last_name,
           street_number, street_name, apt_number,
           city, state, zip_code, date_of_birth)

Multivalued attribute : 별도 스키마 (E의 PK + M)으로 분리. 각 값이 별도 튜플.

inst_phone(ID, phone_number)
-- (22222, 456-7890), (22222, 123-4567)

Relationship set 환원

  • Many-to-Many: 두 엔티티의 PK + 관계의 서술 속성. 예: advisor(s_ID, i_ID).

Redundancy of Schemas (관계 스키마 최적화)

  • Many-to-one / One-to-many가 “many” 쪽에서 total이면, 별도 관계 스키마 대신 “many” 쪽에 “one” 쪽 PK를 추가 속성으로 넣는다. 
    department(dept_name, building, budget)
instructor(ID, name, salary, dept_name)   ← dept_name 흡수
inst_dept(ID, dept_name)                  ← 삭제
  • One-to-one: 어느 쪽이든 “many” 역할 가능 → 한쪽에 추가 속성.
  • Partial participation이면 추가 속성 방식이 null 값을 유발할 수 있다.
  • Weak entity의 identifying relationship 스키마는 redundant → 생략(weak entity 스키마가 이미 필요한 속성을 모두 포함).

직관 — "many 쪽으로 흡수"가 왜 안전한가

many-to-one에서 “many 쪽 엔티티 하나는 one 쪽을 정확히 한 개만” 가리킨다. 그러니 그 “한 개”의 PK를 many 쪽 행에 컬럼 하나로 그냥 적어 넣어도 값이 중복되거나 충돌하지 않는다(행마다 하나씩만 들어가니까). 그래서 별도 관계 테이블이 필요 없다.

  • 예: 교수(many)는 학과(one) 하나에 속함 → instructor에 dept_name 컬럼 하나 추가하면 끝. inst_dept 테이블 불필요.
  • 단, partial participation이면 학과 없는 교수가 있을 수 있어 그 칸이 null이 된다. many-to-many는 한 행에 여러 개를 못 적으니 반드시 별도 테이블이 필요하다.
    외우는 한 줄: “한 개만 가리키는 쪽(=many 쪽)에 상대 PK를 컬럼으로 끼워 넣는다.”

최종 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)

Q8. Specialization / Generalization(ISA)이란?

A. entity set 내에서 구별되는 하위 그룹을 지정하는 top-down 설계로, 하위 집합은 상위의 속성·관계를 **상속(inheritance)**한다.

  • Specialization: top-down — entity set 내에서 구별되는 하위 그룹(lower-level entity set)을 지정. 하위 그룹은 상위에 없는 속성·관계를 가진다.
  • 다이어그램에서 “ISA” 라벨이 붙은 삼각형으로 표기(예: instructor “is a” person).
  • Attribute inheritance: 하위 entity set은 상위의 모든 속성·관계 참여를 상속.

분류

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

스키마 환원 두 방법

방법스키마단점
Method 1 (분리)person(ID,name,street,city), student(ID,tot_cred), employee(ID,salary)전체 정보 얻으려면 두 테이블 join 필요
Method 2 (통합)person, student(+상속 속성), employee(+상속 속성)student이자 employee인 사람은 name/street/city 중복 저장

Q9. ER 설계에서 흔한 실수와 핵심 설계 결정사항은?

A. 속성과 관계의 중복, 관계 속성 오용이 흔한 실수이며, 객체를 속성/엔티티/관계 중 무엇으로 볼지가 핵심 결정사항이다.

흔한 실수

  1. 속성 오용: student에 dept_name 속성과 stud_dept 관계를 동시에 두면 중복 → 속성 삭제.
  2. 관계 속성 오용: stud_section에 assignment_marks 속성을 두면, 한 쌍에 여러 과제 점수가 있을 때 표현 불가 → assignment를 weak entity로 승격하거나 multivalued composite로 표현.

Entities vs Attributes: phone_number를 속성으로만 두면 다중 번호·추가 정보 표현이 어렵다. phone을 독립 entity로 분리하면 여러 번호 + 추가 정보 수용 가능.

Binary vs Non-Binary

  • n-ary 관계는 여러 binary로 분해 가능하지만, n-ary는 여러 엔티티가 단일 관계에 참여함을 더 명확히 보여준다.
  • 예: parents(child, father, mother) ternary → father, mother 두 binary가 더 나음 — 부분 정보(어머니만 아는 경우) 표현 가능. 그러나 proj_guide처럼 본질적으로 non-binary인 관계도 존재.

E-R 설계 결정사항 요약

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

부록. ER 표기 기호 요약

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

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