DB - Major Funtionalities of Database Systems

# 1 -6 RDB Functionalities

# Views

- 뷰는 특정 사요자로부터 특정 속성을 숨기는 기능

- 데이터베이스 스키마 일부를 특정 사용자에게 숨김

- 뷰 사용목적은 주로 데이터 보호

 

* View Definition

- "CREATE VIEW" 

 

* Views are always up to date

- 뷰는 항상 최신 데이터를 보유한다. 

- 뷰는 일반 테이블과 다르게 튜플을 실제 뷰 내부에 저장하지 않는다. 

 

* Views Using Other Viwes

- 뷰를 정의할 때 베이스테이블이나 또는 다른 뷰를 사용할 수 있다. 

 

* View Expansion

- 뷰에 대한 질의가 들어오면, 해당 뷰를 기존에 저장되어 있는 뷰 정의로 치환하여 뷰가 아닌 베이스 테이블에 대한 질의문이 되도록 한다.

 

* View Modifications

- 뷰에 대한 검색 연산 외에 변경 (입력, 삭제, 갱신) 연산도 가능하다

- 뷰에 대한 변경 연산은 뷰를 정의하고 있는 베이스 테이블에 대한 변경 연산으로 변환되어 수행이 되는데, 뷰에 대한 속성으로 인하여 변경 연산에는 많은 제약이 따른다. 

 

* Updatable View

- 변경 연산이 지원되는 뷰를 변경가능 뷰라고 한다.

- 뷰 생성 정의시에 다양한 제약이 존재. 

1. from 절은 오직 하나의 테이블

2. select 절은 오직 하나의 속성만. 집계함수 금지. distinct 금지

3. select 절의 속성은 Null 안됨

4. group by 나 having 절 있으면 안됨

 

 

* Restrictions on Views (뷰 제약)

1. 뷰에 대한 색인은 불가능하다. 

     - 뷰는 튜플을 가지고 있지 않아 색인이 의미가 없다

2. 뷰에 대한 키 속성 또는 무결성 제약을 정의할 수 없다. 

 

 

# Integrity Constraints

- 데이터베이스 시스템이 항상 만족하여야 하는 조건

 

* Constraints on a Single Relation

1. not null

2. primary key

3. unique

4. check (P), where P is a predicate

 

* Not Null / Primary Key / Unique Constraints

- not null은 개별 속성에 적용 가능 

- pk와 unique는 한 개 이상의 속성에 적용 가능 

- pk가 되면 null 을 가질 수 없으나, unique는 null 가질 수 있음 

 

* check clause

- 관련 테이블이 항상 만족하여야 하는 조건 명시

 

* Referential Integrity Constraints (참조 무결성 제약)

- 외래 키에 나오는 모든 값은 외래 키가 참조하는 테이블의 PK 값으로 나와야 한다. 

- FK는 Null을 가질 수 있음

 

Refential Integrity Declaration

- 참조 무결성이 위반되는 경우 이를 해결하는 구체적인 행동까지 명시할 수 있음

- "cascade", "set null", "set default" 

- 참조 무결성은 외래키를 가지는 테이블에서 선언됨. 참조되는 테이블에서는 선언하는 부분이 없다.

 

* "on delete" (삭제 연산 처리)

- professor 테이블의 첫 번째 튜플이 삭제되면, teaches 테이블에서 참조하는 튜플로 인하여 참조 무결성이 위배된다.

- 이 경우, 행동이 명시되지 않았으면 삭제 연산이 허용되지 않는다.

- cascade인 경우에는 삭제 연산이 teaches 테이블에 파급되어 삭제된 튜플 참조하는 두 튜플이 모두 삭제된다. 

- set null  행동은 해당 테이블 속성 값을 널 값으로 하는 것인데, 이 경우에는 teaches 테이블 PK이므로 허용 X

 

* "on update " Operation

- professor 테이블의 첫 번째 튜플의 값을 100에서 400으로 변경하면, 참조 무결성 제약에 위반되므로 수행 x

- cascade인 경우에는 teaches 테이블의 첫 번째와 두 번째 튜플의 값이 함께 변경된다. 

 

* Deferrable ICs (연기된 무결성 제약)

- 무결성 제약은 기본적으로는 즉시 실행되나, 무결성 제약을 명시할 때 "initially deferred" 표현을 하면 무결성 제약 검사 및 행동을 연기할 수도 있다. 

- 트랜잭션 정의 시에 무결성 제약 점검을 연기할 수도 있다. 

 

* Complex Integrity Constraints

생략

* Assertion Example

생략

 

 

# Triggers

- 데이터베이스 시스템이 무결성 제약 관리를 위하여 지원하는 기능

- 기본적으로 사건 (event) / 조건 (condition) / 행동 (action) 부문으로 구성된다. 

- 데이터베이스 시스템에 어떤 사건이 발생하면, 주어진 조건을 평가하여 조건이 만족되면 주어진 행동을 하는 규칙

- 여기서 사건이란 DB 변경 연산을 뜻함. (insert/delete/update)

 

* Events and Actions in Triggers

- 트리거에서 의미하는 사건은 튜플 인스턴스 변화.

- insert, delete, update 연산을 의미

 

# Example

→ after update of grade on takes

→ referencing old row as : for deletes and updates

→ referencing new row as : for inserts and update

 

 

*  Trigger Example 1

- 학생이 수업을 수강하여 학점을 취득하면 학생이 취득한 총 학점을 변경하는 트리거를 구성해 보자.

- Event 

    →  Update of grade on takes :: grade 속성에 변경이 있을 때 

- Condition

    → 값이 변경 전에는 F 아니면 null

    → 변경 후에는 F도 아니고 null 도 아니어야 함

    → 변경 후에도 F, null 이면 트리거 수행 ㄴㄴ

- Action

    → student 테이블의 totalCredit 속성 값 조정

    → 추가하는 학점은 course 테이블에서 찾을 수 있다. 

 

- 첫 문장에서 트리거 이름과 사건 명시

- 2, 3번째 문장은 update가 발생하는 경우 update 전과 후의 테이블의 튜플을 참조하는 문장 

- 4번째 문장(for each row)은 조건과 행동을 값이 변경된 각 튜플을 기준으로 수행. 즉, takes 테이블의 udpate된 각 튜플에 대하여 조건을 검사하고 조건이 만족하면 행동(update 문장) 수행

- when 절은 조건 명시, 조건 밑에 나오는 begin 블록이 트리거의 행동 명시 

- begin 블록 내용은 student 테이블의 totalCredit 속성 갱신

 

 

* Trigger Example 2

- 간단한 은행 관련 스키마 

- Event :

    → account 관계 갱신

 

- Condition :

    → balance 속성 값이 음수로 되는 것 

 

- Action:

    →  트리거는 잔고보다 더 많은 금액의 수표가 발생되는 경우(즉, overdraft), 대출 계좌를 사용자 명의로 개설하고 대출금을 overdraft된 금액으로 하는 작업

 

- 첫 번째 입력 연산 : borrower 테이블에 새로운 튜플 생성

- depositor 관계에 있는 account 번호를 loan number 로 사용

 

- 두 번쨰 입력 연산 : loan 테이블에 새로운 튜플 생성 

- 주어진 balance 값에 음수를 붙여 양수로 만들고, 이를 loan amount로 입력 

 

- 마지막 갱신 연산 : account 테이블의 balance 속성 값을 0으로 갱신

 

⭐️ action에 해당되는 insert/insert/update 문장을 트랜잭션으로 수행하기 위하여 "begin atomic ... end" 사용

- 이렇게 하면 all-or-nothing

- 만약 aciton SQL 문장이 하나면 사용하지 않아도 무방

 

 

* Trigger Example 3

- Event :

    → employee 테이블의 salary 속성에 변경 발생

- Condition : 

    → nrow, dNumber 값이 널이 아님

- Action : 

    → department 테이블의 totalSalary 속성을 변경

 

 

 

 

* Triggers can be activated before an event

- 트리거는 이벤트 전에 수행될 수 있다.

- 트리거를 정의할 떄, before 키워드를 사용하면 트리거는 이벤트가 수행되기 전 수행

grade가 빈칸이면 null로 갱신하는 트리거

- takes 테이블을 갱신하기 전에 튜플의 grade 속성 값이 ' ' 이면 null 로

 

* Statement Level Triggers

- 문장 수준 트리거는 튜플 단위가 아니고 SQL 문장 단위로 트리거 수행

- Evnet 전후 테이블을 테이블 단위로 참조

- 트리거 행동으로 인하여 많은 튜플에 변화가 있는 경우 문장 수준 트리거 유용

 

- "for each row"가 대신 "for each statement" 사용

- 임시 테이블을 지칠하기 위해 "referencing old table" or "referencing new table" 사용

 

 

* Statement Level Triggers Example

- employee 테이블의 salary 속성에 변경이 발생하는 경우 department 테이블의 totalSalary 속성을 변경하는 문장 수준 트리거

- when 조건 : 구 테이블이나 신 테이블의 dNumber 속성이 null 이 아닌 튜플이 존재하면 만족

- 트리거 실행 부분에서 각 튜플별로 수행을 하지 않고 전체 테이블에 대하여 일괄적으로 totalSalary 속성 값을 변경하고 있다. 

 

 

* Comments an Triggers

- 트리거는 속성의 통계정보를 유지하거나, 또는 임의 테이블의 복사본을 유지할 떄 많이 사용하였다. 

- 현대 DB는 편리한 실체화된 뷰 기능을 제공하고, 테이블 복제를 지원하는 replication 기능 제공

 

- 데이터의 대한 연산을 메소드 방식으로 지원하므로 꼭 트리거를 사용하여 구현하지 않아도 된다.