DB트랜젝션 / ACID, Schema & Query Design
데이터베이스 트랜젝션과 ACID
- 트랜젝션: 여러 개의 작업을 하나로 묶은 실행 유닛, 하나의 특정 작업으로 시작, 묶여 있는 모든 작업을 다 완료해야 정상적으로 종료됨(중간에 하나라도 실패하면 모든 작업을 실패로 돌림, 롤백과 비슷한 개념)
- 데이터베이스 트랜젝션은 ACID라는 특성을 가짐
- Atomicity(원자성): 하나의 트랜젝션에 속해있는 모든 작업이 전부 성공하거나 전부 실패해서 결과를 예측할 수 있어야 함, 모든 작업이 성공하거나, 모두 실패하게 만들어 기존 데이터를 보호해야 함.
- SQL에서도 마찬가지, 특정 쿼리를 실행했을 때 부분적으로 실패하면, 전체를 실패하도록 구현됨, 때때로 충돌 요인에 대해서 선택지를 제공함.
- Consistency(일관성): 데이터베이스의 상태가 일관되어야 한다는 성질, 하나의 트랜젝션 이전과 이후에 데이터베이스의 상태는 이전과 같이 유효해야 함, 즉 이후의 데이터베이스도 제약이나 규칙을 만족해야 함
- 이름 없는 새로운 고객을 추가, 또는 기존 고객의 이름을 삭제 => 이름이 있어야 한다는 규칙을 위반
- Isolation(격리성, 고립성): 모든 트랜젝션은 다른 트랜젝션으로부터 독립되어야 한다는 의미
- 동시에 여러 개의 트랜젝션이 수행될 때, 각 트랜젝션은 격리되어 실행되므로 동일한 결과를 나타냄
- 1번 계좌에서 2번과 3번에 각각 6천원을 동시에 송금할 때에
- 2번에 송금하고 나서 3번에 송금하는 것과 동일한 결과가 나와야 한다는 것
- 만약 동시에 송금하기에 잔액이 부족하다고 하여 마이너스가 되는 것이 아닌
- 2번에 송금하고 나서 3번에 송금하는 것과 결과가 같아야 함
- Durability(지속성): 하나의 트랜젝션이 성공적으로 수행되면 로그가 남아야 한다, 런타임 오류나 시스템 오류가 발생하더라도, 해당 기록은 영구적이여야 한다는 의미.
- 계좌이체를 성공적으로 실행한 뒤에, 해당 은행 데이터베이스에 오류가 발생해 종료되더라도 계좌이체 내역은 기록으로 남아야한다, 마찬가지로 계좌이체를 로그로 기록하기 전에 시스템 오류 등에 의해 종료가 된다면, 해당 이체는 실패로 돌아가고, 각 계좌들은 계좌이체 이전 상태들로 돌아가게 된다.
Schema & Query Design
- Schema(스키마): 데이터베이스에서 데이터가 구성되는 방식과 서로 다른 entities(엔티티) 간의 관계에 대한 설명, 즉 "데이터베이스의 청사진"과 같다
- Entities(엔티티): 고유한 정보의 단위, 데이터베이스에서는 테이블로 표시할 수 있다
- Field(필드): 엔티티의 특성을 설명, 행렬에서의 열(column)에 해당
- 교수라는 테이블에는 이름, 학과, 담당 수업 등의 특성이 있을 것
- Record(레코드): 테이블에 저장된 항목, 행렬에서의 행(row)에 해당
- 한국대 교수 중 이름: 윤교수, 학부: 경제학부, 담당 수업: 경제학개론,미시경제학,거시경제학...
- 일대다의 관계(1:N, one-to-many): 담당 수업의 경우, 여러 강의를 하므로 여러개의 레코드를 가짐
- 교수의 수업 목록과 수업 테이블 간의 연결이 필요함, 테이블의 고유 ID(기본 키, Primary key)를 연결해주고, 참조하는 곳에서는 이를 foreign key(외래 키)라고 한다
- 문제는 최대 수업을 늘리게 될 때에, 수업 ID를 담을 공간이 부족해 질 수 있음
- 검색에서도 문제, 내부 상수 접근으로 상수 시간(constant-time)에 대한 검색 손실이 발생함
- 다대다의 관계(N:N, many-to-many): 학생은 여러 수업을 가지고, 수업은 여러 수강생을 가진다
- 조인 테이블(Join table): 수업의 ID와 학생의 ID를 가지고 만드는 새로운 테이블을 작성
