Database 면접 스터디를 시작하게 된 계기

컴퓨터 공학과를 나왔지만 Database 수강을 실패하여 개인적으로 Database의 책을 찾아보고 공부하여 정리하였지만, Database의 개념이 부족하다고 생각이 들었다. 그때 인프런을 통해서 JSCode에서 진행하는 Database 면접 스터디를 확인하였고, 주저없이 신청하게 되었다.

각 주차별로 큰 주제가 있으며 그 주제 안에서 면접에서 충분히 질문이 가능한 항목들을 미리 운영진 분들께서 추려주어 해당 부분에 대해 한 주동안 학습해오고 스터디날 면접 스터디를 역할을 나누어 진행하는 것이 프로세스였다. 스터디를 해보지 않아서 비교하기는 어렵지만, 운영진들께서 체계적으로 프로세스를 준비한다는 것이 느껴졌고, 역할을 나누어서 면접을 진행하는 것이 큰 도움이 되었던 것 같다. 

그렇게 5주간의 Database 공부가 시작되었다.

활동내역

공부를 넘어서 주마다 과제가 있는데, 학습 내용을 블로그에 작성하는 것이 과제였다. 하지만 나는 학생때부터 계속 노션을 이용해와서 익숙한 노션이 아닌 tistory에 작성하는 것이 쉬운 일은 아니였는데, 한번 노션에 작성하고 초안으로 작성한 노션의 내용을 다시 tistory에 옮기면서 두번의 공부를 진행했다. 총 세번의 복습을 진행하였고, 스터디날 전까지 해당 부분을 계속해서 학습하였다.

역할 기여한 부분

데이터베이스 면접 스터디를 진행하면서 가장 크게 기여한 부분은 5주동안 꾸준히 참여한 것이라고 생각한다. 회사 퇴근하고 나서 따로 개념 정리를 하고 과제를 제출하며 면접 스터디를 진행하는 것은 쉬운 일이 아니였고 꽤나 공이 들어가는 테스크였다. 하지만 내가 공부한 부분을 면접을 통해 다른 사람들에게 공유하면서 정보를 제공하고, 내가 참고하지 못한 부분들에 대해서도 다른 분들이 도와주어 지식을 채워나갈 수 있었던 이유가 5주동안 꾸준히 참여한 큰 성과라고 생각한다. 다른 분들도 마찬가지로 면접 스터디에 열심히 임해주시고 준비해주어 상부상조의 결과가 되었던 것 같다. 

나를 바라본 이미지 및 장점

생각보다 초반부터 칭찬들이 이어져서 개인적으로 놀랐다. 이전 몇번의 면접을 본 경험과 준비를 착실히 해서 나온 결과라고 생각해서 무엇이든 노력을 안하면 안되는게 없다고 생각이 들었다. 말하는 속도에 따라 면접관이 이해를 할 수 있도록 질문에 대해 몇가지 특징들을 제시하면서 답변한 내용들이 대체적으로 좋다고 했다.

아쉬운 점이 있다면 프로젝트의 경험에 빗대어 면접관의 답변을 했으면 좋겠다는 의견도 있었다. 이 부분에 대해서는 부족하다고 느끼고 다음에 면접이 있다면 이 부분에 대해 접목시킬 생각이다.

배운점 느낀점 아쉬운점

개인 생활도 있었을 뿐더러 회사 업무도 있어 퇴근하고 나서 데이터베이스를 공부하고 정리하는 것은 여간 쉬운 작업은 아니였다. 하지만 어느 곳에서는 나보다 더 열심히 살아가고 준비하는 사람이 있다는 생각이 막연하게 있었지만 이번 면접 스터디를 하면서 실제 치열하게 공부하는 사람들을 보며 더욱 자극받았고, 나 또한의 동기부여가 되었다. 

그리고 아쉬운 점으로는 5주동안 진행하면서 뒤로 갈수록 해이해진 부분이 있었다. 초반에는 모든 꼬리질문에 대해서도 다 대답할 수 있도록 준비를 철저히 하였고 모든 내용에 대해 학습을 하였지만 4, 5주차가 되면서 이해가 되지 않은 부분도 머리로 이해하지 않고 텍스트로만 암기했던 부분이 있었던 것 같다. 비록 스터디는 끝났지만 이번 스터디에 정리한 내용을 토대로 계속해서 나의 데이터베이스 지식을 더 갈고닦아 더 많은 지식을 함유할 생각이다. 

Commit에 대해서 설명해주세요.

> `Commit`은 데이터베이스에서 **하나의 트랜잭션 단위**로 트랜잭션을 종료하고 해당 업데이트 정상적으로 처리했다는 것을 의미하는 것으로 변경된 사항을 **데이터베이스에 영구적으로 반영**됩니다. Commit 이후에는 모든 사용자가 변경한 데이터의 결과를 조회할 수 있으며 명령어로는 DDL문(CREATE, ALTER, DROP) 또는 (INSERT, DELETE, UPDATE)이 있습니다.
> 

### 트랜잭션 종료

- **DDL 실행**(`CREATE`, `ALTER`, `DROP`)
- **DCL**(`GRANT`, `REVOKE`)
- DEADLOCK과 같은 ERROR
- **Transaction**(`INSERT`, `UPDATE`, `DELETE`) 작업내용 취소

### SAVEPOINT

- 현재 트랜잭션을 분할하는 명령어
- `SAVEPOINT`는 `ROLLBACK TO SAVEPOINT`로 원하는 곳까지 ROLLBACK가능
- 여러개의 SQL문을 수행하는 트랜잭션의 경우, SAVEPOINT 지정 가능.

Rollback에 대해서 설명해주세요.

> `ROLLBACK`은 데이터베이스 작업 중에 **트랜잭션 처리 과정에서 발생한 변경사항을 취소**하고 트랜잭션 과정을 종료하는 명령어로써, 마지막 COMMIT(트랜잭션의 결과)으로 돌아갑니다. 또는 SAVEPOINT명령어를 사용하여 원하는 지점까지로 설정할 수 있습니다.
> 
- Transaction(INSERT, DELETE, UPDATE) 내용을 취소.
- COMMIT 내용 복구

### COMMIT과 ROLLBACK 장점

- 데이터 무결성 보장
- 데이터 원자성 보장
- 데이터 변경사항 확인 가능
- 논리적인 작업 그룹화 가능

Auto Commit 설정에 대해서 설명해주세요.

> `Auto Commit`이란 사용자가 Commit 명령을 따로 하지 않아도 **자동으로 모든 명령을 Commit**되어 즉시 반영되는 명령어를 말합니다. SQL로는 SET AUTOCOMMIT = 1/0(true/false)로 활성화 비활성화 가능합니다. SELECT으로 @AUTOCOMMIT을 확인할 수 있습니다. Commit이 된 트랜잭션은 ROLLBACK이 불가능하기에 주의해서 사용해야 합니다.
> 

### Auto Commit Case

- SQL*PLUS가 정상 종료된 경우
- DDL, DCL 수행된 경우

### Auto ROLLBACK Case

- SQL*PLUS 비정상 종료
- 컴퓨터의 다운

- mySQL에서는 auto commit이 default로 enable
- autocommit이 켜진 상태에서 start transaction하면 auto commit이 끊기고 transaction을 종료하면(commit, rollback) 다시 원래의 auto commit 상태로

트랜잭션에 대해 설명해주세요.

> `트랜잭션`은 데이터베이스 내에서 하나의 그룹으로 처리되어야하는 **명령문들을 모아놓은 작업단위**로 데이터베이스에 영구 저장되는 단위를 말합니다. 이런 논리적인 조각을 통해서 **데이터 무결성**을 지키기 위한 `COMMIT`과 `ROLLBACK`을 할 수 있습니다.
> 

### 개념

- 데이터의 일관성과 무결성을 보장하기위한 트랜잭션 관리.
- 트랜잭션
    - 데이터베이스 내에서 하나의 그룹으로 처리되어야하는 명령문들을 모아놓은 작업단위.
    - DBMS의 상호작용의 단위

### 특성

- ALL-OR-NOTHING

### 사용법

- Begin_transaction으로 시작, END_TRANSACTION으로 마무리.
- 내부에 명령문 기술

• 트랜잭션의 성질 ACID에 대해서 설명해주세요.ACID
  • 원자성(Atomicity)
    • 트랜잭션 내의 쿼리는 모두 성공하거나 모두 실패해야 .
    • 트랜잭션은 논리적으로 쪼개질 수 없는 작업 단위이기 때문에 SQL문이 실패하면 지금까지의 모든 작업을 취소해서 아무 일도 없었던 것처럼 ROLLBACK을 해야함.
    • 이 속성에서 개발자은 언제 Commit 할 지 ROLLBACK할 지 판단.
    • 나머지 DB에 영구적으로 저장하는 것과 이전 상태로 되돌리는 것은 DBMS가 담당.
  • 일관성(Consistency)
    • 트랜잭션이 DB에 정의된 rule을 위반했는지 DBMS가 커밋하기 전에 확인 및 통지.
    • DB에 정의된 role 외에 애플리케이션 관점에서 트랜잭션이 consistent하게 동작하는 지는 개발자가 확인.
  • 독립성(Isolation)
    • 서로 다른 트랜잭션은 서로에게 영향을 주면 안됨. 다른 얘기로 여러 트랜잭션이 동시에 실행될 때도 혼자 실행되는 것처럼 동작하게 만듭니다. ⇒ 병행성
    • 동시성을 컨트롤할 때 성능 저하의 문제 발생 가능.
    • 따라서 DBMS의 종류에 따라 여러 종류의 isolation level을 제공.
      개발자는 isolation level 중에 어떤 level로 트랜잭션을 동작시킬지 설정 가능.
  • 지속성(Durability)
    • 커밋된 트랜잭션은 DB에 영구적으로 저장.
    • DB System에 문제가 발생하더라도 COMMIT된 트랜잭션은 DB에 남아있어야 하는 속성.
    • 영구적으로 저장한다는 뜻은 비휘발성 메모리(hdd, ssd …)에 저장함.
      이 속성은 기본적으로 DBMS에서 보장.
•  

ACID는 트랜잭션이 안전하게 수행된다는 것을 보장하기 위한 성질을 가르키는 약어로
원자성(Atomicity), 일관성(Consistency), 독립성(Isolation), 지속성(Durability)이 있습니다.

트랜잭션 격리 수준이 뭘까요?

> `트랜잭션 격리 수준`이란 여러 트랜잭션이 동시에 처리될 때, 특정 트랜잭션이 다른 트랜잭션에서 변경하거나 조회하는 데이터를 볼 수 있게 **허용할지 여부를 결정하는 것**입니다. 고립 수준이 높은 순서대로 `SERIALIZABLE`, `REPEATABLE READ`, `READ COMMITTED`, `READ UNCOMMITED`가 있습니다. 이 트랜잭션슬은 AUTO COMMIT이 FALSE인 상태에서만 발생합니다.
> 

|  | Dirty READ | Non-Repeatable Read | Phantom Read |
| --- | --- | --- | --- |
| READ UNCOMMITED | 발생 | 발생 | 발생 |
| READ COMMITTED | 없음 | 발생 | 발생 |
| REPEATABLE READ | 없음 | 없음 | 발생 |
| SERIALIZABLE | 없음 | 없음 | 없음 |

트랜잭션 격리 수준 READ UNCOMMITTED에 대해서 설명해주세요.

> `READ UNCOMMITTED`는 **커밋하지 않은 데이터에 접근할 수 있는 격리 수준**으로 다른 트랜잭션 중에도 작업 중인 데이터 조회가 가능하여 부정합 문제인 **Dirty READ**를 유발합니다. 따라서 MySQL에서는 최소한 READ COMMITTED 이상의 격리 수준을 사용해야합니다.
> 

### READ UNCOMMITTED

- **커밋하지 않은 데이터조차도 접근할 수 있는 격리수준**.
- 어떤 트랜잭션의 작업이 완료되지 않았는데도, 다른 트랜잭션에서 볼 수 있는 부정합 문제 ⇒ Dirty READ
    - 데이터가 조회되었다가 사라지는 현상
- 정합성이 많은 격리 수준이므로 MySQL을 사용하면 최소한 READ COMMITTED 이상의 격리 수준 사용해야함.

• 트랜잭션 격리 수준 READ COMMITTED에 대해서 설명해주세요.READ COMMITTED
  • 커밋된 데이터만 조회.
  • Phantom Read에 더해 Non-Repeatable Read(반복 읽기 불가능)문제가 발생.
  • READ COMMITTED에서는 커밋된 데이터만 조회할 수 있으므로, REPEATABLE READ와 마찬가지로 언두 로그에서 변경 전의 데이터를 찾아서 반환.
•  

READ COMMITTED는 커밋된 데이터만 조회할 수 있는 격리 수준으로 SELECT 조회 시 다른 트랜잭션에 의해 추가된 레코드를 발견하는 Phantom Read나 Non-Repeatable Read가 발생할 수 있습니다.

트랜잭션 격리 수준 REPEATABLE READ에 대해서 설명해주세요.

> `REPEATABLE READ`는 **MVCC를 이용하여 한 트랜잭션 내에서는 동일한 결과를 보장하지만, 새로운 래코드의 추가를 막지 않는 격리수준**으로 `Pahntom Read`가 발생할 수 있으며
> 

### REPEATABLE READ

- 일반적인 RDBMS는 **변경 전 레코드를 UNDO 공간에 백업**. ⇒ 변경 전/후 데이터가 모두 존재하므로 동일한 레코드에 대해 여러 버전의 데이터가 존재하는 것을 `MVCC(Multi-Version Concurrency Control, 다중 버전 동시성 제어)`라고 부름.
- 이를 통해서 트랜잭션이 롤백된 경우 데이터 복원이 가능 및 트랜잭션 간에 데이터 제어 가능.
- 각각의 트랜잭션은 고유한 **트랜잭션 번호**가 존재하고 백업 레코드는 어느 트랜잭션에 의해 백업되었는지를 함께 저장.
- 데이터가 불필요하다고 판단되는 시점에 주기적으로 백그라운드 스레드를 통해 삭제.
- MVCC를 이용하여 한 트랜잭션 내에서는 동일한 결과를 보장하지만, 새로운 레코드가 추가되는 경우 부정합이 생길 수 있음.
- REPEATABLE READ는 새로운 레코드의 추가까지는 막지 않는다고 하였다. 따라서 SELECT로 조회한 경우 트랜잭션이 끝나기 전에 다른 트랜잭션에 의해 추가된 레코드가 발견될 수 있는데, 이를 유령 읽기(Phantom Read).
- 하지만 MVCC 덕분에 일반적인 조회에서 유령 읽기(Phantom Read)는 발생하지 않는다. 왜냐하면 자신보다 나중에 실행된 트랜잭션이 추가한 레코드는 무시하면 되기 때문
- Phantom Read가 발생하는 순간은 잠금이 사용되는 경우.
    - MySQL은 다른 RDBMS와 다르게 특수한 갭 락이 존재
- 트랜잭션 안에서 실행되는 SELECT라면 항상 일관된 데이터를 조회하게 된다. 하지만 트랜잭션 없이 실행된다면, 데이터의 정합성이 깨지는 상황 발생 가능

트랜잭션 격리 수준 SERIALIZABLE에 대해서 설명해주세요.

> `SERIALIZABLE`은 가장 엄격한 격리 수준으로 **트랜잭션을 순차적으로 진행하는 격리 수준**입니다. 동시 성능이 매우 떨어집니다. 이는 `SELECT FOR SHARE/UPDATE` 구문에서 사용합니다.
> 

### SERIALIZABLE

- 가장 엄격한 격리 수준
- 트랜잭션을 순차적으로 진행
- 여러 트랜잭션이 동일한 레코드에 동시 접근 불가능.
- 순차적으로 트랜잭션이 처리되어야 하므로 동시처리 성능이 매우 떨어짐
- MySQL에서 SELECT FOR SHARE/UPDATE는 대상 레코드에 읽기 쓰기 잠금을 걸음.
- 순수한 SELECT는 아무런 레코드 락이 없는데, SERIALIZABLE 격리 수준에서는 순수한 SELECT에서도 대상 레코드에 넥스트 키락을 읽기 잠금을 걸음.

DB 동시성 제어에 대해서 설명해주세요.

> `동시성 제어`는 여러개의 트랜잭션이 작업을 성공적으로 마칠 수 있도록 **트랜잭션의 실행 순서를 제어**하는 기법입니다. 이를 통해 데이터 무결성 및 일관성을 보장할 수 있습니다. 이를 위한 방법으로 Lock, TimeStamp, MVCC 등의 기법들이 있습니다.
> 

### 동시성 제어

- 여러개의 트랜잭션이 작업을 성공적으로 마칠 수 있도록 트랜잭션의 실행 순서를 제어하는 기법
- 목적
    - 트랜잭션의 직렬성 보장
    - 공유도 최대, 응답시간 최소, 시스템 활동의 최대 보장
    - 데이터 무결성 및 일관성 보장
- 동시성 제어를 하지 않은 경우 발생하는 문제점
    - **갱신손실(Lost Update)**
        - 하나의 트랜잭션이 갱신한 내용을 다른 트랜잭션이 덮어씀으로써 **갱신이 무효화**되는  것을 의미.
        - 두개이상 트랜잭션이 한개의 **데이터를 동시에 Update**할 때 발생.
    - **현황 파악 오류(Dirty Read)**
        - 읽기 작업을 하는 트랜잭션 1이 쓰기 작업을 하는 트랜잭션 2가 **작업한 중간에 데이터**를 읽기 때문에 발생하는 문제.
        - 작업중인 트랜잭션 2가 작업을 롤백한 경우 트랜잭션 1은 무효가 된 데이터를 읽게되고 잘못된 결과를 도출
    - **모순성(Inconsistency)**
        - 다른 트랜잭션들이 해당 항목 값을 갱신하는 동안 한 트랜잭션이 두개의 항목 값 중 **어떤 것은 갱신되기 전의 값을 읽고 다른 것은 갱신된 후의 값을 읽게되어** 데이터의 불일치가 발생하는 상황
    - **연쇄 복귀(Cascading Rollback)**
        - 두 트랜잭션이 **동일한 데이터 내용을 접근**할 때 발생
        - 한 트랜잭션이 데이터를 갱신한 다음 실패하여 Rollback 연산을 수행하는 과정에서 갱신과 Rollback 연산을 실행하고 있는 사이에 해당 데이터를 읽어서 사용할 때 발생할 수 있는 문제.
- 기법
    - Lock
        - shared Lock
        - Exclusive Lock
    - 2 Phase Locking
    - Timestamp Ordering
        - 트랜잭션을 식별하기 위하여 DBMS가 부여하는 유일한 식별자인 타임스탬프를 지정하여 트랜잭션 간의 순서를 미리 선택하는 동시성 제어 기법
        - 시스템에 들어오는 트랜잭션의 순서대로 시간 스탬프를 지정하여 동시성 제어의 기준으로 사용
        - 교착 상태를 방지하지만 Rollback 발생률이 높고 연쇄 복귀를 초래할 수 있음.
    - Validation
        - 트랜잭션을 수행하는 동안 어떠한 검사도 하지 않고, 트랜잭션 종료시에 일괄적으로 검사하는 기법
        - 트랜잭션 수행동안 그 트랜잭션을 위해 유지되는 데이터 항목들의 지역 사본에 대해서만 갱신이 이루어짐.
        - 트랜잭션 종료시에 동시성을 위한 트랜잭션 직렬화가 검증되면 일시에 DB로 반영
    - MVCC

| 기법 | 장점 | 단점 |
| --- | --- | --- |
| Locking(2PL) | 1. 데이터 오류 가능성 예방
2. 간단한 알고리즘 | 1. Lock 대기 시간 발생
2. Deadlock 발생 |
| Timestamp | 1. Dealock 발생 없음
2. 트랜잭션 대기 시간 없음 | 1. Rollback 발생확률 낮음
2. Cascading Rollback 가능 |
| Validation | 1. 동시 처리 능력 증가
2. 트랜잭션 대기 시간 없음 | 1. 장기 트랜잭션 철회시 자원낭비 |
| MVCC | 1. 최근 데이터 값을 선택
2. 동시성, 일관성 동시 해결 | 1. Undo 블록 IO에 따른 오버헤드 발생 |

갱신 손실 문제에 대해 설명해주세요.

> `갱신 손실 문제`는 **하나의 트랜잭션이 갱신한 내용을 다른 트랜잭션이 덮어씀으로써 갱신이 무효화** 되는 것을 의미합니다. 두개 이상의 트랜잭션이 한개의 데이터를 동시에 갱신할 때 발생하는 것으로 Lock을 통해서 해결가능합니다.
> 

### 갱신 손실 문제

- 하나의 트랜잭션이 갱신한 내용을 다른 트랜잭션이 덮어씀으로써 갱신이 무효화 되는 것.
- 두개 이상의 트랜잭션이 한개의 데이터를 동시에 갱신할 때 발생

• DB 락에 대해서 설명해주세요.Locking 기법
  • Locking은 하나의 트랜잭션이 실행하는 동안 특정 데이터 항목에 대해서 다른 트랜잭션이 동시에 접근하지 못하도록 Mutual Exclusive 기능을 제공하는 기법
  • 종류
    • Shared lock
      • 읽기 연산만 가능
      • 하나의 데이터 항목에 대해 여러개의 공유 잠금이 가능
    • Exclusive lock
      • 배타 잠금을 설정한 트랜잭션은 데이터 항목에 대해서 읽기 연산과 쓰기 연산 가능
      • 동시에 여러개의 배타 잠금 불가능
  • 잠금 단위 ⇒ 잠금의 대상이 되는 데이터 객체의 크기를 의미.
    • 레코드의 필드 값. 레코드, 디스크 블럭, 테이블, 데이터베이스까지 하나의 잠금 단위가 될 수 있음.
    • 잠금 단위가 클수록 동시성 수준은 낮아지고 동시성 제어 기법은 간단해짐
    • 잠금단위가 작을 수록 동시성 수준은 높아지고 관리가 복잡해짐.
•  

DB 락은 하나의 트랜잭션이 실행되는 동안 특정 데이터 항목에 대해서 다른 트랜잭션이 동시에 접근하지 못하도록 하는 기법으로 종류로는 Shared Lock과 Exclusive Lock이 있습니다. 잠금 단위는 레코드의 필드 값부터 테이블, 데이터베이스까지 될 수 있습니다.

•  
• DB 데드락에 대해서 설명해주세요.데드락
  • 두 트랜잭션이 각각 Lock을 정하고 다음 서로의 Lock에 접근하여 값을 얻어오려고 할 때 이미 각각의 트랜잭션에 의해 Lock이 설정되어 있기 때문에 양쪽 트랜잭션 모두 영원히 처리되지 않는 상태.
  • 데이터의 일관성과 무결성을 유지
  • 종류
  • row-level lock
    • shared lock
      • 데이터를 읽을 때 사용하는 Lock
      • Select문과 같이 클라이언트가 읽기 작업하는 데이터 영역
      • 하나의 데이터 항목에 대해서 동시에 두개 이상의 S-lock 설정이 가능.
    • exclusive lock
      • 데이터를 변경할 때 사용하는 lock
      • 트랜잭션이 완료될 때까지 Exclusive lock이 끝나기 전까지 어떠한 접근도 허용하지 않는다.
  • Table-level lock(Intention lock)
    • SQL server에서 shared lock이나 exclusive lock
  • Record lock
    • DB의 Index record에 걸리는 lock
    • shared lock과 exclusive lock
  • gap lock
    • 실제 존재하는 인덱스 레코드에 락을 거는 것이 아니고 범위를 지정하기 위해 인덱스 레코드 사이의 범위에 락을 거는 것.
    • DB index record의 gqp에 걸리는 lock ⇒ gap이란 index 중 DB에 record가 없는 부분.
    데드락 발생 줄이기
  • 인덱스 설정 → 인덱스가 없으면 Lock이 걸리는 범위가 훨씬 넓어지기 때문에 교착상태가 발생하기 쉬워진다. ex) update
  • Isolation Level 조정
    • 1) READ UNCOMMITED : Share-lock 사용안함.
    • 2) READ COMMITED : 매번의 read 마다 Consistent read를 통한 새로운 snap shot을 생성하며, Share-lock을 사용안함
    • 3) REPEATABLE READ : Shared Lock도 트랜잭션 종료시까지 지속된다. UPDATE, DELETE 상태일때 unique index에 대해 찾으면 → index record에만 lock (record lock)
    • range-type (범위로) 찾으면 → gap lock 사용
    • 4) SERIALIZABLE : Shared Lock이 트랜잭션 종료시까지 지속된다.
  • Lock Timeout 설정 ( 트랜잭션 처리속도를 최소화 )
  • 프로시저 우선순위 설정. 트랜잭션 진행방향을 같은방향으로 처리
  • 데드락 발생시 DBMS는 둘 중 한 트랜잭션에 에러를 발생시킴으로써 문제를 해결.
•  

DB 데드락은 두 트랜잭션의 Lock을 논리적으로 설정을 잘못하여 두 트랜잭션 모두 기다리고 있는 상태를 의미합니다. 이를 예방하기 위해서는 개발자가 Lock을 사용할 때에는 논리적으로 설계를 해야합니다.

•  
• DB 회복에 대해서 설명해주세요.DB 회복
  • 트랜잭션들을 수행하는 도중 장애로 인해 손상된 데이터 베이스를 손상되기 이전의 정상적인 상태로 복구시키는 작업.
  • 유형
    • 트랜잭션 장애: 트랜잭션의 실행 시 논리적인 오류로 발생하는 에러
    • 시스템 장애: HW 시스템 자체에서 발생할 수 있는 에러
    • 미디어 장애: 디스크 자체의 손상으로 발생할 수 있는 에러
    로그
  • 트랜잭션이 반영한 모든 데이터의 변경사항을 데이터베이스에 기록하기 전에 미리 기록해두는 별도의 데이터베이스
  • 안전한 하드디스크에 저장되며 전원과 관계없이 기록이 존재
  • 로그의 구조: <트랜잭션 번호, 로그의 타입, 데이터 항목 이름, 수정 전 값, 수정 후 값>
  • 로그의 타입: START, INSERT, UPDATE, DELETE, ABORT, COMMIT 등 트랜잭션의 연산 타입
  • 로그파일을 이용한 복구
    • 로그파일에 트랜잭션의 시작(START)과 종료(COMMIT)가 있는 경우 REDO 수행
    • 로그파일에 트랜잭션의 시작(START)은 있고 종료(COMMIT)는 없는 경우 UNDO 수행
•  

DB 회복은 트랜잭션을 수행하는 도중 장애로 인해 손상된 데이터베이스를 손상되기 전 상태로 복구시키는 작업으로 REDO와 UNDO를 통해 복구합니다.

REDO, UNDO에 대해서 설명해주세요.

> `UNDO`는 트랜잭션 **로그를 이용**하여 오류와 관련된 모든 변경을 **취소하여 복구**를 수행하고, `REDO`는 트랜잭션 **로그를 이용**하여 오류가 발생한 트랜잭션을 **재실행하여 복구를 수행**하는 것을 의미합니다.
> 

### REDO, UNDO

- REDO
    - 영속성을 보장
    - 무언가를 다시하는 행위(복구)
    - **REDO**는 복구를 할때 사용자가 했던 작업을 그대로 다시
- UNDO
    - 원자성을 보장
    - 무언가를 되돌리는 것.(작업 롤백, 읽기 일관성, 복구)
    - **UNDO**는 사용자가 했던 작업을 반대로 진행
    - 기록되는 데이터
        - INSERT시, insert된 로우의 id 기록
        - UPDATE시, 바뀐 칼럼의 바뀌기 전 값 기록
        - DELETE시, 지워진 모든 데이터 기록
- 복구 방법의 차이
    - UNDO를 통해 복구. ⇒ ROLLBACK
    - 시스템의 장애가 발생하면 UNDO 데이터도 모두 날아감
    - 시스템 장애시 REDO 데이터를 이용해서 마지막 CHECK POINT부터 장애까지 DB BUFFER CACHE를 복구. 이후 UNDO를 이용하여 COMMIT되지 않은 데이터를 모두 ROLLBACK 함으로써 복구 완료.

체크포인트 회복 기법에 대해서 설명해주세요.

> `체크포인트 회복 기법`은 **DB 회복을 하는 방법**으로 지연 갱신 회복 기법, 즉시 갱신 회복 기법 등이 있습니다.
> 

### 회복 기법

- 지연 갱신 회복 기법
    - 트랜잭션 커밋 완료까지 갱신 내용을 로그에 저장하고 DB에 저장하지 않고 지연
    - 중간에 갱신을 하지 않았으므로 undo는 필요 없고 원자성 보장
    - REDO만 하면 됨.
- 즉시 갱신 회복 기법
    - 데이터 변경 시 로그와 DB에 즉시 갱신
    - 커밋되기 전에 장애가 나면 UNDO 커밋 후에 장애가 나면 Redo
- 체크포인트 회복 기법
    - REDO, UNDO를 해야할 트랜잭션을 결정하기 위해서 이론적으로 로그 전체를 확인해야하는데 시간 소요 및 REDO. 필요없는 트랜잭션을 REDO해야하는 문제를 해결하는 기법
    - UNDO를 수행하여 회복하는 것을 후진 회복, REDO를 수행하여 회복하는 것을 전진회복.
- 그림자 페이징 회복 기법
    - 로그를 사용하지 않고 트랜잭션 실행동안 현재 페이지 테이블과 그림자 페이지 테이블 2개 관리기법.
    - 데이터 변경시 현재 테이블만 변경, 회복 시 현재 페이지 테이블을 그림자 테이블로 대체
    - UNDO 연산이 간단하며, REDO 연산이 필요 없기에 신속한 회복 가능
    - DB 페이지 변경 시 물리적 위치의 변경으로 인해 단편화가 발생.
- 미디어 회복 기법
    - 비휘발성 저장장치가 손상될 경우 사용되는 회복 기법
    - 주기적으로 데이터를 덤프하여 장애 시 최근 덤프를 DB에 적재
    - 덤프를 다른 저장소에 옮길 때 대용량 데이터 전송이 필요하며 이때 트랜잭션 처리를 중단해야하기에 CPU 낭비가 되어 비용이 많이 소모

MySQL InnoDB의 기본 트랜잭션 고립 수준은 뭘까요?

> `REPEATABLE READ`입니다. 바이너리 로그를 가진 MySQL의 장비에서는 최소 REPEATABLE READ 격리 수준 이상을 사용해야 한다고 합니다. InnoDB 스토리지 엔진은 트랜잭션이 ROLLBACK될 가능성에 대비해 변경되기 전 레코드를 `언두(Undo) 공간`에 백업해두고 실제 레코드 값을 변경합니다. 이러한 변경 방식을 `MVCC`라고 합니다.
>

이상 현상이 뭘까요?

이상현상은 데이터베이스의 테이블을 설계를 잘못하여 데이터를 가공할 때 데이터의 무결성이 깨지는 현상을 말합니다. 그 유형으로는 삽입이상, 갱신이상, 삭제이상으로 구성되어 있습니다.

 이상현상

• 정규화를 거치지 않은 릴레이션에서 발생할 수 있는 이상 현상.
• 데이터들이 불필요하게 중복.
• 속성들의 종속관계를 하나의 릴레이션에 표현하기에 발생.
• 삽입이상
  • 데이터 삽입 시 의도와 다른 값들도 삽입되는 것.
• 삭제이상
  • 데이터 삭제 시 의도와 다른 값들도 연쇄 삭제되는 것.
• 갱신이상
  • 데이터 갱신 시 일부 튜플만 갱신되어 모순 발생.
• 데이터 정규화를 통해 해결.

  학번	이름	나이	성별	강의코드	강의명	전화번호
  1011	이태호	23	남	AC1	데이터베이스 개론	010-1234-5678
  1012	강민정	20	여	AC2	운영체제	010-5325-6913
  1013	김현수	21	남	AC3	자료구조	010-5830-3291
  1013	김현수	21	남	AC4	웹 프로그래밍	010-5830-3291
  1014	이병철	26	남	AC5	알고리즘	010-2348-5892

삽입 이상(Insertion Anomaly)에 대해서 설명해주세요.

삽입이상은 자료를 삽입할 때 의도하지 않은 자료까지 삽입해야만 자료를 테이블에 추가 가능한 현상을 말합니다. 위 테이블을 기준으로 강의를 아직 수강하지 않는 학생에게는 null값이 들어가야하는 문제가 생기는 경우를 의미합니다.

갱신 이상(Update Anomaly)에 대해서 설명해주세요.

갱신이상이란 중복된 데이터 중 일부 데이터만 수정되어 데이터 간의 일관성이 깨지는 현상을 의미합니다. 강의코드 AC3의 김현수의 전화번호를 변경할 때 1013의 김현수의 전화번호가 모두 바뀌어야 하는데 AC3의 데이터에 해당하는 김현수의 전화번호만 바뀌는 현상을 의미합니다.

삭제 이상(Deletion Anomaly)에 대해서 설명해주세요.

삭제이상이란 정보를 삭제할 때 의도하지 않은 정보까지 삭제되어 버리는 현상을 의미합니다. AC1인 데이터베이스 개론의 강의를 삭제하게 되면 이태호 학생의 데이터까지 삭제되는 현상이 발생합니다.

함수 종속성이 무엇인가요?

함수 종속성이란 속성들 간의 관련성을 말합니다. 이를 이용하여 이상현상을 예방할 수 있도록 릴레이션을 설계하는 과정이 정규화입니다.

• 함수 종속성
  • 릴레이션의 속성 A와 B에 대해서 A값에 의해 B값이 유일하게 정해지는 관계
    (B는 A에 함수 종속이다. A → B, A는 결정자, B는 종속자)
  • 완전 함수 종속
    • 기본키를 구성하는 모든 속성에 종속되는 경우
  • 부분 함수 종속
    • 기본키를 구성하는 속성의 일부에 종속되거나, 기본키가 아닌 다른 속성에 종속되는 경우
  • 이행적 함수 종속
    • A→B, B→C가 종속관계일 때 A→C가 성립하는 경우

    학번	이름	학년	과목번호	성적

  • 위와 같은 릴레이션이 있을 때(기본키: (학번, 과목번호)) 
  • 학생은 이름, 학번만 알아도 유일하게 결정.
  • 성적은 (학번, 과목번호)로 유일하게 결정
  • 학년과 이름은 (학번, 과목번호)에 대해 부분 함수 종속
  • 성적은 완전함수 종속

완전 함수적 종속은 뭔가요?

완전 함수적 종속은 X의 값이 Y의 값에 모두 포함되어 있는 것을 의미합니다

부분 함수적 종속은 뭔가요?

부분 함수적 종속은 X의 부분집합이 Y에 종속되어 있을 때를 의미합니다.

이행적 함수적 종속은 뭔가요?

이행적 함수적 종속은 함수 종속 관계가 X → Y, Y → Z일 때 논리적으로 X → Z가 성립될 때 Z가 X에 이행적으로 함수에 종속되었다고 합니다.

• X(이름, 성별) → Y(주소)
• Y(주소) → Z(지역)
• X(이름, 성별) → Z(지역)
• X → Z

정규화(Normalization)에 대해서 설명해주세요.

정규화는 데이터의 이상현상을 예방하고 효과적인 연산을 하기위한 기법으로, 릴레이션 간의 함수 종속성을 파악하여 기본키와 외래키를 이용하여 릴레이션을 효과적으로 설계하는 과정을 의미합니다.

 정규화

• 속성간의 종속성으로 인해 발생하는 이상현상을 릴레이션 설계 시에 제약조건을 통해서 이상현상을 없애는 과정.
• 정규형의 차수가 높아질수록 제약사항이 많아지고 엄격해지지만 이상현상의 발생 가능성이 떨어진다.
• 릴레이션의 특성에 따라서 적합한 정규형을 선택해야함.

장점

• 이상현상 해결
• 속성의 구조 추가로 인해 DB 구조를 확장하는 경우, 구조 변경 최소화

제 1 정규형에 대해서 설명해주세요.

제 1정규형은 릴레이션의 모든 속성의 도메인이 원자 값만으로 구성되어 있어야한다는 특성으로 예를 들어~~

제 1 정규형

• 제 1 정규형만 지킨다면 데이터 중복 이상현상이 발생할 수 있다.
• 기본키에 완전 함수 종속되지 못한 칼럼이 있다면 갱신, 삭제, 삽입 이상이 일어날 가능성 존재.
  ⇒ 부분 함수적 종속을 제거하여 제 2 정규형을 만족하도록.

  학번	과목코드
  CS123	B31, A15
  CS345	N04

  학번	과목코드
  CS123	B31
  CS123	A15
  CS345	N04

• 왼쪽 테이블의 과목코드의 칼럼이 원자 값이 아님.
• 오른쪽 테이블로 변경해야함.

제 2 정규형에 대해서 설명해주세요.

제 2정규형은 릴레이션이 제1 정규형에 속하고, 기본키가 아닌 모든 속성이 기본키에 완전 함수 종속되어야 한다는 특성으로 예를 들어~~

• 테이블의 기본키: (학번, 과목코드)
• (학번, 과목코드) -> 성적
• (과목코드) -> 강의실

• 테이블을 분리하여 제 2정규형 만족

제 2 정규형

• 이행적 함수 종속이 존재하면 갱신이상이 가능.
  ⇒ 이행적 함수 종속을 제거하여 제 3정규형을 만족하도록

제 3 정규형에 대해서 설명해주세요.

제 3 정규형은 릴레이션이 제 2 정규형에 속하고, 모든 속성이 기본키에 이행적 함수 종속되지 않아야한다는 특성으로 예를 들어~~

• 기본키: 학번
• 학번 -> 과목코드
• 과목코드 -> 수강료
• 학번 -> 과목코드

• 학번 -> 과목코드
• 과목코드 -> 수강료 분리
• 이를 통해 갱신 이상 해결 가능

BCNF 정규형에 대해서 설명해주세요.

BCNF 정규형은 제 3 정규화를 진행한 테이블에 대해 모든 결정자가 후보키가 되도록 테이블을 분해하는 것으로

• 3 정규형은 만족하지만 다음과 같은 이상 현상 가능
  • 삽입이상: 새로운 교수가 특정 과목을 담당한다는 새로운 정보를 추가할 수 없다. 적어도 한 명 이상의 수강 학생이 필요하다.
  • 갱신이상: 학번 100이 C234 과목을 취소하면, P2가 C234 과목을 담당한다는 정보도 삭제된다.
  • 삭제이상: 삭제 이상 : - 갱신 이상 : P1의 과목이 변경되면 P1인 행을 모두 찾아 변경시켜주어야 한다.
• 원인은 결정자(Determinant)가 후보키(Alternative Key)로 취급되고 있지 않기 때문이다.
• 후보키는 슈퍼키(super key) 중에서 최소성을 갖는 키이므로 이 릴레이션에서는 (학번, 과목명)이나 (학번, 담당교수)가 후보키가 된다.
• 담당 교수만으로는 후보키가 될 수 없다. 하지만, 후보키가 아님에도 과목명을 결정할 수 있기 때문에 담당 교수는 결정자에 속한다. 

  학번	담당교수
  100	P1
  100	P2
  200	P1
  300	P3
  400	P4

  담당교수	과목명
  P1	C123
  P2	C234
  P3	C234
  P4	C234

반정규화에 대해서 설명해주세요.

반정규화는 정규화를 통해 릴레이션을 디자인할 시 릴레이션의 분해나, 데이터베이스의 성능이 떨어지는 결과를 초래할 수 있습니다. 따라서 이러한 경우를 예방하기 위한 기술로 종류로는 테이블 통합/분할/추가/중복 속성 추가등이 있습니다. 반정규화 과정을 거치게 되면 데이터의 일관성이나 무결성이 보장되지 않을 수 있기에 개발자가 데이터 관리를 더욱 신경써야합니다.

 반정규화

• 시스템의 성능 향상을 위해 정규화된 데이터 모델을 통합하는 작업
• 종류
  • 테이블 통합
  • 테이블 분할
  • 테이블 추가
  • 중복 속성 추가
• 시스템의 성능 향상
• 데이터의 일관성이나 무결성 보장 불가능
  • 검색기능 향상
  • 갱신, 삭제 성능 낮아짐
• 대상
  • 수행 속도가 많이 느린 경우
  • 테이블의 JOIN연산을 지나치게 사용하여 데이터를 조회하는 것이 어려운 경우
  • 테이블에 많은 데이터가 있고, 다량의 범위 혹은 특정 범위를 자주 처리해야하는 경우.

랜덤 I/O와 순차 I/O에 대해서 설명해주세요.

랜덤 I/O(Random I/O, direct accss)와 순차 I/O(Sequential I/O) 모두 하드 디스크 드라이브의 플래터를 돌려서 읽어야 할 데이터가 저장된 위치로 디스크 헤더를 이동시킨 다음 데이터를 읽습니다. 하지만 여러개의 데이터를 읽을 때 순차 IO 는 디스크 헤드를 한번만 움직이지만, 랜덤 IO 는 디스크 헤더를 데이터 갯수만큼 움직여야 합니다. 디스크 헤더를 움직이게 되면 시간이 걸리기에 여러 번 쓰기 또는 읽기를 요청하는 랜덤 I/O 작업이 작업 부하가 훨씬 더 큽니다. 하지만 SSD에서도 랜덤 I/O는 순차 I/O보다 처리율(Throughput)이 떨어집니다. 인덱스 레인지 스캔(Index Range scan)은 데이터를 읽기 위해 주로 랜덤 I/O를 이용하고 풀 테이블 스캔(Full Table scan)은 순차 I/O를 사용합니다.

클러스터링 인덱스를 활용한 스캔은 "순차 I/O"

클러스터링 인덱스(PK)를 이용해 레인지 스캔을 하게 되면, "순차 I/O" 방식으로 동작합니다. 왜? 클러스터링 인덱스는 메모리 상에 저장된 데이터 페이지의 논리적인 위치와 물리적으로 저장된 위치가 동일한 순서로 정렬됩니다.

그래서, 여러 개의 데이터를 조회하거나 수정할 때, 바로 옆의 데이터를 조회하면 되기 때문입니다. 그래서 랜덤 I/O 방식대로 동작할 이유가 없고, 순차 I/O 방식으로 동작하는 것이 훨씬 효율적입니다.

하지만, 클러스터링 인덱스를 통해서 조회하더라도, 순서대로 조회하는 것이 아니라 띄엄띄엄 조회하게 된다면 랜덤 I/O 방식으로 동작합니다.

물론, 클러스터링 인덱스 또한 하나의 데이터에 대해 조회하거나 업데이트하는 것은 랜덤 I/O 방식이라고 봐도 무방합니다.

단, 랜덤 I/O와 순차 I/O를 구분짓는 차이점은 여러 개의 데이터를 어떻게 조회하는 것이므로 하나의 데이터를 조회하는 방법에 대해선 논의하지 않겠습니다.

세컨더리 인덱스를 활용한 스캔은 "랜덤 I/O"

세컨더리 인덱스는 클러스터링 인덱스와는 달리, 데이터 페이지의 위치와 물리적인 위치가 동일한 순서가 아닙니다. 세컨더리 인덱스는 인덱스 구조를 봐도, 물리적인 저장위치를 저장하는 것이 아니라, 클러스터링 인덱스의 위치를 저장하고 있습니다.

즉, 세컨더리 인덱스를 이용해 조회하는 명령은 여러 곳에 분산된 데이터를 조회하게 되므로, 랜덤 I/O 방식으로 동작합니다. 또한 수정하는 작업 또한 인덱스를 활용하므로, 여러 데이터를 동시에 수정하는 작업도 랜덤 I/O 방식으로 동작하게 됩니다.

인덱스에 대해서 설명해주세요.

인덱스는 데이터베이스 테이블에 대한 검색 성능의 속도를 높여주는 자료구조입니다. 특정 컬럼에 인덱스를 생성하면, 해당 컬럼의 데이터들을 정렬하여 별도의 메모리 공간에 데이터의 물리적 주소와 함께 저장된다. 또한, 인덱스 생성 시 오름차순으로 정렬하기 때문에 데이터를 읽는 것만으로도 정렬된 상태가 유지됩니다.

📎 장점: 인덱스를 사용하는 이유

👉 데이터가 정렬되어 있기 때문에 테이블에서 검색과 정렬 속도를 향상시킨다.

• 조건 검색 Where절의 효율성: 보통 Where절의 사용할 때 특정 조건에 맞는 데이터를 찾기 위해 데이터를 처음부터 끝까지 다 비교해야 하는데, 인덱스를 통해 데이터가 정렬되어 있으면 빠르게 찾아낼 수 있다.
• 정렬 Order by 정의 효율성: 인덱스를 사용하면 Order by에 의한 Sort과정을 피할 수 있다. 본래 Order by는 굉장히 부하가 많이 걸리는 작업이기 때문에 인덱스를 통해 이미 정렬되어 있으면 부하가 걸리지 않을 수 있다.
• MIN, MAX의 효율적인 처리가 가능: 이것 또한 인덱스를 통해 데이터가 정렬되어 있기 때문에 처음부터 끝까지 뒤져서 찾는 것이 아닌 인덱스로 정렬된 데이터에서 MIN, MAX를 효율적으로 추출할 수 있다.

👉 인덱스를 사용하면 테이블 행의 고유성을 강화시킬 수 있다.

👉 시스템의 전반적인 부하를 줄일 수 있다.

📎 단점: 인덱스 사용시 주의할 점

👉 인덱스의 가장 큰 문제점은 정렬된 상태를 계속 유지시켜야 한다는 점이다.

인덱스가 적용된 컬럼에 정렬을 변경시키는 INSERT, UPDATE, DELETE 명령어가 수행된다면 계속 정렬을 해주어해서 그에 따른 부하가 발생한다. 이런 부하를 최소화하기 위해 인덱스는 데이터 삭제라는 개념에서 인덱스를 사용하지 않는다 라는 작업으로 이를 대신한다.

• INSERT: 새로운 데이터에 대한 인덱스를 추가
• DELETE: 삭제하는 데이터의 인덱스를 사용하지 않는다는 작업 진행
• UPDATE: 기존의 인덱스를 사용하지 않음 처리하고, 갱신된 데이터에 대해 인덱스 추가

👉 무조건 인덱스 스캔이 좋은 것은 아니다

검색을 위주로 하는 테이블에 인덱스를 생성하는 것이 좋지만 무조건 인덱스가 검색에 좋은 것은 아니다. 예를 들어, 1개의 데이터가 있는 테이블과 100만개의 데이터가 들어 있는 테이블이 있다고 하자. 100만 개의 데이터가 들어있는 테이블이라면 풀 스캔보다는 인덱스 스캔이 유리하겠지만, 1개의 데이터가 들어있는 테이블은 익덱스 스캔보다 풀 스캔이 더 빠르다.

👉 속도 향상을 위해 인덱스를 많이 만드는 것이 좋지 않다.

인덱스를 관리하기 위해서는 데이터베이스의 약 10%에 해당하는 저장공간이 추가로 필요하다. 때문에 너무 많이 인덱스를 생성하면 하나의 쿼리문을 빠르게 만들 수 있지만 대신에 전체적인 데이터베이스의 성능 부하를 추래한다. 때문에 무조건적인 인덱스 생성보다 SQL문을 효율적으로 짜고, 인덱스 생성은 마지막 수단으로 사용해야한다.

인덱스의 동작 방식에 대해 설명해주세요

제가 사용한 MySQL을 기준으로 설명드리겠습니다. 먼저 Clustered Index는 개발자가 설정한 Index가 아닌 MySQL이 설정한 Index입니다. 해당 테이블에 Auto increments값으로 PK를 설정하거나, unique 컬럼, 또는 MySQL에서 내부적으로 Hidden Clustered Index Key (row ID)를 만들어 Clustered Index로 사용합니다. Non Clustered Index는 개발자가 설정한 Index를 말하는데 B-트리에 저장된 인덱스의 root node로 가서 branch node의 경로를 안내해주고 leaf node로의 경로를 알려줍니다. 그렇게 leaf node까지 도착하게 되면 leaf node는 index 의 값과 디스크의 주소값을 가지고 있어 해당 값을 참조하게 됩니다.

insert는 b-tree 넣는 과정
delete는 leaf node 찾아서 지우고 그 부모 데이터는 자식 데이터 중 가장 작은 값으로 변경
update는 delete → insert 과정

그렇다면 어떤 컬럼에 Index를 설정하면 좋을까

MySQL에서 자동 설정하는 Clustered Index의 조건을 다시한번 생각해보자. 테이블에서 모든 row에 중복이 적으면 적을수록 좋다. 카디널리티가 높은 컬럼이 좋다. 즉 데이터의 중복이 적으면 적을수록 좋다. discint foo 했을 때 랑 count(*) 가 비슷한 컬럼일수록 Index 효율이 높다.

Index와 무관하게 Full Scan으로 동작하는 경우

• 컬럼의 가공
• ≠ (부정형)
• like 앞 %
• count(*)
• 멀티 컬럼에서 두번째 컬럼을 조건으로 사용하는 경우
• 멀티 컬럼 Index 순서를 바꾸는 경우

어떤 기준으로 인덱스를 설정해야할까요?

카디널리티가 높고, 선택도가 낮으며, 활용도가 높고 수정 빈도가 낮은 컬럼을 Index로 사용하는게 좋습니다.

인덱스는 DML에 취약

INSERT, UPDATE, DELETE를 통해 데이터가 추가되거나 값이 바뀐다면 인덱스 테이블 내에 있는 값들을 다시 정렬을 해야 한다. 그리고 위에 사진처럼 인덱스 테이블, 원본 테이블 이렇게 두 군데의 데이터 수정 작업을 해줘야 한다는 단점도 발생

향상된 쿼리 성능

카디널리티가 높다는 것은 인덱싱된 열이 전체 행 수에 비해 많은 수의 고유 값을 포함한다는 것을 의미합니다. 이러한 고유성은 인덱스를 더 선택적으로 만들어 데이터베이스 엔진이 검색을 효율적으로 좁힐 수 있습니다. 선택성이 높은 인덱스를 가진 쿼리는 특정 행을 빠르게 찾을 수 있으므로 쿼리 실행 속도가 빨라집니다.

디스크 I/O 및 CPU 사용량 감소:

높은 카디널리티 인덱스를 가진 데이터베이스 엔진은 쿼리를 실행할 때 더 작은 데이터 서브셋을 스캔해야 합니다. 이는 필요한 정보를 검색하는 데 필요한 디스크 I/O 및 CPU 처리의 양을 줄입니다. 디스크 읽기 및 계산이 적을수록 전체 시스템 성능이 향상됩니다.

테이블에 인덱스를 많이 설정하면 좋을까요?

MySQL은 B-Tree를 통해 인덱스를 관리합니다. B-Tree는 인덱스 값을 기준으로 정렬된 상태를 계속 유지하기에 인덱스를 많이 설정하는 것은 좋은 방법이 아닙니다. select는 index에 의해 더 빨라지겠지만, update, delete, insert의 동작이 더 느려지게 될것이다. 새로운 데이터가 생겼을 때 index 1개면 위 과정이 1번이겠지만 index가 20개라면 20번 실행되어야 한다.

커버링 인덱스(Covering index)에 대해서 설명해주세요.

커버링 인덱스란, 쿼리를 충족시키는데 필요한 모든 데이터를 갖고 있는 인덱스를 말합니다.

인덱스는 조회 성능을 향상. 커버링 인덱스는 여기서 "2. 실제 데이터 접근" 의 행위 없이 인덱스에 있는 컬럼값들로만 쿼리를 완성하는 것을 이야기 합니다.

• 쿼리를 충족시킨다 : SELECT, WHERE, ORDER BY, LIMIT, GROUP BY등에서 사용되는 모든 컬럼이 인덱스 컬럼 안에 다 포함되는 경우.

장점

• DB Optimizer가 멋대로 PK를 활용한 조회 작동을 Index를 활용하도록 조회.
• 대용량 데이터 조회 시 성능 향상

다중 컬럼 인덱스(Multi-column index, 복합 인덱스)에 대해서 설명해주세요.

다중 컬럼 인덱스는 두개 이상의 필드를 조합하여 생성한 Index입니다. 첫번째 조건과 두번째 조건을 함께 index하여 검색 성능을 향상시키지만 단일 컬럼 인덱스에 비해 insert, update, delete 과정이 비효율적으로 일어나기에 업데이트가 안되는 값을 선정해야합니다.

다중 컬럼 인덱스의 정렬

• 다중 컬럼 인덱스에서 인덱스를 구성하는 컬럼은 첫번째 컬럼부터 차례대로 정렬.
• N번째 인덱스 컬럼은 N-1번째 인덱스에 의해 정렬

다중 컬럼 인덱스의 스캔

1. 인덱스 컬럼의 순서에 따른 성능 차이
   1. 다중 컬럼 인덱스 내 컬럼의 순서는 성능에 큰 영향을 미치므로 어떤 방식의 조회가 자주 일어나는지, 필터링이 어떻게 되는지 고민해야함.
2. 다중 컬럼 인덱스의 사용 여부
   1. 선행하는 컬럼를 먼저 조회해야 함.

B-Tree 인덱스와 B+Tree 인덱스에 대해 설명해주세요.

B-Tree 데이터가 정렬된 상태로 유지되어 있는 BST와 비슷한 구조이지만 자식노드가 2개 이상이 가능한 자료구조입니다. 이는 Key 값을 이용하여 찾고자하는 데이터를 트리 구조를 이용해서 찾을 수 있습니다. B+Tree는 branch node에는 key만 담아두고 data는 담지 않고, data는 오로지 leaf node에만 저장하고 leaf 노드끼리는 linkedlist로 연결되어 있는 자료구조입니다. 이는 메모리를 더욱 확보할 수 있기때문에 많은 key를 수용할 수 있습니다. 

Hash 인덱스에 대해서 설명해주세요.

Hash 인덱스는 인덱스를 해시 함수를 통해 키 값을 저장하고, 조회하는 방식을 의미합니다. 해시 인덱스는 동등 비교 검색에는 최적화되어 있지만 쿼리 조건문에 많이 사용하는 범위 검색이나 정렬에는 좋은 성능을 보이지 못합니다.

클러스터링 인덱스에 대해서 설명해주세요.

DBMS에서 테이블을 선언할 때 PK가 있을 때, 만약 PK가 없으면 unique column, 둘다 없을 경우 row id를 기반으로 선언하는 인덱스를 클러스터링 인덱스라고 합니다.

인덱스 스캔 방식에 대해서 설명해주세요.

인덱스 스캔 방식에는 Index Range Scan, Full Scan, Unique Scan, Skip Scan등이 있습니다.

MySQL의 인덱스의 일반적인 엑세스 방식인 Index Range Scan은 수직적으로 탐색하고 필요한 범위만큼 수평적 탐색하는 스캔 방식입니다.

Index Full Scan은 수직적 탐색없이 leaf block부터 수평적 탐색하는 방식입니다. 최적의 인덱스가 없을 때 차선으로 선택되고,

Unique Scan은 수직적 탐색으로만 데이터를 찾는 스캔 방식입니다. =조건으로 탐색하는 경우 동작하고, 범위 조건으로 검색하게 되면 Index Range Scan으로 처리됩니다.

index Skip Scan은 오라클 9i부터 제공하고 스캔방식은 조건절에 빠진 선행 인덱스 칼럼의 Distinct Value 갯수가 적고 후행 컬럼의 Distinct Value 갯수가 많을 때 유리합니다.

쿼리 실행 계획에 대해서 설명해주세요. 실행 계획을 확인해본적이 있나요?

쿼리 실행 계획(Query Plan)은 데이터베이스 관리 시스템(DBMS)이 SQL 쿼리를 처리하기 위해 사용하는 실행 계획입니다. DBMS에서 쿼리를 처리할 때 데이터베이스에서 데이터를 검색하고 가져오는 방법을 결정하는데 사용되고 쿼리 실행에 필요한 단계를 보여주며, 각 단계에서 DBMS가 사용하는 액세스 경로를 보여주고, 쿼리 실행에 필요한 리소스 및 비용 정보를 제공합니다.

특징

• 쿼리 실행에 필요한 단계를 보여준다.
• 각 단계에서 DBMS가 사용하는 액세스 경로를 보여준다.
• 쿼리 실행에 필요한 리소스 및 비용 정보를 제공한다.

장점

• 성능 문제를 식별하는 데 도움이 된다.
• 실행 계획을 변경하여 쿼리 성능을 개선할 수 있다.
• 쿼리 최적화를 위한 정보를 제공한다.

힌트에 대해서 설명해주세요.

힌트란 SQL 튜닝의 핵심 부분 옵티마이저의 실행계획을 조작하는 지시 구문입니다. 오라클 옵티마이저(Optimizer)에게 SQL문 실행을 위한 데이터를 스캐닝하는 경로, 조인하는 방법 등을 알려주기 위해 SQL사용자가 SQL 구문에 직접 작성하는 것을 뜻한다. 오라클이 항상 최적의 실행 경로를 만들어 내기는 불가능하기 때문에  직접 최적의 실행 경로를 작성해 주는 것입니다. 사용자가 특정 SQL 문장에서 어떤 인덱스가 선택도가 높은지 알고 있는 경우 Optimizer에 의존한 실행 계획보다 훨씬 효율적인 실행 계획을 구사할 수 있습니다.

인덱스가 잘 동작하고 있는지 어떻게 확인할 수 있을까요?

실행 계획을 통해서 실행 시간을 확인할 수 있습니다.

인덱스 사용시 주의해야할 점에 대해서 알려주세요.

너무 많은 칼럼을 인덱스로 선언할 시 MySQL기준 Insert, Update, Delete에 성능이 떨어지고 메모리를 많이 차지하게 됩니다. 또 카디널리티가 높은 컬럼을 기준으로 선언해야합니다.

GROUP BY 사용시 인덱스가 걸리는 조건에 대해 설명해주세요.

인덱스 칼럼의 순서와 같아야하고, 뒤에 있는 컬럼이 GROUP BY 절에 명시되지 않아도 사용이 가능합니다. 하지만 인덱스가 선행되는 컬럼이 먼저 선언되어 있지 않으면 인덱스를 사용할 수 없습니다.

이름, 국가, 성별이 있는 테이블에서 인덱스를 어떻게 걸어야할까요?

인덱스는 카디널리티가 높은 컬럼을 선택하는 것이 더욱 효율적입니다. 따라서 이름을 선행칼럼으로 잡고, 다음이 국가, 그 다음이 성별로 인덱스를 설정하는 것이 효과적입니다.

Week2

SQL에 대해서 설명해주세요. C언어와 같은 프로그래밍 언어와 어떤차이가 있나요?

SQL은 구조화 질의어로 관계형 데이터베이스 관리 시스템의 데이터를 관리하기 위해 설계된 언어입니다. 이는 자료 검색과 관리, 스키마 생성과 수정 등의 기능이 있고, 데이터 정의 언어인 DDL, 데이터 조작 언어인 DML, 데이터 제어 언어 DCL이 있습니다.

C나 자바와 같은 일반 프로그래밍 언어는 절차적 언어로 특징은 프로그래밍 순서대로 로직이 처리되는 것인데 반해,
SQL은 집합적 언어로 집합적 언어는 데이터를 특정 집합 단위로 분류해 이 단위별로 한 번에 처리하는 언어 입니다. 또 SQL은 어떤 DBMS를 쓰느냐에 따라서 문법이 조금씩 다릅니다.

• SQL은 데이터베이스의 데이터와 메타 데이터를 처리하고 생성하는 문법만 가지고 있어서 데이터 부속어라고 부릅니다.
• SQL은 비절차적(선언적) 언어이므로 찾는 데이터만 기술하고 처리과정을 기술할 필요가 없습니다. 하지만 C, JAVA와 같은 프로그래밍 언어는 절차적 언어이기 때문에 개발자가 처리절차를 일일이 기술해야 합니다.
• SQL은 입력과 출력이 모두 테이블이지만, 일반 프로그래밍 언어의 경우에는 모든 형태의 입출력이 가능합니다.

개발자가 작성한 SQL이 어떤 과정을 통해 실행 되는지 설명해주세요.

SQL이 문법적으로 틀리지 않았는 지 확인하는 구문분석 후 필요 없는 부분들이 제거되어 표준화된 쿼리 트리가 만들어 집니다. 그 이후 통계나 조각 정보를 바탕으로 실행 계획을 만듭니다. 컴파일을 하면 이진코드가 생성되고, 액세스 루틴으로 가서 실제 처리를 하고 결과를 돌려줍니다.

1. 구문 분석(Parsing)
   1. 해당 쿼리가 문법적으로 틀리지 않은지 확인
   2. 해당 구문을 SQL 서버가 이해할 수 있는 단위들로 분해하는 과정
   3. 구문이 부정확할 시에는 처리를 중단
      1. Batch abort: Batch중 하나라도 syntax error가 있다면 전체 batch가 실행되지 않는다.
2. 표준화(Standardization)
   1. 실제로 필요없는 부분들이 제거되어 표준화된 쿼리 트리 생성
3. 최적화(Optimization)
   1. 통계나 조각 정보를 바탕으로 실행 계획 생성.
   2. 쿼리 처리에서 매우 중요한 단계.
      1. 쿼리 분석: 검색 제한자(SARG)인지 조인 조건인지 판단

          WHERE PRICE BETWEEN 10 AND 20
          WHERE PRICE >= 10 AND PRICE <= 20
          // 1행을 실행하면 옵티마이저가 2행으로 변경
         
          WHERE NAME LIKE '%영웅'
          // 위 행은 검색 제한자가 아님.

💡 검색 제한자(Search argument)
옵티마이저가 인덱스를 선택할 수 있도록 해주는 WHERE 절의 검색조건 검색 제한자가 있더라도 선택도가 나쁘면 인덱스 사용하지 않음.

1. 1. 1. 인덱스 선택: 분포 통계 정보를 이용하여 인덱스 검색이나 테이블 스캔 중의 하나를 선택. 여러 인덱스 중 가장 효율적인 인덱스를 선택
      2. 조인처리: JOIN, UNION, GROUP By, ORDER BY 절을 가지고 있는지 확인하여 적절한 작업 순서를 선택
      3. 이 단계의 출력은 실행 계획.
2. 컴파일(Compilation)
   1. 컴파일을 하면 이진 코드가 생성됩니다. 일반적인 경우, 컴파일 이후 .exe, .dll 등의 이진 파일이 만들어지는데, SQL 서버에서는 메모리(프로시저 캐시)에만 올리기 때문에 컴파일 속도가 매우 빠릅니다.

💡 프로시저 캐시
SQL Server가 컴파일된 Query Plan이 저장되는 메모리 공간으로 Query Plan이 재사용 될 수 있도록 저장함으로써 complie하는 비용을 최소화하기 위해 사용됨.

실행(Execution)

1. 액세스 루틴으로 가서 실제 처리를 하고 결과를 돌려준다.

💡 쿼리 트리
A tree data structure that corresponds to a relational algebra expression. It represents the input relations of the query as leaf nodes of the tree, and represents the relational algebra operations as internal nodes.

DML은 무엇인가요? 어떤 구문이 있는지도 설명해주세요.

DML은 데이터 조작 언어로써, 데이터베이스에 대한 데이터 검색, 등록, 삭제, 갱신을 위한 데이터베이스 언어입니다. DML은 즉시 실행되지만 롤백문으로 취소할 수 있습니다.

데이터의 선택하는 SELECT, 테이블에 데이터를 추가하는 INSERT, 테이블의 데이터를 삭제하는 DELETE, 값을 업데이트하는 UPDATE과 같은 구문이 있습니다.

SELECT * FROM;
INSERT INTO 고객(ID, 이름, 주소) VALUES (1, 'John Smith', '123 Main St');
고객 UPDATE SET 주소 = '456 Park Ave' WHERE id = 1;
DELETE FROM WHERE id = 1;

• 선언적 데이터 조작 언어
  • 사용자가 무슨 데이터를 원하는 지만 명세하는 언어
• 절차적 데이터 조작 언어
  • 사용자가 무슨 데이터를 원하며 어떻게 접근해야하는지 명세하는 언어

DDL은 무엇인가요? 어떤 구문이 있는지도 설명해주세요.

데이터 정의 언어로써, 데이터베이스의 테이블과 인덱스 구조를 정의하는 언어입니다. DDL은 즉시 실행되고 영구적입니다. 따라서 객체가 생성, 변경 또는 삭제가 되는데에 있어 롤백을 할 수 없어 DDL을 실행 전에 DB 백업이 있는지 확인하는 것이 중요하며, 이러한 역할을 하는데 있어서 권한이 부여가 되어 있어야 합니다.

테이블을 생성하는 CREATE, 테이블의 구조 또는 컬럼을 변경하는 ALTER, RENAME, 데이터 베이스의 객체를 삭제하는 DROP, TRUNCATE과 같은 구문이 있습니다.

  CREATE TABLE 고객( id INT PRIMARY KEY, name VARCHAR(255), address VARCHAR(255));
  ALTER TABLE 고객 이메일 ADD VARCHAR(255);
  DROP TABLE 고객;
  RENAME TABLE TO 클라이언트로;

DDL과 DML의 차이.

• DDL은 데이터베이스 개체를 생성, 변경 및 삭제.
• DML은 데이터베이스의 데이터를 조작하는데 사용.

DCL은 무엇인가요? 어떤 구문이 있는지도 설명해주세요.

DCL은 데이터 제어 언어로써, 데이터베이스에서 데이터에 대한 액세스를 제어하기 위한 데이터베이스 언어입니다. 이를 통해 악의적인 사용자부터 데이터를 보안할 수 있으며 무결성 및 시스템 장애에 대한 회복을 가능하게 해줍니다. 

권한을 부여하고 박탈하는 GRANT, REVOKE과 같은 구문이 있습니다.

참조 무결성에 대해서 설명해주세요.

참조 무결성은 관계 데이터베이스 관계 모델에서 2개의 관련있던 관계 변수 간의 일관성(데이터 무결성)을 말합니다. 하나의 속성이 다른 테이블의 속성을 참조하고 있다면, 참조한 해당 속성이 존재해야 합니다.

이를 통해 기본키와 외래키 간의 관계가 항상 유효하도록 관리합니다. 기본키를 참조하는 외래키가 있다면, 해당 기본키는 수정과 삭제가 불가능합니다.

무결성

• 데이터베이스에 저장된 값들에 대하여 여러가지 제한을 통해 데이터의 신뢰를 보장하게 하여 일관성을 유지시켜주는 것.

1. 도메인 무결성
   1. 한 칼럼에 대하여 NULL 허용 여부와 타당한 데이터 값들을 지정.
   2. data type이나 규칙과 제약, 값 범위등을 제한.
   3. 예
      1. 대학생의 학년 도메인이 1, 2, 3, 4 일때 9라는 값을 가질 수 없음.
2. 참조 무결성
   1. 기본키와 참조키 간의 관계가 항상 유지됨을 보장.
   2. 참조되는 테이블의 행을 이를 참조하는 참조키가 존재하는 한 삭제될 수 없고, 기본키도 변경될 수 없음.
   3. 조건
      1. 기본 테이블에서 사용한 필드는 기본키이거나 고유 인덱스가 설정되어 있어야함.
      2. 기본 테이블과 관계 테이블 둘다 액세스 테이블이여야함.
      3. 관계를 설정하는 테이블은 형식이 같아야함.
3. 개체 무결성
   1. 테이블에 있는 모든 행들이 유일한 식별자를 가져야함.

CASCADE 설정에 대해서 설명해주세요.

참조 무결성을 지키기 위해 데이터베이스의 값을 수정 또는 삭제할 때, 해당 값을 참조하고 있는 레코드 역시 종속적으로 수정 또는 삭제를 가능하게 하는 조건입니다.

ON UPDATE CASCADE 옵션을 활용하면 기본키의 값을 수정할 수 있습니다.
ON DELETE CASCADE 옵션을 활용하면 해당 값을 참조 중인 레코드를 삭제할 수 있습니다.

제약조건

• NOT NULL
  • 속성은 기본적으로 NULL값을 가질 수 있음.
  • NOT NULL 조건을 통해 이 속성은 NULL 값을 명시적으로 제어할 수 있음. 
  • 💡 NULL은 알 수 없는 데이터를 표현.

CREATE TABLE PERSON ( 
	ID INT NOT NULL, 
    NAME VARCHAR (20) NOT NULL, 
    AGE INT NOT NULL, 
    ADDRESS CHAR (25), 
    PRIMARY KEY (ID) 
);

• DEFAULT
  • INSERT INTO 문에서 구체적인 값을 입력하지 않은 열에 기본 값을 부여.

CREATE TABLE PERSON ( 
	ID INT NOT NULL, 
    NAME VARCHAR (20) NOT NULL, 
    AGE INT NOT NULL, 
    ADDRESS CHAR (25) DEFAULT("대한민국 서울특별시 종로구"), 
    PRIMARY KEY (ID) 
);

• UNIQUE
  • 서로 다른 두 레코드의 특정한 열이 동일한 값을 가지는 것을 방지.

CREATE TABLE PERSON (
       ID       INT            NOT NULL,
       NAME     VARCHAR (20)   NOT NULL UNIQUE,
       AGE      INT            NOT NULL,
       ADDRESS  CHAR (25),
       PRIMARY KEY (ID)
);

• PRIMARY KEY
  • 테이블에 레코드를 고유하게 식별하는 테이블의 필드 값 설정.
  • 반드시 고유해야하며(UNIQUE), NULL 값을 가질 수 없음.
  • 단일 필드 외에 여러 필드가 하나의 기본키를 가질 수 있음.

CREATE TABLE PERSON (
       ID       INT            NOT NULL,
       NAME     VARCHAR (20)   NOT NULL UNIQUE,
       AGE      INT            NOT NULL,
       ADDRESS  CHAR (25),
       PRIMARY KEY (ID)
);

• FOREIGN KEY
  • 두 테이블의 관계설정을 위한 키
  • 다른 테이블의 기본키와 일치하는 값을 가지는 하나의 컬럼 혹은 여러 컬럼

CREATE TABLE PERSON (
       ID       INT            NOT NULL,
       NAME     VARCHAR (20)   NOT NULL UNIQUE,
       AGE      INT            NOT NULL,
       ADDRESS  CHAR (25),
       PRIMARY KEY (ID)
			 ALTER TABLE ORDERS
         ADD FOREIGN KEY(Customer_ID) REFERENCES CUSTOMERS(ID);
);

CREATE TABLE ORDERS(
       ID          INT         NOT NULL,
       DATE        DATETIME, 
       CUSTOMER_ID INT references CUSTOMERS(ID),
       AMOUNT      double,
       PRIMARY KEY(ID)
);

• CHECK
  • 레코드에 입력되는 값에 조건을 걸 수 있음.

CREATE TABLE PERSON (
       ID       INT            NOT NULL,
       NAME     VARCHAR (20)   NOT NULL UNIQUE,
       AGE      INT            NOT NULL CHECK(AGE >= 20),
       ADDRESS  CHAR (25),
       PRIMARY KEY (ID)
);

• INDEX
  • 데이터베이스로부터 매우 빠르게 데이터를 생성하고 검색하기 위해 사용.
  • 테이블의 단일 컬럼 또는 컬럼의 그룹을 사용함으로써 생성.
  • 데이터를 정렬하기 전에 각 행마다 ROW ID 할당.

CREATE TABLE PERSON (
       ID       INT            NOT NULL,
       NAME     VARCHAR (20)   NOT NULL UNIQUE,
       AGE      INT            NOT NULL,
       ADDRESS  CHAR (25),
       PRIMARY KEY (ID)
);
CREATE INDEX idx_age ON CUSTOMERS(AGE);

VIEW에 대해서 설명해주세요.

가상의 테이블로 정의하여 실제 테이블로 사용할 수 있도록 만든 개체입니다.
미리 정의된 뷰를 일반 테이블처럼 사용할 수 있기에 편리하고, 재사용이 가능하며 메모리를 차지하지 않습니다.
하지만 SELECT 문을 제외한 일부 물리적인 테이블의 갱신작업을 수행하는데 제약이 있습니다.

• 기본 테이블은 디스크 공간에 할당. 뷰는 데이터 딕셔너리 테이블에 뷰에 대한 정의만 저장. 디스크 저장공간 X
• 무결성 제약조건 그대로 유지.
• 기존 테이블이 삭제되면 뷰도 자동적으로 제거.
• 한번 정의한 뷰는 변경할 수 없으며 삭제한 후 다시 생성해야한다.

뷰 필요성

• 사용자에 따라 특정 객체만 조회할 수 있도록 할 필요가 있음. (모든 직원에 대한 정보를 모든 사원이 보면 안됨.)
• 복잡한 질의문을 단순화
• 데이터의 중복성을 최소화(판매부에 속한 사원들마을 사원테이블에서 찾아서 다른 테이블로 만들면 중복성이 발생.)

장단점

• 장점
  • 논리적 독립성 제공
  • 데이터 접근 제어(보안)
  • 사용자의 데이터 관리 단순화
  • 여러 사용자의 다양한 데이터 요구 지원
• 단점
  • 뷰의 정의 변경 불가
  • 삽입, 삭제, 갱신 연산에 제한

  create view <viewName> as <SQL Sentence>

   

SELECT 절의 처리순서에 대해서 설명해주세요.

FROM(+JOIN) -> WHERE -> GROUP BY -> HAVING -> SELECT -> ORDER BY -> LIMIT

1. FROM
   • 각 테이블을 확인
2. ON
   • JOIN 조건을 확인
3. JOIN
   • JOIN이 실행되어 데이터가 SET으로 모아지게 된다. 서브 쿼리도 함께 포함되어 임시 테이블로 만들 수 있게 도와줌.
4. WHERE
   • 데이터 셋을 형성하게 되면 WHERE의 조건이 개별 행에 적용된다. WHERE 절의 제약조건은 FROM 절로 가져온 테이블에 적용.
5. GROUP BY
   • WHERE의 조건 적용 후 나머지 행은 GROUP BY절에 지정된 열의 공통 값을 기준으로 그룹화.
   • 쿼리에 집계 기능이 있는 경우에만 이 기능을 사용.
6. HAVING
   • GROUP BY 절이 쿼리에 있을 경우 HAVING 절의 제약조건이 그룹화된 행에 적용.
7. SELECT
   • SELECT에 표현된 식이 마지막으로 적용.
8. DISTINCT
   • 표현된 행에서 중복된 행은 삭제
9. ORDER BY
   • 지정된 테이블을 기준으로 오름차순, 내림차순 정렬
10. LIMIT
    • LIMIT에서 벗어난 행들은 제외되어 출력

SELECT ~ FOR UPDATE 구문에 대해서 설명해주세요.

동시성 제어를 위하여 특정 데이터에 대해 배타적 LOCK을 거는 기능으로써
가장 먼저 LOCK을 획득한 세션의 SELECT된 ROW들이 UPDATE 쿼리 후 커밋되기 이전까지 다른 세션들은 해당 ROW들을 수정하지 못하도록 하는 기능입니다.

• SELECT ~ FOR UPDATE : 누군가가 LOCK 중이면 무한정 대기.
• SELECT ~ FOR UPDATE NOWAIT : 누군가가 LOCK 중이면 exception 처리.
• SELECT ~ FOR UPDATE WAIT 5(초) : 누군가가 LOCK 중이면 입력한 시간(초단위)만큼 Lock을 재시도. 이후에 exception 처리

SELECT <attribute> FROM <TableName> WHERE <where clause> FOR UPDATE;
SELECT <attribute> FROM <TableName> WHERE <where clause> FOR UPDATE NOWAIT;
SELECT <attribute> FROM <TableName> WHERE <where clause> FOR UPDATE WAIT 5;

GROUP BY절에 대해서 설명해주세요.

속성에 대해 같은 값을 가진 행끼리 그룹화하는 명령어 입니다. GROUP BY 절을 사용하면 집계함수를 사용할 수 있으며 묶은 그룹에 대해 SELECT할 수 있는 속성이 제한이 되어 있습니다.

집합 연산자는 COUNT, SUM, AVG, MAX, MIN 등이 있고 DISTINCT와 같이 중복 데이터를 제거하는 특징이 있습니다.

  SELECT <attribute> FROM <TABLE> GROUP BY <attribute>;
  SELECT <attribute> FROM <TABLE> WHERE <WHERE caluse> GROUP BY <attribute>;
  SELECT <attribute> FROM <TABLE> GROUP BY <attribute> HAVING <HAVING caluse>;

ORDER BY절에 대해서 설명해주세요.

SQL문의 실행 결과를 특정 순서대로 출력하고 싶을 때 사용하는 명령어입니다.
기본적으로 오름차순이고, 내림차순으로 정렬하려면 DESC 키워드를 사용하면 됩니다.

innodb는 모든 데이터는 pk(클러스터링 키)기반으로 비트리 형태로 저장한다.

• secondary index는 어떤식으로 데이터를 저장하나여
  • 이게 innodb는 secondary index가 clustering 인덱스를 포함하는 요상한구조를 가지고 있음
  • 끝까지 찾아갔는데? 결국 clustering index 알려줌
  • 그래서 항상 clustering index btree를 다시 뒤져야됨
• non-clustering index와 clustering index의 차이는 무엇인가

풀 테이블 스캔

• 인덱스를 사용하지 않고 테이블의 데이터를 처음부터 끝까지 읽어서 요청된 작업을 처리하는 작업.

Using filesort

정렬을 처리하기위해 file sort

Sort Buffer

• 정렬을 수행하기 위해 별도의 메모리 공간을 할당받아서 사용. 이 메모리 공간의 이름이 Sort Buffer

정렬 알고리즘

• 레코드를 정렬할 때, 레코드 전체를 소트 버퍼에 담을지 또는 정렬 기준 칼럼만 소트 버퍼에 담을지
• 싱글패스 알고리즘
  • 소트 버퍼에 정렬 기준 칼럼을 포함해 SELECT되는 칼럼 전부를 담아서 정렬을 수행하는 방법.
  • 정렬이 완료되면 버퍼의 내용을 그대로 클라이언트로 넘겨준다.
• 투패스 알고리즘
  • 정렬 대상 칼럼과 PK 값만을 소트 버퍼에 담아서 정렬을 수행.
  • 정렬된 순서대로 PK로 테이블을 읽어서 SELECT 할 칼럼을 가져오는 알고리즘.

• innodb는 PK가 없는 경우 행 ID에 의해 정렬된 행은 물리적으로 삽입된 순서대로 정렬됩니다.

INNER JOIN과 OUTER JOIN의 차이점에 대해서 설명해주세요.

INNER JOIN은 데이터간의 교집합으로 연관된 두 내용의 데이터를 검색하는 조인 방법입니다.두 테이블을 조인할 때, 두 테이블에 모두 지정한 열의 데이터가 있어야합니다.
반면 OUTER JOIN은 두 테이블을 조인할 때, 1개의 테이블에만 데이터가 있어도 결과가 나옵니다. 외부 조인은 반드시 OUTER가 되는 테이블을 먼저 읽어야하기 때문에 조인 순서를 옵티마이저가 선택할 수 있습니다.

INNER JOIN

• nested-loop만 지원

💡 NESTED LOOP 2개 이상의 테이블에서 하나의 집합을 기준으로
순차적으로 상대방 row를 결합하여 원하는 결과를 조합하는 조인방식.

OUTER JOIN

• 일치하는 레코드가 있으면 INNER 조인과 같은 결과. 없으면 NULL로 채워서 결과 가져오기.

LEFT OUTER JOIN, RIGHT OUTER JOIN에 대해서 설명해주세요.

왼쪽 테이블을 기준으로 모든 값이 출력되면서 JOIN 조건에 해당하는 오른쪽 테이블의 값을 선택하는 것이 LEFT OUTER JOIN이고
오른쪽 테이블을 기준으로 모든 값이 출력되면서 JOIN 조건에 해당하는 왼쪽 테이블의 값을 선택하는 것이 RIGHT OUTER JOIN입니다.

Driving VS Drivien

• Join할 때 먼저 Access되어 Access Path를 주도하는 테이블을 Driving table이라고 하고 나중에 access 되는 테이블을 driven table. Driving table은 옵티마이저가 선택

CROSS JOIN에 대해서도 설명해주세요.

수학적으로 카타시안 곱이라고 하는 CROSS JOIN은 brute force하게 두 테이블의 모든 데이터를 조인하는 방법입니다.
다른 테이블에 없는 값을 가져올 시 NULL로 데이터를 채워서 가져옵니다. FULL OUTER JOIN이라고도 불립니다.

서브쿼리에 대해서 설명해주세요.

하나의 SQL문에 포함되어 있는 또 다른 SQL 문으로 단일 행 또는 복수 행 비교연산자와 함께 사용이 가능합니다.
SELECT, FROM, WHERE 절 등 다양한 곳에서 사용이 가능합니다.

단일행 서브쿼리

• 서브 쿼리가 단일 행 비교 연산자(=, <, ≤, ≥, >)와 함께 사용할 때는 서브 쿼리 결과가 1건 이하여야 함.
• 결과가 2건 이상이면 오류 발생

SELECT C1, C2, C3
FROM T1
WHERE C1 <= (SELECT AVG(C1) FROM T2 WHERE C2 = '3')
ORDER BY C1, C2, C3

다중행 서브쿼리

• 서브 쿼리의 결과가 2건 이상 반환될 수 있다면 반드시 다중행 비교 연산자(IN, ALL, ANY, EXISTS)과 함께 사용.
• IN : 서브쿼리의 결과에 존재하는 임의의 값과 동일한 조건을 의미.
• ALL : 서브쿼리의 결과에 존재하는 모든 값을 만족하는 조건을 의미.
• ANY(SOME) : 서브쿼리의 결과에 존재하는 어느 하나의 값이라도 만족하는 조건을 의미.
• EXISTS : 서브쿼리의 결과에 만족하는 값이 존재하는 지 여부 확인

SELECT C1, C2, C3
FROM T1
WHERE (C1, C2) IN (SELECT C1, C2 FROM T2 WHERE C2 = '3')
ORDER BY C1, C2, C3;

위치에 따른 서브쿼리 명

• SELECT
  • 스칼라 서브 쿼리
  • 한행, 한 컬럼만을 반환
• FROM
  • 인라인 뷰
  • 데이터 베이스의 동적인 뷰이기에 메모리에 저장 X

DROP, TRUNCATE, DELETE에 각각에 대해 설명해주세요. 어떤차이가 있나요?

DROP은 테이블을 완전히 삭제하는 방식으로 삭제 후 되돌릴 수 없습니다. 
TRUNCATE는 전체 데이터를 한번에 삭제하는 방식으로 테이블 용량이 줄어들고 인덱스도 삭제되지만 테이블은 삭제할 수 없고 삭제 후 되돌릴 수 없습니다.
DELTETE는 데이터는 지우지만 테이블 용량은 줄어들지 않고 원하는 데이터만 지울 수 있고, 삭제 후 되돌릴 수 있습니다.

DROP

• 기존 테이블의 존재를 제거합니다.
• ROLLBACK이 불가능합니다.
• 테이블의 행, 인덱스 및 권한도 제거됩니다.

TRUNCATE

• 개별적으로 행을 삭제할 수 없으며, 테이블 내부의 모든 행을 삭제합니다.
• WHERE 절을 함께 사용할 수 없습니다.(개별적으로 행 삭제가 불가능합니다.)
• ROLLBACK이 불가능.
• 로그 X ⇒ 작업이 빠름
• 테이블의 데이터베이스 할당 해제를 기록

DELETE

• 테이블의 내부의 행을 모두 삭제하며, WHERE 절을 사용하여 개별적으로 행을 삭제할 수 있습니다.
• ROLLBACK 가능.
• 로그되는 작업. ⇒ 각 행은 트랜잭션 로그에 기록되므로 작업이 느림.

DISTINCT에 대해서 설명해주세요. 사용해본 경험도 설명해주세요.

데이터 베이스의 중복을 제외하고 조회하는 명령어 입니다.내부적으로 GROUP BY와 동일한 코드를 사용하지만
DISTINCT는 GROUPING 작업만, GROUP BY는 GROUPING과 정렬 작업도 동시에 진행하기에 DISTINCT가 더욱 빠릅니다.

• 정렬이 보장되지 않음.
• 각 칼럼에 유니크한 값을 가져오지 못함. ⇒ 이를 위해선 GROUP BY 이후 DISTINCT 시도.
• DISTINCT 키워드는 시간이 많이 드는 키워드. ⇒ exists를 통해서

SQL Injection 공격이 무엇인지 어떻게 공격을 예방할 수 있는지 설명해주세요.

악의적인 사용자가 보안상의 취약점을 이용하여 임의의 SQL문을 주입하고 실행되게 하여 데이터베이스가 비정상적으로 동작하도록 조작하는 행위를 일컫습니다.
이를 예방하기 위해서는 예외처리를 통한 검증을 하는 파라미터 바인딩과 저장 프로시저를 사용하는 방법이 있습니다.

공격 종류 및 방법

• Error based SQL Injection
  • 입력 값에 대한 검증이 없음을 확인하고 임의의 SQL 구문을 주입.
• Union based SQL Injection
  • 두개의 쿼리문에 대한 결과를 통합해서 하나의 테이블로 보여주게하는 키워드.
  • 두 테이블의 컬럼 수가 같아야하며 데이터형이 같아야함.
• Blind SQL Injection
  • 데이터베이스로부터 특정한 값이나 데이터를 전달받지 않고, 단순히 참과 거짓의 정보만 알 수 있을 때 사용.

예방

1. 입력값을 검증하여 사용자의 입력이 쿼리에 동적으로 영향을 주는 경우 입력된 값이 개발자가 의도한 값인지 검증 ⇒ 파라미터 바인딩.
2. 저장 프로시저를 사용.

💡저장 프로시저
사용하고자 하는 쿼리에 미리 형식을 지정하는 것. 지정된 형식의 데이터가 아니면 Query가 실행되지 않기에 보안성이 향상

알고 있는 SQL 안티패턴이 있다면 설명해주세요.

SQL 쿼리나 데이터베이스 설계에서 흔히 발생하는 잘못된 패턴을 말합니다.
SQL 안티 패턴은 성능 저하, 데이터 무결성 손상, 보안 취약점 등의 문제를 야기할 수 있습니다.
따라서 SQL 안티 패턴을 인식하고 피하는 것이 중요합니다.

예시

1. SELECT * FROM
   1. 모든 컬럼을 조회하는 쿼리.
   2. 테이블의 구조가 변경되거나 컬럼이 추가되면 예상치 못한 결과를 가져다 줌
   3. 필요하지 않은 컬럼까지 조회하므로 네트워크 부하 및 메모리 사용량 증가
   4. 해결책
      1. 명시적으로 필요한 컬럼만 조회하도록 설계
2. 문자열 연결로 동적 쿼리 생성
   1. SQL injection 공격에 취약.
   2. 해결책
      1. 파라미터화된 쿼리나 저장 프로시저 사용

      name = request.getParameter("name");
      sql = "SELECT * FROM users WHERE name = '" + name + "'"; -- 안티 패턴
      stmt = conn.createStatement();
      rs = stmt.executeQuery(sql);
      
      name = request.getParameter("name");
      sql = "SELECT * FROM users WHERE name = ?"; -- 권장
      pstmt = conn.prepareStatement(sql);
      pstmt.setString(1, name);
      rs = pstmt.executeQuery();

3. 잘못된 데이터 타입 사용
   1. 데이터 타입은 데이터의 종류와 크기를 정의
   2. 데이터 타입을 잘못 사용하면 데이터의 정확성과 효율성이 떨어짐.
   3. 날짜나 시간을 문자열로 사용. ⇒ 관련 함수 사용 X
   4. 해결책
      1. 데이터의 성격과 범위에 맞는 데이터 타입을 사용.
4. 다중 칼럼 속성
   1. 하나의 엔터티에 여러개의 칼럼으로 만들어 대응
      1. 검색: 원하는 정보가 어디에 있는 지 모두 확인해야함
      2. 수정: 어떤 칼럼을 수정해야할 지 확인하고 수정해야함.
      3. 일관성: 여러 칼럼에 중복되는 값이 저장되는 것을 예방하기 어려움
      4. 테이블 잠금: 칼럼 하나의 값을 수정하기 위해 테이블 전체가 잠금이 설정될 수 있음
   2. 해결책
      1. 종속 테이블을 생성해 사용.

-- 안티 패턴
CREATE TABLE member (
id INT PRIMARY KEY,
name VARCHAR(10),
hobby1 VARCHAR(10), // 취미1
hobby2 VARCHAR(10), // 취미2
hobby3 VARCHAR(10), // 취미3
);CREATE TABLE hobby (
hobby_id INT PRIMARY KEY,
name VARCHAR(10)
);
-- 권장
CREATE TABLE member (
member_id INT PRIMARY KEY,
name VARCHAR(10),
hobby_id INT FOREIGN KEY REFERENCES hobby(hobby_id)
);

1. 한개의 칼럼에 컴마를 넣으면 안된다
   1. 검색하기 어렵고, 문자열 칼럼의 문자 수 제한이라는 제약.
   2. validation이 어려움
   3. 해결책
      1. 교차 테이블을 생성.
2. 트리 형태의 계층 구조를 1개의 테이블로 표현하면 안된다.
   1. 계층 구조가 깊어지면 SQL이 복잡해지고 노드 조회 및 삭제가 어려워짐.
   2. 해결책
      1. 대체 트리 모델을 사용.
3. 모든 테이블에 id를 만드는 것이 필요 없다.
   1. 장황해 질 가능성.
   2. id가 PK가 아니기에 헷갈릴 가능성.
   3. 해결책
      1. PK는 명확한 이름을 붙힌다.
      2. 복합키를 사용한다.
4. FK 제약을 사용하지 않는 패턴은 좋지 않음.
   1. 참조 무결성을 재구현해야함.
   2. 데이터의 손상시 문제 발생
   3. 해결책
      1. 외부키를 사용해야한다.
5. 테이블이나 열을 복사하거나 데이터에 의존하여 테이블을 작성하면 안됨.
   1. 열의 수가 많은 테이블을 생성하거나 적은 수의 테이블을 생성해야함.
   2. 테이블 간의 정합성을 얻기 어렵다
   3. 해결책
      1. 행으로 분리하는 수평 파티셔닝을 사용한다.
      2. 열로 분리하는 수직 파티셔닝을 사용한다.
6. 이미지와 같은 대용량 파일을 저장할 때 링크만을 데이터베이스에 저장하는 것은 좋지 않다.
   1. 레코드가 삭제된다고 해도 실제 파일까지 삭제의 보장성이 없다.
   2. 롤백으로 되돌아오지 않는다.
   3. 외부 파일은 SQL의 액세스 권한 영향을 받지 않는다.
   4. 해결책
      1. BLOB형을 고려한다.
7. 인덱스를 잘못 설정하는 것.
   1. 인덱스를 사용하지 않는다.
   2. 인덱스를 붙인다.
   3. ⇒ 퍼포먼스가 안좋아짐
8. LIKE나 정규 표현을 이용한 패턴 매치는 안티패턴이다.
   1. 인덱스의 효과가 없어지고 테이블 스캔이된다.
   2. 해결책
      1. 전문 검색 엔진 혹은 elasticSearch를 활용한다
9. 패스워드를 평문으로 저장하는 것은 안티패턴이다
   1. 보안상의 위험이 있다.
   2. 해결책
      1. 해시하여 저장한다.
      2. 패스워드는 복구가 아닌 리셋을 한다.
   등등..

페이지네이션을 구현한다고 했을때 쿼리를 어떻게 작성해야할까요?

LIMIT와 OFFSET 키워드를 사용합니다.
LIMIT는 가져올 레코드의 수를 지정하고, OFFSET은 시작점을 지정합니다.

예시

// 첫페이지
SELECT * 
FROM posts 
LIMIT 10 OFFSET 0;
// 두번째 페이지
SELECT * 
FROM posts 
LIMIT 10 OFFSET 10;

문제점

• 성능이 안좋아짐.
• MySQL 기준 처음부터 해당 위치까지의 모든 레코드를 읽어오기에 느려짐.
• 또 페이지를 읽던 중 새로운 행이 추가된다면 데이터가 중복 조회됨.

WHERE 절과 인덱스를 사용하는 방법

• id에 인덱스가 걸려있다고 가정하고

// 첫번째 페이지
SELECT * 
FROM posts 
WHERE id <= 10 
ORDER BY id DESC;
// 두번째 페이지
SELECT * 
FROM posts 
WHERE id > 10 and id <= 20 
ORDER BY id DESC;

Week1

파일시스템과 데이터베이스의 차이점에 대해서 설명해주세요.

파일 시스템은 파일을 저장하고 관리하는 간단한 방법으로 기본적인 데이터 저장 및 검색에 적합합니다.
하지만 이는 같은 내용의 데이터가 여러 파일에 중복 저장이 되므로 데이터의 일관성과 무결성에 문제가 있습니다.

반면, 데이터베이스는 구조화된 데이터를 관리하기 시스템으로 고급 질의, 동시성 제어 및 데이터 무결성 시행을 가능하게 합니다.

데이터베이스의 특징에 대해 설명해주세요.

데이터베이스는 사용자의 요구에 따라 실시간으로 응답할 수 있고, 데이터가 계속 변화하지만 데이터의 원자성이 보장됩니다.
또 여러 사용자가 동시에 이용할 수 있으며 프로그래밍 언어에서의 메모리 주소 값으로 접근하는 것이 아닌 값으로 참조할 수 있습니다.

• 실시간 접근(real-time accessibility)
  • 데이터베이스는 사용자의 데이터 요구에 실시간으로 응답할 수 있어야 함.
  • 사용자의 특성이나 서비스 유형에 따라 응답시간이 다를지라도, 대게 몇초 이내에 데이터를 제공해야한다.
• 계속 변화(continuous evolution)
  •  현실 세계의 상태를 정확히 반영.
  • 현실 세계의 데이터가 계속 변화하므로 데이터베이스의 데이터 역시 삽입, 삭제, 수정을 하여 데이터를 정확하게 유지해야 한다.
• 동시 공유(concurrent sharing)
  • 여러 사용자가 동시에 이용할 수 있는 동시 공유 특징을 제공.
  • 여러 사용자가 다른 데이터를 동시에 사용하는 것뿐만 아니라 같은 데이터를 사용하는 것까지 포함. 
    ⇒ 이 부분이 어려워 더욱 까다로운 처리가 필요.
• 내용 참조(Content reference)
  • 데이터베이스는 저장된 주소로 검색하는 것이 아닌, 값으로 참조할 수 있다.
  • 조건에 맞을 시 대부분 검색이 가능하다.

DBMS는 뭘까요? 특징에 대해 설명해주세요.

통합 저장된 데이터를 관리하고 모든 응용 프로그램이 공통으로 요구하는 데이터에 대한 기본 처리를 담당하면서
동시 공유, 보안, 회복 등의 기능을 제공해주는 시스템을 말합니다.

이를 통해서 파일 시스템의 데이터 중복과 데이터 종속 문제를 해결할 수 있습니다.
또 응용 프로그램을 대신하여 데이터베이스의 데이터를 삽입, 삭제, 수정, 검색 및 공유가 가능합니다.

• 응용프로그램이 동시에 데이터베이스를 사용할 때 발생하는 문제점 해결
  • 데이터 중복 X
    • PK값을 어떻게 설정하느냐 또는 효율성 측면에 따라 데이터 중복이 발생가능
  • 데이터 중복을 제어
  • 데이터 일관성
• 사용하기 쉬운 인터페이스를 제공하므로 데이터 처리 요구가 쉬움

스키마가 뭘까요? 3단계 데이터베이스 구조에 대해 설명해주세요.

데이터베이스에 저장되는 데이터 구조와 제약조건을 정의한 것입니다.

데이터베이스는
개별 사용자 관점에서 외부 스키마
조직 관점에서의 개념 스키마
물리적인 저장 장치의 관점에서 내부 스키마로 나누어져 있습니다.

• 외부 단계
  • 개별 사용자 관점. 데이터베이스를 이해하고 표현
  • 각 사용자마다 원하는 데이터가 다른 것.
    이처럼 외부 단계에서 사용자에게 필요한 데이터베이스를 정의한 것을 외부 스키마
  • 여러개의 외부 스키마가 존재할 수 있음.
• 개념 단계
  • 데이터베이스를 이용하는 사용자들의 관점. 데이터베이스를 조직 전체의 관점에서 이해하고 표현.
  • 모든 사용자에게 필요한 데이터를 통합하여 전체 데이터베이스의 논리적 구조를 정의 → 개념 스키마
  • 개념 스키마
    • 조직 전체의 관점에서 생각하는 데이터베이스
    • 전체 데이터베이스에 어떤 데이터가 저장되는지, 데이터들 간에는 어떤 관계가 존재하고
      어떤 제약조건이 있는 지에 대한 정의
      데이터에 대한 보안 정책이나 접근 권한에 대한 정의도 포함.
    • 데이터베이스 하나당 개념 스키마 하나.
• 내부 단계
  • 데이터베이스를 디스크나 테이프 같은 저장장치의 관점에서 이해하고 표현.
  • 전체 데이터베이스가 저장 장치에 실제로 저장되는 방법 정의 → 내부 스키마
  • 내부스키마
    • 데이터베이스는 저장 장치에 파일 형태로 저장.
    • 파일에 데이터를 저장하는 레코드의 구조, 레코드를 구성하는 필드 크기, 인덱스를 이용한 레코드 접근 경로 등을 지정.
    • 하나의 데이터베이스 당 하나의 내부 스키마.

데이터 독립성에 대해서 설명해주세요.

데이터베이스를 생성하고 접근하며 관리하는 일은 전부 데이터베이스 관리 시스템이 담당합니다.

데이터베이스의 구조와 데이터의 내용이 서로 영향을 미치지 않는 특성을 데이터 독립성이라고합니다.

• 논리적 데이터 독립성
  • 개념 스키마가 변경되더라도 외부 스키마가 영향 받지 않는 것.
  • 논리적인 데이터 구조가 변하더라도 외부/개념 사상 정보만 적절히 수정하면 직접 관련이 없는 외부 스키마는 변경할 필요가 없음.
• 물리적 데이터 독립성
  • 내부 스키마가 변경되더라도 개념 스키마가 영향을 받지 않는 것. ⇒ 외부 스키마까지 영향을 받지 않음.

RDBMS(관계형 데이터베이스 관리시스템)는 뭘까요?

RDBMS(Rational Database Management System)는 관계형 모델을 이용하여 데이터를 관리하고 정리하는 소프트웨어 시스템으로, 데이터를 행(레코드)과 열(속성)로 구조화된 테이블(관계)에 저장하고, 데이터 무결성을 강제하며, 테이블 간의 관계를 정의할 수 있도록 합니다.

RDBMS는 데이터 검색 및 조작을 위해 SQL을 사용하고, ACID 속성을 통해 데이터 일관성을 보장하며, 성능 최적화를 위한 인덱싱을 제공하며, 동시성 제어 및 데이터 보안을 지원합니다. 구조화된 데이터를 효율적으로 관리하기 위해 다양한 응용 분야 및 산업 분야에서 널리 사용되고 있어 데이터 저장 및 검색을 위한 기본 도구로 자리 잡고 있습니다.

트랜잭션의 특성(ACID)

1. 원자성(Atomicity) 작업이 모두 반영되던지 아니면 전혀 반영되지 않아야 한다.
2. 일관성(Consistency) 트랜잭션 실행 전 DB 내용이 잘못되지 않으면 실행 후도 잘못되지 않아야 한다.
3. 고립성(Isolation) 둘 이상의 트랜잭션이 동시에 실행될 경우 서로의 연산에 끼어들 수 없다.
   1. 고립 레벨에 따라 하나의 데이터에 여러 트랜잭션이 발생할 수 있다.
4. 고립성(Isolation) 트랜잭션 실행도중 다른 트랜잭션의 영향을 받아 잘못된 결과를 만들어서는 안된다.
5. 영속성(Durability) 완료된 결과는 영구적으로 반영되어야 한다.

릴레이션 스키마와 릴레이션 인스턴스에 대해서 설명해주세요.

릴레이션 스키마는 릴레이션을 정의하기 위한 튜플 구조와 제약조건을 명세한 것이고
릴레이션 인스턴스는 실제 데이터가 존재하는 릴레이션을 의미합니다.

릴레이션 스키마: 부모 및 자식 테이블, 외부 키 및 기본 키를 포함하여 관계형 데이터베이스의 테이블이 연결되는 방법을 설명합니다.

릴레이션 인스턴스(Relationship Instance): 라이브러리 데이터베이스에서 대출자가 체크아웃한 특정 책과 같이 부모 테이블과 자식 테이블의 레코드 간의 실제 데이터 연결을 나타냅니다.

릴레이션의 차수와 카디널리티에 대해 설명해주세요.

한 릴레이션에 들어 있는 애트리뷰트의 수를 차수라고 합니다. 따라서 유효한 릴레이션의 최소 차수는 1입니다.

카디널리티는 릴레이션 튜플의 갯수이다. 릴레이션의 경우 카디널리티가 0일 수 있으며 시간이 지남에 따라 카디널리티는 계속해서 변화합니다.

중복도가 ‘낮으면’ 카디널리티가 ‘높다’고 표현한다. 중복도가 ‘높으면’ 카디널리티가 ‘낮다’고 표현한다.
카디널리티는 전체 행에 대한 특정 컬럼의 중복 수치를 나타내는 지표 ⇒ 인덱싱은 카디널리티가 높은 곳에 적용해야함

키(Key)에 대해서 설명해주세요. (슈퍼키, 후보키, 기본키, 대리키, 외래키)

릴레이션에서 모든 튜플들을 유일하게 구분하는데 사용되는 요소들을 슈퍼키라고 합니다.

슈퍼키의 부분집합이 슈퍼키가 아닌 최소한의 슈퍼키를 후보키라 합니다. 이는 유일성과 최소성을 동시에 만족해야합니다.

후보키 중 하나를 기본키로 설정하고 테이블 당 기본키는 하나여야 하며 NULL 값을 가질 수 없으며 중복값도 가질 수 없습니다.

후보키가 두개 이상인 경우 기본키가 아닌 나머지 후보키를 대리키라고 합니다.

다른 릴레이션에 관계가 있는 속성을 외래키라고 합니다. 여기서 참조될 데이터는 기본키로 설정되어 있어야하며, 값이 있어야 합니다.

• 슈퍼키
  • 테이블에서 각 행을 유일하게 식별할 수 있는 하나 또는 그 이상의 속성들의 집합
  • 유일성이란 하나의 키로 특정 행을 바로 찾아낼 수 있는 고유한 데이터 속성
  • 어떤 속성끼리 묶던 슈퍼키는 유일성만 만족하면 슈퍼키가 됨.
• 후보키
  • 테이블에서 각 행을 유일하게 식별할 수 있는 최소한의 속성들의 집합
  • 유일성과 최소성 동시에 만족
• 기본키
  • 후보키들 중에서 하나를 선택한 키로, 최소성과 유일성을 만족하는 속성
  • 테이블에서 기본키는 오로지 한개
  • 기본키는 테이블 안에서 유일하게 각 행을 구별할 수 있도록.
  • NULL이 아니며 중복된 값을 가질 수 없다.
• 대체키(대리키)
  • 기본키가 아닌 후보키
• 외래키
  • 테이블이 다른 테이블의 데이터를 참조하여 테이블간의 관계를 연결하는 것
  • 다른 테이블의 데이터를 참조할 때 없는 값을 참조할 수 없도록 제약
  • 참조될 테이블이 먼저 만들어지고 참조하는 테이블에 값이 입력되어야함.
  • 참조될 값은 참조될 테이블에서 기본키로 설정
  • 부모 테이블 먼저 삭제될 수 없음. ⇒ 외래키 오류
  • 제약조건
    • cascade
      • 부모 테이블의 컬럼이 변경 또는 삭제될 경우, 외래키로 참조하는 컬의 값도 변경/삭제
    • restrict
      • 부모 테이블의 컬럼이 변경/삭제될 때 그 컬럼을 변경/삭제할 칼럼을 참조하고 있는 경우 변경/삭제가 취소
    • NO ACTION
      • 부모 테이블의 컬럼이 변경/삭제될 때 변경/삭제할 개체만 변경/삭제되고 참조하고 있는 개체는 변동 X
    • SET NULL
      • 부모 테이블의 컬럼이 변경/삭제될 때 다른 개체가 변경/삭제할 개체를 참조하고 있을 경우 참조하고 있는 값 NULL로 세팅

무결성 제약조건에 대해서 설명해주세요. (도메인 무결성, 개체 무결성, 참조 무결성)

무결성 제약조건은 데이터베이스의 정확성, 일관성을 보장하기 위해 저장, 삭제, 수정등을 제약하기 위한 조건을 말합니다.

개체 무결성은 각 릴레이션의 기본키를 구성하는 속성은 NULL값이나 중복된 값을 가질 수 없습니다.
참조 무결성은 외래키 값은 NULL이거나 참조하는 릴레이션의 키본키 값과 동일해야합니다. ⇒ 즉 릴레이션은 참조할 수 없는 외래키의 값을 가지지 않습니다.
도메인 무결성은 속성들의 값은 정의된 도메인에 속한 값이어야 합니다.
고유 무결성은 특정 속성에 대해 고유한 값을 가지도록 조건이 주어진 경우, 릴레이션의 각 튜플이 가지는 속성 값들은 서로 달라야합니다.
NULL 무결성은 릴레이션의 특정 속성 값은 NULL이 될 수 없으며
키 무결성은 최소한 한개 이상의 키가 존재해야합니다.

사용했던 데이터베이스에 대해서 설명해주세요. (오라클DB, MySQL, MariaDB, MongoDB 등)

(MySQL을 사용했다면) MySQL 엔진에 대해서 설명해주세요.

MySQL 서버는 MySQL 엔진과 스토리지 엔진으로 나뉘어집니다.

MySQL 엔진은 클라이언트로부터 오는 요청 처리(SQL 분석 및 최적화)를 담당하고
스토리지 엔진은 실제 데이터를 디스크 스토리지에 저장하거나 조회하는 부분을 담당합니다. 

MySQL 엔진

• Connection Handler : 커넥션 및 쿼리 요청을 처리 담당
• SQL 인터페이스 : DML, DDL, Procedure, View 등 SQL 인터페이스 제공 담당
• SQL 파서(parser) : SQL문법 오류 탐지 및 SQL 쿼리 문장을 MySQL이 처리하기 좋은 토큰 단위로 나눠서 트리 형태로 파싱 하는 작업 담당
• SQL 옵티마이저(optimizer) : 쿼리의 최적화된 실행 담당
• 캐시와 버퍼 : 성능 향상을 위한 보조 저장소 기능 담당

스토리지 엔진

• MySQL 엔진과 플러그인 형태로 연동/분리 가능하고 핸들러 API(핸들러 요청)를 통해 스토리지 엔진에 읽기/쓰기 요청이 가능

MySQL 스레드 구조

MySQL thread = foreground thread + background thread

• 포그라운드 스레드
  • 클라이언트/사용자가 요청한 쿼리 문장을 처리하는 스레드(고객 창구 역할)
  • 데이터 조회 스레드(데이터 버퍼나 캐시 또는 직접 디스크나 인덱스 파일로 접근하여 데이터를 가져오는 스레드)
• 백그라운드 스레드
  • Insert buffer를 병합하는 스레드
  • 로그 기록 스레드
  • InnoDB 버퍼 풀의 데이터를 디스크로 기록(Write)하는 스레드
  • 데이터를 버퍼로 읽어들이는 스레드
  • 잠금, 데드락을 모니터링하는 스레드
  • 모든 백그라운드 스레드를 관리하는 메인 스레드
• 포그라운드 스레드는 'thread_cache_size' 설정 값에 따라 일정 스레드 개수로 유지

(MySQL을 사용했다면) InnoDB에 대해 설명해주세요.

MySQL의 엔진 중 레코드 기반의 Lock을 제공하며 높은 동시성 처리가 가능하고 안정적인 스토리지 엔진입니다.

특징으로는 primary key 순서대로 디스크에 저장되므로 range scan이 굉장히 빠르며 다른 보조 인덱스에 비해 pk가 선택될 확률이 높습니다.

구조

• 메모리 영역
  • InnoDB 버퍼 풀 : 실제 데이터 블록(페이지)을 메모리에 적재하는 영역 + 인서트 버퍼 + 언두 레코드
  • 로그 버퍼 : 로그 스레드에 의해 로그 파일로 기록되기 전 버퍼링 하는 영역
• 디스크 영역
  • 시스템 테이블 스페이스
  • 사용자 테이블 스페이스
  • 리두(Redo) 로그

InnoDB 스토리지 엔진의 특징

• 테이블은 Primary Key 순서대로 디스크에 저장되며 그렇기 때문에 Range scan이 굉장히 빠르다
• 실행계획 결정에서 다른 보조 인덱스에 비해 Primary Key가 선택될 확률이 높다.
• MVCC를 이용하여 락을 걸지 않고 읽기 수행
• 외래 키 지원
  • 외래 키는 부모 테이블과 자식 테이블 모두 해당 컬럼에 대한 인덱스 생성이 필요하고 변경 시에는 반드시 부모 테이블과 자식 테이블의 데이터가 있는지 체크하는 작업이 필요하므로 잠금(Lock)이 전파되는 특징이 있다. Lock이 여러 곳에 전파되면서 데드락 발생을 시킬 수 있기 때문에 실무에서 제약을 걸지 않는 경우가 많다.
• 자동 데드락 감지 : 감지 시 변경된 레코드가 가장 작은 트랜잭션을 롤백해버려서 데드락을 풀어준다.
• 자동 장애 복구 : 완료하지 못한 트랜잭션이나 일부만 기록되어 손상된 데이터 페이지 등을 자동 복구한다.