CS/DB

DB 기초 - 2

hyelie 2023. 10. 1. 04:11
이 글은 포스텍 한욱신 교수님의 데이터베이스시스템(CSED421) 강의를 기반으로 재구성한 것입니다.

 

Key

 다음 4종류가 있다.

  • Candidate Key : tuple을 unique하게 식별할 수 있는 attribute set.
    • + minimality : attribute 1개를 지우면 식별할 수 없다.
  • Super Key : key의 super set
  • Primary Key : candidate key 중 지정된 것.
  • Foreign Key : 다른 relation을 참조하기 위해 다른 relation의 key를 가져온 것. dangling을 알아서 처리해 준다.

 

 

 

Normal Form / Normalization

 [1NF - 2NF - 3NF - BCNF - 4NF - 5NF] 순서로 더 higher하다. 사용하는 목적은 redundancy를 줄여 anomaly를 막기 위함이다. 단점으로는 relation이 쪼개져 join 연산이 많아진다는 것이 있다.

  • 1NF : 모든 도메인이 atomic value일 때
  • 2NF : 모든 non-key attribute가 candidate key에 fully dependent한 경우.
    • (부분적 함수 종속 제거, partial functional dependency 삭제)
    • candidate key의 일부분으로 식별할 수 없는 것.
  • 3NF : 모든 functional dependency X => Y에 대해 X가 superkey이거나 Y가 prime attribute인 경우.
    • (이행적 함수 종속 제거, transivity functional dependency 삭제)
    • X => Y, Y => Z로 식별할 수 있는 정보가 없는 것.
  • BCNF : 모든 functional dependency X => Y에 대해 X가 candidate key인 경우.
    • (모든 결정자 X가 후보키인 것)
  • 4NF : 다치 종속 제거
  • 5NF : 조인 종속 제거

 

 

Functional Dependency

 어떤 relation의 모든 tuple t$_1$, t$_2$과 어떤 field X, Y에 대해 if t$_1$[X] = t$_2$[X] then t$_1$[Y] = t$_2$[Y]인 X, Y의 관계를 functional dependency라고 한다. 말로 풀어쓰면 relation의 field X로 Y를 식별할 수 있는 관계. 더 풀어 쓰면 X를 알면 Y를 알 수 있는 관계를 말한다.

이를 사용해 redundancy를 formal한 방식으로 알아낼 수 있는데, functional dependency X => Y가 있는 경우, X가 중복되면 Y도 중복됨을 알 수 있기 때문이다.

 한편, key는 모든 attribute를 functionally determine한다.

 

 

 

Anomaly

 anomaly는 redundancy 때문에 발생하며, 다음 3가지가 있다.

  • insertion anomaly : insert 시 없는 정보가 있어 삽입하지 못하는 경우. 또는 null 정보를 넣어야 한다.
  • deletion anomaly : 삭제 시 원하지 않는 정보가 삭제되는 경우
  • update anomaly : 중복된 여러 값들 중 하나만 수정되는 경우

 

 

 

Prepared Statement

 일반적인 SQL의 경우 parse 과정을 거치는데, prepared statement는 해당 SQL의 문법을 검사한 후 DB에 caching한다. 때문에 성능이 향상되고, SQL이 이미 caching된 상태이므로 parameter에 들어가는 값을 SQL로 인식하지 않고 parameter로 인식하므로  injection을 막을 수 있다.

 

 

 

CAP Theorem / PACELC Theorem

 Consistency, Availability, Partition Tolerance 3가지를 만족할 수 없다는 정리. 증명되었다.

  • consistency : 모든 request가 최신 데이터를 받는다.
  • availability : 모든 request는 정상적인 response를 받는다.
  • partition tolerance : 네트워크 오류 상황이어도 정상 작동한다.

 

 PACELC theorem은 normal state, abnormal state를 구분해 설명하는 방식이다.

  • partition이 존재하는 경우 (abnormal)
    • availability과 consistency는 tradeoff이다.
  • partition이 존재하지 않는 경우 (normal)
    • latency와 consistency는 tradeoff이다.

 

 

 

Redis

  • append only file : query를 저장하고, crash 시점부터 다시 만들어 두는 방식
  • snapshot : 특정 지점을 디스크에 백업
  • key-value로 이루어졌다.

 

 

 

2 Phase Locking

 transaction에 lock을 걸어서 serialization을 보장하는 concurreny 처리 방법. lcok은 resource에 대한 mutual exclusion을 위해 사용한다. lock 종류는 다음과 같다.

  • Shared Lock : 해당 resource에 대해 read 연산만 가능한 lock. 따라서 한 resource에 여러 개의 shared lock이 걸릴 수 있다.
  • Exclusive Lock : 해당 resource에 대해 read 연산과 write 연산 둘 다 가능한 lock. 따라서 한 resource에 하나의 exclusive lock만 걸릴 수 있다.

 

2 phase locking

 lock만으로는 deadlock이 발생할 수도 있기 때문에 strict 2 phase lock을 사용한다. locking phase와 unlocking phase 2단계로 나뉜다. 

  • locking phase : lock 연산만 수행할 수 있는 단계
  • unlocking phase : unlock 연산만 수행할 수 있는 단계. unlock은 transaction이 완전히 끝난 후에 실행한다.

 

 

 

Isolation Level

 non consistent data를 허용하는 수준.

  • Level 1 (Read Uncommited) : 아직 commit되지 않은 record나, transaction이 처리중인 record을 다른 transaction에서 접근할 수 있음. 이 경우 consistent하지 않다.
    • commit되지 않은 data를 보는 dirty read가 발생할 수 있다.
  • Level 2 (Read Commited) : commit된 transaction의 결과만 조회할 수 있다.
    • 하나의 transaction에 같은 query가 2개 이상 있을 때, 다른 결과가 나오는 non repeatable read가 발생할 수 있다. query 실행 시점 사이에 다른 transaction이 2개 실행되면 이런 현상이 생긴다. (insert - update - insert의 경우)
  • Level 3 (Repeatable Read) : 하나의 transaction에서 조회한 record가 같음을 보장한다. 하나의 transaction이 읽은 record를 다른 transaction이 변경하지 못하게 한다.
    • MVCC를 사용해 transaction에서 사용하는 record들의 version을 관리한다. 때문에 select transaction 실행 중 다른 transaction이 update를 하더라도 MVCC가 저장하고 있는 record를 넘겨주며, 이 때문에 읽는 값은 같다.
    • 그러나 MVCC는 update는 versioning을 하지 않기 때문에, 같은 transaction을 2번 실행했을 때 결과가 다른 phantom read가 발생할 수 있다. (select - insert - select의 경우)
  • Level 4 (Serializable) : 한 transaction이 사용하는 record를 다른 transaction에서 접근할 수 없다.

 

 

 

ARIES Recovery

 ARIES recovery의 가정 : strict 2 phase locking, WAL (write ahead logging)

  • DB에 접근하기 전 lock, transaction 끝난 후 unlock하는 것을 말한다.

 

 

Force / Steal

  • Force: transaction commit 후 바로 disk에 쓰는 방식
  • No Force : transaction commit 후 바로 disk에 쓰지 않는 방식
  • Steal: transaction 완료 여부에 상관없이 data를 disk에 기록하는 방식
  • No Steal: transaction uncommit 상태에서 data를 disk에 기록하지 않는 방식

 

ARIES recovery의 경우 Force + No Steal 방식으로, 어렵지만 빠르다.

 

 

Commit, Rollback

 commit은 모든 작업이 정상적으로 수행되었다는 명령이며, 실 DB에 반영하게 된다.

 rollback은 crash가 난 경우, 해당 transaction의 변경을 취소하는 과정이다. 직전 commit까지만 복구한다.

 이를 통해 consistency를 보장할 수 있다.

 

 

WAL

  • disk에 update하기 전에 log를 작성한다. undo를 위해 사용하며, disk에 update한 후 crash가 나면 undo할 수 없기 때문이다.
  • transaciton이 commit되기 전에 모든 작업 내용을 log에 기록해야 한다. redo를 위해 사용하며, 해당 transaction이  commit되었음을 보장한다.

 

 

ARIES recovery algorithm

 strict 2 phase lock을 사용하고 있기 때문에 data에 대한 접근은 걱정하지 않아도 된다.

  • analysis : REDO 시작위치 결정 (checkpoint : transaction이 모두 disk에 쓰인 시점), crash 위치 결정
  • redo : analysis에서 결정한 위치부터 crash 직전까지 redo 수행.
  • undo : log를 역순으로 읽으면서 uncommit transaction까지 undo. (최근 commit까지)

 

 

Transaction State

 크게 5가지 종류가 있다.

  • active : transaction이 실행 중인 상태
  • failed : transaction에 오류가 발생해 중단된 상태
  • partially commited : 사용자의 commit 요청이 왔을 때 도착하는 상태. 아직 반영된 상태가 아니다. commit 되면 commited로 가고, 그렇지 않으면 failed로 간다.
  • commited : transaction이 성공적으로 종료된 상태
  • aborted : rollback을 수행하고 있는 상태

 

 

 

 

잘못된 내용이나 오탈자에 대한 지적, 질문 등은 언제나 환영합니다.

 

 

 

 

 

저작자표시