Query Processing, Transactions, Integrity Constraint

Basic Steps in Query Processing

Parsing & Translation

• input query → relational algebra
• parser checks syntax & verifies if the query expression is correct or not

Optimization

• The process of choosing suitable execution strategy to process a query (translated algebra)

1. how to reduce the number of disk access
2. how to reduce the size of intermediate result
3. how to reduce the response time

ex)
$\sigma_{balance<2500}(\Pi_{balance}(account))$
$\Pi_{balance}(\sigma_{balance<2500}(account))$ ← 효율성 ↑

ex)
$R \Join (\sigma_{Sc}(S))$ ← 효율성 ↑
$\sigma_{Sc}(R\Join S)$

Evaluation

• The query-evaluation engine generates an executable code
  from the optimized algebra, executes the code and finally
  returns the answer

Example

1. Q: Retrieve name of students who register 'C413' course
2. Step 1) → SQL Query

FROM S,E
WHERE S.Sno=E.Sno AND Cno='C413'

3. Step 2) → Relational Algebra (parser & translator)
   $\Pi_{Sname}(\sigma_{cno='C413'}(E \Join S))$
4. Step 3) → More Efficient Relational Algebra (optimization)
   $\Pi_{Sname}(\sigma_{cno='C413'}(E) \Join S)$

Transaction - Concept & Issues

Transaction

• 데이터에 억세스해서 update 등을 수행하는 프로그램의 단위
• 서로 간 독립성을 보장해야함

ex) 계좌 A → 계좌 B ($50 송금)

1. read(A)
2. A := A-50
3. write(A)
4. read(B)
5. B := B+50
6. write(B)

Transaction Issues

Atomicity issue in a case of failure

• step 3 / step 6 사이에 failure 발생하면 데이터에 문제가 생길 수 있음
• 트랜잭션은 DB를 완벽하고 정확하게 update하거나 update하지 말아야함

Consistency issue

• 위 드랜잭션 수행 전후의 A와 B의 합은 유지되어야함
• 트랜잭션 수행 전후의 데이터의 일관성이 유지되어야함

Isolation issue in a case of multiple transactions

• step 3 / step 6 사이에 다른 트랜잭션 T2가 DB에 억세스하면, T2의 결과가 틀릴 수 있음
• T2: $read(A), read(B), print(A+B)$
• isolation(고립)이란 여러 개의 트랜잭션이 동시에 수행될때 서로 영향을 주지 않으면서 각 트랜잭션이 완료되어야함
• 해결방안: 트랜잭션을 순차적으로 수행하는 방법 etc.

Durability issue

• 한번 완료된 트랜잭션의 결과는 계속 유지되어야함
• 트랜잭션 완료 후 SW, HW failure가 발생해도 결과가 유지되어야함
• 완료된 트랜잭션의 결과는 휘발성 메모리보다는 하드디스크에 저장하는 것이 안정적임

Transaction - ACID Properties

ACID Properties

Atomicity: failure 상황 발생해도 데이터에 문제가 생기지 않도록 update 여부 결정
Consistency: 전후 데이터의 합 이 일정해야함
Isolation: multiple transaction에서 동일한 곳 접근할때는 순차적으로
Durability: 비휘발성 메모리에 저장

Transaction - Transaction State

Active 상태

• 트랜잭션의 초기 상태 및 실행 중인 상태

Partially committed (부분 완료) 상태

• 트랜잭션의 마지막 operation이 실행된 직후의 상태

Failed (실패) 상태

• 트랜잭션이 완료되기 전에 더 이상 정상적인 수행이 불가능한 상태

Aborted (중단) 상태

• 트랜잭션 실패로 진입하는 상태
• 트랜잭션 중단 상태 이후 처리 방법
  • restart the transaction
  • kill the transaction

Committed (완료) 상태

• 트랜잭션을 성공적으로 완료한 상태

Integrity Constraint - Domain Constraint

• 도메인 무결성 제약조건
• 특정 attribute에 저장되는 값에 제약을 두는 방법

ex)

create domain hourly-wage float(3)
	constraint value-test check(value >= 4.00)

ex)

create domain GENDER char(1)
	constraint value-test check(value in ('남', '여'))

ex)

create table 학생
	(이름 varchar(15) not null,
    학년 INT,
    성별 GENDER,						← 자료형 자리에 DOMAIN CONSTRAINT 이름
    PRIMARY KEY(이름),
    CONSTRAINT 학년제약 CHECK(학년>=1));	← CONSTRAINT 추가

Integrity Constraint - Referential Integrity

• 참조 무결성 제약조건
• 외래키(참조키) 제약조건
• attribute A는 다른 relation의 attribute A에 포함되는 값만 가질 수 있다는 제약을 두는 방법

ex)

create table account
	(branch-name char(15),
    account-number char(10) not null,
    balance integer,
    primary key(account-number),
    foreign key(branch-name) references branch)		← 외래키 제약조건

Cascading Actions in SQL

ex)

create table account
	(branch-name char(15),
    account-number char(10) not null,
    balance integer,
    primary key(account-number),
    foreign key(branch-name) references branch	← 쉼표 없음에 주의
    on delete cascade		← on delete cascade; 쉼표 없음에 주의
    on update cascade)		← on update cascade; 쉼표 없음에 주의

on delete cascade

• branch relation에서 어떤 tuple이 삭제되면, account relation에서 해당 branch_name을 가지고 있는 튜플도 함께 삭제

on update cascade

• branch relation에서 어떤 tuple의 branch_name이 갱신되면, account relation에서 해당 branch_name의 값도 함께 갱신