엔티티-관계 데이터모델(데이터베이스)

표현적 데이터 모델(구현 데이터 모델)

일반 사용자들이 이해할 수 있는 개념을 제공한다. 데이터 저장 구조의 세부사항을 은폐하지만 컴퓨터 상에서 직접 구현이 가능하다. 상용DBMS에서 주로 사용한다.

엔티티 애트리뷰트 관계

엔티티는 데이터베이스 내에 표현된 작은 세계에 존재하는 객체 또는 실체이다. 애트리뷰트들은 엔티티를 기술하기 위한 속성들이다. 두 개 또는 그 이상의 엔티티들을 특정한 의미로 연관 짓는 것이다.

구조적 제약조건

카디낼러티 제약조건은 엔티티가 참여할 수 있는 최대 관계 인스턴스들의 수를 명시, 1:1, 1:N, N:M 이다. 참여 제약조건은 각 엔티티가 참여할 수 있는 관계 인스턴스의 최소 수를 명시, 전체 참여, 부분 참여 이다.

약한 엔티티 타입

키 애트리뷰트가 없는 엔티티, 존재가 다른 엔티티에 의존한다. 약한 엔티티는 식별 엔티티 타입과 식별 관계 타입에 참여해야 한다.

구조적 제약조건

관계의 제약조건, 카디낼러티 제약조건, 참여 제약조건이 있다.

3진 관계와 n-ary관계

차수가 3인 관계 타입을 3진 관계라 하고, 차수가 n인 관계를 n-ary 관계라 한다.

데이터 모델링

• 데이터 모델
  • 현실 세계의 정보들을 컴퓨터에 표현하기 위해 단순화, 추상화하여 체계적으로 표현한 모형
• 데이터 모델의 분류
  • 물리적 데이터 모델(저수준 데이터 모델) : 어떻게 데이터가 컴퓨터에 저장되는지의 세부 사항을 명시하는 개념을 제공
  • 개념적 데이터 모델(고수준 데이터 모델) : 사용자들이 데이터를 인식하는 방식에 대한 개념을 제공
  • 표현적 데이터 모델(구현 데이터 모델) : 일반 사용자들이 이해할 수 있는 개념을 제공, 데이터 저장 구조의 세부 사항을 은폐하지만 컴퓨터상에서 직접 구현 가능, 상용 DBMS에서 주로 사용함

3단계-스키마 아키텍처

• 외부 단계 또는 뷰 단계
  • 특정 사용자 그룹이 관심을 갖는 부분을 나타내고 나머지는 은폐함
• 개념 단계
  • 전체 사용자를 위한 데이터베이스의 구조를 기술함
  • 엔티티, 관계, 연산, 제약 조건들에 중점
• 내부 단계
  • 저장구조의 세부 사항과 접근 경로를 기술
• 3단계-스키마 아키텍처 목적
  • 논리적 데이터 독립성 : 외부 스키마나 응용 프로그램을 변경하지 않으면서 개념 스키마를 변경할 수 있는 성질
  • 물리적 데이터 독립성 : 개념 스키마를 변경하지 않으면서 내부 스키마를 변경할 수 있는 성질

관계형 데이터베이스 설계 절차 개요

• 요구사항 수집 및 분석
• 개념적 설계 : 객체-관계(relationship) 모델
• 논리적 설계 : 관계(table) 모델
• 물리적 설계 : 물리적 저장구조, 인덱스(해쉬, B+트리)

고수준의 개념적 데이터 모델

데이터베이스 설계의 주요 단계

• 요구사항 수집 및 분석(Requirement Analysis)
• 개념적 설계(Conceptual design): 개념적 스키마, ER Model
• 논리적 설계(Logical design) : 논리적(개념적) 스키마, Relational Model
• 물리적 설계(Physical design)
• 

엔티티, 엔티티타입, 애트리뷰트, 키

엔티티와 애트리뷰트

• 엔티티는 데이터베이스 내에 표현된 작은 세계에 존재하는 객체 또는 실체
  • ex) EMPLOYEE 홍길동, DEPARTMENT 연구부, PROJECT X-프로젝트 등이 있음
• 애트리뷰트는 엔티티를 기술하기 위한 속성
  • ex) EMPLOYEE 엔티티는 속성으로 Name, SSN, Address, Sex, BirthDate를 가짐
• 엔티티는 자신의 각 애트리뷰트에 대해, 값을 가짐
  • ex) 한 특정한 사원 엔티티는 Name=＇홍길동', SSN='1234567', Address ='경기도 덕양구', Sex='M', BirthDate=‘2009-01-15‘를 값으로 가짐
• 각 애트리뷰트는 정수, 실수, 문자열과 같이 자신에게연계된 값 집합(데이터 타입, 도메인)을 가짐

애트리뷰트 타입

• 단순 애트리뷰트(Simple Attribute) : 하나의 요소만으로 구성되는 애트리뷰트
  • ex) SSN, Salary
• 복합 애트리뷰트(Composite Attribute) : 복수 개의 요소들로 구성되는 애트리뷰트
  • ex) Address (Apt#, House#, Street, City, State, ZipCode, Country) 또는 Name (FirstName, MiddleName,LastName)
• 다치 애트리뷰트(Multi-valued Attribute) : 여러 값을 가질 수 있는 애트리뷰트
  • ex) {Color} 로 표기되는 CAR 의 색 또는 {PreviousDegrees} 로 표기되는 STUDENT의 이전 학위 내역
• 일반적으로 복합 및 다치 애트리뷰트는 몇 단계로 내포될 수 있지만 그런 경우는 흔하지 않음
  • STUDENT의 PreviousDegrees는 {PreviousDegrees (College, Year, Degree, Field)}로 표기되는 복합 다치 애트리뷰트일 수 있음

엔티티타입과 키 애트리뷰트

• 엔티티타입
  • 동일한 애트리뷰트들을 갖는 엔티티들의 집합으로 정의함
• 키 애트리뷰트
  • 한 엔티티 타입에서 각 엔티티가 유일한 값을 가지는 애트리뷰트를 그 엔티티타입의 키 애트리뷰트라 함 (보통은 단일 키(Single Key) 형태)
  • ex) 사원의 사번, 학생의 학번, 선원의 선원번호
• 복합 키(Composite Key) 형태
  • ex) 학생의 (이름, 학과), 예약의 (선원번호, 선박번호)
• 엔티티타입은 한 개 이상의 키를 가질 수 있음
  • ex) : CAR 엔티티타입은 다음과 같이 2개의 키를 가짐차량 고유 번호(VehicleIdentificationNumber), 차량 넘버(VehicleTagNumber)

요구사항으로부터 엔티티 식별

• 
• 
• 점선으로 이중 선은 유도 속성

관계, 관계타입, 관계집합, 구조적제약조건

관계, 관계타입, 관계집합

• 관계(relationship)는 두 개 또는 그 이상의 엔티티들을 특정한 의미로 연관 짓는 것
  • ex) EMPLOYEE Sim은 ProductX PROJECT에서 일하며, EMPLOYEE Han은 Research DEPARTMENT를 관리한다
• 같은 형의 관계들은 관계타입으로 그룹화됨
  • ex) EMPLOYEE들과 PROJECT들이 참여하는 WORKS_ON 관계타입
  • ex) EMPLOYEE들과 DEPARTMENT들이 참여하는 WORKS_FOR 관계타입
• 데이터베이스에 표현되어 있은 관계 인스턴스의 집합 또는 관계타입의 현재 상태를 관계집합이라고 함
• 관계타입의 차수(Degree)는 참여하는 엔티티타입의 개수임
  • WORKS_ON 과 WORKS_FOR 는 모두 이진 관계
• 두 엔티티타입들에 대해 한 개 이상의 관계타입이 있을 수 있음
  • ex) EMPLOYEE와 DEPARTMENT 간의 관계 WORKS_FOR 와 관계 MANAGES는 서로 다른 연관 의미를 가짐
• 관계타입의 애트리뷰트
  • 엔티티타입처럼 관계타입도 애트리뷰트들을 가질 수 있다
  • 사원이 프로젝트에 근무하는 주당 시간을 기록하기 위한 WORKS_ON 관계타입에 Hours 애트리뷰트 추가
  • 관리 사원이 부서를 관리하기 시작한 날짜를 기록하기 위한 MANAGES 관계타입에 Start_date 애트리뷰트 추가

구조적 제약조건(관계타입에서의 제약조건)

• 카디낼러티 제약조건(Cardinality Constraints)
  • 엔티티가 참여할 수 있는 최대 관계 인스턴스들의 수를 명시함, WORKS_FOR에서 Department: Employee 는 1:N 인데 이는 한 부서가 다수의 사원들과 연관되고 한 사원은 하나의 부서와 연관됨을 의미
  • 이진 관계에서 가능한 카디낼러티 비율은 1:1, 1:N, N:M
  • MANAGES에서 Department : Employee는 1:1
  • WORKS_ON에서 Employee : Project 는 N:M
• 참여 제약조건(Participation Constraints)
  • 관계 타입에서 한 엔티티의 존재가 연관되어 있는 다른 엔티티에 의존하는지의 여부를 명시
  • 각 엔티티가 참여할 수 있는 관계 인스턴스의 최소 수를 명시하므로 최소 카디낼러티
    제약조건이라고도 함
  • 전체 참여(Total Participation)와 부분 참여(Partial Participation)가 있음
  • 모든 사원이 반드시 특정한 부서에 소속되어 근무해야 한다면, 사원 엔티티는 그것이 적어도 하나의 WORKS_FOR 관계 인스턴스에 참여할때만 존재할 수 있음
  • 이때 EMPLOYEE가 WORKS_FOR에 참여하는 것은 전체참여
  • 모든 사원이 반드시 한 부서를 관리하는 것이 아니므로 EMPLOYEE가 MANAGES 관계 타입에 참여하는 것은 부분참여

약한 엔티티타입

• 키 애트리뷰트가 없는 엔티티
  • 존재가 다른 엔티티에 의존
  • 하지만 존재 종속성이 있다고 해서 반드시 약한 엔티티는 아님
  • ex) DRIVERS_LICENSE(운전 면허) 엔티티는 PERSON(사람) 엔티티와 연관되지 않는 한 존재할 수 없지만, 자신의 키 속성으로 License_number(면허증 번호)를 가지고 있기 때문에 약한 엔티티는 아님
  • 약한 엔티티는 식별 엔티티타입과 식별 관계타입에 참여해야 함
  • 약한 엔티티들은 다음의 조합에 의해 식별됨
    • 약한 엔티티타입의 부분 키(Partial key) + 식별 엔티티타입의 키

ER 설계의 개선

COMPANY 데이터베이스에 대한 ER 설계의 개선

• 초기 엔티티 설계에서 관계를 나타내는 애트리뷰트들을 관게 타입으로 변환하여 개선

• 각 관계타입의 카디낼러티와 참여 제약은 요구사항들로부터 결정됨

• 카디낼러티와 참여 제약이 요구사항들로부터 결정될 수 없다면 데이터베이스 구축을 의뢰한 고객과 협의해야 함

• 초기 엔티티타입과 속성

  • 

• MANAGES(관리) 관계 타입

  • DEPARTMENT의 Manager 속성과 Manager_start_date 속성을 관계타입으로 변환
  • EMPLOYEE와 DEPARTMENT 사이
  • 카디낼러티 비율 1:1
  • EMPLOYEE는 부분 참여
  • DEPARTMENT는 요구사항 명세만으로 부족하여 고객과 협의 결과, 부서에는 항상 그 부서를 관리하는 관리자가 있어야 함을 도출
  • 이것은 DEPARTMENT가 전체 참여임을 의미

• WORKS_FOR(근무) 관계 타입

  • 어떠한 엔티티타입의 속성으로도 표시되어 있지 않지만 요구사항을 반영하여 도출되는 관계타입
  • DEPARTMENT와 EMPLOYEE사이
  • 카다낼러티 비율 1: N
  • DEPARTMENT는 전체 참여
  • EMPLOYEE도 전체 참여

• CONTROLS(제어) 관계 타입

  • PROJECT의 Controlling_department 속성을 관계타입으로 변환
  • DEPARTMENT 와 PROJECT 사이
  • 카다낼러티 비율 1: N
  • 고객 협의 결과, PROJECT는 전체 참여
  • 고객 협의 결과, DEPARTMENT는 부분 참여

• WORKS_ON(참여) 관계 타입

  • EMPLOYEE의 Works_on 속성을 관계타입으로 변환
  • EMPLOYEE와 PROJECT 사이
  • 고객 협의 결과, 한 사원은 여러 프로젝트에 참여할 수 있고, 한 프로젝트에 여러 명의 사원들이 참여할 수 있음
  • 따라서, 카다낼러티 비율은 M : N
  • EMPLOYEE는 전체 참여
  • PROJECT도 전체 참여

• DEPENDENTS_OF(부양) 관계 타입

  • DEPENDENT의 Employee 속성을 관계타입으로 변환
  • 이 관계 타입은 약한 엔티티타입 DEPENDENT에 대한 식별 관계타입이어서 카디낼러티와 참여제약이 고정됨
  • EMPLOYEE와 DEPENDENT 사이
  • 카다낼러티 비율은 1 : N (고정)
  • EMPLOYEE는 부분 참여
  • DEPENDENT 전체 참여 (고정)

• SUPERVISION(관리자) 관계 타입

  • EMPLOYEE의 Supervisor 속성을 관계 타입으로 변환
  • 이 관계 타입은 재귀 관계타입이므로 역할 이름을 부여하는 것이 좋음
  • 상사 역할의 EMPLOYEE 와 사원 역할의 EMPLOYEE 사이
  • 카다낼러티 비율은 1 : N
  • 고객 협의 결과, 모든 사원이 상사가 아니므로 상사 역할의 EMPLOYEE는 부분 참여
  • 고객 협의 결과, 모든 사원이 상사를 가지는 것이 아니므로 사원역할의 EMPLOYEE도 부분 참여

재귀적 관계 타입(Recursive Relationship type)

• 한 개의 엔티티 타입이 어떤 관계 타입에 서로 다른 역할로 중복 참여하는 경우를 의미

  • ex) EMPLOYEE(상사의 역할로)와 EMPLOYEE(부하직원의 역할로) 간의 SUPERVISION 관계

• 앞서, SUPERVISION 관계타입에 EMPLOYEE 엔티티타입이 상사의 역할(supervisor)로도 참여하고 부하직원의 역할(supervisee)로도 참여

• ER 다이어그램에서는 이런 참여의 차이를 구분하기 위해 역할 이름을 표기함

• 예시

  • 

  3차 이상의 관계 타입

  3진 차수 이상의 관계

  • 2진 관계
    • 차수가 2인 관계 타입을 2진 관계라고 함
  • 3진 관계, n-ary 관계
    • 차수가 3인 관계 타입을 3진 관계라 하고, 차수가 n인 관계를 n-ary 관계라고 함
    • 제약조건의 명시가 2진 관계보다 더 어려움
  • “n-ary 관계”와 “n개의 이진 관계들” 사이의 차이
    • 보통 n-ary 관계는 n개의 이진 관계들과 같지 않음
    • 3개의 2진 관계가 1개의 3진 관계 보다 더 많은 의미를 표현할 수도 있음(양은 많이 표현할 수 있지만, 정확도가 떨어질 수 있음)
    • 1개의 삼진 관계와 3개의 2진 관계 예시(의미가 다름)
    • 

엔티티-관계 다이어그램

ERD 표기법(P.Chen 이 제안)

구조적 제약조건을 위한 또 다른 (min, max) 표기법

• 관계 타입 R을 기준으로 엔티티 타입 E의 각 참여를 명시
• E 내의 각 엔티티 e가 최소한 min 만큼 그리고 최대한 최대값 max 만큼 R 내의 관계 인스턴스들에 참여함을 나타냄
• 디폴트 값은 최소값=0, 최대값=n
• ex)
  • 사원은 최대 한 개의 부서를 관리할 수 있으며, 각 부서에는 정확히 한 명의 부서장이 있음
  • 관계타입 MANAGES에 대한 EMPLOYEE의 참여를 (0, 1)로 표기
  • 관계타입 MANAGES에 대한 DEPARTMENT의 참여를 (1, 1)로 표기
  •