Chapter 3: 엔터티-관계(ER) 모델을 사용한 데이터 모델링

데이터베이스 설계 프로세스 개요

데이터베이스 설계 프로세스 개요

• 데이터베이스 응용 프로그램
• 특정 데이터베이스와 관련된 프로그램들로 질의 및 업데이트를 구현을 의미: 예를 들면 은행(BANK) 데이터베이스 응용 프로그램
• 응용 프로그램 디자인과 데이터베이스 디자인 두 가지 주요 활동을 포함함
• 특정 데이터베이스와 관련된 프로그램들로 질의 및 업데이트를 구현을 의미: 예) 은행(BANK) 데이터베이스 응용 프로그램
• 응용 프로그램 디자인과 데이터베이스 디자인 두 가지 주요 활동을 포함함

• 응용 프로그램 디자인
• DB에 접근하는 프로그램과 인터페이스에 중점을 둠
• 일반적으로 소프트웨어 공학의 일부로 간주됨

• 데이터베이스 디자인
• 개념적 => 데이터베이스 응용 프로그램에 대한 개념 스키마를 디자인하는 것에 중점
• 이 챕터의 중점
• 논리적 (표현적; DBMS 특화)
• 물리적

데이터베이스 설계 과정의 간략한 개요

• 단계 1: 요구 사항 수집 및 분석
• 기능적 / 데이터 요구 사항

• 단계 2: 개념적 설계
• 개념적 스키마

• 단계 3: 논리적 설계 (또는 데이터 모델 매핑)
• 논리적 스키마

• 단계 4: 물리적 설계
• 내부 스키마: 내부 저장 구조, 파일 구성, 색인, 접근 경로 및 데이터베이스 파일에 대한 매개변수

엔티티 유형, 엔티티 집합, 속성, 키

개념: 엔티티와 속성

• Entity-Relationship (ER) 모델은 데이터를 다음과 같이 설명함

• 엔티티, 관계, 그리고 속성.

• 엔티티(Entity(s))
• ER 모델의 기본 개념
• DB에서 표현되는 미니월드 내의 특정한 것이나 객체
• 예) 물리적 존재(사람, 자동차, 집) 또는 개념적 존재(회사, 직업, 대학 강좌)

• 속성(Attribute(s))
• 엔티티를 설명하는 특정한 특성
• 예) 직원 엔티티와 관련된 이름, 주민등록번호, 주소, 성별, 생년월일
• 엔티티는 각 속성에 대한 특정 값이 있을 것임
• 각 속성에는 관련된 값 집합(또는 데이터 타입)이 있음
• 예) 정수, 문자열, 날짜, 열거형 타입...

속성 종류

• 단순 (원자적)
• 각 엔티티는 속성에 대한 단일 원자값을 가짐
• 예) 주민등록번호, 성별

• 합성
• 속성은 여러 구성요소로 이루어질 수 있음
• 예) 주소 (아파트 번호, 방 번호, 거리, 도시, 주, 우편번호, 국가) 또는 이름 (이름, 성).
• 구성요소는 일부 구성요소 자체가 “합성”인 계층을 형성할 수 있음
• 다중 값 (Multi-valued)

• 엔티티는 해당 속성에 대해 여러 값을 가질 수 있음
• 예: CAR 엔티티의 "색상" 또는 STUDENT 엔티티의 "이전 학위".
• ER에서 “{“, “}”로 표시됨
• 예) {색상}, {이전 학위}
• 합성 속성과 다중 값 속성은 임의의 수준까지 중첩될 수 있음; 매우 드뭄
• 예) STUDENT의 이전 학위: 합성 다중 값 속성, {이전 학위 (대학, 연도, 학위, 분야)}로 표시됨
• 여러 이전 학위 값 (예: 학사, 석사, 박사)이 존재할 수 있음

• 저장된 속성 vs 파생된 속성
• 저장된 속성: 기록된 값이 있는 것
• 파생된 속성: 저장된 것에서 값이 파생될 수 있는 것
• 생년월일 vs. 나이
• DEPARTMENT 엔티티의 직원 수

• 복잡한 속성
• 합성 속성과 다중 값 속성의 혼합 속성

엔티티 유형, 엔티티 집합

• 엔티티 유형 (외연)
• 동일한 기본 속성을 가진 엔티티의 유형 (또는 그룹) (스키마와 같이)
• 예) EMPLOYEE, COMPANY

• 엔티티 집합 (외연)
• 데이터베이스에서 특정 엔티티 유형의 모든 엔티티의 컬렉션 (상태와 같이)
• 예) EMPLOYEE: e1, e2, ... ,

엔티티 유형의 키 속성

• 키 속성
• 각 엔티티가 고유한 값을 가져야 하며 고유하게 식별될 수 있는 엔티티 유형의 속성
• 예) EMPLOYEE의 SSN, STUDENT의 Student_number

• 엔티티 유형에 키 속성이 둘 이상 있을 수 있음
• 예) CAR

속성의 값 집합 (도메인)

• 각 단순 속성은 값 집합 (또는 값의 도메인)과 연결됨
• 날짜는 MM-DD-YYYY의 값을 가지며, 각 문자는 정수에 해당함
• 나이는 16에서 70 사이의 값을 가지며, 성(lastname)은 최대 15자까지만 가능함

• 값 집합은 개별 엔티티와 관련된 속성의 값 집합을 지정함

• 값 집합은 대부분의 프로그래밍 언어에서 사용 가능한 기본 데이터 유형과 유사함
• 예) 정수, 문자열, 더블, ...

[인라인 부록] 값 집합의 수학적 표현

• 값 집합 (예: {10,...,99})를 가지는 엔터티 집합 (예: PERSON)의 속성 (예: 나이)는 다음과 같이 정의됨
여기서 는 의 멱집합을 나타냄

• : 엔티티 에 대한 속성 의 값

• 위의 정의는 단일 값 및 다중 값 속성도 포함함

• 합성 속성 에 대해서는? (예: birth_date(yr, mon, day))

• 여기서 은 를 구성하는 단순한 구성 요소 속성의 값 집합임

엔터티-관계(Entity-Relationship, ER) 다이어그램에서의 엔터티 및 속성에 대한 표기법과 예시

엔터티

• 일반적으로 직사각형으로 표시됨. 엔터티의 이름은 직사각형 내부에 적음

속성

• 타원형으로 표시되며, 해당 속성의 이름을 타원형 내부에 적음

• 타원형은 해당 엔터티를 나타내는 직사각형에 연결됨

키 속성

• 엔터티 타입 내에서 각 엔터티를 고유하게 식별할 수 있는 속성

• 각 엔터티는 이 키 속성에 대해 고유한 값을 가져야 함

다중 값 속성

• 엔터티가 가질 수 있는 여러 값을 표현하는 속성

• 여러 개의 값으로 구성될 수 있음
• 예) "전화번호"는 사용자가 여러 개 가질 수 있는 다중 값 속성일 수 있음

합성 속성

• 여러 개의 기본 속성들로 구성된 속성

• 여러 개의 다른 속성들을 합쳐서 표현하는 속성
• 예) "주소"는 "도시", "구", "동"과 같은 다른 속성들로 구성될 수 있음

유도 속성

• 다른 속성에서 파생될 수 있는 속성

• 다른 속성의 값으로부터 계산되거나 유도될 수 있음
• 예) "나이"는 "생년월일" 속성으로부터 유도될 수 있음

예시 (CAR 엔터티 타입의 ER 다이어그램 표기법)

데이터베이스의 초기 개념 설계

(간략화된) 요구사항

• "COMPANY"는 여러 개의 DEPARTMENT들로 구성됨
• 각 부서는 고유한 이름, 고유한 번호를 가지며, 특정 직원이 그 부서를 관리함
• 또한 해당 직원이 부서 관리를 시작한 날짜를 기록함
• 부서는 여러 위치를 가질 수 있음

• 부서는 여러 PROJECT들을 관리함
• 각 프로젝트는 고유한 이름, 고유한 번호 및 단일 위치를 가짐

• 각 EMPLOYEE에는 몇 가지 속성이 있음
• 이름, 주민등록번호(SSN), 주소, 급여, 성별, 생년월일

• 각 직원은 하나의 부서에서 근무하지만 여러 프로젝트에서 일할 수 있음

• 회사 데이터베이스는 다음 내용 또한 기록함
• 직원이 각 프로젝트에서 주당 근무하는 시간 수와 각 직원의 직접적인 감독관에 관한 정보
• 각 직원은 보험 때문에 여러 명의 부양가족들을 가질 수 있음

• 각 종속자는 이름, 성별, 생년월일 및 직원과의 관계를 가짐

COMPANY 데이터베이스 스키마에 대한 초기 개념 설계

• 요구사항을 기반으로 네 가지 초기 엔터티 타입이 있음
1. DEPARTMENT
• 속성: 이름, 번호, 위치, 관리자, 관리 시작 날짜
2. PROJECT
• 속성: 이름, 번호, 위치, 관리 부서
3. EMPLOYEE
• 속성: 이름, 주민등록번호, 주소, 급여, 생년월일, 부서, 감독관
4. DEPENDENT
• 속성: 직원, 종속자 이름, 성별, 생년월일, 직원과의 관계

관계 유형, 관계 세트, 역할 및 구조적 제약 조건

• 여러 엔터티 유형 간에는 여러 가지 암시적 관계가 있음

• 한 엔터티 유형의 속성이 다른 엔터티 유형을 참조할 때마다 어떤 관계가 존재함

관계, 관계 유형, 관계 세트, 인스턴스, 관계 유형의 차수

• 관계
• 특정한 의미로 두 개 이상의 구별된 엔터티를 관련시킴
• 예1) EMPLOYEE 홍길동은 GPT-5 PROJECT에서 일함
• 예2) EMPLOYEE 안철수는 R&D DEPARTMENT에서 일함

• 관계 유형
• 개의 엔터티 유형 간의 연관성의 유형임
• 같은 유형의 관계를 가진 관계의 그룹
• 예) WORKS_ON, WORKS_FOR
• 관계 유형의 차수: 참여하는 (구별된) 엔터티 유형의 수
• WORKS_ON과 WORKS_FOR의 차수는?
• 예) 단항 (1) (자기 자신을 위한), 이항 (2) (두 개가 참여), 삼항 (세 개 정도 참여), ...

• 관계 세트
• 개의 엔터티 유형 사이의 관계 집합
• 관계 인스턴스 의 집합으로,
• 각 는 개의 개별 엔터티 ()를 연결하며,
• 의 각 엔터티 는 인 엔터티 세트 의 구성원

관계 유형의 차수

관계 유형 vs. 관계 집합

역할 이름 (Role Name)

• 관계 인스턴스 내에서 엔터티 유형의 참여하는 엔터티가 하는 역할에 의미를 부여함

• 관계가 무엇을 의미하는지 설명하는데 도움이 됨

• WORKS_FOR 관계 유형의 경우,
• EMPLOYEE의 역할: 직원 또는 근로자
• DEPARTMENT의 역할: 부서 또는 고용주

• 모든 참여하는 엔터티 유형이 명확할 경우 기술적으로 필요하지 않음
• 엔터티 유형 이름 = 역할 이름

• 같은 엔터티 유형이 다른 역할로 관계 유형에 두 번 이상 참여하는 경우는?
• 예: 같은 직원에 대한 주요 역할, 두 번째 역할? (직원, 관리자)

재귀 관계 (또는 자기 참조 관계)

• 같은 엔터티 유형 내의 엔터티들 사이의 관계 유형을 나타냄

• 참여하는 두 엔터티 유형이 모두 다른 역할로 동일한 엔터티 유형임

• EMPLOYEE와 EMPLOYEE 사이의 SUPERVISION(감독) 관계
• 감독자 또는 상사의 역할로서의 EMPLOYEE
• 근로자 또는 부하직원의 역할로서의 EMPLOYEE

이진 관계 유형에 대한 구조적 제약 조건

• 시나리오
• 모든 직원은 반드시 하나의 부서에서 근무해야 함
• 일부 직원들은 자신의 부서를 관리함
• 이러한 종류의 "제약 조건"은 ER에서 어떻게 표시될 수 있을까?

1. 기수 비율 (이진 관계의)
• 엔터티가 참여하는 관계 인스턴스의 최대 수를 지정함
• 예를 들어, 1:1, 1:N, N:1 또는 M:N
• ER 다이어그램에서 관계 테두리에 적절한 숫자를 표시하여 나타냄

2. 참여 제약 조건 (각 참여하는 엔터티 유형에 대해)
• 엔터티의 존재가 관계 유형을 통해 다른 엔터티와 관련되어 있어야 하는지 여부를 명시함
• 참여할 수 있는 관계 인스턴스의 최소 수를 지정함
• 모든 직원은 반드시 어느 부서에서든 근무해야 함
• 모든 직원 엔터티 집합의 모든 엔터티는 WORKS_FOR를 통해 부서와 관련되어 있어야 함
• 모든 직원이 부서를 관리할 필요는 없음
• 직원 엔터티 집합의 일부는 MANAGES를 통해 어떤 부서 엔터티와 관련될 수 있음
• 전체 참여 (존재 종속성이라고도 함)
• ER 다이어그램에서 두 배 선으로 표시됨
• 부분 참여 (기본값)
• ER 다이어그램에서 단일 선으로 표시됨

MANAGES: EMPLOYEE와 DEPARTMENT 간의 1:1 관계의 관계 인스턴스

• "MANAGES"는 관계의 이름이며, 이는 특정 직원이 특정 부서를 관리한다는 의미의 관계를 나타냄

• 1:1 관계는 한 직원이 한 부서만 관리하며, 그 반대로 한 부서도 한 명의 직원에 의해서만 관리됨

WORKS_ON: EMPLOYEE와 PROJECT 간 M:N 관계의 관계 인스턴스

• EMPLOYEE(직원)와 PROJECT(프로젝트) 사이의 M:N 관계에 있는 관계 인스턴스들을 나타냄

• "WORKS_ON" 관계는 직원이 여러 프로젝트에 참여할 수 있고, 한 프로젝트에는 여러 직원이 참여할 수 있다는 것을 의미함

WORKS_FOR: DEPARTMENT와 EMPLOYEE 간 1:N 관계의 관계 인스턴스

• WORKS_FOR 관계 집합 내의 일부 인스턴스들

• 이 집합은 DEPARTMENT와 EMPLOYEE 사이의 WORKS_FOR라는 관계 유형을 나타냄

관계 유형의 속성

• 관계 유형도 엔터티 유형과 유사한 관계 속성을 가질 수 있음
• 레이첼은 ECM 프로젝트에서 주당 몇 시간(HoursPerWeek) 일하는가?
• 챈들러가 자신의 부서를 관리하기 시작한 날짜(Start_date)는 언제인가?

• 대부분의 관계 속성은 M:N 관계에 사용됨
• HoursPerWeek의 값은 특정 (직원, 프로젝트) (예: (레이첼, ECM)) 조합에 따라 다름

• 1:N (WORKS_FOR) 관계 (예: DEPT : EMP)에서는 관계 속성 (예, Emp_start_date)을 관계의 N-측에 있는 엔터티 유형으로 이동시킬 수 있음
• 1:1 관계에서는?

약한 엔터티 타입

개념

• 약한 엔티티 타입(Weak Entity Types): 자신만의 주요 속성(key attributes)이 없는 엔티티 타입을 의미함
• 이는 '하위(child)' 또는 '종속(subordinate)' 엔티티 타입으로도 불림
• 지금까지 논의한 일반적인 (또는 강한) 엔티티 타입과 대조됨

• 약한 엔티티 타입의 개체들 (자기 자체로는 존재할 수 없음)
• 다른 엔티티 타입, 즉 부모(parent) 또는 주요(dominant), 식별(identifying), 소유주(owner) 엔티티 타입과 특정한 관계에 있음으로써 식별됨
• 식별 관계: 약한 엔티티 타입과 그 소유주를 연결하는 관계 타입을 의미함
• 예) Java의 클래스 - 인스턴스, EMPLOYEE - DEPENDENT와 같은 관계

• 약한 엔티티 타입은 항상 그 식별 관계에 있어 부분적(partial) vs 전체적(total) 참여 제약이 있음
• 왜 그럴까?

• 약한 엔티티 타입의 개체들
• 다음의 조합에 의해 식별됨
1. 약한 엔티티 타입의 부분 키(Partial key): 동일한 소유주 엔티티와 관련된 약한 엔티티를 고유하게 식별할 수 있는 속성
• 예) Dependent_id (또는 최악의 경우, 모든 약한 엔티티의 속성의 복합 속성)
2. 식별 관계 타입에서 관련된 특정한 (부모) 엔티티
• 일반적으로 부모의 아이디 (예: Employee_id) 만으로 충분함

• ER 다이어그램의 표기법

COMPANY 데이터베이스의 ER 설계 정제하기

엔티티 타입 간의 식별 관계

• 이전 요구 사항을 검토한 후 여섯 개의 관계 타입이 식별되었음
• 모든 관계가 "이진" 관계라는 것에 주목

• 아래에 참여하는 엔티티 타입과 함께 나열되어 있음
• WORKS_FOR: EMPLOYEE와 DEPARTMENT 사이
• MANAGES: EMPLOYEE와 DEPARTMENT 사이
• CONTROLS: DEPARTMENT와 PROJECT 사이
• WORKS_ON: EMPLOYEE와 PROJECT 사이
• SUPERVISION: EMPLOYEE(감독자로서)와 EMPLOYEE(감독받는 자로서) 사이
• DEPENDENTS_OF: EMPLOYEE와 DEPENDENT 사이

관계 타입에 대한 논의

• 세밀화된 설계에서 초기 엔티티 타입의 일부 속성들은 "관계"로 세밀화됨
• DEPARTMENT의 매니저 -> MANAGES로
• EMPLOYEE의 Works_On -> WORKS_ON으로
• EMPLOYEE의 부서 -> WORKS_FOR로
• PROJECT의 Controlling_Department -> CONTROLS로
• EMPLOYEE의 감독 -> SUPERVISION으로

• 일반적으로 관계에 참여하는 동일한 엔티티 타입들 사이에 여러 관계 타입이 존재할 수 있음
• 그 경우에는 서로 다른 의미와 서로 다른 관계 인스턴스를 주어야 한다는 것을 확인해야 함
• 예) MANAGES와 WORKS_FOR는 EMPLOYEE와 DEPARTMENT 사이의 별개의 관계 타입임

관계 구조적 제약 조건에 대한 추가 논의

• 관계 타입 에서 엔티티 타입 의 각 참여에 대한 제약 조건을 지정함
• 예) 의 각 엔티티 는 R에서 최소 개부터 최대 개의 관계 인스턴스에 참여한다고 가정
• 로 표기됨 (더 정확함)

• 기본값 (제약 없음): (부분 참여), (제한 없음)

• 모든 경우에 대해, 이어야 함

• 예시:
• 부서는 정확히 한 명의 관리자를 가지며, 직원은 최대 한 개의 부서만 관리할 수 있음
• MANAGES에서 DEPARTMENT의 참여에 대해 로 변환됨
• MANAGES에서 EMPLOYEE의 참여에 대해 로 변환됨
• 직원은 정확히 하나의 부서에서 일할 수 있지만, 부서는 임의의 수의 직원을 가질 수 있음
• WORKS_FOR에서 EMPLOYEE의 참여에 대해 로 변환됨
• WORKS_FOR에서 DEPARTMENT의 참여에 대해 로 변환됨

ER 다이어그램에서 관계를 위한 표기법

COMPANY 데이터베이스의 초기 설계

COMPANY 데이터베이스를 위한 세밀화된 ER 스키마 - 참여 제약 조건의 표기법을 사용하여 (역할 이름과 함께)

요약

• 엔터티-관계(ER) 데이터 모델은 데이터베이스 설계에 널리 사용되는 데이터 모델임
• ER 모델 개념: 엔터티, 속성, 관계
• ER 모델 내의 제약 조건들
• ER 스키마는 데이터베이스의 전반적인 논리 구조를 나타냄

• COMPANY 데이터베이스를 위한 개념 스키마 설계를 단계별로 사용하는 ER

• 엔터티는 실세계에 존재하는 객체임
• 다른 객체와 구분 가능함

• 관계는 여러 엔터티 간의 연관이 있음
• 관계 집합은 동일한 유형의 관계들의 집합임
• 엔터티 집합은 동일한 유형의 엔터티들의 집합임

• 매핑 카디널리티는 관계 집합을 통해 다른 엔터티에 연결될 수 있는 엔터티의 수를 나타냄

• 약한 엔터티 집합: 기본 키를 형성하기에 충분한 속성이 없는 엔터티 집합임 (강한 엔터티 집합과 대비)

• ER 다이어그램으로 지정된 데이터베이스 설계는 관계 스키마의 모음으로 표현될 수 있음
• ER 다이어그램 - 표기법
• DB의 각 엔터티 집합 및 관계 집합에 대해 해당 엔터티 집합 또는 관계 집합의 이름이 지정된 고유한 관계 스키마가 있음
• 이것은 ER 스키마에서 관계형 DB 설계를 도출하는 기반이 됨

에필로그

스키마 구성 요소에 대한 적절한 명명을 위한 일반 지침

• 엔터티 유형의 이름은 단수(복수형이 아닌)로 표기

• 엔터티 유형과 관계 유형의 이름은 대문자로 표기

• 속성 이름의 첫 글자는 대문자로 시작

• 역할 이름은 소문자로 (첫 글자를 대문자로 할까?)

• 엔터티 유형 이름에는 명사 사용

• 속성 이름에 추가 명사 사용

• 관계 유형 이름에는 동사 사용

• 이진 관계 이름은 읽을 수 있게

• 왼쪽에서 오른쪽으로

• 위에서 아래로 (DEPENDENTS_OF 관계 유형의 경우, 그 반대 방향으로)

ER 개념 설계에 대한 설계 선택

• 어떤 개념은 먼저 "속성"으로 모델링될 수 있고 나중에 "관계"로 세밀화될 수 있음 (개념: 속성 -> 관계)
• 다른 엔터티 유형을 참조하는 것으로 판단될 때
• 이러한 속성 쌍은 나중에 이진 관계로 세밀화됨
• 그 후, 원래의 엔터티 유형에서 제거됨

• 속성은 여러 엔터티 유형에 존재할 때 일반적인 (또는 독립적인) 엔터티 유형이 될 수 있음
• 예) 대학 데이터베이스의 DEPARTMENT

• 또는 일반 엔터티 유형이 된 속성 (예: Dept_name)은 그것이 다른 엔터티 유형과만 관련이 있을 때 원래의 엔터티 유형의 속성으로 강등될 수 있음

• 이진 관계 -> n-ary 관계: 더 많은 엔터티 유형이 기존 관계에 참여할 때