데이터베이스 2 - 모델링, 정규화, 트랜잭션, 격리수준, ...

출처 도서 - MySQL로 배우는 데이터베이스 이론과 실습

• 모델링
  개념적 모델링, 논리적 모델링, 물리적 모델링
  
  
• 정규화
  1. 제 1 정규화 : 속성값은 모두 원자값이어야 한다.
  
  2. 제 2 정규화 : 기본키가 복합키일 때, 복합키 중 다른 속성의 결정자가 있으면 안 된다.
  예를 들어, A B C D 속성이 있으며 A와 B가 기본키라고 하자.
  기본키(A와 B)가 C의 결정자가 아닌 B만이 C의 결정자인 경우 문제가 발생한다.
  그렇다면 A와 B가 기본키인 A, B, D 속성이 있는 테이블과
  B가 기본키인 B, C 속성이 있는 테이블로 테이블 분리를 시행하는 것이 해결 방법이 된다.
  
  3. 제 3 정규화 : 속성들이 이행적으로 종속되어 있으면 안 된다.
  A -> B -> C 라면, A -> B, B -> C로 분리해야한다.
  
  4. BCNF : 후보키가 아닌 속성이 다른 속성의 결정자이면 문제가 됨
  결정자를 기본키로 테이블을 분리 변경해야한다.

• 트랜잭션 : 데이터 처리 단위. all or nothing.
  원자성(Automicity), 일관성(Consistency), 고립성(Isolation), 지속성(Durability)

• • 동시성 제어
    • 락 : 트랜잭션이 데이터를 읽거나 수정할 때 데이터에 표시하는 잠금 장치.
      • 공유락 : 읽기용 락
      • 배타락 : 읽기/쓰기용 락 -> 둘 다 안 됨
      • 락이 걸려있으면 대기 상태가 된다.
      • 락 유지시간으로 인해 락 해제 발생 가능 -> 이 때는 2단계 락킹을 이용.
      • 데드락 발생할 수 있음 -> 하나 강제로 중지 작업 필요

• • 고립 수준
    • READ UNCOMMITTED : 커밋되지 않은 데이터 읽어들임(오손 읽기)
    • READ COMMITTED : 커밋된 데이터만 읽어들임
      다른 트랜잭션에서 update + commit된 데이터 읽힘(반복불가능 읽기; 데이터 불일치 문제)
    • REAPEATABLE READ :
      반복불가능 읽기 문제 방지
      하지만 다른 트랜잭션에서 insert + commit된 데이터 나타나는 유령 데이터 현상 있음
    • SERIALIZABLE : select에 공유락 설정. 성능에 안 좋음

• JPA와 트랜잭션, 락
  • 보통은 READ COMMITTED 수준에서 낙관적 락, 비관적 락 사용
  • @Version : JPA에서의 낙관적 락 -> 트랜잭션이 충돌하지 않을 것으로 가정하기에 충돌이 난 후 롤백
    예외 처리로 다시 업데이트 시도도 가능
  • @Lock : READ, WRITE, NONE
    READ가 JPA의 비관적 락 -> 트랜잭션이 충돌할 것으로 가정하기에 조회할 때부터 락; select for update