전체 글

[ Database - Intermediate ] - Index

SELECT * FROM customer WHERE first_name = "Minsoo'; (인덱스가 걸려있지 않은 상황)이런식으로 Customer 테이블을 full scan(=table scan)을 통해 tuple을 찾으면 $O(N)$의 시간 복잡도가 걸릴 것입니다. 그리고 Customer 테이블의 로우 수가 많아지면 많아질 수록 이는 비효율적인 scan이 되겠죠. 이는 B-tree based index를 적용해서 table scan을 하게되면 $O(logN)$으로 로우를 찾을 수 있습니다. 즉 해당 쿼리문이 더 빠르게 처리될 수 있습니다. 이는 상황에 따라서 조건을 만족하는 튜플(들)을 빠르게 조회하거나 바르게 정렬, 그룹핑하기 위해 사용됩니다. MySQL에서 Indexing 해보기 만약 위와같은 ..

[ Database - Intermediate ] - DB 정규화 (1NF, 2NF, 3NF, BFNF, 역 정규화)

DB 정규화(normalization) db정규화란 이전에도 봤다싶이 데이터 중복과 insertion, update, deletion anomaly를 최소화하기 위해 일련의 normal forms(NF)에 따라 relational DB를 구성하는 과정이라고 할 수 있습니다. DB 정규화 과정은 위와같습니다. 이는 처음부터 순차적으로 진행되며 앞쪽 NF를 만족하지 못하면 만족하도록 테이블 구조를 조정해야 합니다. 그리고 1NF ~ BCNF까지는 FD와 key만으로 정의되는 normal forms입니다. 그래서 3NF까지 도달하면 정규화 됐다고 말하기도 합니다. 그래서 실무에서는 보통 3NF 혹은 BCNF까지만 진행합니다. 4NF~6NF는 학술적인 측면이 강합니다. 우리는 위 Employee_account를..

[ Database - Intermediate ] - Functional dependency

위와같이 empl_id(집합 X)가 같다면 그 empl_name ~ salary까지(집합 Y)가 같다는 즉 X에 의해 Y가 결정되고 Y는 X에 의존하는 것을 X -> Y로 표현하고 이것을 Functional dependency (FD)라고 부릅니다. 주의해야 할 점이 있는데, state만으로 FD를 판단해서는 안됩니다. 위와같이 {empl_name} -> {birth_date} 이렇게 하게되면 Jinho라는 동명이인이 들어왔을 떄 birth_date가 달라지기 때문이죠. 그리고 위와같이 dept_id를 이전에 FD에 포함하지 않았었는데, 이는 구축하려는 DB의 attribute가 관계적으로 어떤 의미(sementics)를 지닐지에 따라 달라집니다. 그 이유는 임직원이 여러개의 부서를 가질 수 있다면 X ..

[ Database - Basic ] - DB 테이블 설계를 잘못하면 발생할 수 있는 문제점

중복 데이터 문제 만약 위와같이 예전에 봤던 employee 데이터베이스 스키마와 department 데이터베이스 스키마를 한번에 합친 모습입니다. 이때는 Insertion anomalies가 발생하게 되는데, 위와같이 중복된 데이터가 삽입되게 됩니다. 이렇게 하게되면 저장공간 낭비일 뿐더러, 실수로 인한 데이터 불일치 가능성이 존재하게 됩니다. 실수로 dept_name을 DEV가 아닌 DEB이렇게 삽입하면 발생할 수 있는 문제점입니다. 그리고 만약 어떤 employee가 부서배치를 받기 전이라면 dept_id부터 dept_leader_id까지의 정보가 싹다 null이 될 것입니다. 뒤에서 볼거지만 이렇게 로우에 null을 난발하는 것은 좋지 못한 것입니다. 또다른 문제점이 있습니다. 만약 임직원의 정보..

[ Database - Advance ] - MVCC

먼저 MVCC가 무엇인지 알아보기 위해 위는 간단한 예시입니다. write(x=50)은 write_lock을 잡고 write하는 일련의 과정을 나타낸 것입니다. 앞으로 생략하겠습니다. 또한, commit하고 그 뒤에 unlock(x) 즉 write-lock을 해제해주는 과정을 진행해 주어야 하는데, 그 이유는 recoverability를 위해 commit 시점 뒤에 해준다고 이전에 설명했었습니다. 위 그림 시점 이후에 또 tx1 에서 tx2 unlock이후에 x를 읽는다면 어떻게 될까요?? 10일까요 아니면 50일까요?? 이는 당연히 DBMS의 isolation level에 따라 다르겠지요. 만약 read committed는 read하는 시간을 기준으로 그 전에 commit된 데이터를 읽기 때문에, tx..

[ Database - Intermediate ] - Lock을 활용한 concurrency control - 2PL(two-phase locking)

먼저 간단히 read-write lock에 대한 예시입니다. 우리는 이를 OS에서 많이 보았습니다. 먼저 read-lock은 read시에 획득하는 lock으로써 read_lock끼리는 동시에 이 lock에 접근할 수 있습니다. 그 이유는 read 끼리는 공유 자원을 변경하지 않기 때문이죠. 하지만 write-lock은 말 그대로 Mutex(Mutual Exclusion)을 만족시키게 하는 lock입니다. 그냥 일반적인 lock이라고 보시면 됩니다. 즉 아래와 같은 호환성 표를 이해할 수 있을 겁니다. lock을 써도 생기는 이상한 문제 위 두개의 트랜잭션이 있습니다. 한눈에 봐도 두개의 트랜잭션을 serial하게 실행하면 결괏값이 달라질 수 있다는건 알 수 있을 겁니다. 만약 위처럼 그럼 동시에 실행해보..

[ Database - Intermediate ] - Isolation level

위와같은 상황을 다시 한번 리마인드 해보겠습니다. 흐름도를 보면, x=10, y=20에서 시작해서 x는 write(y=70)된 다음 y값을 읽어서 80으로 갱신한다음에 commit했는데, tx2는 abort가 되어 x의 값이 좀 이상해지게 되는데 즉 이를 Dirty read(commit 되지 않은 변화를 읽음) 입니다. 그리고 만약 tx1이 x를 두번 읽는데, 같은 데이터의 값을 달라지는 아래와 같은 상황을 보겠습니다. 이는 isolation 관점에서 봤을 때. isolation은 마치 트랜잭션이 고립된 환경에서 실행되어야 하는데, x를 읽었더니 값이 달라지게 되면 이는 좀 이상합니다. 그리고 우리는 이를 Non-repeatable read, Fuzzy read라고 합니다. 그리고 위와같이 없던 데이터가..

[ Database - Intermediate ] - concurrency control (schedule, serializability, recoverability )

바로 트랜잭션에서 동시성을 관리하는 방법에 대해 알아보겠습니다. 우선 이전 상황을 가정할 것인데요, K가 H에게 20만원을 이체할 때 H도 ATM에서 본인 계좌에 30만원을 입금하는 상황입니다. 이러한 상황에서는 여러 형태의 실행이 가능할 수 있습니다. 위와같이 20만원 -> 30만원 트랜잭션 순서로 실행될 수 있습니다. 또한 30만원 -> 20만원 순서로 실행될 수 있습니다. 위와같이 중간에 30만원 트랜잭션이 실행될 수도 있습니다. 그리고 이전에 봤던것 처럼 기존의 30만원입금이 씹히는 즉 Lost update 현상이 나타나는 케이스도 있을 수 있습니다. 우리는 이제부터 위 하나하나의 명령어를 operation이라고 정의해보겠습니다. 그리고 이 operation을 짧게 나타내서 case 4를 아래와같..

[ Database - Intermediate ] - transaction

만약 위와같은 이체라는 작업을 한다고 해 봅시다. 이는 원자성있게 동시에 성공했을 때 "이체" 라는 작업이 성공한 것이 될겁니다. 이러한 이체라는 작업은 둘 다 정상 처리돼야만 성공하는 단일 작업이라는 것입니다. 이러한 것을 Transaction이라고 합니다. 즉 논리적인 이유로 여러 SQL문들을 단일 작업으로 묶어서 나눠질 수 없게 만든 것이 transaction입니다. START TRANSACTION; UPDATE account SET balance = balance - 200000 WHERE id = 'J'; UPDATE account SET balance = balance + 200000 WHERE id = 'H'; COMMIT; 이런식으로 transaction을 만들고 SQL구문을 작성해주고 맨..

[ Database - Intermediate ] - SQL trigger

SQL에서 Trigger 란 데이터에 변경이 생겼을 때에 DB에 insert, update, delete가 발생했을 떄 이것이 계기가 되어 자동적으로 실행되는 프로시저(procedure)를 의미하게 됩니다. 바로 예시를 들어서 살펴보도록 하겠습니다. 만약 사용자의 닉네임 변경 이력을 저장하는 트리거를 작성해 보고 싶다고 해 보겠습니다. 위와같은 상황이라고 할 때, USERS_LOG에 기존 닉네임을 저장해야 합니다. delimiter $$ CREATE TRIGGER log_user nickname_trigger BEFORE UPDATE ON users FOR EACH ROW BEGIN insert into users_log values(OLD.id, OLD.nickname, now()); END $$ de..