Chapter 3

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 사이의 사원들의 나이(정수)

-> 도메인은 실제 데이터 타입으로 명시함(int, char(10), ...)

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

- 릴레이션 이름 R과 애트리뷰트 들의 집합으로 로 표기함.

예: STUDENT(Name, SSN, BirthDate, Addr)

- DB의 구조(스킴의 복수형)

• 릴레이션의 차수(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, ...)는 릴레이션 스키마를 가리킨다.

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

이 경우 애트리뷰트 이름 앞에 릴레이션 이름을 붙여서 서로를 구분한다.

- STUDENT.Name, Faculty.Name, Employee.name

3.2 관계 모델 제약조건과 관계 데이터베이스 스키마

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

• 주요 제약조건

- 도메인 제약조건(domain constraints)

- 키 제약조건(key constraints)

- 엔티티 무결성 제약조건(entity integrity constraints)

- 참조 무결성 제약조건(referential integrity constraints)

• 이 절의 구성

3.2.1 도메인 제약조건

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

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

- 정수, 실수와 같은 표준 숫자형

- 문자, 고정길이 문자열, 가변길이 문자열

- 날짜, 시간

- 화폐단위

- 메모 등

3.2.2 키 제약조건과 널에 대한 제약조건

• R의 슈퍼키(superkey)

- R이 애트리뷰트 집합 SK로서 다음의 성질을 만족해야 한다.

- 모든 유효한 릴레이션 인스턴스 에서 어떠한 두 투플도 동일한 SK값을 갖지 않아야 한다.

즉, 내의 임의의 서로 다른 두 투플 과 에 대해

이어야 한다.

• R의 키(key)

- "최소" 슈퍼키; 즉, 슈퍼키 K를 구성하는 어느 한 애트리뷰트라도 빠지면 슈퍼키가 될 수 없는

슈퍼키 K를 의미한다.

• 키 제약 조건

1) 서로 다른 두 투플은 동일한 키 애트리뷰트를 가질 수 없다.

(릴레이션 인스턴스 내에서 같은 값이 절대로 중복되지 않는 속성이다.)

2) 키는 최소의 슈퍼키(minimal superkey)

• 기본 키(primary key)

- 릴레이션이 여러 개의 후보키(candidate key)를 가지면 이중 하나를 임의로 선택하여

기본키(primary key)로 지정한다.

- 기본키를 구성하는 애트리뷰트는 밑줄로 표시한다.

- 후보키 중에서 데이터베이스 설계자가 지정하는 키

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

• null: 확정되지 않는 값

3.2.3 관계데이터베이스와 관계 데이터베이스 스키마

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

- 동일한 데이터베이스에 속하는 릴레이션 스키마들의 집합 S와 무결성 제약조건 IC로 구성된다.

- 릴레이션 스키마 집합 S를 데이터베이스 이름이라고 정의한다.

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

- 릴레이션 상태들의 집합

예) Company {Employee, Department, Dept_locations, Projects, Works_On, Dependent}

는 관계 데이터베이스 스키마이고(그림 3.5),

그림 3.6은 Company 스키마에 해당하는 관계 데이터베이스 상태를 보여준다.

EMPLOYEE

Fname

Minit

Lname

Ssn

Bdate

Address

Sex

Salary

Super_ssn

Dno

DEPARTMENT

Dname

Dnumber

Mgr_ssn

Mgr_start_date

PROJECT

Pname

Pnumber

Plocation

Dnum

WORKS_ON

Essn

Pno

Hours

DEPENDENT

Essn

Dependent_name

Sex

Bdate

Relationship

[그림 3.5] 기본키에 밑줄을 그은 COMPANY 관계 데이터베이스 스키마 

3.2.4 엔티티 무결성 제약조건, 참조 무결성 제약조건, 외래키

• 엔티티 무결성 제약조건

- 어떠한 기본 키 값도 널 값을 가질 수 없다는 제약 조건이다.

- 기본키가 각 투플들을 식별하는 데에 이용되기 때문이다.

• 참조 무결성 제약조건

- 참조 무결성은 두 릴레이션에 대한 제약조건이다.

- 한 릴레이션 의 투플 이 다른 릴레이션 의 투플 을 참조할 때의 제약조건이다.

- : 참조하는 릴레이션

- : 참조되는 릴레이션

- 외래키(foreign key): 의 기본키(PK) 값을 참조하기 위해 존재하는 내의 속성 집합 FK

- 외래키(FK)의 제약조건

1) FK는 의 PK와 동일한 도메인을 가진다.

2) 의 FK값은 의 어떤 투플 의 PK값과 일치하거나 Null 값을 가진다.

- 관계형 데이터베이스 스키마에서 참조 무결성 제약조건은 . FK에서 로의 화살표로 표시한다.

• 무결성

1) 현실세계와 데이터베이스의 데이터가 일치하여 결함이 없는 것.

2) 현실세계의 객체와 데이터베이스안의 정보가 일치해야 한다.

릴레이션 인스턴스

3.3 갱신 연산과 트랜잭션 그리고 제약조건 위반의 처리

• 릴레이션에 대한 기본 갱신 연산들

- 삽입, 삭제, 수정

• 갱신 연산을 실행하는 경우 스키마에 정의된 무결성 제약조건을 위반하지 않아야 한다.

• 삽입 연산: 4가지 제약 조건을 위반할 수 있다.

- 삽입되는 투플 t에서 애트리뷰트의 값이 도메인에 없으면 도메인 제약 조건을 위반한다.

- t에서 기본 키(PK)의 값이 다른 투플에서 이미 존재한다면 키 제약 조건을 위반하며,

null이면 엔티티 제약 조건을 위반한다.

- t에서 외래 키(FK)의 값이 참조되는 릴레이션의 키 값으로 존재하지 않는다면

참조 제약 조건을 위반한다.

• 제약 조건을 위반하면 그 삽입을 거부하거나 그 위반 사실을 사용자에게 알려야 한다.

• 삭제 연산

- 투플이 삭제되는 경우 다른 테이블에서 참조하고 있는지 검사하여

그렇지 않는 경우에만 삭제한다.(참조 무결성)

• 삭제 연산이 참조 무결성 제약 조건을 위반하는 경우 취할 수 있는 3가지 옵션

- 삭제를 거부한다.

- 삭제되는 투플을 참조하는 투플들까지 모두 삭제한다.(연쇄 삭제)

- 삭제되는 투플을 참조하는 투플에서 외래키 값을 널로 바꾸거나 다른 유효한 투플을 참조하도록 변경한다.

• 위의 3가지 옵션 중 사용자가 응용의 특성에 적합한 것을 선택하도록 하는 것이 바람직하다.

• 갱신 연산

- 갱신 연산은 기본적으로 "삭제 후 삽입" 연산으로 간주할 수 있으므로 삽입과 삭제시의 문제점이 모두 나타난다.

- 기본 키(PK)나 외래키(FK)가 아닌 애트리뷰트 값의 변경은 문제가 없다.

3.4 요약

• 관계 모델의 개념

- 용어 정의

• 관계 제약조건과 관계형 데이터베이스 스키마

- 도메인 제약조건, 키 제약조건, 엔티티 무결성 제약조건, 참조 무결성 제약조건

- 스키마는 릴레이션의 집합과 제약 조건 집합으로 구성되어 있다.

• 갱신 연산과 제약조건의 위반 처리

- 릴레이션에 투플을 삽입하거나 삭제 변경할 때 제약조건을 만족하는 검사한다.