[CS 전공지식 노트] CH4 데이터베이스

4.1 데이터베이스의 기본

 

 

4.1.1 엔터티

 

4.1.2 릴레이션

엔터티 vs 릴레이션

• 엔터티
  • 업무적으로 분석을 하면 그룹을 선정할 수 있다. 임직원, 제품, 계약, 법인카드, 계좌, 거래처 등등.. 이렇게 업무 분석 중 도출되는 개체들을 엔터티(Entity)라고 한다.
  • 데이터베이스를 논리적으로 설계하는 단계에서는 엔터티라고 한다.
• 릴레이션 (관계형 데베에서 테이블)
  • 개념, 논리 모델링을 거쳐 물리 모델링을 통해 릴레이션을 기반으로 실제 물리적인 데이터를 저장하는 공간 
  • 엔터티가 특정 DBMS로 구현되는 단계부터 테이블이라고 부름
  • 릴레이션 스키마와 인스턴스로 나뉨

=> --개념모델링--> 엔터티 --논리모델링-물리모델링--> 테이블(관계형 데이터 모델에서의 릴레이션)
=>개념적 엔터티와 관계형 릴레이션은 잘 구성되고 최적의 성능을 낼 수 있는 물리적 테이블을 위해 필요한 과정의 산물

 

186 page

SQL vs NOSQL

• SQL (관계형 DB)
  • 일반적으로 수직적 확장만 지원
    • 단순히 데이터베이스 서버의 성능을 향상 시키는 것 (CPU 업그레이드 등)
  • 데이터는 정해진 데이터 스키마에 따라 테이블에 저장된다.
  • 데이터는 관계를 통해 여러 테이블에 분산된다.
  • 장점
    • 명확하게 정의된 스키마, 데이터 무결성 보장
    • 관계는 각 데이터를 중복없이 한번만 저장
  • 단점
    • 덜 유연함. 데이터 스키마를 사전에 계획하고 알려야 함. (나중에 수정하기 힘듬)
    • 관계를 맺고 있어서 조인문이 많은 복잡한 쿼리가 만들어질 수 있음
    • 대체로 수직적 확장만 가능함
• NOSQL
  • 수평적 확장
    • 더 많은 서버가 추가되고 데이터베이스가 전체적으로 분산됨 (하나의 데베에서 작동하지만 여러 호스트에서 작동) 
    • 수직 확장보다 값싼 서버 증설, 혹은 클라우드 서비스를 이용하는 확장이라고도 함
  • 레코드를 도큐먼트(문서)라고 부른다.
  • SQL은 정해진 스키마를 따르지 않으면 데이터 추가가 불가능하지만 NOSQL에서는 다른 구조의 데이터를 같은 컬렉션에 추가가 가능하다.
  • 장점
    • 스키마가 없어서 유연함. 언제든지 저장된 데이터를 조정하고 새로운 필드 추가 가능
    • 데이터는 애플리케이션이 필요로 하는 형식으로 저장됨. 데이터 읽어오는 속도 빨라짐
    • 수직 및 수평 확장이 가능해서 애플리케이션이 발생시키는 모든 읽기/쓰기 요청 처리 가능
  • 단점
    • 유연성으로 인해 데이터 구조 결정을 미루게 될 수 있음
    • 데이터 중복을 계속 업데이트 해야 함
    • 데이터가 여러 컬렉션에 중복되어 있기 때문에 수정 시 모든 컬렉션에서 수행해야 함 (SQL에서는 중복 데이터가 없으므로 한번만 수행이 가능)
• 어떤 걸 사용할까?
  • SQL이 더 적합한 경우
    • 관계를 맺고 있는 데이터가 자주 변경되는 애플리케이션의 경우
    • 변경될 여지가 없고, 명확한 스키마가 사용자와 데이터에게 중요한 경우
  • NOSQL이 더 적합한 경우
    • 정확한 데이터 구조를 알 수 없거나 변경/확장 될 수 있는 경우
    • 읽기를 자주 하지만, 데이터 변경은 자주 없는 경우
    • 데이터베이스를 수평으로 확장해야 하는 경우 (막대한 양의 데이터를 다뤄야 하는 경우)

=> 정답은 없다. 데이터 특성과 프레임워크를 고려해서 결정하면 됨

 

 

4.1.3 속성

 

4.1.4 도메인

도메인

하나의 속성이 취할 수 있는 동일한 유형의 원자값들의 집합을 의미한다.

즉, 특정 속성에서 사용할 데이터의 범위를 사용자가 정의하는 사용자 정의 데이터 타입이다.

예를 들어 학년 속성의 데이터 타입이 정수형이고 6학년까지 있으면 학년 속성의 도메인은 {1, 2, 3, 4, 5, 6}이 된다.

 

 

4.1.5 필드와 레코드

4.1.6 관계

 

4.1.7 키

 

https://hoyashu.tistory.com/6

 

4.2 ERD와 정규화 과정

 

4.2.1 ERD의 중요성

 

4.2.2 예제로 배우는 ERD

 

4.2.3 정규화 과정

 

4.3 트랜잭션과 무결성

 

4.3.1 트랜잭션

 

4.3.2 무결성

 

4.4 데이터베이스의 종류

 

4.4.1 관계형 데이터베이스

 

4.4.2 NoSQL 데이터베이스

 

4.5 인덱스

https://www.youtube.com/watch?v=iNvYsGKelYs&t=3s 

 

4.5.1 인덱스의 필요성

select 할 때 더 빠르게 찾기 위해 사용됨

• 장점
  • 테이블을 검색하는 속도와 성능이 향상된다
• 단점
  • 인덱스를 관리하기 위한 추가 작업이 필요
  • 추가 저장 공간 필요
  • 잘못 사용하는 경우 오히려 검색 성능 저하
• 인덱스를 사용해야 하는 경우
  • 테이블 행의 갯수가 많은 경우 (=데이터가 많은 경우)
  • 인덱스를 적용한 컬럼이 where 절에서 많이 사용되는 경우
  • JOIN 할 때 사용하는 컬럼 (on 부모테이블.PK = 자식테이블.FK)
  • 검색 결과가 원본 테이블 데이터 2-4%에 해당하는 경우
  • 해당 컬럼이 null을 포함하는 경우 (색인에 null이 제외)
• 인덱스를 사용하면 안좋은 경우
  • 테이블의 행의 갯수가 적은 경우
  • 검색 결과가 원본 테이블의 많은 비중을 차지하는 경우
  • 원본 테이블의 삽입, 수정, 삭제가 빈번한 경우

 

인덱스의 작동 원리

# 예시 SQL문

SELECT *
FROM Drink
WHERE drinkno=702;

• 데이터 파일의 블록이 10만개 일 때, 위와 같은 SQL문을 수행하는 과정
  • ① 서버 프로세스가 파싱 과정을 마친 후 DB Buffer Cache에 drinkno가 702인 정보가 있는지 확인
  • ② 정보가 없으면 하드 디스크 파일에서 702 정보를 가진 블록을 복사해서 DB Buffer Cache로 가져온 후 702 정보만 골라내서 사용자에게 보여줌

• 이 때 두 가지 경우로 나뉘어짐
  • 인덱스 없는 경우
    • 702 정보가 어떤 블록에 들어 있는지 모르므로 10만개 전부 DB Buffer Cache로 복사한 후 하나하나 찾음
  • 인덱스 있는 경우
    • WHERE 절의 컬럼이 인덱스가 만들어져 있는지 확인 후, 인덱스에 먼저 가서 702 정보가 어떤 ROWID를 가지고 있는지 확인한 후 해당 ROWID에 있는 블록만 찾아가서 DB Buffer Cache에 복사함

 

4.5.2 B-트리

https://www.cs.usfca.edu/~galles/visualization/BTree.html

B-Tree Visualization

 

4.5.3 인덱스 만드는 방법

220 page

• 클러스터형 인덱스(Clustered Index).
  • 테이블당 한 개만 생성이 가능하다.
  • 행 데이터를 인덱스로 지정한 열에 맞춰서 자동 정렬한다.
  • 영어 사전처럼 책의 내용 자체가 순서대로 정렬이 되어 있어, 인덱스 자체가 책의 내용과 같음.
• 비클러스터형 인덱스(Nonclustered Index)
  • 테이블당 여러 개를 생성할 수 있다.
  • 비클러스터형 인덱스는 그냥 찾아보기가 있는 일반 책과 같다.

 

4.5.4 인덱스 최적화 기법