aking: 개발노트

2014/05/19 - [Database/Database System] - Chapter 7

2014/04/13 - [Database/Database System] - Chapter 6

2014/04/28 - [Database/Database System] - Chapter 4

2014/04/11 - [Database/Database System] - Chapter 3

2014/04/11 - [Database/Database System] - Chapter 2

2014/04/11 - [Database/Database System] - Chapter 1

8.1 ER-관계 사상을 이용한 관계 데이터베이스 설계

1. ER관계 사상을 이용한 관계 데이터베이스 설계

2. 엔티티 타입은 릴레이션으로 매핑한다. 엔티티 타입의 키 중에서 하나를 릴레이션의 기본키로 지정한다.

3. 약한 엔티티 타입도 릴레이션으로 매핑하되 소유 릴레이션의 키 속성을 포함시킨다. 생성된 릴레이션의 기본키는 소유 릴레이션의 키와 약한 엔티티타입의 부분키를 합쳐서 만든다.

4. 1:1 이진 관계는 관계에 참여하는 두 릴레이션중에서 어느 하나의 외래키 속성으로 매핑한다.

5. 1:N 이진 관계는 N-side 릴레이션의 외래키 속성으로 매핑하며,1-side의 주 키를 참조하도록 한다.

6. N:M 이진관계는 별도의 릴레이션(이를관계릴레이션이라고부름)으로 생성하고, 관계에 참여하는 두 릴레이션의 기본키를 각각 참조하는 외래키로

애트리뷰트를 구성한다. 이때 두 외래키가 관계 릴레이션의 기본키를 형성한다.

7. 다중값 애트리뷰트는 키를 포함하는 릴레이션으로 매핑된다.

8. n차관계는 관계에 참여하는 n개의 릴레이션의 키들로 구성되는 관계 릴레이션으로 매핑된다. 관계 릴레이션의 애트리뷰트들은 참여 릴레이션의 주 키를 참조하는

외래키들과 관계 속성(들)으로 구성된다.

▼

• 단계 1: 정규 엔티티 타입의 사상

- 엔티티 타입은 릴레이션으로 매핑한다.

- 모든 단순 애트리뷰트를 포함시킨다.

- 엔티티 타입의 키 중에서 하나를 릴레이션의 기본 키로 지정한다.

EMPLOYEE

DEPARTMENT

PROJECT

• 단계 2: 약한 엔티티 타입의 사상

- 약한 엔티티 타입을 릴레이션으로 매핑한다.

- 모든 단순 애트리뷰트를 포함시킨다.

- 소유 릴레이션(owner relation)의 키 속성을 포함시킨다.

- 생성된 릴레이션의 기본 키는 소유 릴레이션의 키와 약한 엔티티 타입의 부분 키를 합쳐서 만든다.

• 단계 3: 이진 1:1 관계 타입의 사상

- 외래키 접근 방식: 한 릴레이션(S)을 선택하여 T의 기본 키를 S에 외래키로 포함, S는 완전참여 릴레이션을 선택하는 것이 좋다.

관계 타입의 모든 단순 애트리뷰트를 S에 포함시킨다. (이 방식이 가장 유용하다, 다음 방식은 참조만 할 것.)

- 합병된 릴레이션 접근 방식: 두 릴레이션을 하나의 릴레이션으로 통합, 두 릴레이션이 모두 완전 참여일 때 좋은 방법

- 교차 참조/관계 릴레이션 접근방식: S와 T를 교차 참조하는 제 3의 릴레이션 R 생성

• 단계 4: 이진 1:N 관계 타입의 사상

- 외래키 접근방식: N측의 릴레이션(S)을 선택하여 1측의 릴레이션 T의 기본키를 S에 외래키로 포함, 관계 타입의 모든 단순 애트리뷰트를 S에 포함시킨다. (권장)

- 교차 참조/관계 릴레이션 접근방식: S와 T를 교차 참조하는 제 3의 릴레이션 R 생성

• 단계 5: 이진 M:N 관계 타입의 사상

- M:N 이진 관계는 별도의 릴레이션(이를 관계 릴레이션이라고 부름)으로 생성하고, 관계에 참여하는 두 릴레이션의 기본 키를 각각 참조하는 외래키로

애트리뷰트를 구성한다. 이 때 두 외래키가 관계 릴레이션의 기본키를 형성한다.

• 단계 6: 다치 애트리뷰트의 사상

- 릴레이션 R의 다치 애트리뷰트는 R의 기본키를 포함하는 새로운 릴레이션으로 매핑된다.

- 새로운 릴레이션의 키는 R의 기본키와 다치 애트리뷰트의 조합이다.

• 단계 7: N차 관계 타입의 사상

- n차 관계는 관계에 참여하는 n개 릴레이션의 키들로 구성되는 관계 릴레이션으로 매핑된다. 관계 릴레이션의 애트리뷰트들은 참여 릴레이션의 기본키를 참조하는

외래키들과 관계 속성(들)으로 구성된다.

ER-관계 사상: COMPANY 데이터베이스를 위한 ER 스키마 다이어그램

ER-관계 사상: 변환 결과 생성된 Relational Schema

8.2 요약

2014/04/13 - [Database/Database System] - Chapter 6

2014/04/28 - [Database/Database System] - Chapter 4

2014/04/11 - [Database/Database System] - Chapter 3

2014/04/11 - [Database/Database System] - Chapter 2

2014/04/11 - [Database/Database System] - Chapter 1

개요

• 개념적 모델링은 데이터베이스 설계에 있어 중요한 단계이다.

• 이 장에서는 개체-관계(Entity-Relationship: ER)모델을 사용한 개념적 모델링 기법을 소개한다.

7.1 데이터베이스 설계를 위한 고수준의 개념적 데이터 모델의 사용

[그림 7.1] 데이터베이스 설계의 주요 단계들을 보여주는 간단한 다이어그램

7.2 간단한 예제 데이터베이스 응용

• COMPANY 데이터베이스의 작은 세계

1. 회사는 여러 부서들로 구성된다. 각 부서마다 고유한 이름, 고유한 번호, 부서를 관리하는 특정 사원이 있다. 사원이 부서를 관리하기 시작한 날짜도 유지한다. 한 부서는 여러 위치에 있을 수 있다.

2. 한 부서는 여러 프로젝트들을 관리한다. 각 프로젝트는 고유한 이름, 고유한 번호, 한 개의 위치를 가진다.

3. 각 사원에 대해서 이름, 사회보장번호, 주소, 급여, 성별, 생년월일을 저장한다. 한 사원은 한 부서에 속하지만, 여러 프로젝트들에 관여할 수 있다.

한 사원이 관여하는 프로젝트들을 그 사원이 소속된 부서가 관리하는 프로젝트가 아니어도 무방하다. 반드시 한 부서의 각 사원이 프로젝트를 위해 일하는 주당 근무 시간을 기록한다. 또한 각 사원의 직속 상사도 유지한다.

4. 보험 목적을 위해서 각 사원의 부양 가족들을 기록한다. 각 부양 가족에 대해서 이름, 성별, 생년월일, 사원과의 관계를 기록한다.

개념적 설계의 결과

[그림 7.2] COMPANY 데이터베이스를 위한 ER 스키마 다이어그램. 표기법은 이 장에서 점진적으로 소개됨

7.3 엔티티 타입, 엔티티집합, 애트리뷰트, 키

• ER 모델은 데이터를 엔티티(개체), 관계, 애트리뷰트(속성) 로 모델링 한다.

• 엔티티와 애트리뷰트

- 엔티티: 실세계에서 독립적으로 존재하는 실체

- 애트리뷰트: 엔티티를 기술하는 속성

[그림 7.3] 두 개의 엔티티(사원 과 회사 )와 애트리뷰트

• 애트리뷰트 유형
  

- 복합 애트리뷰트

- 단순 애트리뷰트

- 단일 값 애트리뷰트

- 다치 애트리뷰트

- 저장된 애트리뷰트

- 유도된 애트리뷰트

[그림 7.4] 복합 애트리뷰트의 계층 구조

• 널 값

- 두가지로 사용됨; '적용할 수 없음'이라는 의미와 '알려지지 않음'의 의미

• 복합(composite) 애트리뷰트

[그림 7.5] 복잡한 애트리뷰트 Address-Phone

• 엔티티 타입: 엔티티 집합

[그림 7.6] 두 엔티티 타입 EMPLOYEE, COMPANY와 각 타입에 속하는 일부 엔티티들

[그림 7.7] Registration과 Vehicle_id라는 두 개의 키 애트리뷰트를 갖는 CAR 엔티티 타입, (a) ER 다이어그램 표기법 (b) 세 개의 엔티티를 갖는 엔티티집합

• 키 애트리뷰트
  

- 각 엔티티마다 서로 다른 값을 가지는 애트리뷰트

- 그림 3.2에서

ㆍCOMPANY 엔티티 타입에서 키 애트리뷰트는 Name

ㆍPERSON 엔티티 타입의 키 애트리뷰트는 SocialSecurityNumber

- 복합키

ㆍ두 개 이상의 애트리뷰트들이 모여서 하나의 키 애트리뷰트 역할을 하는 키

• 값 집합(도메인)

- 각 엔티티에서 애트리뷰트가 가질 수 있는 값들의 집합

ㆍEMPLOYEE의 Age 애트리뷰트의 값 집합은? (16부터 70사이의 정수 집합)

[그림 7.8] COMPANY 데이터베이스를 위한 엔티티 타입들의 초기 설계. 몇몇 애트리뷰트들은 관계로 수정될 것임

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

1. 엔티티 타입 DEPARTMENT는 Name, Number, Locations, Manager, Manager_start_date 애트리뷰트를 가진다. Locations는 유일한 다치 애트리뷰트이다.

Name과 Number는 각 부서마다 고유하기 때문에 각각 키 애트리뷰트로 지정할 수 있다.

2. 엔티티 타입 PROJECT는 Name, Number, Location, Controlling_department 애트리뷰트들을 가진다. Name과 Number가 각각 키 애트리뷰트이다.

3. 엔티티 타입 EMPLOYEE는 Name, Ssn, Sex, Address, Salary, Birth_date, Department, Supervisor 애트리뷰트들을 가진다. 사용자가 사원 Name의 각 구성요소
(Fname, Minit, Lname)와 Address의 각 구성요소를 참조할 것인지의 여부를 알기 위해서 사용자와 다시 협의해야 한다.

4. 엔티티 타입 DEPENDENT는 Employee, Dependent_name, Sex, Birth_date, Relationship(사원과의 관계) 애트리뷰트들을 가진다.

7.4 관계, 관계 타입, 역할, 구조적 제약조건

• 관계 타입과 관계 인스턴스

- 관계 타입(관계 집합) R은 엔티티 간의 연관들의 집합이다. 그림 7.9에서 WORKS_FOR

- [그림7.9] 관계 WORKS_FOR에서 관계 인스턴스: 7개 (R1 ~ R7)

[그림 7.9] EMPLOYEE와 DEPARTMENT 간의 WORKS_FOR 관계 타입을 나타내는 WORKS_FOR 관계집합 내의 일부 인스턴스

• 관계 타입의 차수(degree): 관계에 참여하고 있는 엔티티 타입의 수
  

- 이진(binary) 차수: [그림 7.9]의 WORKS_FOR 관계

- 3진(ternary) 차수: [그림 7.10] 3진 관계 SUPPLY

[그림 7.10] SUPPLY 3진 관계집합 내의 일부 관계 인스턴스

• 애트리뷰트로서의 관계: 관계는 참여 엔티티 타입의 속성으로 볼 수도 있음

ㆍ예: (EMPLOYEE의 DEPARTMENT 또는 DEPARTMENT의 EMPLOYEE)

• 역할과 순환적(recursive) 관계

- [그림 7.11] EMPLOYEE에서의 순환적 관계 SUPERVISION은 상사(1)와 부하(2)의 두 역할로 구분할 수 있음.

[그림 7.11] 상사 역할(1)의 EMPLOYEE와 부하 역할(2)의 EMPLOYEE 간의 순환적 관계 SUPERVISION

• 관계 타입에서 제약조건

- 카디날리티 비율: 관계 인스턴스에 참여하는 엔티티의 개수의 비율(이진 관계 타입에 대한 카디날리티 비율은 1:1, 1:N, N:M)

- 참여 제약조건: 한 엔티티의 존재가 관계 타입을 통해 연관되어 있는 다른 엔티티에 의존하는지의 여부(부분참여와 전부참여)

- MANAGER 관계: EMPLOYEE는 부분 참여하고, DEPARTMENT는 전부 참여한다.

[그림 7.12] 1:1 관계 MENAGES

• 관계 타입의 애트리뷰트

- 1:1, 1:N 관계 타입의 애트리뷰트

ㆍMANAGES의 Start_date [그림 7.12], WORKS_FOR의 Start_date [그림 7.9]

- M:N 관계 타입

ㆍWORKS_ON의 Hours [그림 7.13]

- [그림 7.13] M:N 관계 WORKS_ON

[그림 7.13] M:N 관계 WORKS_ON

7.5 약한 엔티티 타입(Weak Entity Type)

• 자신의 키 애트리뷰트가 없는 엔티티 타입

- 예: DEPENDENT 엔티티 타입

• 식별(소유) 엔티티 타입과 식별 관계

- EMPLOYEE와 DEPENDENT에서 EMPLOYEE가 식별 엔티티 타입이며, 두 엔티티 타입 사이의 관계를 식별 관계라고 부른다.

• 부분 키

- 동일한 소유 엔티티와 연관된 약한 엔티티 집합 내의 서브 집합(예를 들어 소유 엔티티 EMPLOYEE e1의 DEPENDENTS SET) 내에서 서로를 구분할 수 있는 애트리뷰트들의 집합(예를들어, Dependent.name)

• 약한 엔티티는 소유 엔티티 타입의 복합 속성으로 표현될 수도 있으나 다음의 경우에는 별도의 엔티티 타입으로 표현하는 것이 바람직하다.

1. 엔티티가 많은 애트리뷰트들을 가지고,

2. 식별 관계 타입 외에 다른 관계 타입들에 독립적으로 참여하는 경우

7.6 COMPANY DB에 대한 ER 설계의 개선

• [그림 7.8]에서 관계를 나타내는 애트리뷰트들을 관계 타입으로 변환하여 발전시킨다.
• 생성되는 관계 타입들

1. MANAGES: EMPLOYEE와 DEPARTMENT 사이의 1:1관계 타입

2. WORKS_FOR: DEPARTMENT와 EMPLOYEE 사이의 1:N 관계 타입

3. CONTROLS: DEPARTMENT와 PROJECT 사이의 1:N 관계 타입

4. SUPERVISION: EMPLOYEE(상사역할)와 EMPLOYEE(사원역할) 사이의 1:N 관계 타입

5. WORKS_ON: EMPLOYEE와 PROJECT 사이의 M:N 관계 타입

6. DEPENDENT_OF: EMPLOYEE와 DEPENDENT 사이의 1:N 관계 타입

7.7 ER 다이어그램, 이름 지정에 관한 규칙, 설계에 관한 사항

[그림 7.14] ER 다이어그램의 표기법 요약

• 스키마에 사용된 각 구조물에 대해 가능한 한 그 의미를 전달할 수 있는 이름 선택
• 복수보다 단수 이름 선택
• 일반적으로 자연어로 기술된 요구 사항에서 명사는 엔티티 타입 이름, 동사는 관계 타입 이름으로 해석하는 것이 도움이 된다.
• ER 다이어그램은 왼쪽에서 오른쪽, 위에서 아래로 읽기 쉽게 작성한다.
• 스키마 설계는 반복해서 개선하는 작업이 필요하다 - 한번에 완성하기는 쉽지 않다.
• 다음 TP에서는 ER 다이어그램의 또 다른 표기법 소개

[그림 7.15] 구조적 제약조건들을 (min, max) 형식으로 명시한 COMPANY 스키마의 ER 다이어그램과 역할 이름 다이어그램

7.8 3차 이상의 관계 타입

• 관계 타입의 차수: 참여하는 엔티티 타입의 수

- 이진 관계, 3진 관계 등

• 3진 관계 예제: 부품공급(SUPPLY)

[그림 7.16] 삼진 관계 타입, (a) SUPPLY 관계, (b) SUPPLY와 같지 않은 세 개의 이진 관계, (c) 약한 엔티티 타입으로 표현된 SUPPLY

(a): (s1, p1, j1) 관계 표현

(b): (s1, p1) (p1, j1) (j1 p1) 관계가 있어도 (s1, p1, j1) 관계를 표현하지 못할 수도 있다.

• 3진 관계 예제: 부품공급(SUPPLY) (계속)

• 3진 관계 예제: 강좌개설 (OFFERS)

ER Model

- 가장 대중적으로 사용되는 고수준 개념 데이터 모델

ER Diagrams

- ER모델을 그림 형식으로 표현하는 표기법

논리적 모델의 하나의 instance

- 계층형/망형 -> 관계형모델 -> 객체지향 -> 객체관계형

논리적 모델

개발자가 대상을 논리적으로 식별하고 조작하는 수단을 제공

고수준(~보다 높은)은 논리설계를 뜻 함.

개발자와 사용자간에 커뮤니티케이션을 돕기 위해 만드는 설계를 개념적 설계라한다.

개념적 설계까지는 DBMS로부터 독립적이다.

논리적 설계부터는 DBMS에 의존한다.

n-ary 관계성은 n개의 binary 관계로 환원되어야 한다.

2014/04/11 - [Database System] - Chapter 3

2014/04/11 - [Database System] - Chapter 2

2014/04/11 - [Database System] - Chapter 1

• 관계 모델을 위한 기본적인 연산들의 집합을 관계 대수(relational algebra)라고 한다.
• 일련의 관계 대수 연산들은 관계 대수식을 형성한다.
• 대수는 연산자와 피연산자를 통해 연산의 의미와 방법을 기술한 수학의 한 분야이다.

6.1. 단항 관계 연산: 실렉트와 프로젝트

• 관계 대수란

- 릴레이션들을 다루는 연산들

- 검색 요구(질의)를 기술하는 데에 사용한다.

- 질의 결과도 릴레이션

• 이 절의 구성

6.1.1 실렉트(SELECT) 연산

• SELECT 연산 (σ로 표기)

- 릴레이션 R에서 어떤 선택조건 c를 만족하는 투플들을 선택함

- 연산 형식: 

- 조건 c는 R의 애트리뷰트들에 대한 임의의 불리언 식

- 결과 릴레이션은 R과 동일한 애트리뷰트들을 가짐

- 결과 릴레이션은 의 투플 중 애트리뷰트 값들이 조건 c를 만족하는 투플들로 구성됨

- 예제:

6.1.2 프로젝트(PROJECT) 연산

• PROJECT 연산 (Π로 표기)
  

- 릴레이션 R에서 애트리뷰트 리스트 L에 명시된 애트리뷰트(열)들만 선택함

- 연산 형식: 

- 결과 릴레이션은 L에 명시된 R의 애트리뷰트들만 가짐

- 예제:

- PROJECT 연산은 결과 릴레이션이 수학적 집합이므로 중복된 투플들을 제거함

- 예제:

봉급이 1,000,000원인 남자 사원들이 여러명 이더라도 결과 릴레이션에는 단지 하나의

투플만이 포함되며, 나머지는 제거됨.

6.1.3 연산의 순서와 이름 변경 연산

• 다수의 연산을 결합하여 관계 대수식(질의)을 형성할 수 있음

예제: 부서 5에서 일하는 사원들의 이름과 봉급을 검색하라.

• 대상 릴레이션: EMPLOYEE

  선택 조건: 5번 부서

  프로젝션 리스트: 이름, 주소

• 각 중간 단계의 임시 릴레이션에 이름을 부여할 수도 있음

* ... → _ (언더바) 표기

• 결과 릴레이션의 애트리뷰트 이름은 재명명 할 수도 있음 

• 수학적 집합 이론에서의 이진 연산

- 합집합: 

- 교집합: 

- 차집합: 

- 카티션 곱: 

• 연산 에서의 호환성

(b) 

(c) 

Fn	Ln
Susan	Yao
Ramesh	Shah

(d) 

Fn	Ln
Johnny	Kohler
Barbara	Jones
Amy	Ford
Jimmy	Wang
Ernest	Gilbert

(e) 

DEPT_MGR

[그림 6.6] 조인 연산 의 결과

EMPLOYEE

RESULT

• 조인 조건

- <조건> AND <조건> AND ... AND <조건>

- 각 조건의 형태는 이며, 는 R의 애트리뷰트, 는 S의 애트리뷰트이다.

• 외부 합집합 연산

• 외부 유니온(OUTER UNION)

- 호환성이 없는 두 릴레이션을 유니온하는데 사용된다.

- 예:

STUDENT(Name, Ssn, Department, Advisor)와

FACULTY(Name, Ssn, Department, Rank)의 outer union은

RESULT(Name, Ssn, Department, Advisor, Rank) 이다.

RESULT에서 STUDENT 투플은 Rank 속성의 값이 null이고, FACULTY 투플은 Advisor 속성의 값이 null이다.

6.5 관계 대수 질의의 예

질의 1: 'Research' 부서에서 일하는 모든 사원의 이름과 주소를 검색하라.

하나의 in-line 표현식으로 표현한다면, 이 질의는 다음과 같다.

질의 2: 'Stafford'에 위치한 모든 프로젝트에 대하여 프로젝트 번호와 관리 부서 번호, 부서 관리자의 성, 주소, 생년월일을 나열하라.

6.6 투플 관계 해석

• 관계 해석

- "어떻게 검색할 것인가" 보다 "무엇을 검색할 것인가" 만을 기술하는 선언적 표현법을 사용하는 비절차적 질의어

- SQL을 포함한 많은 상업용 관계 언어들이 관계 해석에 기반을 두고 있음.

- 투플 관계 해석(tuple relational calculus)와 도메인 관계 해석(domain relational calculus)으로 구분됨

• 관계 대수와의 차이점

• 관계적 완전성(relationally completeness)

• 투플 변수

• 프로잭션의 표현

- 의 일부 애트리뷰트만을 검색하려면 다음과 같이 작성한다.

이는 다음 SQL 질의와 동일한 의미를 가진다.

6.6.2 투플 관계 해석의 표현식과 식

• 투플 관계 해석의 일반식 형태

- 은 투플 변수

- 각 는 가 범위로 하는 릴레이션의 애트리뷰트

- 는 조건 또는 투플 관계 해석의 식(formula)

• 식(formula)은 다음과 같은 원자(atoms)들로 이루어짐

- 는 의 범위가 임을 명시

- , 는 비교 연산자 

- 또는 , 는 상수

• 각 원자는 특정한 투플들의 조합에 대해서 참(true) 또는 거짓(false)으로 계산되며, 계산된 결과값을 원자의 진리값이라 부름.

• 식(formula): and, or, not으로 연결된 원자들

- 모든 원자들은 식이다.

- 과 가 식이면 , , , 도 식이다.

6.6.3 존재 정량자와 전체 정량자

• 정량자(quantifiers)가 식에 사용될 수 있음

- 전체 정량자(universal quantifier) (for all이라 읽는다.)

- 존재 정량자(existential quantifier) (their exists라 읽는다.)

• 자유(free) 투플 변수와 속박(bound) 투플 변수

- 어떤 식 F가 원자인 경우, 여기에 나타난 투플 변수의 어커런스(occurrence)는 F에서 자유롭다. (자유 투플 변수)

- 식 , , , 에 나타난 투플 변수 가 자유로운가 여부는 이나 에서 자유로운가에 달려있다.

- 내의 투플 변수 의 모든 자유 어커런스들은 나 형태의 식에서 정량자에 속박된다.

• 예제:

- 는 과  모두에서 자유롭다.

- 는 에서 정량자에 속박된다.

• 정량자가 포함된 식의 진리값 계산

- 가 식이면, 도 식이다.

- 내의 의 자유 어커런스들에 할당된 "적어도 하나의 투플" 에 대해서 가 참으로 계산되면 식 는 참이고, 그렇지 않으면 거짓이다.

- 가 식이면, 도 식이다.

- 내의 의 자유 어커런스들에 할당된 "모든 투플" 에 대해서 가 참으로 계산되면 식 는 참이고, 그렇지 않으면 거짓이다.

- 가 참이 되게 하는 어떤 투플 가 "존재" 하면 가 참이므로, 를 존재 정량자라 부른다.

- "모든" 투플들이 를 참이 되도록 해야 가 참이므로, 를 전체 정량자라 부른다.

6.6.4 투플 관계 해석식에서 질의 예(존재 정량자를 이용한 질의 예)

• 질의 1: 'Research' 부서에서 일하는 모든 사원의 이름과 주소를 검색하라.

Q1: 

- 관계 해석 식에서 자유 투플 변수들만 막대 ( | ) 왼쪽에 나타낸다.

- 막대 ( | )는 "such that" 이라 읽는다.

- 는 와 의 범위 릴레이션을 명시한다.

- 는 선택 조건(selection condition)이다. (관계 대수의 Select에 해당한다.)

- 는 조인 조건(join condition)이다. (관계 대수의 EQUI-JOIN과 유사한 목적으로 사용된다.)

• 질의 2: 'Stafford'에 위치한 모든 프로젝트에 대하여 프로젝트 번호, 관리 부서 번호, 부서 관리자의 성, 주소, 생일을 나열하라.

Q2: 

• 질의 3: 5번 부서가 관리하는 모든 프로젝트에서 근무하는 사원들의 이름을 나열하라.

Q3: 

• 질의 4: 성이 'Smith' 인 사원이 직원이나 관리자로서 근무하고 있는 부서에서 관리하는 프로젝트 번호들을 나열하라.

Q4: 

• 질의 8: 각 사원에 대하여, 그 사원의 이름과 성, 그리고 직속 상사의 이름과 성을 검색하라.
  

Q8: 

• AND / OR / NOT
  

- 관계 대수의 UNION은 관계 해석의 OR 연결자에 대응한다.

- INTERSECTION은 AND 연결자에 대응한다.

- NOT 연결자는 전체 정량자와 존재 정량자를 동등한 식으로 변환하는데에 사용될 수 있다.

6.6.6 전체 정량자와 존재 정량자 사이의 변환

• 수학적 논리로부터 유래된 잘 알려진 변환법

• 다음 식들이 성립한다. ( 는 내포(implies)를 나타낸다.)

• 그러나, 다음은 성립되지 않는다.

6.6.7 질의에서의 전체 정량자의 사용

• 전체 정량자를 사용할 때 식이 의미를 갖도록 하기 위하여 몇가지 규칙을 따라야 한다.

• 다음의 질의 3을 통하여 규칙을 살펴보자.

질의 3: 5번 부서가 관리하는 모든 프로젝트에서 근무하는 사원들의 이름을 나열하라.

Q3: 

• Q3을 다음과 같은 기본 구성 요소들로 나눌 수 있다.
  

Q3:

• Q3의 설명
  

- Q3의 결과로 구해지는 사원 는 5번 부서에서 관리하는 모든 프로젝트에서 근무해야 한다.

- 이러한 투플을 찾기 위하여 관심없는 모든 투플들을 전체 정량자로부터 제외시켜야 한다.

- 에서 는 관심있는 릴레이션 "PROJECT" 에 없는 모든 투플들에 대해 를 참으로 만든다.

- 에서 는 관심없는 PROJECT 투플들, 즉 "Dnum이 5가 아닌 투플들" 에 대해 를 참으로 만든다.

- 는 나머지에 대해 만족되어야 할 조건, 즉 "5번 부서에 의해 관리되는 모든 PROJECT 투플들" 을 명시한다.

• 전체 정량자로부터 존재 정량자로의 변환
  

Q3A: 

• 추가적인 예제들:
  

질의 6: 부양가족이 없는 사원들의 이름을 나열하라.

Q6: 

Q6A: 

질의 7: 부양가족이 적어도 한 명 있는 관리자들의 이름을 나열하라.

Q7: 

6.6.8 안전식(safe expression)

• 관계 해석에서의 안전식

- 결과로서 유한 개의 투플들을 생성하는 것이 보장된 식.

- 불안전식은 무한 개의 투플들을 생성할 수 있고, 투플들의 타입이 서로 다를 수 있다.

- 불안전한 식의 예제;

ㆍ 가능한 모든 투플들 중에서 EMPLOYEE가 아닌 모든 투플들을 생성한다.

ㆍ 이러한 투플들은 무한 개의 투플들로 구성되며, 투플의 타입이 상이할 수 있다.

ㆍ 따라서 위의 식은 불안전한 식이된다.

6.7 도메인 관계 해석

• 투플 변수 대신 도메인 변수(domain variables)를 사용하는 관계 해석

• 도메인 변수는 한 애트리뷰트의 도메인을 범위로 가진다.

• 차수가 n인 릴레이션의 경우 n개의 도메인 변수를 사용한다.

예제:

ㆍ 질의 0: 이름이 'John B. Smith'인 사원의 생년월일과 주소를 나열하라.

Q0: 

ㆍ EMPLOYEE의 각 애트리뷰트들을 위한 열 개의 도메인 변수들: 

ㆍ Bdate를 위한 변수 , Address를 위한 

ㆍ 조건에 참여하는 변수들: 

ㆍ 조건에 참여하는 변수들 만 존재 정량자로 속박한다.

또 다른 표기법(QBE에서 사용): 

Q0A: 

ㆍ 질의 1: 'Research' 부서에서 일하는 모든 사원들의 이름과 주소를 검색하라.

Q1: 

ㆍ 는 조인 조건

ㆍ 는 선택 조건

ㆍ 질의 2: 'Stafford'에 위치한 모든 프로젝트에 대해서 프로젝트 번호와 부서 번호, 그리고 부서 관리자의 성, 생일, 주소를 나열하라.

Q2: 

ㆍ 질의 6: 부양가족이 없는 사원들의 이름을 찾아라.

Q6: 

ㆍ 질의 7: 적어도 한 명의 부양가족이 있는 관리자들의 이름을 나열하라.

Q7: 

6.8 요약

• 기본 관계대수 연산

- 선택(SELECT), 프로젝트(PROJECT), 합집합(UNION), 차집합(SET DIFFERNECE), 카티션 프로덕트(Cartesion Product)

• 추가적인 관계연산

- 집계함수, 그루핑 연산, 외부조인 연산

• 관계 대수 질의의 예

• 투플-관계 해석

- 투플 변수와 정량자(존재 정량자와 전체 정량자)

- 질의 예제

- 안전식

• 도메인 관계 해석

합집합 = 삽입(Insert)

차집합 = 삭제(Delete)

삭제 후 삽입 = 수정(Update)

2014/04/11 - [Database System] - Chapter 2

2014/04/11 - [Database System] - Chapter 1

3.1 관계 모델의 개념

• 관계 모델에서 데이터베이스는 릴레이션(테이블)들의 모임으로 표현됨
• 릴레이션은 투플(행, 레코드)들의 집합으로 표현됨
• 투플은 애트리뷰트(컬럼, 필드 혹은 속성)들로 구성됨

• ER모델과의 비교

- 행: 엔티티 혹은 관계에 해당하는 사실을 표현함

- 열: 애트리뷰트들을 표시함

• 관계 모델의 용어

- 행: 투플

- 열: 애트리뷰트(속성)

- 테이블: 릴레이션

• 집합

- 0또는 하나 이상의 서로 다른 원소들의 모임. 단, 원소의 순서는 집합의 다름을 결정하는데 아무런 영향을 끼치지 못함.

3.1.1 도메인, 애트리뷰트, 투플, 릴레이션

• 릴레이션과 연관된 용어들

- 도메인(domain): 원자 값(atomic values)들의 집합.

값의 사실성을 근거로 존재함.

• USA_phone_numbers: 미국에서 사용하는 10자리 전화번호들의 집합
• Names: 개인의 이름들의 집합
• Age: 16~60 사이의 사원들의 나이(정수)

• 릴레이션 스키마(Relation schema)

• 릴레이션의 차수(degree): 릴레이션의 애트리뷰트 갯수

• 릴레이션 의 투플 t: n-투플이라고 부름

- 값들의 (순서화된) 집합  값 는 의 한 원소임.

• R에 대한 릴레이션 혹은 릴레이션 인스턴스(Relation instance) 

- 투플의 집합: 

- : 은 실세계의 특정 상태를 반영

3.1.2 릴레이션의 특성

• 릴레이션에서 투플의 순서는 의미가 없음

- 집합에서 원소의 순서가 무의미한 것과 마찬가지

• 각 투플 내에서의 값들의 순서

- n-투플은 n개 값의 리스트이며, 한 투플 내에서 값들의 순서는 중요

(리스트에서 원소의 순서는 중요한 의미를 가짐)

- 그러나 각 애트리뷰트와 값이 서로 대응될 수 있다면 애트리뷰트 값들의 순서는 중요하지 않을 수 있다.

예를 들어, 하나의 투플은 (<애트리뷰트>, <값>) 쌍들의 집합으로 간주하면 애트리뷰트와 값은 서로 대응될 수 있으며,값의 순서는 중요하지 않다.

• 투플 내의 필드값

- 나눌 수 없는 원자 값(atomic values)들

- 값을 알 수 없거나 해당되는 값이 없을 때에는 null 이라는 특수 값을 사용한다.

- ER 모델에서의 다치 애트리뷰트나 복합 애트리뷰트는 관계모델에서는 허용되지 않는다.

• 중복된 투플을 갖지 않는다.

3.1.3 관계 모델 표기

• 차수가 n인 릴레이션 스키마 R은 으로 표기한다.

• 릴레이션 의 n-투플 t는 으로 표기한다.

여기서 는 애트리뷰트 의 값이다.

•  또는 는 t에서 애트리뷰트 의 값 를 가리킨다.

• 투플 t의 구성 요소 값(component value)을 (투플 t에 대한 애트리뷰트 의 값)로 표기한다. 마찬가지로, 는 애트리뷰트 의 값을 포함하는 부(sub)-투플을 가리킨다.

• 대문자 Q, R, S등은 릴레이션 이름을 나타낸다.

• 소문자 q, r, s등은 릴레이션 상태를 나타낸다.

• 소문자 t, u, v등은 투플을 나타낸다.

• 일반적으로 STUDENT처럼 릴레이션 스키마의 이름은 릴레이션의 현재 투플들의 집합, 즉 현재의 릴레이션 상태를 가리키고, 반면에 STUDENT(Name, SSN, ...)는 릴레이션 스키마를 가리킨다.

• 서로 다른 릴레이션에서 동일한 이름의 애트리뷰트를 사용할 수 있으며,

• 제약조건은 모든 릴레이션 인스턴스들이 만족해야 하는 조건이다.

• 주요 제약조건

• 이 절의 구성

• 각 애트리뷰트 A의 값은 반드시 A의 도메인 에 속하는 원자값이어야 한다.

• 도메인과 관련된 데이터 타입

• R의 슈퍼키(superkey)

• R의 키(key)

• 키 제약 조건

• 기본 키(primary key)

• 애트리뷰트의 값으로 null의 허용 여부도 중요한 제약 조건이다.

• null: 확정되지 않는 값

• 관계형 데이터베이스 스키마

• 데이터베이스 스키마 S의 관계 데이터베이스 상태(혹은 인스턴스)

• 엔티티 무결성 제약조건

• 참조 무결성 제약조건

2014/04/11 - [Database System] - Chapter 1

데이터 모델을 정의하기 위한 3요소

1. 구조
2. 제약조건
3. 연산

2.1 데이터 모델, 스키마, 인스턴스

• 데이터 모델

- 데이터 타입, 관계, 제약조건들을 명시하기 위해 사용할 수 있는 개념들의 집합

- 데이터베이스에서 검색과 갱신을 수행하는 기본 연산들의 집합을 포함

• 점차 DB 응용의 동적 측면 또는 행동이 데이터 모델에 포함됨

- 사용자 정의 연산(user defined operation)

(예) COMPUTE_GPA

2.1.1 데이터 모델의 분류

• 저수준 또는 물리적 데이터 모델

- 어떻게 데이터가 컴퓨터에 저장되는지의 세부 사항을 명시하는 개념을 제공

• 고수준 또는 개념적 데이터 모델

- 사용자들이 데이터를 인식하는 방식에 대한 개념을 제공

- ER 모델, SDM 모델, DAPLEX 모델, ...

• 표현(또는 구현) 데이터 모델

- 고수준 모델과 저수준 모델 사이에 존재

- 일반 사용자들이 이해할 수 있는 개념을 제공

- 데이터 저장 구조의 세부 사항을 은폐하지만, 컴퓨터 상에서 직접 구현 가능함

- 상용 DBMS에서 많이 사용함

- 계층 모델, 네트워크 모델, 관계 모델

2.1.2 스키마, 인스턴스, 데이터베이스 상태

• 데이터베이스 스키마(또는 메타 데이터)

- 데이터베이스에 대한 기술

- 데이터베이스 설계 과정에서 명시하며 자주 변경되지 않음

- 메타 데이터 역할

• 스키마 다이어그램

- 데이터베이스 스키마를 도식화한 것이다.

- 레코드 타입의 이름, 데이터 항목의 이름, 일부 제약 조건 유형들과 같은 스키마의 일부 관점만을 나타낸다.

• 데이터베이스 상태

- 어커런스나 인스턴스들의 집합이라고도 한다.

- 어떤 특정 시점에 데이터베이스에 들어있는 데이터

- 데이터베이스에 갱신 연산이 수행될 때마다 새로운 다른 데이터베이스 상태를 가진다.

- DBMS는 데이터베이스 상태가 스키마에 명시된 구조와 제약조건을 만족하는 유효한 상태임을 보장하는 책임을 일부 가진다.

• 일반적으로 스키마는 내포(intension)라 하고, 데이터베이스 상태는 외연(extension)이라 한다.

STUDENT

COURSE

PREREQUISITE

SECTION

GRADE_REPORT

2.2 3단계-스키마 아키텍처와 데이터 독립성

2.2.1 3단계-스키마 아키텍처

• 3단계-스키마 아키텍처의 목적

- 사용자의 응용과 물리적 데이터베이스의 분리

• 3단계-스키마 아키텍처

1. 내부 단계
2. 개념 단계
3. 외부단계 또는 뷰 단계

• 내부 단계

• 개념 단계

• 외부 단계 또는 뷰 단계

• 사상

2.2.2 데이터 독립성

• 논리적 데이터 독립성

- 외부 스키마나 응용 프로그램을 변경하지 않으면서 개념 스키마를 변경할 수 있는 능력(성질)

• 물리적 데이터 독립성

- 개념 스키마를 변경하지 않으면서 내부 스키마를 변경할 수 있는 능력(성질)

2.3 데이터베이스 언어와 인터페이스

2.3.1 DBMS 언어

• 데이터 정의어(DDL: Data Definition Language)

- 개념 스키마와 내부 스키마를 정의

• 어떤 DBMS에서는 저장구조 정의어(SDL: Storage Definition Language)를 사용하여 내부 스키마를 나타내고, 뷰 정의어(VDL: View Definition Language)를 사용하여 뷰를 명시하거나 개념 스키마 사이의 사상을 나타냄

• 데이터 조작어(DML: Data Manipulation Language)

- 데이터를 검색, 삽입, 삭제, 수정하기 위한 조작 언어

- 비 절차적인 언어, 사용이 편리한 언어를 사용

- DML 명령어는 범용 프로그래밍 언어에 삽입되어 사용될 수 있고, 이때 범용 프로그래밍 언어를 호스트 언어라 하고, 삽입된 DML 명령어를 데이터 부속어라 함.

2.3.2 DBMS 인터페이스

• 메뉴 기반 인터페이스

• 폼 기반 인터페이스

• 그래픽 사용자 인터페이스

• 자연어 인터페이스

• 초보자를 위한 인터페이스

• 데이터베이스 관리자를 위한 인터페이스

2.4 데이터베이스 시스템 환경

2.4.1 DBMS 구성 모듈

• 저장 데이터 관리자

- 디스크에 저장되어 있는 DBMS의 정보(데이터베이스 또는 카탈로그)에 대한 접근을 제어

• 데이터 정의어 컴파일러

- 데이터 정의어로 명시된 스키마 정의들을 처리

- 스키마들에 대한 정보(메타 데이터)를 DBMS 카탈로그 안에 저장

• 런타임 데이터베이스 처리기(run-time database processor)

- 수행시 데이터베이스 접근을 처리

• 질의 컴파일러

- 대화식으로 입력된 고수준 질의들을 처리

• 프리컴파일러(precompiler)

- 호스트 프로그래밍 언어로 작성된 응용 프로그램에서 데이터 조작어 명령들을 추출

• 데이터 조작어 컴파일러

- 데이터 조작어 명령어들을 데이터베이스 접근을 위한 목적 코드로 컴파일

2.4.2 데이터베이스 시스템 유틸리티

• 데이터베이스 유틸리티

- DBMS는 데이터베이스 관리자의 데이터베이스 시스템 운영을 도와줌

• 적재

- 데이터 화일을 자동적으로 데이터베이스 화일의 형식으로 변환해서 저장함

• 백업

- 전체 데이터베이스를 테이프에 복사하여 데이터베이스의 백업 사본을 만듬

• 화일 재조직

- 성능 향상을 위해 데이터베이스 화일 구조를 다른 화일 구조로 재조직함

• 성능 모니터링

- 데이터베이스의 사용을 모니터해서 사용 통계를 데이터베이스 관리자에게 제공함

- 이 정보는 관리자가 데이터베이스 성능을 향상시키기 위해서 화일들을 재족힐 것인지를 결졍하는데 사용됨

• 데이터 사전 시스템(data dictionary system)

- 스키마와 제약 조건들에 관한 카탈로그 정보와 설계 결정, 사용 표준, 응용 프로그램 기술, 사용자 정보 등과 같은 정보를 저장

- DBMS 카탈로그와 유사하니 더 다양한 정보를 가짐

- DBMS 소프트웨어보다는 주로 사용자가 접근

- 데이터 저장소(data repository system) 혹은 정보 저장소(information repository)라고도 함

• 데이터 디렉토리(또는 능동 데이터 사전)

- 사용자와 DBMS 소프트웨어 모두가 사용하는 통합된 카탈로그/데이터 사전

(수동 데이터 사전은 사용자만 이용하는 데이터 사전을 의미)

2.4.3 도구, 응용 환경, 통신 장비

• CASE 도구

- 데이터베이스 시스템을 설계하는 과정에서 사용됨

• 응용 개발 환경

- PowerBuilder 시스템

• 통신 소프트웨어와 통신 장비를 사용하여 데이터베이스 시스템 사이트로부터 멀리 떨어진 컴퓨터 터미널, 워크스테이션, 마이크로 컴퓨터나 소형 컴퓨터에서 데이터베이스를 접근하는 것이 가능함

- DB/DC 시스템: DBMS와 데이터 통신 시스템의 결합체

2.5 DBMS를 위한 중앙집중식과 클라이언트/서버 아키텍처

• DBMS의 분류 기준

- 데이터 모델: 관계, 네트워크, 계층, 객체지향, 객체관계 등

- 사용자의 수: 단일 사용자, 다수 사용자 시스템

- 사이트의 수: 중앙집중식, 분산 DBMS(동질 분산 DBMS 또는 이질 분산 DBMS)

- DBMS의 비용

- 접근 경로의 유형

- 범용 또는 특수 목적용

• 관계 모델

- 데이터베이스는 테이블들의 모임으로 구성

- 그림 1.2와 유사(Chapter 1)

- 고급 질의어를 제공하고 제한된 형태의 사용자 뷰를 지원

• 네트워크 모델

- 데이터를 레코드 타입들로 나타냄

- 그림 2.4 참고

• 계층 모델

- 데이터를 계층적 트리 구조로 나타냄

• 객체지향 모델

- 객체, 객체의 속성, 연산으로 데이터베이스를 정의

- 같은 구조와 행위를 갖는 객체들은 한 클래스에 속하고 클래스들은 계층 또는 비순환 그래프로 조직됨

- 메서드라고 하는 미리 정의된 프로시저들이 클래스의 연산을 나타냄

• 객체관계 모델

- 관계 모델에 객체지향 모델의 개념을 도입하여 확장함

2.6 요약

• 데이터 모델

- 고수준 또는 개념적 데이터 모델(개체 관계)

- 데이터 모델들의 구현(레코드 기반, 객체지향)

- 저수준 또는 물리적 데이터 모델

• 스키마

- 외부 스키마, 개념 스키마, 내부 스키마

• 데이터베이스 상태

• 논리적, 물리적 데이터 독립성

• DBMS가 지원하는 언어

- 데이터 정의어, 데이터 조작어

• 인터페이스 유형

• DBMS 유틸리티

• DBMS의 분류

1.1 개요

• 데이터베이스는 서로 연관이 있는 데이터들의 모임.

• 데이터베이스 정의

- 작은 세계(mini-world) 또는 논의 세계(UoD)라고 부르는 실세계의 일부분을 표현.

- 어떤 특정한 의미를 가지는 데이터의 모임.

- 특정한 목적을 위해서 설계, 구축, 운용.

- 데이터베이스에 저장되는 데이터에 대한 데이터 타입, 구조, 제약조건들을 명세하는 과정

• 데이터

- 관찰, 수집, 측정, 실험등으로 통해 얻어진 객관적 사실이나 값.

- 알려진 사실로서 의미를 가지고 기록될 수 있다는 특성을 갖는다. (의미를 가지면서 기록될 수 있는 알려진 사실)

• 메타데이터

- 타겟이 되는 데이터의 내용을 확인할 수 있게 정보를 제공해주는 것.

- 데이터베이스에 대한 정보

• 정보

- 데이터들의 어떠한 무의미한 값

• 운영 데이터

- 어떤 기관의 고유한 목적을 달성하기 위해 수행하는 활동을 수행하는데 사용되는 모든 데이터

• 데이터베이스 관리 시스템(DBMS)

- 사용자가 데이터베이스를 생성하고 관리할 수 있도록 편리한 기능을 제공하는 프로그램들의 모임.

- Database의 생성과 관리를 담당하는 소프트웨어 패키지

• 트랜잭션

- 데이터베이스에 데이터를 저장하거나 갱신하는 단위.

- 동시성 제어의 단위.

• 동시성 제어

- 처리 도중 에러가 발생되면 그 전 작업들을 모두 취소가 된다.

- 데이터 무결성 및 일관성 보장

• 보호

1. 하드웨어 또는 소프트웨어 오동작(또는 붕괴)으로부터 시스템을 보호
2. 보안 위협으로부터 보호

• 유지보수

DBMS는 시간이 지남에 따라 변화하는 요구사항을 반영할 수 있도록 데이터베이스 시스템을 유지보수할 수 있어야 한다.

• 데이터베이스 시스템(Database System)

• 데이터베이스 접근방법

• 작은 세계(mini-world)

- 데이터베이스 구축의 대상이 되는 실세계의 일부분

1.2 데이터베이스의 예

• 대학교 정보 데이터베이스 예제 - 엔티티와 관계의 집합

1. 엔티티

- STUDENT

- COURSE

- (COURSE의) SECTION

- DEPARTMENT

- INSTRUCTOR

2. 엔티티 사이의 관계

- SECTION은 특정 COURSE에 속한다.

- STUDENT는 SECTION에 참가한다.

- COURSE는 선수 COURSE가 있다.

- INSTRUCTOR는 SECTION을 강의한다.

- COURSE는 DEPARTMENT에서 제공한다.

- STUDENT는 DEPARTMENT를 전공한다.

STUDENT(학생에 관련된 데이터)

COURSE(개설된 과목에 관한 데이터)

SECTION(과목의 각 강좌에 관한 데이터)

GRADE_REPORT(학생이 수강한 강좌의 성적)

PREREQUISITE(각 과목의 선수과목)

• 데이터베이스 설계과정

1. 요구사항 명세 및 분석(requirements specification and analysis)
2. 개념적 설계(conceptual design)
3. 논리적 설계(logical design)
4. 물리적 설계(physical design)

• 파일처리

- 사용자가 특정한 소프트웨어 응용을 위하여 필요한 파일들을 별도로 정의하고 구현.

1.3.1 데이터베이스 시스템의 자기 기술성(self-describing)

- 각 파일들의 구조, 각 데이터 항목의 타입과 저장 형식, 데이터에 대한 다양한 제약조건

- 카탈로그에 저장된 정보를 메타데이터라 부르며, 데이터베이스의 구조를 기술

1.3.2 프로그램과 데이터의 격리 및 데이터 추상화

• 프로그램과 데이터의 분리

- 데이터베이스 내의 데이터 저장 구조가 변경되어도 데이터베이스 응용 프로그램은 영향을 받지 않는 (변경될 필요가 없는) 성질 -> 데이터 독립성을 높임.

• 데이터 추상화

- 데이터 모델(data model)을 사용함으로써 저장 구조의 자세한 내용은 사용자로부터 은닉시키고 각자의 요구에 맞는 개념적인 뷰만 제공함.

• 프로그램-데이터 독립성(program-data independence)

- 데이터 파일의 구조가 응용 프로그램과 분리되어 DBMS 카탈로그에 저장

• 프로그램-연산 독립성(program-operation independence)

- 연산의 구현이 변경되어도 인터페이스가 유지되는 한 응용 프로그램은 변경할 필요가 없다.

- 사용자 응용 프로그램에서는 연산의 구현 내용을 몰라도 연산의 이름과 매개 변수들을 사용해서 연산을 호출함으로써 데이터에 대한 연산을 수행할 수 있다.

1.3.3 데이터에 대한 다중 뷰의 제공

- 사용자는 전체 데이터베이스 보다는 관심이 있는 데이터베이스의 일부를 뷰로 정의할 수 있음.

1.3.4 데이터의 공유와 다수 사용자 트랜잭션 처리

- 여러 사용자가 동일한 데이터베이스 공유 가능하도록 지원

- 동시에 사용하더라도 일관성을 보장하기 위한 동시성 제어 기능 제공

TRANSCRIPT

(a) 학생의 성적표 뷰

STUDENT - Student_name

SECTION - Course_number | Semester

GRADE_REPORT -  Grade | Section_identifier

COURSE_PREREQUISITES

(b) 과목의 선수과목 뷰

COURSE - Course_name | Course_number

PREREQUISITE - Course_number | Prerequisite_number

1.4 데이터베이스 사용자의 분류

1.4.1 데이터베이스 관리자(Database administrator, DBA)

- 데이터베이스 시스템의 관리를 책임진 사람

1.4.2 데이터베이스 설계자(Database Designer)

- 데이터베이스 설계를 책임진 사람

1.4.3 최종 사용자

- 데이터베이스에 대하여 질의, 갱신, 보고서 작성 등을 담당하는 사람

• 캐주얼 사용자(casual end user)

- 비정기적인데이터베이스 사용자

- 정교한 질의어를 사용해 데이터를 요구하며, 대개 중상급의 관리자

• 초보 사용자(naive 또는 parametric end user)

- 미리 일정한 용도로 작성된 프로그램을 사용하는 사용자(은행 점원이나 여행사 예약 담당원 등)

• 전문 사용자(sophisticated end user)

- 엔지니어, 과학자, 비즈니스 분석가 등으로, DBMS의 고급 기능을 이용하여 복잡한 응용을 개발(구현)

• 독자적인 사용자(stand-alone end user)

- 메뉴나 그래픽 사용자 인터페이스를 제공하는 편리한 패키지를 사용하여 개인 데이터베이스를 유지하는 사용자(세금 계산을 목적으로 개인의 다양한 재정 데이터를 저장하는 세금 패키지의 사용자)

1.4.4 시스템 분석가 및 응용 프로그래머(소프트웨어 공학자)

- 초보 사용자를 위하여 잘 정의된 기능의 응용을 분석/설계하고 구현하는 사람

1.5 무대 뒤의 사람들(Database 사용자)

• DBMS 설계 및 구현자

- DBMS 소프트웨어 자체를 설계하고 구현하는 업무를 담당하는 사람들

• 도구 개발자

- 데이터베이스를 사용하는 데에 필요한 도구들(데이터베이스 설계 및 구축 도구, 성능 도구, 인터페이스 등)을 설계하고 구현하는 사람들

• 운영 및 유지 보수 요원

- 데이터베이스 시스템을 운영하는 데에 필요한 하드웨어 및 소프트웨어의 운영 및 유지 보수 담당 요원들

1.6 DBMS의 장점

- 데이터 중복이 있어선 안된다.

1.6.1 중복성의 제어

• 데이터 중복성의 제어 및 중복의 최소화

- 데이터 일치성(consistency) 보장 및 메모리 낭비 방지

1.6.2 권한이 없는 접근의 통제

• 보안 기능

- 권한없는 사용자의 데이터 접근을 통제

1.6.3 프로그램 객체를 위한 지속성 기억 공간 제공

• 프로그램 객체와 데이터 구조에 대한 지속성 기억 공간 제공

- 데이터베이스에 영구적으로 보관/저장

1.6.5 백업과 회복 제공

- 시스템 고장시에도 데이터의 일관성을 보장

1.6.6 다수의 사용자 인터페이스 제공

1.6.7 데이터 간의 복잡한 관계의 표현

1.6.8 무결성 제약조건의 시행

1.6.9 규칙을 사용한 추론과 수행

- 연역적 규칙을 이용하여 데이터베이스 저장된 사실로부터 새로운 정보를 추론

- 자동으로 수행되는 능동 규칙의 정의 및 실행

• 연역 데이터베이스 시스템(deductive database system)

• 트리거(trigger)

• 저장된 절차(stored procedure)

1.6.10 데이터베이스 사용에 함축된 또 다른 의미

1. 표준 강화
2. 응용 개발 시간의 단축
3. 융통성
4. 최신 정보의 가용성
5. 규모의 경제성

• 동시성 제어 기능 제공

- 여러 사용자가 동시에 DB를 접근하여 효율적으로 처리

- 동시 접근 시에도 데이터의 손실 방지, 일관성 보장

• 데이터 독립성 제공

- 데이터베이스를 쉽게 사용할 수 있게 함, 응용 프로그램 개발이 용이

- 내부 저장 구조를 변경하기 용이, 프로그램 및 데이터베이스 유지보수가 용이

데이터 불일치와 제어된 중복: 예

GRADE_REPORT

(a)

GRADE_REPORT

(b)

(a) 제어된 중복성

- 성능을 위하여 GRADE_REPORT 파일에 Student_name과 Course_number를 포함시키고, 두 속성의 값이 STUDENT에서의 두 속성값과 일치하도록 DBMS가 보장함

(b) 비제어된 중복성

- 1.2 데이터베이스의 예의 STUDENT 레코드와 불일치하는 GRADE_REPORT 레코드의 예(17번 학생은 Brown이 아니라 Smith임)

1.7 데이터베이스 사용의 효과

• 표준화된 데이터 관리

- 조직 내 모든 부서에서 표준화된 문서 관리로 업무 효율성 증대

• 응용 프로그램의 개발 시간 단축

- 응용 프로그램의 상당한 부분을 DBMS가 처리함

• 데이터 구조 변경에 융통성 부여

- 데이터베이스 내의 자료 구조가 어떠한 이유로 변경되어도 사용자에 대한 영향은 거의 없음

• 항상 최신의 정보를 제공

- 사용자 중에서 한 사람의 갱신으로 나머지 사람은 즉시 변경된 값을 접근가능

• 규모의 경제성(economics of scale)

- 부서마다 다른 방식으로 자료를 관리하는 것보다 통합 DB로 관리하는 것이 전체적인 관점에서 저 비용임

1.8 Database를 사용하지 않아도 좋은 경우

• DBMS를 사용하면 비용이 높아짐

- 높은 초기 투자 비용과 추가적인 하드웨어 필요함

- 데이터의 보안, 동시성 제어, 회복, 무결성 조건 등의 기능이 필요하지 않은 응용(오버헤드가 됨)

• 언제 DBMS가 불필요한가?

- 데이터베이스와 응용이 단순하고 잘 정의되어 있으며, 변경될 가능성이 적을 경우

- DBMS 오버헤드로 인하여 엄격한 실시간 데이터 처리 요구사항을 만족시키기 힘든 경우

(최근들어 이러한 경우 실시간 DBMS 활용 가능)

- 다 사용자 데이터 접근이 필요하지 않은 경우

1.9 요약

• 용어 정의

- Database, DBMS, Database System

• 기존 화일 처리 시스템에 비하여 데이터베이스의 특징

- 카탈로그, 프로그램-데이터의 독립성, 프로그램-연산의 독립성, 데이터 추상화, 다중 뷰의 지원, 여러 트랜잭션 간의 데이터의 공유

• 데이터베이스 사용자의 분류

- 데이터베이스 관리자, 설계자, 최종 사용자, 시스템 분석가와 응용 프로그래머, DBMS 설계자 및 개발자, 데이터베이스 도구의 개발자, 운영자와 유지보수 인력

• DBMS의 기능들

- 중복성 제어 및 권한 검사

- 프로그램 객체와 데이터 구조에 대한 지속성 기억 공간 제공

- 규칙을 사용한 추론과 수행

- 다중 사용자 인터페이스 제공

- 데이터 사이의 복잡한 관련성 표현

- 무결성 제약조건 처리, 백업과 회복 기능

• 기존 화일 처리 시스템에 비하여 데이터베이스의 장점

- 표준화 강화, 응용 개발 시간의 단축, 융통성 증가, 최신 정보를 즉시 이용, 규모의 경제성