-
CS 스터디 - 데이터베이스CS 2023. 6. 14. 04:19
용어 정리
DB : 데이터의 집합
DBMS : 데이터베이스를 운영하고 관리하는 소프트웨어
이미지출처 : https://cocoon1787.tistory.com/769
테이블 : 행과 열로 이루어진 데이터의 집합
키 : 테이블에서 행의 식별자로 이용되는 값
- 후보키 : 유일성(key로 하나의 행 구분 가능) 최소성(최소 개수의 속성들로 구성)만족하는 속성들의 집합
- 기본키 : 후보키 중 선택한 키, 테이블에서 기본키는 오직 1개, Null 및 중복값 불가
- 대체키 : 후보키가 2개이상일 경우 기본키 외 다른 후보키들
- 외래키 : 다른 테이의 데이터를 참조하여 테이블의 관계를 연결하는 키, 참조될 테이블 A의 기본키 == 참조할 테이블 B의 외래키
- 슈퍼키 : 유일성은 만족하나 최소성을 만족하지 못하는 키 집합
Index : Table의 Column을 따로 파일로 저장하여(인덱스화) 레코드를 다 스캔하지 않게 함으로써 검색속도 향상 / B Tree 자료구조
-> 자식노드가 2개 이상인 트리, 리프노드들을 LinkedList로 연결하여 순차 검색이 가능하다. O(log2N)
-> 해시테이블이 시간복잡도가 O(1)로 검색이 매우 빠름에도 사용하지 않는 이유는 부등호 연산처럼 연속적인 데이터를 위한 순차 검색이 불가능하기 때문(해시테이블은 순서가 없다)
-> 테이블이 생성되면 MYD(실 데이터파일), MYI(인덱스정보), FRM(테이블 구조가 저장) 3가지 파일을 생성하고, Index가 사용되는 Column 이라면 MYI파일을 검색
-> 정렬된 상태를 유지하므로 검색속도는 향상되나, 새로운 데이터 삽입, 삭제, 수정시 속도 느림, 파일이 추가 생성되므로 파일크기도 증가
-> Where, FK, Join등에 자주 걸리면 사용하면 좋다. / 중복도 높거나 삽입,삭제,수정 자주 일어나는 컬럼은 피하기
=> 인덱스란, 데이터를 빠르게 검색할 수 있게 해주는 객체로써, 레코드를 풀 스캔하지 않고 인덱스 파일 검색을 통해 검색속도를 향상시킵니다. B+트리 구조를 사용하여 리프노드에 모든 데이터를 담고 있어 한 번의 선형 탐색만 수행하면 빠르게 찾기가 가능합니다.
(B-트리 구조는 브랜치노드에 key+data 들어가는데 B+트리는 브랜치 노드에 key만 담아둔다. 리프노드에 키 + 데이터 저장하고 리프노드끼리 연결해둠. 리프 노드에만 데이터를 담아두기 때문에 메모리를 더 확보 ~ 더 많은 key 담을 수 있음 B+트리가 B-트리의 확장 개념이다 )
인덱스 걸려있는 곳이 Delete 수행하면 Index는 지워지지 않고 사용안됨 표시만... Update 수행하면 delete -> insert 순서대로 수행한다.
Schema : 데이터베이스를 구성하는 데이터 개체(Entity), 개체의 특성을 나타내는 속성(Attribute), 개체 사이에 존재하는 관계 및 데이터 조작시 데이터 값들이 갖는 제약조건 등을 기술한 것 / Schema가 존재한다 : 그 구조가 미리 정의 되어 있어야 한다.
데이터베이스 종류 비교 (RDBMS vs NoSQL)
RDBMS :
- 정해진 데이터 스키마에 따라 테이블에 저장, 관계를 통해 여러 테이블에 분산되어 저장
- 하나의 테이블에서 중복 없이 하나의 데이터 관리, 스키마를 준수하지 않는 데이터는 테이블에 추가할 수 없음
- 관계를 맺고 있는 데이터가 자주 변경, 스키마가 변경될 여지가 적고 명확한 경우
NoSQL :
- 비 관계형 데이터베이스 지칭, 대량의 분산된 데이터를 저장하고 조회하는데 특화, 스키마 없이 사용 가능하거나 느슨한 스키마를 제공(데이터를 저장하는 칼럼이 각기 다른 이름과 다른 데이터 타입을 갖는 것이 허용된다)
- 관계형 데이터베이스처럼 여러 테이블에 나누어 담지 않고 관련 데이터를 동일한 컬렉션에 넣는다.
- 데이터 구조가 정확하지 않고 변경/확장 가능성이 있거나 막대한 양의 데이터를 다루고 읽되, 데이터 변경은 자주 일어나지 않는 경우
데이터베이스의 특징
1) 실시간 접근성 : 실시간 처리에 의한 응답 가능
2) 지속적인 변화 : 상태가 동적, 새로운 데이터 삽입/삭제/갱신으로 최신의 데이터 유지
3) 동시 공용 : 다수의 사용자가 동시에 같은 내용의 데이터를 이용할 수 있어야 함
4) 내용의 의한 참조 : 데이터의 주소나 위치에 의한 참조가 아닌, 사용자가 요구하는 데이터 내용으로 찾음
데이터베이스의 언어
DDL(Data Definition Language) : 데이터베이스 구조를 정의, 수정, 삭제하는 언어
-> create(테이블 생성), alter(칼럼 추가/삭제, 칼럼명 변경 등), drop(테이블 삭제)
DML(Manipulation) : 데이터베이스 내 자료를 검색, 삽입, 삭제, 갱신을 위한 언어
-> select, insert, update, delete
DCL(Control) : 데이터의 무결성을 유지, 보호관리하기 위한 언어
-> commit, rollback, grant(권한부여), revoke(권한삭제)
Join 연산
-> 두 개 이상의 테이블이나 데이터베이스를 연결하여 데이터를 검색하는 방법
이미지 출처 : https://imgur.com/gallery/8u7fc
Inner Join : 교집합 검색
Outer Join : 한쪽에만 데이터 있는 경우를 검색
Transaction
데이터베이스의 상태를 변화시키기 위해(SQL 질의어를 통해 DB에 접근) 수행하는 작업 단위(사람이 정한 기준에 따라 정의)
- 특징
1) 원자성 : 트랜잭션이 DB에 모두 반영되거나, 혹은 전혀 반영되지 않아야 한다(All or Nothing)
2) 일관성 : 트랜잭션이 완료된 다음의 상태에서도 트랜잭션이 일어나기 전의 상황과 동일하게 데이터의 일관성을 보장해야 한다.
3) 고립성 : 각각의 트랜잭션은 서로 간섭없이 독립적으로 수행되어야 한다.
4) 지속성 : 트랜잭션이 정상적으로 종료된 다음에는 영구적으로 데이터베이스에 작업의 결과가 저장되어야 한다.
- 트랜잭션 격리수준
동시에 여러 트랜잭션이 처리 될 때, 다른 트랜잭션에 변경한 데이터를 볼 수 있도록 허용할지 말지, 그 격리 수준을 결정하는 것
* 내려갈 수록 고립정도 높아지고 성능이 하향
READ UNCOMMITTED
= 어떤 트랜잭션의 변경 내용이 Commit, Rollback 상관없이 다른 트랜잭션에게 보인다.
-> 데이터의 일관성을 유지하는 것이 불가능함
-> DirtyRead 문제 ( 아직 실행이 끝나지 않은 다른 트랜잭션에 의한 변경사항을 보게 됨 )
READ COMMITTED
-> 커밋이 이루어진 트랜잭션만 조회 가능, 오라클의 기본 격리수준
-> non repeatable read 문제 (한 트랜잭션 내에서 같은 쿼리 두 번 수행시 그 사이 다른 트랜잭션이 수정해버리면 동일 쿼리에 대한 결과가 다르게 나오는, 일관성이 깨진 현상)
REPEATABLE READ
-> 트랜잭션이 시작되기 전 커밋된 내용에 대해서만 조회, 다른 사용자는 트랜잭션 영역에 해당되는 데이터에 대한 수정 불가능, mysql
- Phantom Read 문제 ( 트랜잭션 도중 수정은 불가능하지만 새로운 레코드 삽입은 가능하므로 처음엔 없던 데이터가 나중에 다시 생기는 현상)
SERIALIZABLE
-> 완벽한 읽기 일관성 모드, 트랜잭션에 해당되는 데이터 수정 / 입력 작업이 모두 제한된다.
DB 락
트랜잭션 처리의 순차성을 보장하기 위해 사용
- 공유락(=Read Lock) : 트랜잭션이 읽기 작업 수행시 사용, 읽기만 수행하므로 같은 공유락끼리는 동시 접근 가능
- 베타락(=Write Lock) : 데이터를 변경할 때 사용, 트랜잭션 완료될 때까지 유지되어 이 락이 끝나기 전까지는 어떠한 접근도 허용 X
트리거
데이터베이스 트리거는 테이블에 대한 이벤트에 반응해 자동으로 실행되는 작업을 의미한다. 트리거는 INSERT, DELETE, UPDATE 같은 DML(데이터 조작 언어)의 데이터 상태 관리를 자동화하는데 사용된다
- 데이터 무결성 강화(참조 무결성)
- 업무 규칙의 설정
- 검사 기능의 확장
무결성
데이터의 정확성, 일관성, 유효성이 유지되는 것을 의미하며 무결성이 유지되어야 데이터베이스에 저장된 값과 실제 값이 일치하는지에 대한 신뢰가 생긴다.
개체 무결성 : 기본 키로 선택된 필드는 빈 값 허용하지 않음
참조 무결성 : 서로 참조 관계에 있는 두 테이블은 항상 일관된 값을 유지해야 함
고유 무결성 : 특정 속성이 고유한 값을 가지도록 조건이 주어진 경우 그 속성값은 모두 고유한 값 가짐
Null 무결성 : Null을 허용하지 않는 조건이 주어진 경우 그 속성은 Null이 될 수 없다는 제약조건
정규화
하나의 릴레이션에 하나의 의미만 존재하도록 분해하는 과정
제 1 정규화 : 테이블의 컬럼이 하나의 값(원자값)만을 갖도록 분해
제 2 정규화 : 테이블의 모든 컬럼이 완전 함수적 종속을 만족한다...
-> 기본키의 부분집합 키가 결정자가 되어서는 안된다는 뜻
-> 기본키가 (키1, 키2) 이런 형태라면 두 키 중 하나의 키만으로 다른 컬럼을 결정지을 수 있으면 안된다.
제 3 정규화 : 이행정 종속을 없애는 과정 / 이행적 종속 A->B, B->C 면 A -> C 성립
-> 기본 키가 아닌 속성들은 기본키에 의해서만 구분되어야 한다.
-> Ex ( 대회 이름 / 개최 연도 / 수상자 / 수상자의 생년월일) 이런식이라면 수상자의 생년월일은 기본키가 아닌 수상자에 의해 결정된다. 그러므로 얘는 정규화 작업이 필요
장점
- 데이터베이스 이상현상 문제를 해결하고, 데이터베이스의 구조를 확장할 경우 변경을 최소화할 수 있다.
- 또한 테이블의 데이터 용량이 최소화
단점
- 릴레이션의 분해로 인해 Join 연산이 많아지고, 질의에 대한 응답시간이 느려질 수도 있음
반정규화?
- 정규화 작업 후 테이블 간 join 연산으로 인한 성능 저하 우려가 있으므로, 이를 개선하고자 부분적으로 정규화 원칙을 깨고 테이블을 병합하거나 중복 테이블을 생성하는 등의 처리를 수행.
이상현상(Anomaly)
테이블 설계 단계에서 잘못 설계하여 데이터를 삽입, 삭제, 수정할 때 논리적으로 생기는 오류, 정규화를 통해 이상현상을 방지
- 삽입 이상
데이터 삽입 시 불필요한 자료까지 추가하여야 데이터 삽입이 가능한 경우
(EX 기본 키를 학번 + 강의번호 -> 아직 수강이력이 없는 학생의 경우 강의번호에 null을 넣어야 하나 기본키가 null 이 될 수 없음 -> 미수강이라는 불필요한 강의번호 만들어야 함)
- 갱신 이상
중복된 데이터 중 일부만 수정되어 데이터 모순이 일어나는 현상
- 삭제 이상
특정 데이터 삭제로 인해 의도하지 않은 다른 데이터들까지 함께 삭제되어 버리는 현상
DB 튜닝
- DB 구조나 데이터베이스 자체, 운영체제 등을 조정하여 전체적인 성능을 개선하는 작업
순서 & 대상
- DB 설계 튜닝(모델링 관점) : 반정규화, 분산 파일 배치
- DBMS 튜닝(cpu/ 메모리 io 등 환경 관점) : Buffer, Cache 크기
- SQL 튜닝 단계로 진행(App 관점) : SQL 작성시 성능 고려 Hash, Join
mvcc(multi version concurrency control)
데이터베이스 시스템에서 동시성 제어를 위해 사용하는 방식
여러개의 버전으로 데이터를 관리, 여러 트랜잭션이 수행될 때 일관성을 유지하는 방법
각 트랜잭션은 자신이 시작한 시점에서 유효한 버전을 참조하기 때문에 데이터 충돌을 방지하고 일관성을 유지할 수 있음
=> 추가적인 저장 공간을 요구(이전 버전을 유지하기 위해)
=> 삭제된 데이터표시를 위해 플래그를 사용하므로 삭제된 데이터 처리 및 공간회수 추가작업
=> 일관성 유지에 대한 제약(동일 데이터 동시 수정하는 경우)
=> 롤백시간 및 비용 증가, 인덱스 성능 저하 (인덱스 업데이트/유지 비용이 증가하므로)
'CS' 카테고리의 다른 글
CS 스터디 - 운영체제 Q&A(1) (0) 2023.08.10 CS 스터디 - 네트워크 Q&A (1) (0) 2023.08.03 CS 스터디 - 운영체제 (0) 2023.07.21 CS 스터디 - 네트워크 이론 (0) 2023.07.05 CS 스터디 - Spring (0) 2023.06.20