데이터베이스 기말고사 내용정리

시험 전 중간고사 내용을 정리하여 학습 및 암기를 하기 위해 끄적여 봅니다.

검색 용도와는 맞지 않는 페이지일 수 있습니다.

---

4. 뷰, 인덱스

뷰 : 하나 이상의 테이블을 합하여 만든 가상의 테이블

편리성 및 재사용성 : 미리 정의된 뷰를 일반 테이블처럼 사용할 수 있기 때문에 편리하다.

-> 복잡한 질의를 간단하게 작성할 수 있다.

보안성 : 각 사용자별로 보안이 필요한 데이터를 제외하여 선별하여 보여줄 수 있다.

-> 개인정보, 급여, 건강 같은 민감한 정보를 제외한 테이블을 만들어 사용.

독립성 : 논리 DB의 원본 테이블의 구조가 변해도 응용 프로그램에 영향을 주지 않도록 하는 논리적 독립성을 제공한다.

 

- 뷰의 특징

- 원본 데이터 값에 따라 같이 변한다.

- 독립적인 인덱스 생성이 어렵다.

- 뷰는 테이블처럼 사용할 수 있지만 SELECT 문을 제외한 일부 물리적인 테이블의 갱신작업을 수행하는 데 제약이 있다. ==> DML 작업(INSERT, UPDATE, DELETE 등)은 경우에 따라 수행되지 않는다. 기본키를 포함하지 않는 수정 요청이나 베이스 테이블에서 두 개 이상 속성을 포함하는 수정 요청은 제약을 위반할 가능성이 있기 때문에 금지된다.

 

(1) 뷰 생성

CREATE VIEW vw_Book

AS SELECT *

FROM Book

WHERE bookname LIKE ‘%축구%’;

 

(2) 뷰 수정

CREATE OR REPLACE VIEW AS SELECT ...

 

(3) 뷰 삭제

DROP VIEW vw_Book;

 

- DB의 물리적 저장

데이터가 실제로 저장되는 곳은 보조기억장치다(하드디스크, SSD, USB 메모리 등).

이중 하드디스크가 제일 많이 쓰이는데, 이는 원형 플레이트로 구성되어 있고, 이 플레이트는 논리적으로 트랙으로 나뉘며 트랙은 다시 몇 개의 섹터로 나뉜다. 원형 플레이트는 초당 빠른 속도로 회전하고, 회전하는 플레이트를 하드디스크의 액세스 암과 헤더가 접근하여 원하는 섹터에서 데이터를 가져온다. 하드디스크에 저장된 데이터를 읽어 오는 데 걸리는 시간은 모터에 의해 분당 회전하는 속도(RPM), 데이터를 읽을 때 액세스 암이 이동하는 시간(latency time), 주기억장치로 읽어오는 시간(transfer time)에 영향을 받는다.

 

액세스 시간 = 탐색시간(seek time, 액세스 헤드를 트랙에 이동시키는 시간) + 회전지연시간(rotational latency time, 섹터가 액세스 헤드에 접근하는 시간), 데이터 전송시간(data transfer time, 데이터를 주기억장치로 읽어오는 시간)을 말한다.

즉, 액세스 시간은 데이터를 요청했을 때 주기억 장치에 로드되는 시간을 말한다.

 

- 인덱스와 B-tree

B-tree : 데이터 검색 시간을 단축하기 위한 자료구조. 루트 노드, 내부 노드, 리프 노드로 구성되며, 리프 노드가 모두 같은 레벨에 존재하는 균형 트리이다. 각 노드는 키 값과 포인터를 가진다. 키 값은 오름차순으로 저장되어 있으며, 키 값 좌우에 있는 포인터는 각각 키 값보다 작은 값과 큰 값을 가진 다음 노드를 가리킨다. B-tree는 키 값이 새로 추가되거나 삭제될 경우 동적으로 노드를 분할하거나 통합하여 항상 균형 상태를 유지한다.

(B+tree의 차이점 : B-tree는 가지, 리프 노드가 모두 데이터이고, 중복 허용X, B-tree의 단점은 순차처리가 시간이 오래 걸림(포인터가 메모리를 왔다갔다하므로). B+tree는 가지는 인덱스(데이터X), 리프는 데이터임. 이는 순차 처리가 가능하다는 장점이 있다.

 

인덱스 : 자료를 쉽고 빠르게 찾을 수 있도록 만든 데이터 구조.

인덱스는 테이블에서 한 개 이상의 속성을 이용하여 생성한다.

빠른 검색과 함께 효율적인 레코드 접근이 가능하다.

순서대로 정렬된 속성과 데이터의 위치만 보유하므로 테이블보다 작은 공간을 차지한다.

저장된 값들은 테이블의 부분집합이 된다.

일반적으로 B-tree 형태의 구조를 가진다.

데이터의 수정, 삭제 등의 변경이 발생하면 인덱스의 재구성이 필요하다.

 

MySQL 인덱스

모두 B-tree 인덱스르 기본으로 한다.

클러스터 인덱스 : 연속된 키 값의 레코드를 묶어서 같은 블록에 저장하는 방법으로, 테이블 당 하나만 생성할 수 있으며, 키 값에 의한 동등 및 범위(BETWEEN) 검색 모두에 유리하다. B-tree 인덱스의 리프 노드에서 페이지의 주소 값 대신 테이블의 열 자체가 저장되는 형태다.

테이블 생성 시 기본(PK)를 생성하면 자동으로 생성된다.

장점 : 특정 값을 찾기 쉽고, 범위 검색도 손쉽게 할 수 있다. 인덱스 페이지가 단순해져 인덱스 저장 시 차지하는 공간도 작다.

보조 인덱스 : 속성의 값으로 B-tree 인덱스를 구성하며 리프 노드의 각 행은 해당 페이지의 주소 값을 저장한다. 테이블당 여러 개를 만들 수 있다. 특정 키 값은 잘 찾을 수 있으나, 범위 검색은 저장된 Block 값들의 저장 순서가 일정치 않을 수 있어서 검색 효과를 보장할 수 없다.

 

 

 

인덱스 생성 시 고려사항

인덱스는 WHERE 절에 자주 사용되는 속성이어야 한다.

인덱스는 조인에 자주 사용되는 속성이어야 한다.

단일 테이블에 인덱스가 많으면 속도가 느려질 수 있다.(테이블 당 4~5개 권장)

속성이 가공되는 경우 사용하지 않는다.

속성의 선택도가 낮을 때 유리하다.(속성의 모든 값이 다른 경우)

 

* 인덱스 생성 : CREATE INDEX ix_Book ON Book (bookname);

* 인덱스 재구성 : ANALYZE TABLE 테이블이름;

* 인덱스 삭제 : DROP INDEX ix_Book ON Book;

 

 

데이터 모델링

 

(1) 요구사항 수집 및 분석 : 사용자들의 요구사항을 듣고 분석하여 DB 구축의 범위를 정하는 단계.

(2) 설계 : 분석된 요구사항을 기초로 주요 개념과 업무 프로세스 등을 식별(개념적 설계), 사용하는 DBMS의 종류에 맞게 변환(논리적 설계)한 후, DB 스키마를 도출(물리적 설계)한다.

(3) 구현 : 설계 단계에서 생성한 스키마를 실제 DBMS에 적용하여 테이블 및 관련 객체(뷰, 인덱스 등)을 만든다. 또한 관련 S/W에 설계한 DB를 적용하여 서비스를 제공할 수 있도록 프로그램을 완성한다.

(4) 운영 : 구현된 DB를 기반으로 S/W를 구축하여 서비스를 제공한다.

(5) 감시 및 개선 : DB 운영에 따른 시스템의 문제를 관찰하고 DB 자체의 문제점을 파악하여 개선한다. 이 단계에서는 DB가 지속적으로 운영될 수 있도록 변경 및 유지, 보수한다.

 

데이터 모델링 과정

 

① 요구사항 수집 및 분석 -> 현실 세계의 대상 및 사용자의 요구사항을 정리 및 분석

(사용자 식별, DB 용도 식별, 사용자 요구사항 수집 및 명세)

② 개념적 모델링 -> 중요 개념을 구분

(핵심 Entity 추출, ERD 작성)

③ 논리적 모델링 : 각 개념을 구체화

(ERD-RDB 모델 사상, 상세 속성 정의, 정규화 등)

④ 물리적 모델링 -> DB 생성 계획에 따라 개체, 인덱스 등을 생성

(DB 개체 정의, 테이블 및 인덱스 등 설계)

 

데이터 모델링의 각 과정

① 요구사항 수집 및 분석 : 현실 세계를 파악하고 사용자의 요구사항을 수집 및 분석하는 단계. 담당자는 구축할 DB와 관련된 전문적 지식을 갖추고 있어야 하며, 관련 자료를 수집할 때도 가장 기초적인 내용에 중점을 두고 진행해야 한다.

<요구사항 수집 방법>

1, 실제 문서 수집, 분석

2. 담당자 인터뷰 or 설문조사를 통해 요구사항 직접 수렴

3. 비슷한 업무 처리하는 기존의 DB를 분석

4. 각 업무와 연관된 모든 부분을 살핌.

 

② 개념적 모델링 : 요구사항을 수집하고 분석한 결과를 토대로 업무의 핵심적 개념을 구분하고 전체적인 뼈대를 만드는 과정. 즉, 개체를 추출하고 각 개체들 간의 관계를 정의하여 ER 다이어그램(ERD, Entity Relationship Diagram)을 만드는 과정까지를 말한다.

설계자는 사용자의 요구사항을 분석해 가장 핵심적인 개체와 개별 개체를 식별할 수 있는 핵심 속성(PK), 그리고 각 개체 간 관계를 정의해 DB화 할 수 있는 일반적인 개념으로 표현함.

 

③ 논리적 모델링 : 개념적 모델링에서 만든 ER 다이어그램을 사용하려는 DBMS에 맞게 사상(매핑, mapping)하여 실제 DB로 구현하기 힘든 모델을 만드는 과정

(1) 개념적 모델링에서 추출하지 않았던 상세 속성들을 모두 추출한다.

(2) 정규화를 수행한다.

(3) 데이터의 표준화를 수행한다.

 

④ 물리적 모델링 : 작성된 논리적 모델을 실제 컴퓨터의 저장 장치에 저장하기 위한 물리적 구조를 정의하고 구현하는 과정. DBMS의 특성에 맞게 저장 구조를 정의하여야 DB가 최적의 성능을 낼 수 있음

트랜잭션, 저장 공간 설계 측면에서 고려할 사항-

(1) 응답 시간(트랜잭션 시작->종료까지 시간)을 최소화해야 한다.

(2) 얼마나 많은 트랜잭션을 동시에 발생시킬 수 있는지 컴토해야 한다.

(3) 데이터가 저장될 공간을 효율적으로 배치해야 한다.

 

 

ER 모델

ER (Entity Relationship) 모델

세상의 사물을 개체(entity)와 개체 간 관계(relationship)로 표현함.

 

개체

독립적인 의미를 지니고 있는 유무형의 사람 또는 사물

개체의 특성을 나타내는 속성에 의해 식별됨. 개체끼리 서로 관계를 가짐.

 

특징 : 유일한 식별자에 의해 식별 가능, 꾸준한 관리를 필요로 하는 정보, 두 개 이상 영속적으로 존재, 업무 프로세스에 이용, 반드시 자신의 특징을 나타내는 속성을 포함, 다른 개체와 최소 한 개 이상의 관계를 맺고 있음.

 

개체 : 직사각형 강한 개체 : 다른 개체 도움 없이 독자적으로 존재할 수 있는 개체 약한 개체 : 독자적으로는 존재할 수 없고 반드시 상위 개체 타입을 가짐. 속성 : 개체가 가진 성질(타원) 속성이 개체를 유일하게 식별할 수 있는 키일 경우 속성 이름에 밑줄을 그음.

관계 : 개체 사이 연관성을 나타내는 개념. 관계 타입 : 개체 타입과 개체 타입 간 연결 가능한 관계를 정의한 것이며, 관계 집합은 관계로 연결된 집합을 의미한다. 관계 대응 수(cardinality) : 두 개체 타입의 관계에 실제로 참여하는 개별 개체수

 

관계대응수 1:1, 1:N, 1:M에 최솟값을 표기해보기

(최솟값, 최댓값)은 관계 대응 수와 달리 해당 개체 쪽에 표기한다.

 

ISA 관계

상위 개체 타입의 특성에 따라 하위 개체 타입이 결정되는 형태

 

예 : 학생을 신분에 따라 휴학생/재학생/졸업생으로 구분, 이를 ISA 관계로 표현한 것.

슈퍼클래스에는 공통 속성을 가지고, 서브클래스의 각 개체 타입에는 자신만이 가지는 고유 속성을 부여한다.

재학생의 경우, 슈퍼클래스 속성인 (학생번호, 이름, 성별)을 상속받고, (등록학기, 지도교수) 속성을 포함하여 모두 다섯 개의 속성을 가지게 된다.

 

참여 제약 조건

[참여 제약 조건] - 개체 집합 내 모든 개체가 관계에 참여하는지 유무에 따라 전체 참여와 부분 참여로 구분 가능 전체 참여는 개체 집합의 모든 개체가, 부분 참여는 일부만 참여함. 전체 참여를 (최솟값, 최댓값)으로 표현할 경우 최솟값이 1 이상으로 모두 참여한다는 뜻이고, 부분 참여는 최솟값이 0 이상임. [역할] - 주석 역할, 없어도 된다. 개체 타입 간 관계를 표현할 때 각 개체들은 고유한 역할을 담당한다.

 

순환적 관계

 

하나의 개체 타입이 동일한 개체 타입(자기 자신)과 순환적으로 관계를 가짐 예 : 학생들 간 멘토링 관계를 맺어 멘토와 멘티 모두 학생 개체인 경우, 자기보다 직급이 낮은 사원에게는 업무 지시를 내리고, 높은 사원에게는 업무 지시를 받음.

 

약한 개체 타입

상위 개체 타입이 결정되지 않으면 개별 개체를 식별할 수 없는 종속된 개체 타입. 독립적인 키로는 존재할 수 없지만 상위 개체 타입의 키와 결합하여 약한 개체 타입의 개별 개체를 고유하게 식별하는 속성을 식별자 혹은 부분키라고 한다.

 

 

IE 표기법

 

ER 모델과 관계 데이터 모델의 사상 알고리즘

(in 논리적 모델링 사상(mapping 시)

1. 강한 개체 타입 : 정규 개체 타입 E의 경우 대응 하는 릴레이션 R을 생성한다.   2. 약한 개체 타입 : 이로 생성된 릴레이션은 자신 의 키와 함께 강한 개체 타입의 키를 외래키로 사상 하여 자신의 기본키를 구성한다.

※ 관계 타입 사상 3. 이진 1:1 관계 타입 : 왼쪽 그림의 방법 모두 사용 가능, 개체가 가진 정보 유형에 따라 판단(외래키(FK)에 NULL값이 덜 발생하는 방법으로!)   4. 이진 1:N 관계 타입 : N의 위치에 따라 방법1,2의 유형으로 사상된다. -> N의 위치인 릴레이션에 다른 릴레이션의 기본키를 외래키로 사용.   5. 이진 M:N 관계 타입 : 방법 4로 사상 (이때, 왼쪽 그림의 R은 교차 릴레이션이다.)

6 : N진 관계 타입 ER 모델 차수가 3 이상인 다진 관계 타입의 경우, 방법 4로 사상된다. 생성되는 릴레이션의 키는 각 개체 타입의 기본키를 모은 복합키를 사용한다.

7. 다중값 속성 속성의 개수를 알 수 없는 경우 방법 1, 속성의 개수가 제한적으로 정해지는 경우라면 방법 2를 사용한다.

 

7. 정규화

이상 현상 : 삭제, 삽입, 수정 등 테이블에 저장된 내용을 조작할 때 문제가 발생하는 현상

삭제이상 : 투플을 삭제하므로 유지돼야 하는 정보도 연쇄 삭제되는 현상

삽입이상 : NULL을 가질 수 없는 속성에 대해 NULL 입력 시 투플 삽입이 거부되는 이상현상으로 원하지 않는 정보로 입력해야 함.

-> NULL값이 있는 경우 투플은 다섯 개지만, 수강 학생은 4명인 경우가 발생!

수정이상 : 투플 수정 시 중복된 데이터의 일부만 수정되어 데이터 불일치 문제가 일어나는 현상 -> 불일치 문제 발생! (하나는 수정되고, 다른 건 수정이 안되서 데이터 불일치 발생!)

 

이상현상이 발생하는 이유는 “함수의 종속성” 때문이다. 이상 현상을 없애려면 “함수의 종속성”을 제거해야 한다.

=> 해결방법 : 테이블을 분리하면 된다. => “정규화”

 

함수 종속성

각 속성 사이에 의존성이 존재할 때, 어떤 속성 A의 값을 알면 다른 속성 B의 값이 유일하게 정해지는 관계를 ‘속성 B는 속성 A에 종속한다.’ 혹은 ‘속성 A는 속성 B를 결정한다’고 한다.

‘A->B’로 표기하며 A를 B의 결정자(키)라고 한다.

 

 

함수 종속성 규칙

- 부분집합(Subset) 규칙 : if Y

X, then X -> Y

= Y가 X의 부분집합이라면 X는 Y를 결정할 수 있다.

- 증가 규칙 : if X -> Y, then XZ -> YZ

이행 규칙 : if X -> Y and Y -> Z, then X -> Z

위의 세 가지 규칙으로부터 부가적으로 다음 규칙을 얻을 수 있다.

결합 규칙 : if X -> Y and X -> Z, then X -> YZ

분해 규칙 : if X -> YZ, then X -> Y and X -> Z

유사이행 규칙 : if X -> Y and WY -> Z, then WX -> Z

 

함수 종속성과 기본키

릴레이션의 함수 종속성을 파악하기 위해서는 우선 기본키를 찾아야 한다.

릴레이션이 R(K, A, B, C)로 구성되어 있고 K가 기본키라면, K->R이 성립한다. 즉, 기본키는 릴레이션의 모든 속성에 대해 결정자이다.

 

이상현상과 결정자

이상현상은 한 개의 릴레이션에 두 개 이상의 정보가 포함되어 있을 때 나타난다.

즉, 기본키가 아니면서 결정자인 속성(비후보키 결정자 속성)이 있을 때 발생한다.

이상현상을 없애려면 릴레이션을 분해한다.

 

함수 종속성이 성립하는지 확인하기 위해서는

모든 투플의 (A,B) 값이 모두 다르거나, A값에 대하여 B값이 한 개씩만 대응하면 성립!!

 

정규화

-> 이상현상이 발생하는 릴레이션을 분해하여 이상현상을 없애는 과정

이상현상이 있는 릴레이션은 이상현상을 일으키는 함수 종속성의 유형에 따라 등급 구분 가능

릴레이션은 정규형 개념으로 구분하며, 정규형이 높을수록 이상현상은 줄어든다.

 

제 1정규형 : 릴레이션 R의 모든 속성값이 원자값을 가지면 제 1정규형이라고 함.

(비정규 릴레이션이 1정규화를 만들어주기 위해서는 속성의 원자값(도메인 원자값)을 가져야 한다.)

 

제 2정규형 : 릴레이션 R이 제 1정규형이고 기본키가 아닌 속성이 기본키에 완전 함수 종속일 때를 말한다. 즉, 릴레이션의 기본키가 복합키일 때, 복합키의 일부분이 다른 속성의 결정자인지 여부를 판단하는 것이다. (완전 함수 종속 : A와 B가 릴레이션 R의 속성이고 A -> B 종속성이 성립할 때, B가 A의 속성 전체에 함수 종속하고 부분 집합 속성에 함수 종속하지 않을 경우 완전 함수 종속!)

 

불완전 함수 종속 or 부분 함수 종속

 : A -> B 종속성에서 A의 속성 일부를 제거해도 종속성이 여전히 성립하는 경우.

이상현상의 원인

기본키가 아닌 속성이 기본키에 완전 함수 종속이 아닌 불완전 함수 종속되어 있으면 이상현상이 발생한다!

정규화가 필요한 이유

논리적 설계에서 릴레이션 설계를 한 이후에는, 이상현상을 제거해줘야 한다. 이상현상이 발생하는 이유는 함수 종속성 때문이다. 따라서, 이상현상을 제거하고 함수 종속을 제거하려면 릴레이션 분할 작업이 필요하다. 이를 위해 정규화 작업이 필요하다.

 

 

8장. 트랜잭션

● 트랜잭션 : DBMS에서 데이터를 다루는 논리적인 작업의 단위

● DB에서 트랜잭션을 정의하는 이유

DB에서 데이터를 다룰 때 장애가 일어날 시 데이터를 복구하는 작업의 단위가 됨.

DB에 여러 작업이 동시에 같은 데이터를 다룰 때가 이 작업을 서로 분리하는 단위가 됨.

● 트랜잭션은 전체가 수행되거나 또는 전혀 수행되지 않아야 한다.

구분	트랜잭션	프로그램
프로그램 구조	BEGIN TRANSACTION ... COMMIT TRANSACTION	main(( {...}
다루는 데이터	DB에 저장된 데이터	파일에 저장된 데이터
번역기	DBMS	컴파일러
성질	원자성, 일관성, 고립성, 지속성	-

 

 

트랜잭션의 네 가지 성질 (ACID 성질)

원자성 : 트랜잭션이 원자처럼 더 이상 쪼개지지 않는 하나의 프로그램 단위로 동작해야 함, 즉, 트랜잭션에 포함된 작업은 전부 수행되거나 아니면 전부 수행되지 않아야 한다.

일관성 : 트랜잭션을 수행하기 전이나 수행한 후나 DB는 항상 일관된 상태를 유지해야 함. 일관성은 테이블이 생성 시 CREATE 문과 ALTER 문의 무결성 제약조건을 통해 명시됨.

 

고립성 : 수행 중인 트랜잭션에 다른 트랜잭션이 끼어들어 변경 중인 데이터 값을 훼손하는 일이 없어야 한다.

DB는 공유가 목적이므로 여러 트랜잭션이 동시에 수행된다. 이들은 상호 존재를 모르고 독립적으로 수행되는데, 이를 고립성이라고 한다. 이를 유지하려면 트랜잭션이 변경 중인 임시 데이터를 다른 트랜잭션이 읽고 쓸 때 제어가 필요하다.

=> 동시성 제어

 

지속성 : 수행을 성공적으로 완료한 트랜잭션은 변경한 데이터를 영구히 저장해야 함. 저장한 DB는 저장 직후 혹은 언제나 발생할 수 있는 정전,장애,오류에 영향을 받지 않아야 함.

트랜잭션이 정상적으로 완료(commit) 혹은 부분완료(partial commit)한 데이터는 DBMS가 책임지고 DB에 기록하는 성질.

 

 

---

          수행 중                     버퍼 내용 기록

begin ---------> 부분 완료 -----------------------> 완료 

          |--------> 실패 ------------------------------> 취소

                                            작업 취소

부분완료 : 트랜잭션  수행은 완료됐지만 변경 내용이 DB에 기록됐는지 확실하지 않은 상태. 이 상태는 DBMS가 최종적으로 변경 내용을 DB에 기록해야 완료 상태가 된다. 만약 DBMS에 기록하지 못하면 실패 상태가 된다.

 

실패 : 트랜잭션 중간에 중단 or 부분완료에서 변경 내용을 DB에 저장 못 했을 때. DBMS는 트랜잭션이 수행한 작업을 모두 원상복구시킨다.

 

트랜잭션과 DBMS

- DBMS는 원자성을 유지하기 위해 회복(복구) 관리자 프로그램을 작동시킨다. - DBMS는 일관성을 유지하기 위해 무결성 제약조건을 활용한다. - DBMS는 고립성 유지를 위해 일관성을 유지하는 것처럼 동시성 제어 알고리즘을 작동시킨다. - DBMS는 지속성 유지를 위해 회복 관리자 프로그램을 이용한다.

 

동시성 제어 : 트랜잭션이 동시에 수행될 때, 일관성을 해치지 않도록 트랜잭션의 데이터 접근을 제어하는 DBMS의 기능

 

갱신손실 문제

두 개의 트랜잭션이 한 개의 데이터를 동시에 갱신할 때 발생하며, DB에서 절대 발생하면 안 되는 현상 -> 해결방법 : 락 락 : 데이터를 수정중이라는 사실을 알리는 방법의 잠금 장치. 락은 트랜잭션이 다루는 데이터를 다른 트랜잭션이 접근하지 못하도록 막아 대기 상태로 만든다. 공유락(LS, shared lock) : 트랜잭션이 읽기를 할 때 사용하는 락 배타락(LX, exclusive lock) : 읽고 쓰기를 할 때 사용하는 락

 

공유락과 배타락의 규칙

데이터에 락이 걸려있지 않으면 트랜잭션은 데이터에 락을 걸 수 있다.

트랜잭션이 데이터 X를 읽기만 하면 LS(X)를 요청하고, 읽거나 쓸 경우 LX(X)를 요청함.

다른 트랜잭션이 데이터에 LS(X)을 걸어뒀다면, LS(X)의 요청은 허용하고 LX(X)는 허용X

다른 트랜잭션이 데이터에 LX(X)를 걸어뒀다면, LS(X)와 LX(X) 모두 허용X

트랜잭션이 락을 허용받지 못하면 대기 상태가 된다.

 

2단계 - 락킹

락을 걸고 해제하는 시점에 제한을 두지 않으면 두 개의 트랜잭션이 동시에 실행될 때 데이터 일관성이 깨질 수 있어 이를 방지하는 방법.

확장단계 : 트랜잭션이 필요한 락을 획득하는 단계로, 이 단계에서는 이미 획득한 락을 해제하지 않음.

수축단계 : 트랜잭션이 락을 해제하는 단계로, 이 단계에서는 새로운 락을 획득하지 않음.

단점 : Deadlock 발생할 수 있다!

 

데드락(교착상태, 사이클이 돌 때)

두 개 이상 트랜잭션이 각각 자신의 데이터에 대해 락을 획득하고 상대방 데이터에 대해 락을 요청하면 무한 대기 상태에 빠질 수 있는 현상.

 

해결방법 : 일반적으로 데드락 발생 시 DBMS는 T1 혹은 T2 작업 중 하나를 강제로 중지시킨다. 그 결과 나머지 트랜잭션은 정상적으로 실행된다. 이때 중지시키는 트랜잭션에서 변경한 데이터는 원래 상태로 되돌려놓는다.

 

Dirty Read (오손 읽기 )

읽기 작업을 하는 트랜잭션 1이 쓰기 작업을 하는 트랜잭션 2가 작업한 중간 데이터를 읽기 때문에 생기는 문제.

작업 중인 트랜잭션 2가 어떤 이유에서 작업을 철회(ROLLBACK)할 경우 트랜잭션 1은 무효가 된 데이터를 읽게 되고 잘못된 결과를 도출하는 현상.

ROLLBACK 전후로 데이터 값이 달라졌음.

 

non-repeatable read( 반복 불가능 읽기 )

트랜잭션 1이 데이터를 읽고 트랜잭션 2가 데이터를 쓰고(갱신, UPDATE) 트랜잭션 1이 다시 한 번 데이터를 읽을 때 생기는 문제

트랜잭션 1이 읽기작업을 다시 한 번 반복할 경우 이전이 결과와 다른 결과가 나오는 현상

T2가 COMMIT을 했으므로 틀린 데이터는 아니지만,

T1 입장에서는 같은 SQL문이 다른 결과를 도출하도록 보이게 됨.

 

유령데이터 읽기(Phantom read)

T1이 데이터 읽고 T2가 데이터 쓰고 T1이 다시 한 번 데이터 읽을 때 생기는 문제

T1이 읽기 작업을 다시 한 번 반복할 경우, 이전에 없던 데이터가 나타나는 현상

T2가 COMMIT을 했으므로 틀린 데이터는 아니지만, T1 입장에서는 새로운 데이터가 반영되었으므로, 이는 같은 SQL 문이 다른 결과를 도출함.

반복불가능 읽기와 비슷하지만 없던 데이터가 삽입되었기 때문에 다르게 구분함.

 

갱신손실 정리 

T1이 읽는 트랜잭션, T2가 쓰는 트랜잭션이라면, T1에서

(1) Dirty Read -> ROLLBACK 현상 있을 때 발생!

(2) 반복 불가능 읽기 -> UPDATE 시 발생!

(3) 유령 읽기 -> INSERT 시 발생

 

 

트랜잭션 고립 수준 명령어

DBMS는 트랜잭션을 동시에 실행시키면서 락보다 좀 더 완화된 방법으로 문제를 해결하기 위해 제공하는 명령어

 

 

명령어 및 설명	요약
1. READ UNCOMMITTED 고립 수준 가장 낮은 명령어. 자신의 데이터에 아무런 공유락을 걸지 않는다. (단, 배타락은 갱신손실 문제 때문에 걸어야 함) 또한 다른 트랜잭션에 공유락과 배타락이 걸린 데이터를 대기하지 않고 읽는다. 심지어 다른 트랜잭션이 COMMIT하지 않은 데이터도 읽을 수 있다. 이 때문에 dirty read가 발생한다.  이 명령어는 SELECT 질의의 대상이 되는 테이블에 대해서 락을 설정하지 않은 것과 같다.
2. READ COMMITTED   dirty read를 피하기 위해 자신의 데이터를 읽는동안 공유락을 걸지만 트랜잭션이 끝나기 전에라도 해지 가능하다.  다른 트랜잭션 데이터는 락 호환성 규칙에 따라 진행한다.
3. REPEATABLE READ 자신의 데이터에 설정된 공유락과 배타락을 트랜잭션이 종료할 때까지 유지하여 다른 트랜잭션이 자신의 데이터를 갱신할 수 없도록 한다.  다른 트랜잭션 데이터는 락 호환성 규칙에 따라 진행한다.  다른 고립화 수준에 비해 데이터 동시성이 낮아 특별한 상황이 아니라면 사용X
4. SERIALIZABLE 고립 수준 가장 높은 명령어. 실행 중인 트랜잭션은 다른 트랜잭션으로부터 완벽 분리.  데이터 집합에 범위를 지어 잠금 설정이 가능하여 트랜잭션 완벽 분리 가능.  제한이 가장 심하고 데이터 동시성도 낮음.  SELECT 질의 대상이 되는 테이블에 미리 배타락을 설정한 것과 같은 효과.

 

회복

DB에 장애가 생겼을 때 DB를 일관성 있는 상태로 되돌리는 DBMS 기능

시스템 충돌 : H/W 혹은 S/W의 오류로 주기억장치가 손실되는 것.

-> 처리 중인 프로그램과 데이터의 일부 혹은 전부가 손실된다.

미디어 장애 : 헤드 충돌이나 읽기 장애로 보조기억장치가 손실되는 것.

-> 보조기억장치에 저장 중인 데이터의 일부 혹은 전부가 손실된다.

응용 S/W 오류 : DB에 접근하는 S/W의 논리적인 오류로 트랜잭션의 수행이 실패하는 것

자연재해 : 화재, 홍수, 지진, 정전 등에 의해 컴퓨터 시스템이 손상됨

부주의 혹은 태업 : 운영자나 사용자의 부주의로 데이터가 손실되거나 의도적 손상을 입는 것

회복 중점 : 시스템 충돌, 미디어 장애, 응용 S/W 오류 -> 두 가지 결과 도출

(1) 변경 중인 데이터를 갖고 있는 주기억장치가 손실

(2) DB가 저장된 하드디스크가 손실

- DBMS 회복 관리자는 트랜잭션의 ACID 성질 중 원자성과 지속성을 보장하여 장애로부터 DB를 보호한다. 이때 트랜잭션의 DB 기록을 추적하는 로그 파일을 사용한다. 로그 파일은 트랜잭션이 반영한 모든 데이터의 변경 사항을 DB에 기록하기 전에 미리 기록해두는 별도의 DB로, 안전한 하드디스크에 저장되며 전원과 관계없이 기록이 남아 있다.

- 로그 파일에 저장된 로그 구조

: <트랜잭션번호, 로그 타입, 데이터 항목 이름, 수정 전 값, 수정 후 값>

- 트랜잭션 연산 타입 : START, INSERT, UPDATE, DELETE, ABORT, COMMIT

 

* 데이터 변경 기록을 저장해 둔 로그 파일을 이용하면 시스템 장애도 복구할 수 있다.

-> DBMS는 트랜잭션이 종료/중단 여부를 판단하여 종료된 트랜잭션은 종료를 확정하기 위해 재실행(REDO)을 진행, 중단된 트랜잭션은 없던 일로 되돌리기 위해 취소(UNDO)를 진행한다.

 

트랜잭션 재실행

장애 발생 후 시스템에 다시 가동했을 때, 로그 파일에 트랜잭션의 시작과 종료가 모두 있는 경우. 이는 트랜잭션이 모두 완료됐지만, 변경 내용이 버퍼에서 DB에 기록되지 않았을 가능성이 있다. 따라서 로그를 보며 트랜잭션이 변경한 내용을 DB에 다시 기록하는 과정이 필요하다. 이 과정을 REDO라고 한다.

 

트랜잭션 취소(UNDO)

장애 발생 후 시스템에 다시 가동했을 때, 로그 파일에 트랜잭션 시작만 있고 종료는 없는 경우. 트랜잭션이 한 일을 모두 취소해야 한다. 완료를 못했지만 버퍼의 변경 내용이 DB에 기록되어 있을 가능성이 있기 때문에 로그를 보며 트랜잭션이 변경한 내용을 DB에 원상복구시켜야 한다. 이 과정을 UNDO라고 한다.

 

즉시 갱신 방법

‘갱신 데이터->로그’, ‘버퍼->DB’ 작업이 부분완료 전에 동시에 진행될 수 있으며, 부분완료가 되면 갱신 데이터는 로그에 기록이 끝난 상태

지연 갱신 방법

‘갱신 데이터->로그’가 끝난 후 부분완료를 하고 ‘버퍼->DB’작업이 진행되는 방법

 

* 체크포인트(=검사점) : DB와 트랜잭션 로그 파일을 몇십 분 단위로 동기화한 후 동기화한 시점을 로그 파일에 기록해 두는 방법 혹은 그 시점

체크포인트 시점에서 하는 작업

주기억장치의 로그 레코드를 모두 하드디스크의 로그 파일에 저장

버퍼에 있는 변경된 내용을 H/D의 DB에 저장

체크포인트를 로그 파일에 표시

 

체크포인트 이전에 [COMMIT] 기록이 있는 경우

아무 작업 필요X. 로그에 체크포인트가 나타나는 시점은 이미 변경 내용이 모두 DB에 기록된 후이기 때문

 

체크포인트 이후에 [COMMIT] 기록이 있는 경우

REDO(T) 진행. 체크포인트 이후 변경 내용이 DB에 반영되지 않았으므로 REDO 진행.

 

체크포인트 이후에 [COMMIT] 기록이 없는 경우

즉시 갱신 방법을 사용했다면 UNDO(T) 진행. 버퍼의 내용이 반영됐을 수도 있기 때문에 원상복구 시켜야 함. 반면 지연 갱신 방법을 사용했다면 아무 작업X. 지연 갱신 방법은 [COMMIT] 이전에 버퍼의 내용을 DB에 반영하지 않기 때문이다.