티끌모아 태산

이번 시간에는 concurrency control 기초인 recoverbility와 트랜잭션들이 동시에 실행될 때 rollback이 발생하면 어떻게 될지 알아 보겠습니다. 지난번에 배웠을 때 처럼 K가 H에게 20만원을 이체할 때 H도 본인 계좌에 30만원을 입금하면 여러 형태의 실행이 가능 할 수있다는 것을 확인했습니다. 그리고 각 case 마다 나다타는 operations의 순서를 우리는 schedule이라고 하였습니다. 여러 transaction들이 동시에 실행될 때 각 transaction에 속한 operation들의 실행 순서를 Schedule 이고 합니다. 자 그럼, 저번 시간에는 serializability에 대해서 배워보았는데요 이번시간에는 recoverbility에 대해서 배워보겠습니다...

이번 시간에는 concurrency control의 기초가 되는 schedule과 serializability에 대해서 알아보도록 하겠습니다. Schedule 자, K라는 사람이 H라는 사람에게 20만원을 이체할 때 H도 ATM에서 본인 계좌에 30만원을 입금한다면 여러 형태의 실행이 가능할 수 있습니다. 1 case K의 트랜잭션이 발생한 이후에 H의 트랜잭션이 발생하는 경우 입니다. 즉 K에서 read, write, commit 한 후 H에서 read, write하고 commit하는 순서입니다. 2 case 이번에는 30만원을 입금하는 트랜잭션이 먼저 발생하고 그 후에 K가 H에게 20만원을 송금하는 트랜잭션이 발생한 것입니다. 3 case 이번에는 20만원을 송금하는 트랜잭션을 먼저 시작을 했습니다..

이번시간에는 트랜잭션과 관련된 중요한 속성들인 ACID에 대해서 공부해 보겠습니다. Transaction 다음과 같이 간단한 예제를 통해서 개념에 대해 배워보겠습니다. J가 H에게 20만원을 이체한다면 각자의 계좌는 어떻게 변경돼야 할까요? 현재 상태를 살펴보면, 먼저 J는 계좌에 100만원이 있고 H는 200만원이 있다고 가정해 보겠습니다. J가 H에게 20만원을 보내게 되면 J는 100만원에서 80만원이 되고 H는 200만원에서 최종적으로 220만원이 됩니다. 그러면 이 과정을 SQL문으로 표현하면 어떻게 될까요? account 테이블에서 잔액을 의미하는 balance 를 업데이트 해주는 과정입니다. // J part UPDATE account SET balance = balance - 200000 ..

이번 시간에는 데이터베이스에서 index가 중요한 이유와 동작 방식 등에 대해서 알아보도록 하겠습니다. Indexing 다음과 같이 쿼리문이 있다고 생각해 보겠습니다. 현재, customer table은 아래와 같이 구성되어 있고, 데이터의 수가 100만개라고 가정해 보겠습니다. SELECT * FROM customer WHERE first_name = 'Minsoo'; 이때, first_name에 index가 걸려있지 않다면 성능은 어떻게 될까요?! index가 걸려 있지 않다면 first_name이 'Minsoo'인 것을 찾기위해 100만개의 데이터를 모두 탐색해야합니다. 이렇게 하나하나 모두 다 확인하는 것을 Full scan or table scan이라고 합니다. 그리고 시간복잡도는 데이터의 개수..

이번시간에는 SQL에서 JOIN의 의미와 종류 그리고 특징에 대해서 배운내용을 정리해보도록 하겠습니다. JOIN SQL에게 JOIN은 두 개 이상의 테이블들에 있는 데이터를 한번에 조회하는 것입니다. 그리고 이 JOIN은 여러 종류가 있습니다. implicit join vs explicit join - ID가 1인 임직원이 속한 부서 이름은? SELECT D.name FROM employee AS E, department AS D WHERE E.id = 1 AND E.dept_id = D.id; 이렇게 FROM절에는 테이블만 나열하고 WHERE절에 join condition을 명시하는 방식을 implicit 방식이라 합니다. 위 내용처럼 implicit join은 가독성과 잘못된 쿼리 작성 가능성 때문에..

이번 시간에도 '쉬운 코드' 님의 강의를 듣고 정리한 내용입니다. 저번시간에 IT회사 RDB 만들기 예시로 SQL을 활용하여 부서, 사원, 프로젝트 관련 정보들을 저장할 수 있는 테이블을 만들고 각각의 스키마를 정의하였습니다. 이렇게 테이블을 수정해 주는 이유는 department 테이블을 만들 당시에 employee 테이블이 없었기 때문입니다. 4개의 테이블을 만들었으니 이제 이 테이블에 데이터를 추가해 보도록 하겠습니다. 우선 EMPLOYEE의 데이블 구조를 살펴보면 다음과 같습니다. ❗️저번시간에도 배웠지만 테이블을 만들 때 constraints를 주의해야합니다. 데이터 추가하기: attributes 순서대로 데이터 추가하기 INSERT INTO table_name VALUES(); 위 사진에서 마..