[Database] 3.ER모델을 통한 데이터 모델링

REF: fundamentals of database systems 7th edition

데이터베이스 설계

ER(entity-relationship model)

High-level data model(컴퓨터와 연결성이 낮다)

• 광범위하게 사용되는 개념적 데이터모델

개념적 데이터 모델

• DB사용자가 이해하는 데이터베이스 구조(miniworld에서 운영되는 시스템을 위함)

1. 개체(Entity) : 실세계의 물건, 개념
   • miniworld가 무엇인지에따라 정해진다.(miniworld에 따라 표현되어야하는 개체의 중요도가 정해지고, 표현될 개체가 선택된다.)
2. 속성(Attribute) : 개체의 성질, 속성
   • miniworld가 무엇인지에따라 정해진다.
3. 관계(Relationship) : 둘 이상의 개체간 관계

데이터베이스 설계 단계

1. 요구수집 및 분석
   • 데이터베이스 설계자가 사용자들의 요구사항을 문서화한다.
   • DB requirements : 데이터 저장 요구사항
   • functional requirement : 데이터 활용 요구사항(삭제, 삽입, 갱신방법)을 지정한다.
2. 개념적 스키마 설계(Concuptual Design)
   • 개체 형태, 관계, 제약에 대한 자세한 묘사
   • high-level data model(ER 모델 등)을 사용해 표현
   • DB기술에 대해 잘 모르는 사람과 대화하기위해 구현에대한 자세한 사항은 다루지 않는다.
3. Functional analysis
   • 기능적 요구사항에 맞게 개념적 스키마가 설계되었는지 확인한다.
   • high-level transaction을 설계
4. 논리적 데이터베이스 설계(데이터베이스 구현, 데이터 모델 매핑)
   • 상용화된 DBMS로 데이터베이스 구현
   • 상용화된 DBMS는 구현 데이터 모델을 사용하므로, 개념적 스키마에서 구현 스키마로의 매핑이 필요하다.
   • high-level data model<->implementation data model
5. 물리적 데이터베이스의 설계
   • 내부저장 구조 및 파일 구조 설정
6. 응용 프로그램 설계 및 구현
   • high-level transaction 사용

ER모델 개념

• 정의 : 데이터를 entity, relationship, attribute로 표현한다.
• Entity : 실세계의 물리적, 개념적으로 존재하는 것
  • 물리적 : 자동차, 직원, 학생
  • 개념적 : 회사, 직업, 과목
• Attribute : Entity의 성질
  • 직원 : 이름, 월급, 나이

각 entity는 attribute에 대한 값을 가지게된다.

Attribute 형태

세분화 할 수 있는가?

• simple(atomic) attribute
  • 더이상 나눠지지 않는 속성
  • 사람의 나이
• composite attribute
  • 기본적인 여러 개의 속성으로 세분화 될 수 있는 속성
  • 주소(서울특별시/서대문구/…)

단일한 값을 가지는가?

• single-valued attributes
  • entity당 1개의 값만 가질 수 있는 속성
  • 사람나이 : 1개의 값
• multi-valued attributes
  • 1개 이상의 값을 가질 수 있는 속성
  • 자동차(경찰차) : 빨, 파, 검, 흰 …

값의 출처

• stored attributes
  • 값이 DB에 저장된다.
• derived attributes
  • 다른 속성의 값에의해 결정된다.
  • ex)나이

NULL Value

• null 값은 다양한 해석이 존재할 수 있으므로, 지양되어야한다.

• not applicable
  • 주소의 아파트번호(단독주택은 null)
  • 사람의 학사(학위 없으면 null)
• not Known
  • missing : 값이 존재하지만, 모른다.
  • not known whether it exists : 속성 값이 존재하는지조차 모른다.

Entity Types, Entity sets, keys, value sets(domain)

Entity types

• 동일한 속성을 갖는 entity의 구조를 정의한다.
• entity의 이름, 속성 이름 리스트

  Entity sets

• set : 서로 다른 원소의 모임
• 동일한 구조(속성)을 갖는 entity의 집합이다.
• 즉, 특정 entity type을 만족하는 entity의 집합
• ERD에서 직사각형이다.
• 일반적으로 entity type으로도 표현된다.(EMPLOYEE는 entity type임과 동시에 모든 employee entity들의 set)이다.

ERD에서 표현

• entity type : 직사각형
• attribute : 타원으로 entity type에 직선으로 연결되어있다.
• composite attribute : Fname처럼 다른 attribute에 직선으로 연결되어있다.
• multi valued attribute : double oval로 표현된다.

Key Attribute

• Entity Type에서 각 entity가 유일한 속성 값을 가지는 속성을 의미.
• Key attribute value : entity = 1:1의 관계를 만족한다.
• 여러 key attribute가 key의 역할을 할 수 있다.(복합키)

Domain(value set) of Attribute

• entity가 가지는 속성 값의 범위를 정의

• single-valued attribute : 1개의 값
• multi-valued attribute : set value
• composite attribute : 카테시안 곱 (P(), P(), P() …)

Attribute Notation

• composite attribute()
  • 이름은 first name과 last name으로 구성되어있다.
  • 이름(first name, last name)
• multi-valued attribute{}
  • 한 개 이상의 집과 전화를 갖는 사람의 속성
  • {AddressPhone({phone(areaCode, phoneNumber)}, address(streetAddress(number, street, aptNum), city, state, zip))}

RelationShip

Type, Sets, Instances

ERD에서 다이아몬드로 표현된다.

• Relationship type
  • n개의 entity type들에 대한 결합집합을 의미한다.
  • 즉, 2개 이상의 entity들의 관계를 정의.
  • 위 그림에서 WORKS FOR을 의미한다.
• Relationship set
  • Relationship type을 만족하는 relation의 집합을 의미한다.
  • binary(2), ternary(3) 등의 relationship set이 있다.
  • relationship instance들의 집합
  • WORKS FOR의 원소들의 집합 R을 의미한다.
• RelationShip Instance
  • binary relationship set R을 가정했을때,
  • R의 원소 r1, r2, r3, … rn은 relation type의 entity type E1, E2의 원소들 e1_1, e1_2,…, e2_1, e2_2, …,간 결합을 의미한다.
  • 여기서 결합에 참여하는 entity type들을 relationship type R에 participate한다고 한다.
  • 위의 EMPLOYEE와 DEPARTMENT entity type은 WORKS FOR relationship type의 parcipate한다.

Degree, Role Names, Recursive

• degree
  • relationship type의 차수(degree)는 participate하는 entity의 개수로 나타난다.
  • 2개의 entity type이 참여한다면 binary라고 불리고, 3개면 ternary라고 불린다.
  • degree에따라 각 relationship instance가 entity type에 연결되어야하는 선의 수를 의미하게된다.
• RelationShip as attribute
  • 
  • 이 도식은 2가지 의미로 해석될 수 있는데, 직원이 일하는 부서, 혹은 부서에서 일하는 직원으로 해석될 수 있다.
• Role Name
  • relationship에 참여하는 각 entity type이 어떤 역할을 하는지 나타내는 단어.
• Recursive relationships
  • 같은 entity type이 동일한 relationship type에 다른 role로 참여하는 것을 의미.
  • 
  • EMPLOYEE entity type하나가 SUPERVISION relationship type에 다른 role로 참여하는 것을 볼 수 있다.
  • 이를 구분하기위해 1이 관리하는 role, 2가 관리받는 role을 의미한다.

Contraints On RelationShip(Structural constraints)

• RelationShip은 relationship에 참여할 수 있는 entity 조합을 제한하기위해 제약을 가질 수 있다.
• 이런 제약 조건은 2가지 경우가 있다.

1.Cardinality Ratios

• relationship에 참여할 수 있는 relationship instance들의 수를 정의한다.

• 1:1
  • MANAGES relationship, 부서-부서장이 참여.
  • 
  • 부서 1개에 부서장은 1명, 부서장은 1개의 부서만 관리
• 1:N
  • WORKS_FOR relationship, 직원-부서가 참여
  • 
  • 직원 1명은 1개의 부서에 속하지만, 부서 1개는 N명의 직원을 가질 수 있다.
• M:N
  • WORKS_ON relationship, 직원-프로젝트가 참여
  • 
  • 직원 1명은 N개의 과제를 수행할 수 있고, 과제 1개는 M명의 직원이 관리할 수 있다.

2.Participation

• 해당 relationship에 참여하는 entity set의 원소가 모두 관계에 참여하는지 아니면 부분적인 원소만 참여하는지

• total participate(existence dependency, 존재의존성)
  • WORKS_FOR relationship
  • 모든 직원은 부서에 속해 일해야한다는 회사규정이 있다면,
  • 따라서 모든 직원 entity는 부서와 WORKS_FOR 관계로 이어져야한다.
  • ERD에서 double line으로 연결된 relationship으로 표현.
• partial participate
  • MANAGES relationship
  • 직원 중 일부는 부서장이다.
  • EMPLOYEE entity set의 일부분이 DEPARTMENT의 entity와 MANAGES로 이어져야한다.
  • ERD에서 single line으로 표현된다.
• total participate를 하는 entity type이 있다면, table을 표현할때, 모든 value값을 가져야함을 의미한다.
• 가령, manages relationship에서, Manages table에서는 모든 department의 키 속성이 테이블에 존재해야함을 의미한다.

Attribute of Relationship Types

• relationship type도 attribute를 가질 수 있다.

• WORKS_ON relationship
  • 각 지원이 과제당 일하는 시간을 보관해야할때 relationship의 attribute로 Hours attribute를 넣을 수 있다.
• MANAGES relationship
  • 또한, 부서장직의 시작날짜 또한 relationship의 attribute로 정의할 수 있다.

attribute migration

• relationship의 attribute는 해당 relationship에 참여하는 entity type의 속성으로 옮길수도 있다.

1:1

• 1:1 relationship의 속성은 어느 entity type으로든 옮길 수 있다.
• 위의 MANAGES 관계에서 부서와 부서장은 1:1의 관계를 가지기때문에, department entity로 값을 가져오든, employee entity에서 값을 가져오든 동일한 값으로 결정된다.

1:N

• 1:N relationship의 속성은 N의 entity type으로 옮길 수 있다.
• WORKS_FOR 관계에서 직원과 부서는 N:1의 관계를 가진다.
• 
• 만약, 직원이 부서에서 일한 시간을 기록한다고 생각할때, 이 속성을 department로 옮기면 어떻게될까?
• 어떤 직원이 부서에서 일할지 모르니, 부서테이블은 각 부서번호마다 employee가 일한 시간을 표현할 수단을 마련할 수 없다.
• 하지만, 직원테이블에 속성을 표시한다면, column한줄만 늘리면 되기에 쉽게 이를 표현할 수 있다.
• 따라서, 해당 relationship에서 1개 relationship instance당 최소 1개의 entity를 가지는 N Side로만 attribute를 옮길 수 있다.

M:N

• M:N relationship의 속성은 어디로도 옮길 수 없다.
• WORKS_ON 관계에서 직원과 프로젝트는 M:N의 관계를 가진다.
• 직원테이블에서 직원A가 수행하는 프로젝트 p1, p2을 표현하고, hours를 표현해야하는데, 이렇게 표현하면 직원테이블의 주키의 유일성제약을 어기게된다.
• 프로젝트의 속성으로 넣는것도 마찬가지이므로 옮길 수 없다.
• 이에따라 M:N relationship의 attribute는 relationship attribute 로 정의되어야만한다.

Weak Entity Types

정의

• 일반적인 entity type들은 대부분 key attribute를 가지지만, 특이하게 key attribute가 없는 entity type들이 있다.
• key attribute가 있는 entity들을 strong | regular entity type 이라고 칭하는데에 반해, key attribute가 없는 entity를 weak entity type이라고 칭한다.

특징

• weak entity type의 entity를 식별하기위해선 반드시 다른 entity의 attribute value와 조합해서 식별해야한다.
  • 직원의 가족을 식별하기위해서는 가족의 이름, 성별 등으로만은 식별이 불가할수도있다.(만에하나 겹칠수도 있기에)
  • 따라서 직원의 ESSN과 가족의 속성을 조합해서 식별해야한다.
• 이 다른 entity를 owner entity type, identifying entity type이라고 한다.
• owner entity type과의 relation을 identifying relationship이라고 한다.
• weak entity type은 identifying relationship에 항상 total participation constraint을 가진다.
  • total participation이라고해서 항상 weak entity type은 아니다.
  • 사람<->운전면허증의 경우, 운전면허증은 사람에게 total participation을 하나, 면허증번호라는 키 속성을 가지기때문.
• 특정 가족을 찾고싶다면, 반드시 owner identifying entity의 속성값이 필요하다.
  • 만의 하나의 경우, 가족의 속성이 모두 동일한 경우도 있을 수 있기에, 특정 가족을 테이블에서 찾고싶다면 가족과 연관된 직원번호와 함께 찾아야한다.

partial key

• weak entity type내에서 동일한 owner identity와 연관된 entity를 식별하기위한 속성의 집합
  • 직원 A의 가족 B와 C가 있을때, B와 C를 구분하기위해선 이름(가족 내에서 동일 이름 안쓴다는 가정)으로 구별하게된다.
  • 책의 예시에서는 dependent의 name이 partial key로 사용된다.
• 최악의 경우에는 weak entity의 모든 속성이 partial key가 될수도 있다.

complex attribute

• 정의
  • 2개 이상의 composite, multi-valued attribute로 구성된 속성
• 모든 weak entity는 complex(composite, multi-valued) attribute로 변환될 수 있다.
  • Dependent(이름(fName, mName, lName), sex, relationship, {nationality})
    • nationality는 multivalue 예시를 위해 억지로 넣은 것. 없어도 상관없음.
• 치환조건
  • complex attribute로 변환하기위해선, 해당 weak entity가 owner identifying entity외의 다른 entity간 relationship이 없어야한다. -직원<->가족 이면서 가족<->프로젝트 일때, 직원은 owner identifying entity이지만, 프로젝트는 아님.

DB refining

1.entity 식별

• 부서, 직원, 가족, 프로젝트

2.entity 속성 식별

• 부서(이름, 번호, {위치}, 부서장, 부서장 시작날짜)
  • 키 : 이름 혹은 번호
• 직원(이름(FName, Lname, Mlnit), 주민번호, 주소, 월급, 성별, 생일, 부서, 관리자, {WorksOn(프로젝트, 시간)})
  • 키 : 주민번호
  • 주민번호((앞6),(뒤7)), 이름(FName, Lname, MiddleInitial)은 복합속성이 될 수 있으니, miniworld에 명시되어있지 않음.
• 프로젝트(이름, 프로젝트번호, 위치, 담당부서)
  • 키 : 이름 혹은 번호
• 가족(직원번호, 가족이름, 생일, 관계, 성별)
  • 키 : 직원번호 + 가족이름
• 한 직원이 여러가지 과제를 수행하고, 한 직원이 과제당 일한 시간은 Works-On속성으로 표시

3.relationship type 정의

MANAGES

• 1:1
• EMPLOYEE <-> DEPARTMENT
• EMPLOYEE는 partial participation
• DEPARTMENT는 total participation
• StartDate가 relationship attibute로 부여된다.

WORKS_FOR

• N:1
• EMPLOYEE <-> DEPARTMENT
• EMPLOYEE total participation
• DEPARTMENT total participation

CONTROLS

• 1:N
• DEPARTMENT <-> PROJECT
• DEPARTMENT total participation
• PROJECT partial participation(과제 없는 부서)

SUPERVISION

• recursive relationship, 1:N
• EMPLOYEE(supervisor) <-> EMPLOYEE(supervisee)
• both partial

WORKS_ON

• N:M
• EMPLOYEE <-> PROJECT
• EMPLOYEE total participation
• PROJECT total participation

DEPENDENT_OF

• identifying relationship
• 1:N
• EMPLOYEE <-> DEPENDENT
• EMPLOYEE partial participation, owner identifying entity type
• DEPENDENT total participation, weak entity type

4. refined attribute 삭제

• 다시 위에서 정의한 entity의 속성들을 살펴보자.
• 부서(이름, 번호, {위치}, 부서장, 부서장 시작날짜)
  • 키 : 이름 혹은 번호
• 직원(이름(FName, Lname, Mlnit), 주민번호, 주소, 월급, 성별, 생일, 부서, 관리자, {WorksOn(프로젝트, 시간)})
  • 키 : 주민번호
  • 주민번호((앞6),(뒤7)), 이름(FName, Lname, MiddleInitial)은 복합속성이 될 수 있으니, miniworld에 명시되어있지 않음.
• 프로젝트(이름, 프로젝트번호, 위치, 담당부서)
  • 키 : 이름 혹은 번호
• 가족(직원번호, 가족이름, 생일, 관계, 성별)
  • 키 : 직원번호 + 가족이

• relationship으로 표현된 attribute들을 삭제해줘야한다.

• MANAGES relationship과 중복되는 속성인 부서의 부서장, 부서장시작날짜를 삭제한다.
• CONTROLS relationship과 중복되는 속성인 프로젝트의 담당부서를 삭제.
• SUPERVISION relationship과 중복되는 직원의 관리자삭제
• WORKS_FOR relationship과 중복되는 속성인 직원의 부서삭제.
• WORKS_ON relationship은 따로 정의되었으므로, 직원에서 삭제.
• DEPENDENT_OF relationship과 중복되는 속성인 가족의 직원번호 삭제.

entity type들과 relationship의 중복성을 최소화해 아래와 같은 결과를 얻을 수 있다.

• entity type
  • 부서(이름, 번호, {위치})
  • 직원(이름(FName, Lname, Mlnit), 주민번호, 주소, 월급, 성별, 생일)
  • 프로젝트(이름, 프로젝트번호, 위치)
  • 가족(가족이름, 생일, 관계, 성별)
• relationship
  • MANAGES
  • WORKS_FOR
  • WORKS_ON
  • SUPERVISION
  • CONTROLS
  • DEPENDENT_OF

5. ER Diagram 표현방법

min-max notation

• relationship의 structural constraint(cardinality, participate)를 표현할때 각각을 따로 표현했는데, min-max notation을 사용하면 한번에 표현할 수 있다.

• 마지막 notation방식을 보면, E의 각 entity가 relationship에 participate할때 참여해야하는 최소, 최대값을 표현하고 있다.

• 1. participate constraint
     • min == 0 각 entity가 참여할수도 있고, 참여하지 않을수도 있기에 partial participate가된다.
     • min > 0 각 entity는 최소한 min번을 participate해야하므로, total participate가 된다.
• 1. cardinality constraint
     • 각 relationship에 연결된 min-max notation의 max값은 cardinality를 나타낸다.
     • 각 entity가 연결될 수 있는 다른쪽 entity

min-max notation example

• WORKS_FOR relationship type을 보면, (1,1) <-> (4,N)으로 보인다.
• participate constraint
  • EMPLOYEE entity는 relationship에 최소한 1번 참여하므로, total participate, DEPARTMENT entity 는 최소 4번 참여하므로 total participate이다.
• cardinality constraint
  • EMPLOYEE entity는 개체당 최대 1번, DEPARTMENT entity는 최대 N번까지 참여할 수 있으므로, EMPLOYEE : DEPARTMENT = N : 1의 cardinality를 가진다.

변수명 규칙

스키마 요소

• entity type -> 단수로 표현.
• entity type, relationship type -> uppercase
• attribute name은 첫 문자대문자로, 나머진 소문자
• role name은 소문자로만

이와같은 변수명 작성 규칙은 작성된 ERD를 참고하면됨.

DB 요구사항에서 파악

• entity type <- 명사
• relationship type <- 동사
• attribute type <- entity type을 묘사하는 명사
• relationship type의 이름 규칙
  • 왼쪽에서 오른쪽으로, 위에서 아래로 읽히게끔

Design choices

1. entity or attribute?
2. entity or relationship?
3. binary or ternary?

• EMPLOYEE에 address 정보를 추가해야한다고 생각해보자. 이때, address정보를 EMPLOYEE의 속성으로 추가해야할까 아니면 entity로 정의해야할까?
  • 간단하게 말하면, 주소를 기준으로 operation을 많이해야한다면, entity로 표현하는 것이 맞다.
  • 만약 employee별로 주소가 여러개일 경우 : multi-valued attribute의 entity
  • 하지만, address의 구조(도시, 도로명, 번지 등)이 중요 : composite valued attribute

이렇게 상황에 따라 다르게 표현될 수 있다.

Entity vs Attribute

Works_In -> duration

• 만약 직원이 일한 부서의 history정보를 유지하고 싶다면?
• 위와같은 ERD에서 Works_In2 relationship type은 2개이상의 값을 가질 수 없다.
• 표현하고싶어서 다양한 방법을 시도해볼 수 있는데,
  • 첫번째로는 relationship instance에 속성을 2개 만드는 것인데, 문법상 오류이다.

  • 두번째로, 홍길동 entity를 2개 만드는 것인데, 이는 개체집합오류이다.

  • 세번째로, cardinality ratio를 M:N의 관계로 바꾸는 것이다. 다대다관계로 바뀌게되면, 이는 더이상 RDBMS의 테이블로는 표현되지 못한다.

• 당연한 것이, Works_In2의 attribute from과 to를 N side인 Employees로 옮긴다고한들, Employee마다 from to 속성값을 2개이상 가지게 하려면 동일한 key 속성을 가지는 entity를 2개 정의해야하므로 이는 불가능하다.

• M:N관계로 변형되어 다수의 relationship instance를 만든다고한들, ERD를 사용해 RDBMS에서 더이상 표현되지 못한다.

• 따라서 이를 해결하기위해선 ternary relationship으로 표현해야한다.
  • 홍길동이 총무부에 배치됐을때, 역사적 정보를 저장해야한다면, 홍길동-총무부관계를 식별할 수 있는 다른 key가 필요하다. 정확하게말하면, works_in3를 weak entity로 owner identifying entity type을 employee와 department로 하여 각 관계를 식별하는게 옳다고 사려된다. 그리고 그때부터 duration이라는 entity는 from(partial key), to(partial key), department(fk), employee(fk)를 통해 테이블을 구성할 수 있다.

• 이는 스키마를 잘못 설계하면 표현할 수 있는 정보에 한계가 있다는 대표적인 예시이다.

Entity vs Relationship

Manages

• 직원 entity가 여러 부서장을 맡을 수 있다고 가정하자.(1:N관계)
• 부서장을 맡을때마다, 회식예산(dbudget)을 얻게되는데, 만약 dbudget을 각 부서별로 할당받을때는 redundancy(중복성)문제가 발생하지 않는다.
• 

• 한 부서장이 여러 부서장을 겸직할때, 부서별로 dbudget을 관리할 수 있다.
• 하지만, 여러 부서에대한 통합예산을 주게된다면 어떻게될까?
  • 이 경우, redundancy가 발생하는 문제가 발생한다.
• 

따라서, 중복성을 해결하기위해선 relationship attribute를 DEPARTMENT 측의 속성으로 표현하는게 아닌, 제 3의 entity로 표현해 binary relationship을 ternary relationship으로 표현해야한다.

• 

Binary vs Ternary

Policies

• 가정
  • 각 보험정책은 1명의 직원만 소유할 수 있다.
• 직원-부양가족-정책의 ternary relationship이 성립되어있을때,
  • 이때 Employee-Policies-Dependents 쌍은 1개씩만 존재할 수 있으므로, 1개 정책이 1개의 dependent만 커버할 수 있다는 의미이다.

• 현실세계와 동떨어져 만들어졌으므로, 이 ERD는 잘못 만들어진 것이다.

• 따라서, 이를 binary로 표현해야한다.

• 부양가족은 policy를 owner identifying entity type, beneficiary를 identifying entity type로 표현해 보험정책에 1:N으로 만들어줘야한다.
• 보험정책을 가진 직원은 부양가족을 당연하게 가지게되고,
• 1개 보험정책은 N명의 부양가족을 커버할 수 있게된다.
• 물론, 여기서 만약 부양가족이 다른 entity와 관계를 맺는다면, weak entity가 아닌, strong entity로 만들어줘야한다.

Can supply

• 하지만 ternary를 binary로 표현하는게 항상 옳은 것은 아니다.

• 이를 예시로 들어보면 supply라는 계약은 supplier, project, part로 이뤄진다.

• 이를 binary로 변환한다면 아래와같이 될 수 있다.

• 여기서 문제점은, qty가 식별되기 위해서는 supplier, project, part가 모두 필요한데, 이를 표현할 관계나 개체가 없다는 것이다.
• can_supply에 넣는다고한들, 기존에 project정보를 표현할수는 없다.

• 이를 binary로 나타내기위해서는 SUPPLY를 relationship이 아닌, 3개의 binary relationship으로 연결된 Entity로 표현한다.

Job Offer

• 회사와 직업지원자간 INTERVIE라는 관계가 있을 때, JOB OFFER라는 entity를 빼내고싶으면 어떻게 해야할까?

• (b) : JOB OFFER가 없을때, ternary가 깨져버리므로 문법오류
• (c) : relationship간 연결 -> 오류
• (d) : 개체관계를 묶어서 result라는 관계 도출 -> 오류

• 결국, INTERVIEW라는 entity는 company와 job_applicant없이는 표현할 수 없으므로, weak_entity type으로 표현될 수 있다.

ERD 작성시 주의사항

1. entity와 entity는 직접 연결할 수 없다.
2. attribute와 attribute만의 연결은 불가능하다.
3. relationship간의 연결은 불가능하다.
   • Works_In 연장
4. 동일한 entity간 2개의 연결은 불가능하다.
   • 
5. 개체집합오류
   • 
6. 테이블 속성값을 2개 가진다.
   •