#06 트랜잭션(격리성, 원자성), MVCC, 모델링 기초

#01 트랜잭션

 - RDBMS의 간판 기능
 - 트랜잭션(ACID)을 보장한다는 것은
    - 커밋/롤백 보장 (학부 수준)
    - 일관성 보장
    - 격리성 보장
    - 내구성 보장
 
1. ACID
    - 원자성(Atomicity)
    - 일관성(Consistency)
    - 격리성(Isolation)
    - 내구성(Durability)
 
2. All or Nothing
    - 커밋(Commit) or 롤백(Rollback)
        - 여러 줄의 SQL 쿼리를 실행할 때 장애가 발생했을 경우, 쿼리를 전체 취소하거나 확정함
          (돈 거래와 같은 상황에서 장애가 발생하여 나의 계좌에선 돈이 빠졌는데 상대 계좌에는 돈이 들어가지 않은 상황이 발생할 수 있음. 이를 막기 위한 것이 All or Nothing 특성임)
 
3. MySQL에서의 트랜잭션
    - 스토리지 엔진에 따라 트랜잭션 지원 여부가 다름
        - MyISAM: 트랜잭션 지원X
        - InnoDB(기본): 트랜잭션 지원, 외래키 지원, MVCC 지원
        - Memory: 트랜잭션 안정성 지원X, 외래키 지원X
 

show engine\G을 입력하면
MySQL이 지원하는 스토리지 엔진 리스트와 해당 스토리지 엔진의 기능 지원 여부를 보여줍니다.
 

show create table employees\G를 입력하면
employees 테이블이 사용하는 엔진을 확인합니다. InnoDB를 사용하는 것을 확인할 수 있습니다.
 
 
4. 트랜잭션의 롤백과 커밋 구현 방법
    - Undo Log: 실행 취소 시 사용하는 로그, 트랜잭션이 진행중이면 데이터의 값이 생성, 수정, 삭제가 되면 Undo Log에 Commit 여부와 함께 기록함. 로그에 적힌 Commit 여부를 보고 Rollback 시작 시점을 파악하는 것.
 
 
5. MySQL의 InnoDB 트랜잭션 설정 실습
- MySQL의 InnoDB엔진은 기본설정이 트랜잭션 미지원 상태임
  - 트랜잭션이 지원되게 하기 위해서는 기본설정을 변경해야 함 (autocommit 설정 off)

autocommit의 값을 0으로 설정하여 설정을 off로 바꾸고 확인했습니다.
 
 
6. 커밋/롤백 실습 - 기본

1)    emp_no가 1000인 레코드를 삽입합니다.
2)    select문으로 해당 레코드를 조회합니다.
3)    rollback 해본 뒤 다시 해당 레코드를 조회합니다. -> 조회되지 않습니다.
4)    emp_no가 2000인 레코드를 삽입합니다.
5)    commit 후 rollback한 뒤 다시 해당 레코드를 조회합니다. -> 조회됩니다.
→ 이 실습을 통해 commit하지 않고 rollback하면 데이터가 확정되지 않아 사라지지만, commit 후 rollback하면 데이터가 확정된 후이기 때문에 사라지지 않고 조회된다는 것을 확인했습니다.
 
6-2. 커밋/롤백 실습 - savapoint 지정

1)    emp_no가 3000인 레코드를 삽입합니다.
2)    savepoint A를 지정합니다
3)    emp_no가 4000인 레코드를 삽입합니다.
4)    A로 롤백합니다.
5)    레코드를 조회해보면 emp_no가 3000인 레코드만 조회되는 것을 확인할 수 있습니다.
 
 
6-3. DDL 문의 트랜잭션

1)    employees와 동일한 스키마의 employees_test 테이블을 생성합니다.
2)    테이블 리스트를 확인합니다.
3)    rollback 합니다.
4)    테이블 리스트를 다시 확인합니다. -> employees_test 테이블이 그대로 남아있는 것을 확인할 수 있습니다.
→  DDL 문에는 rollback이 되지 않는다는 것을 확인할 수 있습니다.
 
 

#02 Transaction Isolation (격리성)

1. 격리수준: 멀티 스레드/트랜잭션이 동시에 동일한 테이블/레코드에 접근할 때 적용되는 규칙
1) Read Uncommitted: 커밋 여부와 상관없이 현재 값을 넘기는 격리 수준
    - commit 되지 않는 데이터 접근 가능
    - 가장 낮은 데이터 안정성 / 가장 높은 성능
    - Dirty Read 현상 발생가능 (커밋되지 않은 제일 최근 값을 읽어왔는데 롤백이 되었다면 -> 내가 읽은 값은 쓰레기 값이 됨)
 
2) Read Committed: 커밋된 값을 기준으로 넘김
    - commit 된 데이터만 접근 가능
    - 일반적으로 가장 많이 사용하는 격리수준
    - Non-Repeatable Read 현상 발생 (동일한 트랜잭션 안에서 동일한 쿼리의 결과가 다른 경우 발생)
 
3) Repeatable Read: 백업 당시의 값을 넘김 (실제값이 변경되었어도..)
    - 동일한 트랜잭션에서는 한 쿼리의 값은 항상 일정함
    - Phantom Read 현상 발생 (데이터 변경은 불가능하지만 추가/삭제는 가능함)
    - 백업이나 복제(Replication)와 같이 상대적으로 긴 시간동안 동작하는 트랜잭션에서 안정적인 실행보장이 필요할 경우 사용
      (백업/복제의 안정성)
 
4) Serializable (직렬화 가능)
    - 두 개의 트랜잭션이 동시에 수행되지 않음
    - 가장 높은 데이터 안정성 / 가장 낮은 성능
 
 
2. 각 데이터베이스의 기본 격리수준
- 오라클: Read Committed
- MySQL: Repeatable Read
 
2-1. MySQL 격리수준 변경 실습
1) 격리수준 확인 및 변경

기본 격리수준이 'REPEATABLE-READ'임을 확인할 수 있습니다.
 

격리수준을 ‘READ-COMMITTED’로 변경하고 확인해보았습니다.
 
 

#03 MVCC

 - 락 없이 읽기 성능을 증가시키는 기술
    - 락: 여러 개의 트랜잭션이 동시에 접근해도 데이터가 깨지지 않게 함. 그러나 속도는 떨어짐
        - 락은 하나의 DB를 둘이 동시에 읽으려고 하는 것이 문제
           → 만약 격리수준이 다르다면 동시에 액세스하도록 허용하자! 격리수준이 다르면 요구하는 값이 다를 것이기 때문)
 
 - Undo Log 사용 범위
    1. 트랜잭션의 롤백 지원
    2. 트랜잭션의 격리수준을 지원
    3. MVCC를 지원
 
 

#04 데이터 모델링

1. 데이터 모델링
- 추상화: 현실세계를 일정한 형식에 맞추어 표현
- 단순화: 현실세계를 약속된 규약이나 제한된 표기법과 언어로 표현
- 명확화: 누구나 이해하기 쉽게 애매모호함을제거하고 정확하게 현상을 기술
 
2. 추상화 수준에 따른 구분
모델링 3단계
- 개념모델링 (컨셉 디자인)
    - 현실 세계의 데이터를 추상화를 통해서 개념 세계의 데이터로 표현하는 과정 정보 모델링 또는 개념적 설계와 동일한 개념
    - 모델링 결과를 ER 다이어그램으로 표현
- 논리모델링 (컨셉카)
    - 개념 세계의 개체 타입을 DBMS가 지원하는 논리적 데이터 모델로 변환시키는 과정
    - 논리적 설계(Logical Design)와 동일한 개념
- 물리모델링 (양산차)
    - 데이터가 저장될 수 있도록 논리적 데이터 모델을 물리적 데이터 구조로 변환시키는 과정
    - 물리적 설계(Pysical Design)과 동일한 개념
 
2-1. 개념모델링
- 정보공학: 대형 프로젝트를 진행하는 체계적인 방법론
    - ISP(마스터플랜) - 기술위주의 분석
 
2-2. 논리모델링
- 정규화(Normalization) 진행
    - 논리적 데이터 모델의 일관성을 확보하고 중복을 제거하는 작업
    - 신뢰성있는 데이터 구조를 얻는데에 목적이 있음
 
2-3. 물리모델링
- 논리모델링을 하면 테이블 수가 지나치게 많음 -> 테이블 수를 줄여주는 과정
 
 
3. E-R (개념-관계) 모델링
- Entity-Relationship Modeling
    - 테이블을 좀 더 세분해서 1차(기본) 테이블인 엔티티(Entity)와 유도된 테이블인 릴레이션십(Relationship)으로 구분
- 표기법
    - 피터 첸의 표기법
    - 까마귀 발
 
4. 대응수
- 1:1
- 1:N
- N:1
- M:N
 
- 기본적으로 모든 관계는 M:N 관계 (Entity - Relationship - Entity 3개의 테이블이 필요함
- 엔티티의 개수를 논리/물리 모델링화하면 테이블 개수 많아짐
    - M:N -> 1:N / N:1 -> 1:1 순서로 축소
    - 1:N은 테이블 2개로 축소 가능함 (외래키로)
    - 1:1은 테이블의 컬럼 추가로 해결 가능