DATABASE 3장

 

OVERVIEW

 

-개념 모델링은 성공적인 데이터베이스를 설계하는데 있어 매우 중요한 단계
-Entity Relation model은 가장 높은 레벨의 개념 데이터 모델이며 데이터베이스 응용을위한 개념 스키마를 디자인하는데 사용된다

 

데이터 베이스에서 표현하고자 하는 miniworld

 

-데이터 수집분석 후 Functional(데이터 베이스에 필요한 응용요구사항), Database(데이터 베이스에 표현되야할 정보내용 분석) requirements로 나눠진다.
-서로 상호작용을 통해 좋은 데이터베이스 설계가 가능하다.

-database requiremnets: 개념설계=>개념스키마 생성(ER모델 같은것), 논리설계=>logical schema 생성 , 물리설계

-functional requirements : 응용프로그램 설계, Transaction 포함

-Logical schema는 응용프로그램 설계의 입력값으로 사용된다
-High-level transaction specification은 물리 디자인의 입력으로 사용된다.

 

 

 

COMPANY database 예시

 

요구
-컴퍼니는 부서로 조직되어 있다
각 부서의 정보와 관리하는 매니저가 있다
부서를 관리하는 직원은 관리를 시작한 날짜가 있어야한다
부서는 여러곳에 위치할 수 있다.
-부서는 다수의 프로젝트를 관리한다

 

EMPLOYEE
-각 직원은 하나의 부서에서 근무, 다수의 프로젝트에 참여할 수 있다
-각 직원은 여러 부양가족을 가질 수 있고. 보험목적을 위해 부양가족의 정보를 가져야 한다.

 

ER model은 entities, relationships, attributes로 표현된다.

Entity

-ER모델이 표현하는 기본 객체
-독립적인 존재를 갖는 실세계의 어떤 것
-물리적 존재, 개념적 존재가 있을 수 있다.

 

Attributes

-객체를 설명하기 위한 어떤 성질
ex 회사원의 경우 이름,급여,나이 등등

속성의 타입
-단순/복합
-단일 값/다중 값
-저장/유도

 

address 계층적 복합속성을 가짐

 

Entity types, Entity sets, keys, and Value sets

 

Entity type(동일한 attribute를 갖는 attribute의 집합을 위한 type)
-각 entity type은 이름과 속성으로 표현된다
-entity 집합을 위한 schema 또는 intension 정보
-ERD: 사각형 박스안에 이름을 표현한다

Entity set
-특정 시점에서 동일한 entity type을 갖는 모든 개체의 집합을 entity set이라 함
-entitiy set도 entity type과 같은 이름 사용
-entity type의 extension이다. 

 

employee ,company entity set을 보여준다

 

개체타입의 속성

Key attribute
-개체를 다른 개체와 구별해주는 속성 
-유일성 제약조건을 만족해야한다

복합키
-하나이상 여러개의 속성으로 키가 구성됨
-minimal해야한다
-개체는 여러개의 키를 가진다
-키가 없는 개체가 있을 수 있다: 약한 개체타입

 

set value를 갖는 color같은것은 두줄로 표시된다

 

COMPANY db의 초기 개념 설계

초기설정의 ERD

한 개체 타입간의 어떤 참조관계, 한 개체 타입이 다른 개체 타입을 참조한다면, 관계가 존재한다

참조관계 예시

참조관계는 attribute가 아니라 relationship이라는 표현으로 나타내야 한다.
-초기 설계에는 attribute로 표현되나, 설계가 진행이 되면서 entity types사이의 relationships들로 표현되야 한다.

 

변화과정, controls라는 관계가 있다는 것을 보여주고 필요없는 속성은 삭제한다.

관계성으로 변화시켜 나타낸 최종 ER shcema diagram

WORKS_FOR은 2차수 

 

 

3항관계를 가진다

관계성의 차수 : 관계에 참여하는 개체타입의 수
-가장 일반적인 경우가 binary relationships이며, 고차 relatioships을 가질수록 너무 복잡해진다

 

관계성 타입의 제약

관계성 타입은 제약조건을 가진다
-제약조건은 대응되는 관계성 집합에 참여하는 개체간의 가능한 결합을 제약하는 역활
ex) WORKS_FOR : 하나의 부서에서만 근무할 수 있음

관계성 제약의 타입
-대응 수
-참여제약조건

 

대응 수는 관계성에 참여하는 개체의 수를 명시, 하나의 관계성에 참여할 수 있는 개체의 수 - 1:1 , 1:N ,N:1 , M:N

그림 직원은 한가지 부서만 선택 가능하나 부서는 여러 직원을 받을 수 있다 ( N,1)

참여제약 조건과 존재의존

참여제약 조건

TOTAL : 전체참여 ( 무조건) , 두줄로 표시
PARTIAL : 부분참여(해도 안해도 그만) , 한줄로 표시

 

전체 참여는 존재종속의 의미를 함께 포함한다.

일반적으로 1:1, 1:N 관계성 타입은 참여하는 개체타입의 속성으로 표현할 수 있다. 1:1은 관계의 속성이나 양쪽 모두 표현가능, 1:N는 관계의 속성이나 N측에 표현가능

전체 참여는 존재종속의 의미를 함께 포함한다.

Weak 개체타입

개체타입중 key attribute를 갖지 않는것 => 도와줄 수 있는것이 필요하다
-식별(주인) 개체타입
-식별 관계
weak 개체타입의 경우 식별해주는 개체가 있어야 식별이 되므로 반드시 관계에 참여해야 해서 늘 존재종속을 가진다

-key attribute를 갖는 개체타입의 경우 Regular 개체타입이라 한다.

 

weak 개체타입에 대한 관계도, 식별관계와 weak 개체타입은 두줄로 표시하고, 그 사이는 전체참여 이므로 두줄이 된다.

identifying entity : 식별개체 (EMPLOYEE)

identifying relationship: Weak entity와 연결시켜주는 관계 (두줄표시)
total participation : 두줄 표시
Weak Entity(DEPENDENT) : 두줄표시

Name: Weak 내부에서 자신들끼리 구분 가능한 Partial key (점선표시)

ERD를 위한 대응수를 표시하는 방법

-min/max notation
 관계에 참여하는 상대개체의 숫자를 최대,최소로 표시.
min=0이면 부분참여
min>0이면 전체참여

 

(0,1) 최소0개에서 최대1개 없어도된다 => 부분참여
(1,1,) 최소1개에서 최대1개 반드시 있어야한다 => 전체참여
(1,N) => 당연히 전체참여

 

관계도 예시

ERD의 대안으로 UML을 사용한다.