안 평범한 개발자의 하루

제1정규화
 제1정규형의 정의는 테이블 셀에 복합적인값을 포함하지않는다 (스칼라값만을 갖음), 그러나 배열을 insert 할 수 없기때문에 제 1정규형은 자동으로만족한다.

제2정규화 (2NF)
 부분함수의 종속성 = 기본키를 구성하는 열의 일부에만 종속성을 갖음 (복합키일경우) 예를들어 table 회사별 주문에 회사id+주문번호가 키값이라 쳐보자 
 create table 회사별 주문 {
  회사id ,
  주문번호,
  주문일자,
  회사이름,
  고객기업규모,
  PRIMARY KEY(회사id,주문번호)
} 
 위 테이블은 제2정규형을 만족하지 못함, 회사id에만 종속되는게 존재, 회사이름 및 고객기업규모 만 종속됨. 이게 왜 위험하냐면, 주문을 했을때 주문을 한 정보만으로는 고객기업규모를 알아낼수 없음, 이럴경우 NULL을 허가하거나 더미값추가? => 이런 갱신시 부정합을 갱신이상이라함.

제3정규화 (3NF)
 추이함수의 종속이 없어야한다. 다음과같은 테이블이 있다고 가정하자. 
 create table 회사 {
 회사ID,
 회사명,
 규모,
 업계코드,
 업계명,
 PRIMARY KEY (회사ID)
} 
 2NF까진 만족하는듯 하다. 그러나 추이함수의 종속성을 갖는다. (2단계의 함수종속성)  
현재 (회사ID->업계코드->업계명) 이런식으로 종속되어있다. 이럴경우 새로운 업계를 추가할 수 있을까? 업계코드에 따른 업계명은 다른 테이블을 빼야한다.

지난글 에서는 Transaction이 무엇인지에 대해서 한번 살펴보았다.
이번에는 지난번에 설명했던 ANSI에서 정의한 Transaction의 Isolation level 4단계에대해서 알아보자.

격리레벨 4단계를 이해하기위해 일단 상황을 가정해보자. 
 Table USER는 id와 name column이 있다.
 그리고 동시에 실행되는 processes a, b, c 가 있다고 가정해보자 a는 트렌젝션을 시작하고, 이것은 data를 insert하는데 commit될수도 있고, 커밋이 안될 수 도 있다. b는 SELECT 쿼리를 2번 사용하는 트랜잭션이다. c는 data를 select하고 update 한다. 이 모든 프로세스는 USER Table에서 실행된다고 가정하자.

READ UNCOMMITTED 
* b = (select * from user);
 이 레벨은 table에 락을 걸지 않는다. 이 말인즉슨 A가 USER table에 {id:user10,name:홍길동}을 insert하는 도중에 (권한 처리를 위해  아직 uncomitted되었다.)  B가 SELECT를 한다면 이 Uncommitted 되는 {id:user10,name:홍길동}을 본다는  이야기이다.(Dirty Read) 심지어 a가 rollback 되었음에도 B의 SELECT 결과 에는 사용된다. 이는 가장 빠르긴하지만, 안전하지않다. 

READ COMMITTED
 * b = (select * from user where id='user10');
 이 레벨에서는 커밋된 데이터에 락을건다. 커밋된 데이터만 읽을수 있지만, c가 만약 트랜젝션중간에 update를 하고 commit을 하면, b가 1회에 select한 데이터가 2회에는 달라질수가 있다(Non repeatable read). 예를들어보자. b 트랜젝션에서 {id:user10, name:홍길동} 데이터를 1회 읽었다. 그런데 c transaction에서 user10의 이름을 '김길동'이라고 바꿨다. 다시 b에서 2회 select를 실행했을땐 {id:user10, name:홍길동} 을 읽게된다.

REPEATABLE READ
 * b = (select * from user where name='홍길동');
 이 레벨에서는 block of SQL의 lock을 건다. 만약 현재 USER TABLE에 {user:aaa,name:홍길동}, {user:bbb,name:홍길동}이 있다고 가정하자. 그런데 a 트랜잭션에서 도중에 {user:ccc, name:홍길동}을 넣고 commit 했다. 그리고나서 b가 2회째 select를 수행하게되면 1회째와 달리 총 3개의 행을 select 하게된다.(Phantom read)

SERIALIZABLE
 이 레벨은 전체 테이블을 잠근다(위의 예제는 b가 select를 2번 실행할동안 table 전체를 lock 한다.) 이것은 가장 안전하지만, 비효율적이고 가장 느린데이터 작업방법이다. 

위의 내용들 참고하여 transaction isolation level에 따른 나타날수 있는 현상을 정리하자면 다음과 같다.

출처
https://stackoverflow.com/questions/16162357/transaction-isolation-levels-relation-with-locks-on-table

https://stackoverflow.com/questions/11043712/what-is-the-difference-between-non-repeatable-read-and-phantom-read

트랜잭션이란 

- 복수 쿼리를 한 단위로 묶은 것
- 한 덩어리의 쿼리 처리 단위
- 일반적인 DBMS에서 어플리케이션 로직을 구성할 때 사용

Atomicity
- 데이터의 갱신(insery / delete / update)을 수반하는 데이터 조작이 전부 성공할지 전부 실패할지 보증하는 것
- 하나의 트랜잭션이 부분적으로 실행되다가 중단되지 않는 것을 보장
- 예를들어 돈을 빼 오는 작업만 성공하고 받는 쪽에 돈을 넣는 작업을 실패해서는 안됨.

Consistency (일관성)
- 트랜잭션이 실행을 성공적으로 완료하면 일관성있는 데이터베이스의 상태를 유지해야함.
- 무결성 제약중 NOT NULL 조건이있다면 트랜젝션은 중단되어야한다.

Isolation
- 트랜잭션 연산시 다른연산이 끼어들지 못하도록 보장.
- 예를들어 A와 B가 호텔예약을 한다고 했을때, select 후 insert를 하는 트랜잭션을 생각해보자,  A가 트랜잭션을 위해 select 방;을 했을때 10개 빈방이 존재한다면, A가 트랜잭션을 수행하는도중 B가 트랜잭션을 수행하여 select 방; 을똑같이하면 빈방은 10개여야할까? 9개여야할까? mysql 같은경우는 락을걸어 이런 isolation을 보장한다.
- 즉, 고립성이란 복수의 트랜잭션이 순서대로 실행되는것이며 이는 데이터가 병렬로 처리되는 것이 아닌, 직렬로 처리되는 것을 말함. 이는 Serializable(직렬화 가능)한 고립성이라고 함
- 그러나 직렬화로 인해 동시에 동작하는 Transaction이 1가지일경우 성능면에서 비효율적이다.
- ANSI(미국국가규격협회) 에서 권고하는 트랜젝션 격리 완화수준 4개가 있다. 이를 트랜젝션의 격리수준(Transaction Isolationo Level) 이라 한다.

Durability
-성공적으로 실행된 트랜잭션은 persistance 하게 반영되여야함. 즉 시스템 장애, DB일관성 체크등을 하더라도 유지되어야함.
-트랜잭션은 로그에 모든것이 저장된우 Commit으로 간주됨

추신

원본출처 : http://bombay.tistory.com/3

그러나 오버헤드가 너무 클 것같았다. 고민하던중 다음과 같은 포스팅을 찾을 수있엇다

Scenario: 이번 프로젝트를 할때 설문조사를 실행하여 사람과 사람간의 유사한답변을 찾은사람끼리 매칭시켜주는 기능을 만들고자 했었다.

Solutions: 맨처음에는 주관식을 하여 단어간의 유사성을 찾아 매칭시켜줄려고 했지만, 객관식으로 하는것이 더 깔끔 할 것같아서 바꿈

1.테이블 구조(간단함)

2.설문조사를 시작하자마자 수행되는 쿼리

3.핵심쿼리(내가 선택한 답변을 db에서 다른사람이 선택한 답변과 비교하여 상위 4명을 잘라서 보여줌)