6. E-R Model

Overview of the Design Process

• Design Phases(설계 단계)
  • 초기 단계: 예비 데이터베이스 사용자의 데이터 요구사항을 완전히 특성화
    • 결과물: 사용자 요구사항 명세서
  • 두 번째 단계: 데이터 모델을 선택하고 해당 데이터 모델의 개념 적용
    • 사용자 요구사항을 데이터베이스의 개념적 스키마(conceptual schema)로 변환
    • 개념적 스키마는 기업의 기능적 요구사항을 나타냄
    • 데이터에 수행될 작업(또는 트랜잭션)의 종류를 기술
  • 최종 단계: 추상 데이터 모델에서 데이터베이스 구현으로 이동
    • 논리적 설계(Logical Design): 데이터베이스 스키마 결정
      • "좋은" 관계 스키마(relation schema)의 집합을 찾아야 함
      • 비즈니스 결정: 데이터베이스에 어떤 속성(attribute)을 기록해야 하는가?
      • 컴퓨터 과학 결정: 어떤 관계 스키마를 가져야 하며, 속성들을 다양한 관계 스키마에 어떻게 분배해야 하는가?
    • 물리적 설계(Physical Design): 데이터베이스의 물리적 레이아웃 결정

Design Approaches

• Entity-Relationship Model(개체-관계 모델) (본 장에서 다룸)
  • 기업을 개체(entities)와 관계(relationships)의 집합으로 모델링
  • Entity(개체): 다른 객체와 구별되는 기업 내의 "사물" 또는 "객체"
    • 속성 집합에 의해 기술됨
  • Relationship(관계): 여러 개체 간의 연관성
  • 개체-관계 다이어그램 (E-R diagram)으로 도식화하여 표현
• Normalization Theory(정규화 이론) (다음 장에서 다룸)
  • 어떤 설계가 나쁜지 공식화하고 이를 테스트함

Outline of the Entity-Relationship Model

Entity Sets

• 개체(entity)는 존재하며 다른 객체와 구별되는 객체
  • 예: 특정 사람, 회사, 이벤트
• 개체 집합(entity set)은 동일한 속성을 공유하는 동일한 유형의 개체 집합
  • 예: 모든 사람, 회사, 나무, 휴일의 집합
• 개체는 속성 집합으로 표현됨
  • 속성: 개체 집합의 모든 구성원이 소유한 기술적 속성
  • 예: instructor = (ID, name, salary), course = (course_id, title, credits)
• 도메인(Domain): 각 속성에 허용되는 값의 집합
• 속성의 일부 집합은 개체 집합의 기본 키(primary key)를 형성
  • 기본 키는 집합의 각 구성원을 고유하게 식별함

Entity Sets: instructor and student

• ER 다이어그램에서 개체 집합은 다음과 같이 그래픽으로 표현 가능:
  • 사각형은 개체 집합을 나타냄
  • 속성은 개체 사각형 내부에 나열됨
  • 밑줄은 기본 키 속성을 나타냄

Relationship Sets

• 관계는 여러 개체 간의 연관성
  • 예: student 개체 - advisor 관계 집합 - instructor 개체
• 관계 집합(relationship set)은 $n \ge 2$개의 개체 간의 수학적 관계로, 각 개체는 개체 집합에서 가져옴:

  $$R = \{(e_1, e_2, \dots, e_n) | e_1 \in E_1, e_2 \in E_2, \dots, e_n \in E_n\}$$

  • 여기서 $(e_1, e_2, \dots, e_n)$은 관계. 예: $(76766, 98988) \in \text{advisor}$
• 예: 지도교수 역할을 하는 강사와 학생 간의 연관성을 나타내기 위해 advisor 관계 집합 정의
• 도식적으로, 관련된 개체 사이에 선을 그림
• ER 다이어그램에서 다이아몬드는 관계 집합을 나타냄

Relationship Sets with Attributes

• 속성은 관계 집합과도 연관될 수 있음
• 예를 들어, instructor와 student 개체 집합 간의 advisor 관계 집합은 학생이 지도교수와 연관되기 시작한 시점을 추적하는 'date' 속성을 가질 수 있음
• 관계 집합의 차수(Degree)
  • 이진 관계(Binary relationship): $R = \{(e_1, e_2) | e_1 \in E_1, e_2 \in E_2\}$
    • 두 개의 개체 집합(또는 2차)을 포함
    • 데이터베이스 시스템의 대부분 관계 집합은 이진 관계
  • 세 개 이상의 개체 집합 간의 관계는 드묾
    • 예: 학생들이 강사의 지도 하에 연구 프로젝트를 수행
    • proj_guide 관계는 instructor, student, project 간의 3진 관계(ternary relationship)
• 관계의 개체 집합은 서로 구별될 필요가 없음
  • 개체 집합의 각 발생은 관계에서 "역할(role)"을 수행
  • "course_id"와 "prereq_id" 레이블은 역할(role)이라고 불림

Complex Attributes

• 속성 유형:
  • 단순(Simple) 속성과 복합(composite) 속성
    • 단순: 값이 하위 부분으로 나뉠 수 없음 (예: first_name, last_name)
    • 복합: 여러 부분으로 구성됨 (예: name = (first_name, last_name))
  • 단일값(Single-valued) (예: name) 및 다중값(multivalued) (예: phone_numbers) 속성
  • 파생(Derived) 속성
    • 다른 속성으로부터 계산 가능
    • 예: date_of_birth가 주어졌을 때 age
• 복합 속성은 속성을 하위 부분(다른 속성)으로 나눌 수 있게 함

Representing Complex Attributes in ER Diagram

• 다중값 속성(Multivalued attribute)
• 파생 속성(Derived attribute)

Mapping Cardinality Constraints

• 다른 개체가 관계 집합을 통해 연관될 수 있는 개체의 수를 표현
• 이진 관계 집합을 설명하는 데 가장 유용
• 이진 관계 집합의 경우, 매핑 카디널리티(mapping cardinality)는 다음 유형 중 하나여야 함:
  • 일대일(One to one)
  • 일대다(One to many)
  • 다대일(Many to one)
  • 다대다(Many to many)
• 참고: A와 B의 일부 요소는 다른 집합의 어떤 요소에도 매핑되지 않을 수 있음

Representing Cardinality Constraints in ER Diagram

• 카디널리티 제약 조건은 관계 집합과 개체 집합 사이에 방향성 있는 선(→, "일") 또는 방향성 없는 선(—, "다")을 그려 표현
• 강사와 학생 간의 일대일 관계:
  • 학생은 advisor 관계를 통해 최대 한 명의 강사와 연관됨
  • 강사는 관계를 통해 최대 한 명의 학생을 지도함
• 강사와 학생 간의 일대다 관계:
  • 강사는 여러 명(0 포함)의 학생을 지도함
  • 학생은 advisor 관계를 통해 최대 한 명의 강사와 연관됨
• 강사와 학생 간의 다대일 관계:
  • 강사는 advisor를 통해 최대 한 명의 학생을 지도함
  • 학생은 advisor를 통해 여러 명(0 포함)의 강사와 연관됨
• 강사와 학생 간의 다대다 관계:
  • 강사는 advisor를 통해 여러 명(0 포함)의 학생을 지도함
  • 학생은 advisor를 통해 여러 명(0 포함)의 강사와 연관됨

Mapping Cardinalities affect ER Design

• 관계 카디널리티는 관계 속성의 배치에 영향을 줄 수 있음:
  • 각 학생이 단 한 명의 강사만 가질 수 있다면, date를 관계(advisor) 속성 대신 학생("다" 쪽)의 속성으로 만들 수 있음
• advisor 관계가 일대다 카디널리티를 가진다고 가정

Total and Partial Participation

• 전체 참여(Total participation) (이중선으로 표시): 개체 집합의 모든 개체는 관계 집합에서 최소 하나의 관계에 참여
  • 예: advisor 관계에서 student의 참여는 전체 참여
  • 모든 학생은 연관된 강사가 있어야 함
• 부분 참여(Partial participation): 일부 개체는 관계 집합의 어떤 관계에도 참여하지 않을 수 있음
  • 예: advisor에서 instructor의 참여는 부분 참여
  • 어떤 학생도 지도하지 않는 강사가 있을 수 있음

Notation for Expressing More Complex Constraints

• 선에는 $l..h$ 형태로 최소 및 최대 카디널리티가 연관될 수 있으며, 여기서 $l$은 최소, $h$는 최대 카디널리티
• 최소값 1은 전체 참여를 나타냄
• 최대값 1은 개체가 최대 하나의 관계에 참여함을 나타냄
• 최대값 *는 제한이 없음을 나타냄
• 예시
  • 강사는 0명 이상의 학생을 지도할 수 있음
  • 학생은 반드시 1명의 지도교수를 가져야 하며, 여러 명을 가질 수 없음

Cardinality Constraints on Ternary Relationship

• 카디널리티 제약 조건을 나타내기 위해 3진(또는 그 이상의 차수) 관계에서 나오는 화살표는 최대 하나만 허용
• 예를 들어, proj_guide에서 instructor로의 화살표는 각 학생이 프로젝트에 대해 최대 한 명의 지도교수를 가짐을 나타냄
• 화살표가 하나 이상 있는 경우, 의미를 정의하는 두 가지 방법 존재
  • 예를 들어, $A$, $B$, $C$ 간의 3진 관계 $R$에서 $B$와 $C$로 화살표가 있는 경우
    1. 각 $A$ 개체는 $B$와 $C$로부터 고유한 개체와 연관됨, 또는
    2. ($A$, $B$)의 각 개체 쌍은 고유한 $C$ 개체와 연관되고, 각 쌍 ($A$, $C$)는 고유한 $B$와 연관됨
• 혼동을 피하기 위해 하나 이상의 화살표는 금지

Primary Key

• 기본 키는 주어진 개체 집합 내의 개체와 주어진 관계 집합 내의 관계를 구별하는 방법을 제공
• 고려 대상 기본 키:
  • 개체 집합
  • 관계 집합
  • 약한 개체 집합

Primary Key for Entity Sets

• 정의에 따라, 개별 개체는 구별됨
• 데이터베이스 관점에서, 그들 간의 차이는 속성의 관점에서 표현되어야 함
• 개체의 속성 값은 개체를 고유하게 식별할 수 있어야 함
• 개체 집합 내 어떤 두 개체도 모든 속성에 대해 정확히 동일한 값을 가질 수 없음
• 개체 집합의 키는 개체 집합 내의 개체를 서로 구별하기에 충분한 속성 집합

Primary Key for Relationship Sets

• 관계 집합의 다양한 관계를 구별하기 위해, 관계 집합에 있는 개체의 개별 기본 키 사용
• $R$이 개체 집합 $E_1, E_2, \dots, E_n$을 포함하는 관계 집합이라 할 때,
  • 개체 집합 $E_1, E_2, \dots, E_n$의 기본 키의 합집합(union)은 $R$의 개별 관계를 기술 (즉, 슈퍼키(superkey) 형성)
  • $PK(R) = PK(E_1) \cup \dots \cup PK(E_n)$
• 관계 집합 $R$에 $a_1, a_2, \dots, a_m$ 속성이 연관되어 있다면, $PK(R)$은 $R$의 의미에 따라 달라짐 (즉, $a_1, a_2, \dots, a_m$ 중 하나 이상의 속성을 포함할 수 있음)
• 예: "advisor" 관계 집합
  • 슈퍼키는 instructor.ID와 student.ID로 구성
• 개체 집합이 관계에 두 번 이상 참여하는 경우, 개체 집합 이름 대신 역할 이름 사용
  • 예) "prereq" 관계 집합에서, 슈퍼키는 course_id.ID와 prereq_id.ID로 구성

Choice of Primary key for Binary Relationship

• 관계 집합의 기본 키 선택은 관계 집합의 매핑 카디널리티에 따라 달라짐 (이진 관계 집합 $R$ 가정)
• 다대다 관계
  • 앞선 기본 키들의 합집합은 최소 슈퍼키이며 기본 키로 선택됨: $PK(R) = PK(E_1) \cup PK(E_2)$
• 일대다 또는 다대일 관계
  • "다(Many)" 쪽의 기본 키가 최소 슈퍼키이며 기본 키로 사용됨
  • 일대다: $PK(R) = PK(E_2, \text{Many})$, 다대일: $PK(R) = PK(E_1)$
• 일대일 관계
  • 참여하는 두 개체 집합 중 하나의 기본 키가 최소 슈퍼키를 형성하며, 둘 중 하나를 선택할 수 있음: $PK(R) = PK(E_1)$ 또는 $PK(E_2)$

Weak Entity Sets

• course_id, semester, year, sec_id로 고유하게 식별되는 section 개체를 고려
• 분명히 section 개체는 course 개체와 관련 있음
• section과 course 개체 집합 사이에 sec_course 관계 집합을 만든다고 가정
• sec_course의 정보는 section이 이미 course_id 속성을 가지고 있으므로 중복됨
• 이 중복성을 처리하는 한 가지 옵션은 sec_course 관계를 제거하는 것이지만, 이렇게 하면 section과 course 간의 관계가 속성 내에서 암시적이 되어 바람직하지 않음
• 이 중복성을 처리하는 대안적인 방법은 section 개체에 course_id 속성을 저장하지 않고 나머지 속성인 section_id, year, semester만 저장하는 것
• 그러나, section 개체 집합은 특정 section 개체를 고유하게 식별하기에 충분한 속성을 갖지 못하게 됨
  • section = (course_id, section_id, semester, year, building, room_number, time_slot_id)
• 이 문제를 해결하기 위해 sec_course 관계를 section 개체를 고유하게 식별하는 데 필요한 추가 정보(course_id)를 제공하는 특별한 관계로 취급
• 강한 개체 집합(Strong entity set): 자체 기본 키를 가진 일반 개체 집합
• 약한 개체 집합(Weak entity set)
  • 기본 키를 형성하기에 충분한 속성을 갖지 않는 개체 집합
  • 강한 개체 집합인 식별 개체 집합(identifying entity set)에 의존
  • 약한 개체에 기본 키를 연관시키는 대신, 식별 개체와 함께 판별자 속성(discriminator attributes)이라는 추가 속성을 사용하여 약한 개체를 고유하게 식별
  • 약한 개체 집합의 기본 키 = 식별 개체 집합의 기본 키 + 판별자

Weak Entity Sets (Cont.)

• 모든 약한 개체는 식별 개체와 연관되어야 함; 즉, 약한 개체 집합은 식별 개체 집합에 존재 종속적(existence dependent)임
• 식별 개체 집합의 개체가 삭제되면, 약한 개체 집합에 연관된 모든 개체도 삭제되어야 함
• 식별 개체 집합은 그것이 식별하는 약한 개체 집합을 소유(own)한다고 함
• 약한 개체 집합을 식별 개체 집합과 연관시키는 관계를 식별 관계(identifying relationship)라고 함

Expressing Weak Entity Sets

• E-R 다이어그램에서, 약한 개체 집합은 이중 사각형으로 표시
• 약한 개체 집합의 판별자는 점선으로 밑줄을 그음
• 약한 개체 집합을 식별 강한 개체 집합에 연결하는 관계 집합은 이중 다이아몬드로 표시
• section의 기본 키 = (course_id, sec_id, semester, year)

Redundant Attributes

• 다음과 같은 개체 집합이 있다고 가정:
  • student: 속성으로 ID, name, tot_cred, dept_name
  • department: 속성으로 dept_name, building, budget
• 각 학생이 연관된 학과가 있다는 사실을 stud_dept 관계 집합을 사용하여 모델링
• student 개체 집합의 dept_name 속성은 관계에 있는 정보를 복제하므로 중복되며, 제거 필요
• dept_name을 제거한 후에도 student 개체 집합은 여전히 강한 개체 집합으로 남음 (ID를 기본 키로 가짐)
• 그러나, 테이블(관계형 모델)로 다시 변환할 때, 어떤 경우에는 속성이 다시 도입됨

E-R Diagram for a University Enterprise

Reducing E-R Diagrams to Relational Schemas

Reduction to Relation Schemas

• E-R 다이어그램을 따르는 데이터베이스는 관계 스키마(테이블)의 집합으로 표현될 수 있음
• E-R 모델과 관계형 데이터베이스 모델은 유사한 설계 원칙을 사용
• E-R 설계를 관계형 설계로 변환 가능
• 기본 규칙
  • 각 개체 집합과 관계 집합에 대해, 해당 개체 집합 또는 관계 집합의 이름이 할당된 고유한 스키마가 있음
  • 각 개체 집합 $\rightarrow$ 고유한 관계 스키마
  • 각 관계 집합 $\rightarrow$ 고유한 관계 스키마
• 강한 개체 집합은 동일한 속성을 가진 스키마로 축소됨: student(ID, name, tot_cred)
• 약한 개체 집합은 식별 강한 개체 집합의 기본 키를 위한 열을 포함하는 테이블이 됨: section(course_id, sec_id, sem, year)

Representation of Entity Sets with Composite Attributes

• 복합 속성은 각 구성 요소 속성에 대해 별도의 속성을 생성하여 평탄화(flattened out)됨
• 예: instructor 개체 집합에 구성 요소 속성 first_name, middle_initial, last_name을 가진 복합 속성 name이 주어진 경우, 개체 집합에 해당하는 스키마는 name_first_name, name_middle_initial, name_last_name 세 속성을 가짐
  • 모호함이 없으면 접두사 생략 가능
• 다중값 속성을 무시한 확장된 instructor 스키마:
  • Instructor(ID, first_name, middle_initial, last_name, street_number, street_name, apt_number, city, state, zip_code, date_of_birth)

Representation of Entity Sets with Multivalued Attributes

• 개체 $E$의 다중값 속성 $M$은 별도의 스키마 $EM$으로 표현됨
• 스키마 $EM$은 $E$의 기본 키에 해당하는 속성과 다중값 속성 $M$에 해당하는 속성을 가짐
• 예: instructor의 다중값 속성 phone_number는 inst_phone(ID, phone_number) 스키마로 표현됨
• 다중값 속성의 각 값은 스키마 $EM$에 대한 관계의 별도 튜플에 매핑됨

Representing Relationship Sets

• 기본 규칙 (다대다 관계 집합용)
  • $E_1, \dots, E_k$를 포함하는 관계 집합 $R \rightarrow PK(E_1) \cup \dots \cup PK(E_k) \cup \text{attr}(R)$에 해당하는 속성을 가진 관계 스키마 $R$
• 예: advisor 관계 집합의 스키마: advisor = (s_ID, i_ID)

Combination of Schemas for Removing Redundancy

• "다(many)" 쪽에서 전체 참여인 다대일 및 일대다 관계 집합
  • $R$에 대한 별도의 스키마를 만드는 대신, $E_2$를 나타내는 관계 스키마에 $PK(E_1) \cup \text{attr}(R)$ 속성 추가
  • 이러한 관계 집합은 "다" 쪽에 "일(one)" 쪽의 기본 키를 포함하는 추가 속성을 추가하여 표현 가능
• 예: inst_dept 및 stud_dept 관계 집합에 대한 스키마를 생성하는 대신, instructor 및 student 개체 집합에서 발생하는 스키마에 dept_name 속성 추가
  • instructor 스키마 = (ID, name, salary, dept_name)
  • student 스키마 = (ID, name, tot_cred, dept_name)
• 일대일 관계 집합의 경우, 어느 쪽이든 "다" 쪽 역할을 하도록 선택 가능
• "다" 쪽에서의 참여가 부분적인 경우, "다" 쪽에 해당하는 스키마의 추가 속성으로 스키마를 대체하면 null 값이 발생할 수 있음
• 약한 개체 집합을 식별 강한 개체 집합에 연결하는 관계 집합에 해당하는 스키마는 중복됨
  • 약한 개체 집합의 스키마는 이미 식별 개체 집합의 기본 키를 포함하므로, 관계의 모든 정보가 약한 개체 집합의 스키마에 나타남
  • 따라서 관계형 데이터베이스 설계에 존재할 필요가 없음

Extended E-R Features

Specialization

• 개체 집합은 집합 내 다른 개체와 어떤 면에서 구별되는 개체의 하위 그룹을 포함할 수 있음
• 개체 집합 내의 개체 하위 집합은 개체 집합의 다른 모든 개체와 공유되지 않는 속성을 가질 수 있음
• 예) person 개체 집합은 employee와 student로 더 분류될 수 있으며, 각각 고유한 속성을 가짐
• 특수화(Specialization): 개체 집합 내 하위 그룹을 지정하는 상향식(top-down) 프로세스
• 이러한 독특한 개체 그룹을 나타내기 위해 E-R 모델이 제공하는 수단
• 이러한 하위 그룹은 상위 수준 개체 집합에 적용되지 않는 속성을 갖거나 관계에 참여하는 하위 수준 개체 집합이 됨
• 속이 빈 화살표 머리가 특수화된 개체에서 상위 수준 개체로 향하는 것으로 묘사됨
• 이 관계를 ISA 관계라고 함 (예: student "is a" person)
• 속성 상속(Attribute inheritance): 하위 수준 개체 집합은 연결된 상위 수준 개체 집합의 모든 속성과 관계 참여를 상속함

Specialization Example

• 중첩 특수화(Overlapping specialization)
  • 개체는 여러 특수화된 개체 집합에 속할 수 있음
  • 각 특수화된 개체 집합에 대해 별도의 화살표 사용
  • 예) employee와 student
• 비연관 특수화(Disjoint specialization)
  • 개체는 최대 하나의 특수화된 개체 집합에 속함
  • 단일 화살표 사용
  • 예) instructor와 secretary

Representing Specialization via Schemas

• 방법 1:
  • 상위 수준 개체 집합에 대한 스키마 형성
  • 각 하위 수준 개체 집합에 대한 스키마 형성, 상위 수준 개체 집합의 기본 키와 지역 속성 포함
  • 단점: employee에 대한 정보를 얻으려면 두 개의 관계, 즉 하위 수준 스키마(급여를 얻기 위해)와 상위 수준 스키마(이름, 거리, 도시를 얻기 위해)에 접근해야 함
• 방법 2:
  • 모든 지역 및 상속된 속성을 가진 각 개체 집합에 대한 스키마 형성
  • 단점: student와 employee 모두인 사람들의 경우 name, street, city가 중복 저장될 수 있음

Generalization

• 동일한 특징을 공유하는 여러 개체 집합을 상위 수준 개체 집합으로 결합하는 하향식(bottom-up) 설계 프로세스
• 특수화와 일반화(generalization)는 서로의 단순한 역관계
• 어디서 시작하느냐에 따라 다름
• E-R 다이어그램에서 동일한 방식으로 표현됨
• 특수화와 일반화 용어는 상호 교환적으로 사용됨

Completeness constraint

• 완전성 제약 조건(Completeness constraint): 상위 수준 개체 집합의 개체가 일반화 내의 하위 수준 개체 집합 중 적어도 하나에 속해야 하는지 여부를 명시
• total: 개체는 하위 수준 개체 집합 중 하나에 속해야 함
• partial (기본값): 개체는 하위 수준 개체 집합 중 하나에 속할 필요가 없음
• ER 다이어그램에 "total" 키워드를 추가하고 해당 키워드에서 적용되는 속이 빈 화살표 머리(비연관 일반화의 경우) 또는 화살표 머리 집합(중첩 일반화의 경우)으로 점선을 그려 전체 일반화를 명시 가능

Aggregation

• 앞서 본 3진 관계 proj_guide를 고려
• 프로젝트에서 학생을 지도하는 각 강사가 평가 보고서를 저장해야 한다고 가정
• 평가 보고서를 'evaluation' 개체로 모델링
• 그러면 instructor, student, project, evaluation 개체를 연관시키는 4진(4-way) 관계 집합 eval_for가 필요
• eval_for와 proj_guide 관계 집합은 중복되는 정보를 나타냄
• 이 중복성을 집합화(aggregation)를 통해 제거
  • 관계를 개념적 상위 수준 개체로 추상화
  • 관계 간의 관계를 허용
• 중복성을 도입하지 않고 집합화를 통해 이 중복성 제거
• 다음 다이어그램은 다음을 나타냄:
  • 학생은 특정 프로젝트에서 특정 강사의 지도를 받음
  • 학생, 강사, 프로젝트 조합은 연관된 평가를 가질 수 있음

Aggregation: Reduction to Relational Schemas

• 집합화를 나타내기 위해 다음을 포함하는 스키마 생성
  • 집합화된 관계의 기본 키
  • 연관된 개체 집합의 기본 키
  • 존재하는 경우 모든 기술적 속성
• 예제에서:
  • eval_for 스키마는 eval_for(s_ID, project_id, i_ID, evaluation_id)
  • proj_guide에 대한 관계 스키마는 중복됨

Design Issues

Common Mistakes in E-R Diagrams

• (a) 관계를 사용하는 대신, 개체 집합(department)의 기본 키(dept_name)를 다른 개체 집합(student)의 속성으로 사용
• (b) 다중값 속성이 필요한 상황에서 단일값 속성(assignment, marks)을 가진 관계 사용 (참고: 한 과목 제공에서 여러 과제가 있을 수 있음)

E-R Design Decisions

• 객체를 나타내기 위해 속성 또는 개체 집합 사용 (예: phone_numbers)
• 실세계 개념이 개체 집합 또는 관계 집합으로 가장 잘 표현되는지 여부
• 3진 관계 대 한 쌍의 이진 관계 사용
• 강한 또는 약한 개체 집합 사용
• 특수화/일반화 사용: 설계의 모듈성(modularity)에 기여
• 집합화 사용: 집합 개체 집합을 내부 구조의 세부 사항에 대한 걱정 없이 단일 단위로 취급 가능