Database Summary
1. 키(key)
1) 슈퍼키 (Super Key)
- 유일성은 만족하지만, 최소성은 만족하지 못하는 키
2) 후보키 (Candidate Key)
- 튜플을 유일하게 식별하기 위해 사용되는 속성들의 부분집합.
- 이 후보키 중에서 기본키로 선택하여 사용한다.
- 조건 :
1) 유일성 : key로 하나의 tuple을 유일하게 식별 가능해야함
2) 최소성 : 꼭 필요한 속성으로만 구성
3) 기본키 (Primary Key)
- 후보키 중 선택한 main key
- 중복값을 가질 수 없으며 null도 가질 수 없음
4) 대체키
- 기본키를 대체할 나머지 후보키들의 모음
5) 외래키 (Foriegn Key)
- 다른 릴레이션의 기본키를 그대로 참조하는 속성의 집합
* 데이터 무결성
- 데이터의 무결성은 데이터의 정확성, 일관성, 유효성이 유지되는 것을 말한다.
- 정확성은 중복이나 누락이 없는 상태이다.
- 일관성은 원인과 결과의 의미가 연속적으로 보장되어 변하지 않는 상태이다.
- 유효성은 사용자로부터 정확한 값만 입력되도록 하는것을 말한다.
- 데이터의 무결성을 유지하는 것은 데이터베이스 관리시스템 (DBMS)의 중요한 기능이며, 주로 데이터에 적용되는 연산에 제한을 두어 데이터의 무결성을 유지한다.
- 1) 개체 무결성
- 기본 키로 선택된 필드는 고유한 값을 가져야 하며, null 값은 허용하지 않는다.
- 2) 참조 무결성
- 외래키 값은 피참조 테이블의 기본키 값이거나 NULL 값임 ex) 어떤 테이블의 컬럼이 타 테이블의 기본키를 참조하는 경우, 타 테이블 기본키의 설정이나 값을 그대로 따라야 한다
- 3) 도메인 무결성
- 필드의 타입, NULL값의 허용 등에 대한 사항을 정의하고, 올바른 데이터의 입력 되었는지를 확인하는 것이다. ex) 성별이라는 컬럼이 있을때, 오로지 남자 또는 여자 라는 값만이 참조되어야 하며 그 외의 값이 나오는 것은 무결성을 해친다
- 4) Null 무결성
- 특정 속성값에 null이 올 수 없다는 조건이 주어진 경우, 그 속성값은 null값이 올 수 없다.
- 5) 고유 무결성
- 테이블의 특정 속성에 대해서는 각 레코드들이 각기 다른값을 가져야 한다.
- 1) 개체 무결성
2. SQL Injection
1) 공격 방법
1) 인증 우회
- 로그인 시, 아이디와 비밀번호를 입력한다
- 이 때, SQL syntax를 이용한 교묘한 방법으로 값을 넣어 데이터베이스에 영향을 끼친다.
2) 데이터 노출
- 시스템에서 발생하는 에러 메시지를 이용한 공격방법이다.
- 예를 들어, 해커가 GET방식으로 동작하는 URL 쿼리 스트링을 추가하여 에러 발생
- 오류가 발생하면 에러메시지가 발생하고, 이를 통해 데이터베이스 구조를 유추하여 해킹에 사용
2) 방어 방법
1) input값 받을 때, 특수문자 여부 검사
2) SQL 서버 오류 발생 시, 해당하는 에러 메시지 감추기
3) preparestatement 사용 : 특수문자를 자동으로 escaping 해준다.
3. SQL vs NOSQL
1) SQL (관계형 DB)
1) 정해진 데이터 스키마에 따라 데이터가 테이블에 저장
2) 데이터는 관계를 통해 여러 테이블에 분산
-> 즉, 스키마를 준수하지 않은 레코드는 테이블에 추가 불가함
2) NoSQL(비관계형 DB)
NoSQL에서는 레코드를 document라고 부름
RDBMS와는 달리 정해진 스키마 구조가 없음.
document는 Json과 비슷한 형태로 되어있으며, 관계형 DB와 달리 여러 테이블에 나누어담지 않고 관련 데이터들이 모인 “컬렉션”에 적재
3) 확장 개념
수직적 확장 : 단순히 데이터베이스의 서버 성능 향상(CPU 업그레이드)
수평적 확장 : 더 많은 서버가 추가되고 데이터베이스가 전체적으로 분산됨을 의미
데이터 저장 방식으로 인해 SQL 데이터베이스는 일반적으로 수직확장 만 지원
NoSQL은 수평적 확장을 지원
4) SQL vs NoSQL
1) SQL 장점
1) 명확히 정의된 스키마, 데이터 무결성 보장
2) 관계는 각 데이터를 중복없이 한 번만 저장
2) SQL 단점
1) 유연성이 덜함. 스키마를 사전에 미리 알고 있어야 함
2) 관계를 맺고 있는 테이블이 많으므로, 복잡한 쿼리가 만들어질 수 있음
3) 대체로 수직적 확장만 가능
3) NoSQL 장점
1) 스키마가 없어서 유연. 언제든 저장된 데이터를 조정하고 새로운 필드 추가 가능
2) 데이터는 애플리케이션이 필요로 하는 방식으로 저장. 데이터 Read 속도 빨라짐
3) 수직 및 수평 확장이 가능해서 애플리케이션이 발생시키는 모든 Read/Write 요청 가능
4) NoSQL 단점
1) 유연성으로 인해 데이터 구조 결정이 미뤄짐
2) 데이터 중복을 계속 업데이트 해야함
3) 데이터가 여러 컬렉션에 중복되어 있으므로, 수정 시 모든 컬렉션에서 수행해야 함
(SQL은 중복데이터가 없으므로 한번만 수행 가능)
4. 이상(Anomaly)
정규화가 필요한 이유는 잘못된 테이블 설계로 인한 이상현상 발생 때문이다.
1) 삽입 이상 (Insert Anomaly)
기본키 (student ID, Cource ID)인 경우, Course를 수강하지 않은 학생은 CourseID가 없게되지만 기본키는 Null을 가질 수 없으므로 이도저도 못하는 상황이 됨.
따라서, “미수강” 같은 값을 넣어서 조치를 취해야 하는데 이처럼 불필요한 데이터까지 삽입해야 하는 현상이 발생
2) 갱신 이상 (Update Anomaly)
어떤 학생의 전공이 “컴퓨터” -> “음악”으로 바뀌는 경우
모든 전공을 “음악”으로 바꾸어야함. 그러나 일부를 깜빡하고 바꾸지 못해서 모순의 문제가 생김
3) 삭제 이상 (Delete Anomaly)
- 원하는 정보만 삭제하려 하나, 지우고 싶지 않은 필드들의 정보까지 모두 지워버리는 경우
5. 정규화 (Normalization)
목적
- 데이터의 중복을 없애면서 불필요한 데이터를 최소화시킨다.
- 무결성을 지키고, 이상 현상을 방지한다.
- 테이블 구성을 논리적이고 직관적으로 할 수 있다.
- 데이터베이스 구조를 확장에 용이해진다.
1) 제 1정규화(1NF)
테이블 컬럼이 원자값(하나의 값)을 갖도록 테이블을 분리시키는 것을 말한다.
만족해야 할 조건은 아래와 같다.
- 어떤 릴레이션에 속한 모든 도메인이 원자값만으로 되어 있어야한다.
- 모든 속성에 반복되는 그룹이 나타나지 않는다.
- 기본키를 사용하여 관련 데이터의 각 집합을 고유하게 식별할 수 있어야 한다.
현재 테이블은 한 학생 row에 과목을 여러개 가지고 있어 원자값이 아니다. 따라서 1NF에 맞추기 위해서는 아래와 같이 분리할 수 있다.
2) 제 2정규화(2NF)
테이블의 모든 컬럼이 완전 함수적 종속을 만족해야 한다.
조금 쉽게 말하면, 테이블에서 기본키가 복합키(키1, 키2)로 묶여있을 때, 두 키 중 하나의 키만으로 다른 컬럼을 결정지을 수 있으면 안된다.
기본키의 부분집합 키가 결정자가 되어선 안된다는 것
과목과 학생번호가 키가 되어 성적을 알 수 있다.
지도교수는 과목으로 인해 결정된다. (부분 함수 종속)
하지만, 지도교수는학생번호와 아무런 연관관계가 없는 상황이다.
결국 완전 함수적 종속을 충족시키지 못하고 있는 테이블이다. 부분 함수 종속을 해결하기 위해 테이블을 아래와 같이 나눠서 2NF를 만족할 수 있다.
3) 제 3정규화(3NF)
2NF가 진행된 테이블에서 이행적 종속을 없애기 위해 테이블을 분리하는 것이다.
이행적 종속 : A → B, B → C면 A → C가 성립된다
아래 두가지 조건을 만족시켜야 한다.
- 릴레이션이 2NF에 만족한다.
- 기본키가 아닌 속성들은 기본키에 의존한다.
현재 테이블에서는 Title가 기본키다.
desc, created , author_id는 Title에 종속적이다
하지만, author_name은 기본키가 아닌 author_id에 의해 결정되고 있다.
따라서 이는 3NF를 위반하고 있으므로 아래와 같이 분리해야 한다.
6. 인덱스(Index)
1) 목적
Table의 Column을 색인화 함 (따로 파일로 저장)
-> 해당 Table의 Record를 Full Scan하지 않음
-> 색인화 된 (B+ Tree 구조로) Index 파일 검색으로 검색 속도 향상
2) 과정
- FRM : 테이블 구조가 저장되어 있는 파일
- MYD : 실제 데이터가 있는 파일
MYI : Index 정보가 들어있는 파일
-> Index 미사용시에는 MYI 파일은 비어있으나 인덱싱 할때는 MYI 파일이 생성됨
-> Select 쿼리 탐색 시, 인덱스 사용 컬럼은 MYI 파일 내부를 검색
3) 단점
- Index 생성시, .mdb 파일 크기 증가
- 한 페이지를 동시에 수정할 수 있는 병행성이 줄어듦
- 인덱스 된 필드에서 데이터를 업뎃하거나, 레코드를 추가 또는 삭제시 성능 저하
- 데이터 변경 작업이 자주 일어나면, Index를 재작성 해야하므로 성능에 영향
4) 상황 분석
1) 사용하면 좋은 경우
- Where 절에서 자주 사용 되는 column
- 외래키가 사용되는 Column
- Join에 자주 사용되는 Column
2) 사용을 피해야 하는 경우
- Data 중복도가 높은 Column
- DML이 자주 일어나는 Column
7. 트랜잭션(Transaction)
1. 정의
데이터베이스의 상태를 변화시키기 위해 수행하는 작업 단위
-> 상태 변화 : (SELECT,INSERT,DELETE,UPDATE 같은 질의어로 DB 접근)
-> 작업 단위 : (예시 : A가 B에게 n원을 송금한다 => A통장UPDATE + B통장UPDATE)
와 같이 한 작업에 대해 발생할 수 있는 모든 일들의 묶음
2. 트랜잭션 특징(ACID)
1) 원자성(Automicity) : 트랜잭션이 DB에 모두 반영되거나, 아니거나 둘 중 하나
2) 일관성(Consistency) : 트랜잭션 작업 처리 결과는 항상 일관성을 가져야 한다
3) 독립성(Isolation) : 둘 이상의 트랜잭션 실행 시, 어떤 트랜잭션도 다른 트랜잭션 연산에 못 낌
4) 지속성(Durability) : 트랜잭션이 성공하면 그 결과는 영구히 반영 될 것
3. 작업
1) Commit : 한 트랜잭션이 성공적으로 끝나고, DB가 일관성 있을 때 이를 알려주기 위한 연산
2) Rollback : 하나의 트랜잭션 처리가 비정상적으로 종료되어 트랜잭션 원자성이 깨진 경우, 트랜잭션을 시작하기 이전으로 돌아감
4. Long Transaction & Short Transaction
1) long transaction
- 하나의 트랜잭션이 오랜 시간 동안 지속되는 상황을 가리킴
- 대량의 데이터 변경
- 긴 작업 수행
- 대기 상태
- 일반적으로 성능 문제와 관련이 있으며, 데이터베이스 관리자는 트랜잭션을 최대한 짧게 유지하고 빠르게 실행되도록 노력
2) short transaction
- 상대적으로 빠르게 실행되는 트랜잭션을 가리킵니다.
- 빠른 실행
- 적은 리소스 사용
- 빠른 커밋
- 일반적으로 데이터베이스 시스템의 성능과 효율성을 유지하는 데 중요한 역할을 진행.
- 그러나 모든 작업이 short transaction으로 수행되지는 않으며, 복잡한 작업이나 대량의 데이터 변경이 필요한 경우에는 더 긴 시간이 소요
8. Transaction 관리를 위한 DBMS의 전략
1) DBMS의 구조
- Query Processor : 질의 처리기
- Storage System : 저장 시스템
- 입출력 단위 : 고정길이의 page단위로 disk에 읽거나 씀
- 저장 공간 : disk에 저장. 일부분은 Main memory에 저장
2) Page Buffer Manager
- DBMS의 Storage System에 속하는 모듈 중 하나. Main Memory에 유지하는 페이지를 관리하는 모듈
3) UNDO
- 필요한 이유 : 수정된 Page들이 Buffer 교체 알고리즘에 따라 디스크에 출력될 수 있음
-> Buffer 교체는 트랜잭션과는 무관하게 Buffer 상태에 따라 결정.
-> 이로 인해, 정상적 종료가 안된 트랜잭션이 변경한 page들은 원상복구 되어야 하는데 이것이 UNDO
Case 1 : steal(수정된 페이지를 언제든 디스크에 쓸 수 있는 정책)
- 대부분 DBMS가 채택하는 buffer 관리 정책
- UNDO logging과 복구를 필요로 함
Case 2 : not steal (수정된 페이지들을 EOT[End of Transaction]까지는 버퍼에 유지)
- UNDO 작업은 필요 없으나, 매우 큰 메모리 버퍼 필요
4) REDO
- 이미 commit한 트랜잭션의 수정을 재반영하는 복구 작업
- Buffer 관리 정책에 영향을 받음
- 트랜잭션이 종료되는 시점에 해당 트랜잭션이 수정한 page를 디스크에 쓸지말지 결정
Case 1 : FORCE(수정했던 모든 페이지를 Transaction commit 시점에 disk에 반영)
- 트랜잭션이 commit 되었을 때 수정된 페이지들이 disk 상에 반영되므로 redo 불필요
Case 2 : not FORCE(commit 시점에 미반영)
- 트랜잭션이 disk상의 DB에 미반영 될 수 있으므로 redo 복구 필요(대부분 DBMS정책)
9. 트랜잭션 격리 수준 (Transaction Isolation Level)
- 정의 : 트랜잭션에서 일관성 없는 데이터를 허용하도록 하는 수준
- 필요성 : 데이터베이스는 ACID 특징과 같이 트랜잭션이 독립 수행을 하도록 함.
- 따라서 Locking을 통해, 트랜잭션이 DB를 다루는 동안 다른 트랜잭션이 관여하지 못하도록 막는 것이 필요
1. Isolation level 종류
1) Read Uncommitted (레벨0)
- 트랜잭션이 처리중이거나, 아직 Commit 되지 않은 데이터를 다른 트랜잭션이 읽는 것을 허용
ex) 사용자1이 A라는 데이터를 B라는 데이터로 변경하는 동안, 사용자2는 아직 완료되지 않은 (Uncommitted) 트랜잭션이지만 데이터B를 읽을 수 있다.
2) Read Committed (레벨1)
- 트랜잭션이 수행되는 동안 다른 트랜잭션이 접근할 수 없어 대기하게 됨.
- Oracle 서버가 default로 사용하는 Isolation level 이다. Commit된 데이터만을 읽어오게 된다
ex) 사용자1이 A라는 데이터를 B라는 데이터로 변경하는 동안, 사용자 2는 해당 데이터에 접근 불가
3) Repeatable Read (레벨2)
- 트랜잭션이 범위 내에서 조회한 데이터 내용이 항상 동일함을 보장. 다른 사용자는 트랜잭션 영역에 해당되는 데이터에 대한 수정 불가
- 트랜잭션 내에서 한 번 조회한 값은 계속 같은 값이 조회되는 격리 수준
4) Serializable (레벨3)
- 완벽한 읽기 일관성 모드를 제공. 다른 사용자는 트랜잭션 영역에 해당되는 데이터에 대한 수정 및 입력 불가
2. 낮은 단계 Isolation Level을 활용할 때 발생하는 현상들
1) Dirty Read (레벨0 에서 발생)
- 어떤 트랜잭션에서 아직 실행이 끝나지 않은 다른 트랜잭션에 의한 변경사항을 보게 될 경우
2) Non-repeatable Read (레벨1 에서 발생)
- 한 트랜잭션에서 같은 쿼리를 두 번 수행할 때 그 사이에 다른 트랜잭션 값을 수정 또는 삭제하면서 두 쿼리의 결과가 상이하게 나타나는 일관성이 깨짐
3) Phantom Read (레벨2 에서 발생)
- 한 트랜잭션 안에서 일정 범위의 레코드를 두 번 이상 읽었을 때, 첫번째 쿼리에서 없던 레코드가 두번째 쿼리에서 나타나는 현상
10. 레디스(Redis)
**빠른 오픈 소스 In-memory 키-값 데이터 구조 스토리지 **보통 데이터베이스는 HDD나 SSD에 저장하지만, Redis는 메모리에 저장하므로 디스크 스캐닝이 필요 없어 더 빠르다는 장점을 가짐 -
RAM의 휘발성에 대비하기 위한 백업과정이 존재한다
1 2 3
-> Snapshot : 특정 지점을 설정하고 디스크에 백업 -> AOF(Append Only File) : 명령(쿼리)들을 저장해두고, 서버 셧다운시, 재실행해서 다시 만듦
데이터 구조는 key/value 형식임. (따라서, Redis는 비정형 데이터베이스 관리 시스템)
value 5가지
-> String(text, binary data) : 512MB까지
-> set(String 집합)
-> sorted set(set을 정렬해둔 상태)
-> Hash
-> List(더블 링크드리스트도 가능)
출처 : https://gyoogle.dev/blog/