오래 못 할 짓 하지 않기

DBMS : DataBase Management System ● 목적 - 데이터 정의 및 생성 - 쿼리 날리기 - 정보 업데이트 및 관리 ● Software는 Application이 DB에 정보를 저장하고 분석할 수 있게 도와준다. ( File I/O 단계의 세부적인 건 고려하지 않고 접근 가능 ) 2가지 Interface가 있다. - DDL : Data Definition Language - DML : Data Manipulation Language ▶ SQL : Structured query language 는 DDL과 DML에서 다 쓰인다. Data Model : 정보에 대한 설명을 담고있는 객체(?) 주로 DBMS들이라서 우리는 이 과목에서 이걸 배움 ● 구성요소 3가지 - Structure - ..

특정 컬럼에 대한 데이터를 찾으려고 할 때 ● [ 해당 컬럼에 Index가 걸려있지 않다면 ] 테이블에 있는 모든 정보를 돌아보며 찾아야 한다. 이렇게 테이블을 전체 도는 것을 full scan이라고 한다. = O ( N ) ● [ 해당 컬럼에 Index가 걸려있다면 ] B-tree index 로 되어있다면 = O ( log N ) = Index를 쓰는 이유 1) 조건을 만족하는 튜플을 빠르게 조회하기 위해 2) 빠르게 정렬 / 그룹핑 하기 위해 3) Join 조건도 빠르게 찾기 위해 ▶ CREATE INDEX player_name_idx On player (name); 로 play에 대한 index를 걸어준다. 형태 : CREATE Index ( idx 를 카운트하려는 변수명 ) On ( 원하는 테이블..

저번 시간... 2NF를 만족시키기 위해 모든 Non-prime attribute가 모든 Key에 대해 Fully functionally dependent 하도록 만들었다. 3NF 이제 card_id 에 대해서는 정규화를 했다. - card_id의 문제점은 한 튜플에서 한 Attribute에 두 개의 값이 들어갔다는 것이다. > 이번에는 empl_name을 보자. 중복되는 이름이 많다. 현재 테이블에 관한 Functional Dependency를 보면 아래와 같다. 이 때, empl_name은 empl_id에 따라 값이 바뀌는 걸 알 수 있다. 즉, empl_id가 empl_name을 unique하게 결정한다. = {empl_id} → {empl_name} 또한 empl_id는 account_id에 따라..

DB 정규화 : [ 데이터 중복 ] + [ Insertion , Update , Deletion anomaly ] 를 최소화하기 위해 일련의 Normal Form(NF)에 따라 Releational DB를 구성하는 과정 * Normal form 정규화 되기 위해 준수해야하는 규칙 우리는 1NF부터 BCNF까지만 배울 예정 예제1) ● KEY ● FD 특정 Attribute를 통해 Table의 Tuple을 Unique하게 식별할 수 있다면 그게 FD가 될 수 있다. FD가 될 수 있는 것 - account_id - bank_name & account_num + empl_id 이 같으면 empl_name도 같다. + class가 같으면 bank_name도 같다. 정규화 ● 1NF - 규칙 : Attribut..

Functional Dependency : 한 테이블에 있는 두 개의 Attributes 집합 사이의 제약 Employee table에 6개의 Attribute가 있다고 해보자. 이걸 2개의 집합으로 나눠보자 특징 : 두 Tuple의 X값이 같다면, Y값도 같다. (당연함) 이렇게 X값에 따라 Y의 값이 유일 (Unique) 하게 결정될 때 = [ X가 Y를 함수적으로 결정한다. ] (functionally determin) = [ Y가 X를 함수적으로 의존한다. ] (functionally dependent) 이러한 제약 관계를 Functional dependency 라고 한다. 이름 → 생일 이렇게 둘 다 서로에게 고유한 값을 갖는다고 FD라고 생각하면 안된다. 동명이인이 올 수 있기 때문이다. 따라..

1. 중복 데이터 문제 테이블에는 위와 같은 정보를 하나의 테이블로 만들었다. 이런 테이블에 데이터를 추가해보자 위와 같이 공통적으로 같이 들어가는 경우가 생길 수가 있다. 이런 경우에는 [ 저장 공간 낭비 / 실수로 인한 데이터 불일치 가능성 ] 문제가 생긴다. 만약 부서가 정해지지 않은 직원이 있을 경우에는? 부서에 관련된 부분은 모두 Null로 해야한다. 이번에는 임직원이 한 명도 없는 부서를 입력하려면? 이런 경우에는 직원 관련된 attribute에 모두 null이 들어간다. 이런 일이 생기는 이유 별개의 관심사가 한 테이블에 있기 때문이다. 이와 같이 두 개의 테이블로 나누면 위에 있었던 문제와 Deletion , Edit 등을 수행할 때 발생하는 문제까지 해결 가능하다. 2. Spurious ..

우선 재귀함수에 대해 이해를 하고 가야한다. 피보나치 수열로 예를 들어보자 15번째 값을 구하려면 14,13번째 값을 알아야한다. 14번재 값을 구하려면 13,12번째... 이렇게 13번째 연산이 반복된다. 재귀함수는 이미 해결한 문제를 다시 반복해서 해결하기 때문에 비효율적이다. 이럴 떈 다이나믹 프로그램을 사용한다. 단, 가정이 필요하다. 1. 큰 문제를 작은 문제로 나눌 수 있다. 2. 작은 문제에서 구한 정답은 그걸 포함하는 큰 문제에서도 동일하다. 우선 피보나치 수열을 예시로 분석해보자 [ 재귀 함수 ] 이렇게 구현하는 경우에는 했던 계산을 또 해야하는 비효율성이 생기고 그로 인해 시간이 오래 걸리므로 필요가 없다. [ 다이나믹 프로그래밍 ] int d [ 100 ]; if ( d [ x ] !..

Locking Read MYSQL에서는 Lost Update를 Locking read 라는 기능을 이용하여 해결한다. 다음 쿼리문 같이 끝에 For Update를 붙이면 Lock 획득에 관련해서 Read , Write 둘 다 같은 Lock을 사용한다. Select ... For Update; ▶ Exclusive Lock을 가진다. = 읽고 있으면 다른 곳에서 읽는 것도 안 됨 Select ... For Share; ▶ Shared Lock을 가진다. = 쓰는 거만 동시에 안 하면 ㅇㅋ Write Skew ( In Repeatable read ) Tx 두 개를 실행시켜보자 해결법 Locking Read를 사용한다. PostSQL 에서는 데이터 수정 선빵친 놈이 있으면 늦은 놈이 Rollback Isola..

Lock 기반으로 동작하는 경우에는 Read하는 Tx끼리만 동시에 동작이 가능하다. MVCC 기반으로 동작하는 경우에는 Write만 동시에 동작하는 게 아니라면 다른 경우는 모두 동시에 동작이 가능하다. (이제부터 예시에는 Write Lock 이런 거 표시 안 함. 그냥 Write하면 Lock된 거임) (마찬가지로 Commit 되면 Unlock이 된 것) Tx2에서 x를 50으로 바꾸는데, 이게 Lock이 풀리기 전까지는 Tx2에서만 알 수 있는 공간에 x=50으로 저장해둔다. → 이 다음에 Tx1이 x값을 읽으면 Tx2에서만 알 수 있는 값인 50이 아니라 DB에 커밋되어있는 값인 10을 가져온다. 커밋되면 DB에도 50이 저장된다. Commit 을 할 때 Unlock하는 이유 = Recoverabil..

같은 x(데이터) 에 대해 Read / Write 가 있다면 정상적으로 작동하지 않을 것이다. LOCK의 역할이 이 때 쓰인다. : 데이터마다 LOCK이 있어서, 값을 수정하거나 읽기 위해서 LOCK을 취득해야한다. 그렇지 않다면 접근이 안 된다. 이 기술을 사용하여 동작하는 방식은 아래와 같다 읽는 거든 쓰는 거든 Lock은 필수다. Write Lock : Exclusive라는 특징을 가진다. Read를 하든 Write를 하든 하나의 Transaction만 가능하다. Read Lock : Shared라는 특징을 가진다. 다른 Transaction 이 read할 때 read는 같이 해도 됨. Write는 같이 X Read / Write Lock 예시 Tx2 에서 Read Lock을 건다. > Tx1에서 ..