데이터베이스 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, NONEREAD가 JPA의 비관적 락 -> 트랜잭션이 충돌할 것으로 가정하기에 조회할 때부터 락; select for update
