CS 과목(CS科目）/데이터 베이스（データベース） 썸네일형 리스트형 23. DB 정규화(normalization) - Part 1 그 전에 아래의 용어들을 짚고 넘어 가자. 1. super key : table에서 tuple들을 unique하게 식별할 수 있는 attribute set 2. (candidata) key : super key 중에서 어느 한 attribute라도 제거하면 tuple들을 unique하게 식별 못하는 super key. 3. primary key : (candidata) key 중에서 실제로 tuple을 unique하게 식별하기 위한 선택한 (candidta) key. 4. prime key : 임의의 key에 속하는 attribute. 5. non-prime key : 어떤 (candidate) key에도 속하지 않는 attribute. EMPLOYEE_ACCOUNT에 존재하는 모든 FD를 아래에서 보여.. 더보기 22.함수 종속(Functional Dependency) 위의 정의를 따라도 되지만, 나는 x의 값에 대응하는 y의 값이 오로지 1개만 있을 때, y는 x에 종속된다 or x는 y를 결정한다 라고 정의를 하겠다. 종속 관계를 위 그림의 기호로 나타낼 수가 있다. (x에 대한 y값이 오로지 1개만 존재하는 관계) Jinho라는 x값에 대해 y값이 2개가 존재하므로, 위 경우는 FD가 존재하지 않는다. 위와 같이, 테이블의 특정 부분과 특정 시점의 테이블을 보고 FD를 생각해서는 안된다. 테이블의 스키마(Schema)를 보고 의미적으로 FD가 존재하는지 파악해야 한다. (아래 참조) 위 경우는 FD이다. 위 경우는 FD가 아니다. 왜냐하면 empl_id에 대해서 dept_id가 2개 이상 존재할 수가 있기 때문이다. 1. x->y라고 해서, 반드시 y->x가 존재.. 더보기 21.DB 테이블 설계를 잘못하면 생길 수 있는 문제 JOIN 등의 연산으로 여러 테이블들을 연결시키다 보면 성능이 안 좋아지므로, 일부러 테이블을 나누지 않는 경우도 존재를 한다. 더보기 20. MVCC - Part 2 Locking Read 이번 시간에는 MySQL에서는 Lost Update 문제를 어떻게 해결해야 하는지에 대해 알아 보자. Locking Read는 MySQL에서만 사용하는 개념이다. 보통, read(x)를 하기 위해서는 SELECT balace from account where id = x 라는 SQL문을 작성을 할 것이다. MySQL에서는 Lost Update문제를 해결하기 위해서 FOR UPDATE 문을 추가적으로 개발자가 작성을 하여서, Write_Lock 을 취득하게 하여 값을 read해야 한다. 위와 같이 MySQL 세계관에서는 데이터를 읽을 때(read할 때), Lost Update 문제를 해결하기 위해 write lock을 취득한 후에 값을 읽어 들이는데, 이러한 read를 Locking.. 더보기 19.MVCC - Part 1 이전 시간에, Lock을 활영한 concurrency control에 대해서 살펴 보았다. 같은 데이테에 대해서 read-read인 경우는 허용을 하지만, 그 이외의 경우는 허용을 하지 않는다. 그래서, 트랜잭션의 Operantion에 대한 전체 처리량(throughput)이 좋지가 않았다. 개발자들은 이러한 문제를 해결하고자, write-write한 경우는 그렇다고 쳐도, read-write의 경우에는 어떻게 최적화를 시킬 수 없을까 라는 고민을 하게 되었고, 그렇게 해서 나온 아이디어가 MVCC(Multi Version Concurrency Control)이다. write-write의 경우에 대해서는 어느 한쪽을 block을 시키지만, read-read는 물론, read-write의 경우에 같은 데이.. 더보기 18. LOCK을 활용한 concurrency control 트랜잭션 1의 목적을 달성하기 위해서는 write(x=20) 작업이 필요하다. 그러나, 위 그림은 설명을 쉽게 하기 위해서 단순히 write(x=20) Operation 하나만 실행을 해주면 되는 것처럼 적어놨다. 그러나 write를 하게 될 때, 만약 index가 걸려 있다면 거기에 대한 처리도 해야 할 것이고, 이 데이터가 실제로 저장되는 파 일에 대해서도 이런 저런 처리를 해줘야 하므로, 실제로는 복잡한 실행 과정을 거쳐야 한다. 이때, 트랜잭션1의 write와 트랜잭션2의 write가 동시에 실행이 된다고 해보자. 어떠한 데이터를 write하는 과정은 복잡한 과정이므로, 같은 데이터를 트랜잭션2에서 write를 동시에 처리하게 되면, 최종 적으로 데이터가 깔끔하게 처리되지 않을 가능성이 높다. 그.. 더보기 17. transaction isolation level DB에 {x=10, y=20}이 있을 때, Transaction1,2이 동시에 실행됐을 때 일어나는 현상을 살펴보자. 두 개의 트랜잭션이 nonserial(비순차적)으로 동시에 실행되고 있는 상황이다. 트랜잭션1에 대해 commit이 일어나서, x는 10에서 80으로 영구적으로 저장이 되었다. 그런데, 트랜잭션2에 대해 어떠한 종류의 에러가 발생을 하여 roll back이 실행이 되었을 때를 생각을 해보자. roll back의 실행에 의해, 트랜잭션2가 시작되기 이전의 상태, 즉 y=20으로 데이터를 복구하게 된다. 근데, DB에 저장된 x의 값 80은 read(x)에 얻은 10과 트랜잭션2 유효하지 않은 write(y)의 결과값인 70을 더하여서 나온 값이다. 이 유효하지 않은 Operation인 wr.. 더보기 16. concurrency control - Part 2 unrecoverable schedule 위 그림에서 보듯, transaction1은 commit의 명령어를 만나면서 실행이 종료가 돼, H의 balance=250만원인 상태가 DB 서 버에 영구적으로 저장이 됐다. ( 참고로, 이 commit은 Transaction1에 대한 commit이므로, Transaction2에 해당하는 빨간색 으로 표시된 2개의 명령문에 대해서는 commit이 되지 않는다.) 그런데, Transaction2에서 어떤 예기치 못한 에러가 발생을 하여, ABORT(중단)가 되면, Transaction2에 대해 roll back이 실행이 돼(autocommit에 의해 에러 발생 시, 자동으로 roll back이 실행이 된다), Transaction2의 Operation들의 실행이 모.. 더보기 이전 1 2 3 4 5 다음
