데이터베이스 (DB, DataBase)

데이터베이스 (DB, DataBase)

---

일정한 규칙, 혹은 규약을 통해 구조화되어 저장되는 데이터의 모음

데이터베이스 안에 있는 데이터들은 특정 DBMS마다 정의된 쿼리 언어(query language)를 통해 삽입, 삭제, 수정, 조회 등 수행

DBMS
: 해당 데이터베이스를 제어, 관리하는 통합 시스템

• 실시간 접근

• 동시 공유 가능

• 데이터베이스 위에 DBMS가 있고, 그 위에 응용 프로그램이 존재하여 이러한 구조를 기반으로 데이터를 주고 받는다.

• MySQL(DBMS) 위에 Node.js나 php(응용 프로그램)에서 해당 데이터베이스 안에 있는 데이터를 끄집어내 해당 데이터 관련 로직 구축

종류

• 관계형 데이터베이스
• NoSQL 데이터베이스

1. 엔터티 (entity)

---

사람, 장소, 물건, 사건, 개념 등 여러 개의 속성을 지닌 명사
ex) 회원 (엔터티) - 이름, 아이디, 주소, 전화번호

• 엔터티는 약한 엔터티와 강한 엔터티로 나뉜다.
• 서비스의 요구 사항에 맞춰 속성이 정해진다.
  • 주소라는 속성이 서비스의 요구 사항과 무관한 속성이라면, 주소 속성은 사라지게 된다.

약한 엔터티, 강한 엔터티

• 약한 엔터티 : 자체적으로 키를 보유하지 못한 엔터티

• 강한 엔터티 : 기본 키를 가진 엔터티

• A가 혼자서는 존재하지 못하고, B의 존재 여부에 따라 종속적이라면 A는 약한 엔터티, B는 강한 엔터티

• 방은 건물 안에만 존재하기 때문에 방은 약한 엔터티, 건물은 강한 엔터티

2. 릴레이션 (relation)

---

데이터베이스에서 정보를 구분하여 저장하는 기본 단위
엔터티에 관한 데이터를 DB는 릴레이션 하나에 담아서 관리한다.

• 릴레이션 == 테이블 (관계형 데이터베이스에서)
  • 릴레이션 == 컬렉션 (NoSQL에서)
• 회원이라는 엔터티가 DB에서 관리될 때 릴레이션으로 변화된다.

테이블, 컬렉션

• 대표적 관계형 데이터베이스 - MySQL
  • 구조 : 레코드-테이블-DB
• 대표적 NoSQL 데이터베이스 - MongoDB
  • 구조 : 도큐먼트-컬렉션-DB
• 레코드가 쌓여서 테이블이 되고, 테이블이 쌓여서 데이터베이스가 되는 것이다.

3. 속성 (attribute)

---

릴레이션에서 관리하는 구체적이며 고유한 이름을 갖는 정보

ex) '차' 엔터티
속성 : 차 넘버, 바퀴 수, 색상, 차종 등
이 중에서 서비스의 요구 사항을 기반으로 관리해야 할 필요가 있는 속성들만 엔터티의 속성이 된다.

4. 도메인 (domain)

---

릴레이션에 포함된 각각의 속성들이 가질 수 있는 값의 집합

ex) '성별' 속성
값의 집합 : [남, 여]

• 릴레이션 : 회원
• 속성 : 이름, 아이디, 주소, 전화번호, 성별
• 도메인 : 성별의 [남, 여]

5. 필드와 레코드

---

• 레코드 : 테이블에 쌓이는 행(raw) 단위의 데이터
  • 튜플이라고도 한다.

예시
엔터티, 테이블 : 책
속성 : 제목, 가격, ISBN, 저자, 출판년도 등
그 중 ' 이름, 저자의 아이디, 출판년도, 장르, 생성일시, 업데이트 일시'만 있다고 가정

이 엔터티를 데이터베이스에 넣어 테이블로 만들려면 속성에 맞는 타입을 정의해야 한다.

CREATE TABLE book (
    id INT NOT NULL AUTO_INCREMENT,
    title VARCHAR(255),
    author_id INT,
    phblishing_year VARCHAR(255),
    genre VARCHAR(255),
    created_at DATETIME,
    update_at DATETIME,
    PRIMARY KEY (id)
);

필드 타입

• 숫자 타입 : TINYINT, SMALLINT, MEDIUMINT, INT, BIGINT 등
• 날짜 타입
  • DATE : 날짜 부분은 있으나 시간 부분은 없는 값에 사용
  • DATETIME : 날짜 및 시간 부분을 모두 포함하는 값에 사용
  • TIMESTAMP : 날짜 및 시간 부분을 모두 포함하는 값에 사용
• 문자 타입
  • CHAR : 고정 길이 문자열 (0 ~ 255), 레코드를 저장할 때 무조건 선언한 길이 값으로 고정해서 저장된다.
    • 유동적이지 않은 길이를 가진 데이터의 경우에 효율적
  • VARCHAR : 가변 길이 문자열 (0 ~ 65,535), 입력된 데이터에 따라 용량을 가변시켜 저장한다.
    • 유동적인 길이를 가진 데이터에 효율적
  • TEXT : 큰 문자열 저장할 때 사용 (게시판의 본문)
  • BLOB : 이미지, 동영상 등 (AWS S3 이용해 서버에 파일을 올리고, 파일에 관한 경로를 VARCHAR로 저장)
  • ENUM : ENUM('x-small', 'small', 'medium', ' large', 'x-large') 형태
    • 하나만 선택 가능
    • ENUM 리스트에 없는 잘못된 값을 삽입하면 빈 문자열이 대신 삽입된다.
    • x-small 등이 0, 1 등으로 매핑되어 메모리를 적게 사용하는 이점
    • 최대 65,535개의 요소를 넣을 수 있다.
  • SET : 여러 개의 데이터 선택 가능
    • 비트 단위의 연산 가능
    • 최대 64개의 요소를 넣을 수 있다.
  • ENUM이나 SET을 쓸 경우, 공간적으로 이점을 볼 수 있지만 애플리케이션의 수정에 따라 데이터베이스의 ENUM이나 SET에서 정의한 목록을 수정해야 한다는 단점이 있다.

6. 관계

---

데이터베이스에는 여러 개의 테이블이 있고, 이러한 테이블은 서로의 관계가 정의되어 있다. 이 관계를 관계화살표로 나타낸다.

![[Pasted image 20230206100851.png]]

1:1 관계

하나의 A는 하나의 B로 구성되어 있다.
하나의 레코드가 다른 테이블의 레코드 한 개와 연결되어 있다.

예를 들어 유저당 유저 이메일은 한 개씩 존재하는 경우

• 유저 테이블 : 이름, 전화번호, 주소
• 이메일 테이블 : 이름, 이메일

1:N(일대다) 관계

하나의 레코드가 서로 다른 여러 개의 레코드와 연결되어 있다.
한 개체가 많은 개체를 포함하는 관계

예를 들어 쇼핑몰을 운영한다고 할 때, 한 유저당 여러 개의 상품을 장바구니에 넣을 수 있는 경우이다. 하나도 넣지 않는 0개의 경우도 있으니 0도 포함되는 화살표를 통해 표현한다.

• 유저 테이블 : 이름, 전화번호, 주소
• 상품 테이블 : 이름, 가격, 출시일

N:M(다대다) 관계

여러 개의 레코드가 다른 테이블의 여러 개의 레코드와 관계가 있는 경우
양방향에서 다수의 레코드를 가질 수 있다.

예를 들어 학생과 강의의 관계로 볼 때, 학생은 강의를 많이 들을 수 있고 강의도 여러 명의 학생을 포함할 수 있다.
다대다 관계는 테이블 두 개를 직접적으로 연결해서 구축하지는 않고 1:N, 1:M이라는 관계를 갖는 테이블로 나눠서 설정한다.

• 학생 테이블 : ID, 이름, 전화번호, 주소
• 강의 테이블 : ID, 이름, 교수명
• 학생_강의 테이블 : 학생ID, 강의ID

7. 키

---

테이블 간의 관계를 더 명확하게 하고, 테이블 자체의 인덱스를 위해 설정된 장치
기본키, 외래키, 후보키, 슈퍼키, 대체키

![[Pasted image 20230206102104.png]]
슈퍼키는 유일성이 있고 그 안에 포함된 후보키는 최소성까지 갖춘 키다.
후보키 중에서 기본키로 선택되지 못한 키는 대체키가 된다.

• 유일성 : 중복되는 값이 존재하지 않는다.
• 최소성 : 필드를 조합하지 않고 최소 필드만 써서 키를 형성할 수 있다.

기본키

유일성과 최소성을 만족하는 키로, 테이블의 데이터 중 고유하게 존재하는 속성

기본키에 해당하는 데이터는 중복되어서는 안 된다. 중복된다면 기본키가 되지 말아야 한다.
그러나 만약 ID를 기본키로 설정한다면, 물론 {ID, name}이라는 복합키를 기본키로 설정할 수 있지만 그렇게 되면 최소성을 만족하지 않는다.
자연키 또는 인조키 중에 골라 설정한다.

자연키

중복된 값들을 제외하며 중복되지 않는 것을 '자연스레' 뽑다가 나오는 키
언젠가 변하는 속성을 가진다.

• 예를 들어 유저 테이블로 가정하면, 주민등록번호, 이름, 성별 등의 속성이 있다. 이 중 이름, 성별 등은 중복된 값이 들어올 수 있으므로 부적절하므로 남는 것은 주민등록번호이다. 이가 기본키가 되는 것이다.

인조키

인위적으로 생성한 키

• 자연키와 다르게 대조적으로 변하지 않아서 보통 기본키는 인조키로 설정한다.
• 예를 들어 유저 테이블로 가정하면, 회원 테이블을 생성한다고 한다. 주민등록번호, 이름, 성별 등의 속성이 있다. 인위적으로 유저 아이디를 부여한다. 이를 통해 고유 식별자가 생겨난다.
• 오라클 - sequenece, MySQL - auto increment 등

외래키

다른 테이블의 기본키를 그대로 참조하는 값
개체와의 관계를 식별하는 데 사용

• 중복되어도 괜찮다.
• client 테이블 : 기본키 - ID
• product 테이블 : 외래키 - user_id (client 테이블의 ID)

후보키

• 기본키가 될 수 잇는 후보들
• 유일성과 최소성을 동시에 만족하는 키

대체키

• 후보키가 두 개 이상일 경우, 어느 하나를 기본키로 지정하고 남은 후보키들

슈퍼키

• 각 레코드를 유일하게 식별할 수 있는 유일성을 갖춘 키

관계형 데이터베이스(RDBMS)

---

행과 열을 가지는 표 형식 데이터를 저장하는 형태의 데이터베이스

• SQL 언어를 써서 조작한다.
• 표준 SQL을 지키기는 하지만, 각각의 제품에 특화시킨 SQL을 사용한다.
  • 오라클 - PL/SQL, SQL Server - T-SQL, MySQL - SQL

MySQL

: 대부분의 운영체제와 호환되며 현재 가장 많이 사용하는 데이터베이스

• c, c++로 만들어졌다.
• MyISAM 인덱스 압축 기술, B-트리 기반의 인덱스, 스레드 기반의 메모리 할당 시스템, 매우 빠른 조인, 최대 64개의 인덱스 제공
• 대용량 데이터베이스를 위해 설계되어 있다.
• 롤백, 커밋, 이중 암호 지원 보안 등의 기능 제공

스토리지 엔진 아키텍처

• 스토리지 엔진은 데이터베이스의 심장과도 같은 역할을 하는 곳이다. 모듈식 아키텍처로 쉽게 스토리지 엔진을 바꿀 수 있다.
• 데이터 웨어하우징, 트랜잭션 처리, 고가용성 처리에 강점을 두고 있다.
• 스토리지 엔진 위에는 커넥터 API 및 서비스 계층을 통해 MySQL 데이터베이스와 쉽게 상호 작용 가능

PostgreSQL

• 디스크 조각이 차지하는 영역을 회수할 수 있는 장치인 VACUUM이 특징
• 최대 테이블의 크기 : 32TB
• SQL 뿐만 아니라 JSON을 이용해서 데이터에 접근 가능
• 지정 시간에 복구하는 기능, 로깅, 접근 제어, 중첩된 트랜잭션, 백업 등 가능

NoSQL 데이터베이스 (Not only SQL)

---

SQL을 사용하지 않는 데이터베이스로, 대표적으로 MongoDB와 redis 등이 있다.

MongoDB
: JSON을 통해 데이터에 접근할 수 있고, Binary JSON 형태(BSON)로 데이터가 저장되며 와이어드타이거 엔진이 기본 스토리지 엔진으로 장착된 키-값 데이터 모델에서 확장된 도큐먼트 기반의 데이터베이스

• 확장성이 뛰어나다.
• 빅데이터를 저장할 때 성능이 좋다.
• 고가용성
• 샤딩, 레플리카셋 지원
• 스키마를 정해 놓지 않고 데이터를 삽입할 수 있기 때문에 다양한 도메인의 데이터베이스를 기반으로 분석하거나 로깅 등을 구현할 때 강점을 보인다.
• 도큐먼트를 생성할 때마다 다른 컬렉션에서 중복된 값을 지니기 힘든 유니크한 값인 ObjectID가 생성된다.
  • 기본키로 유닉스 시간 기반의 타임스탬프(4바이트), 랜덤 값(5바이트), 카운터(3바이트)로 이루어져 있다.

redis
: 인메모리 데이터베이스이자 키-값 데이터 모델 기반의 데이터베이스

• 기본적인 데이터 타입은 문자열(string)이며 최대 512MB까지 저장 가능
• 셋, 해시 지원
• pub/sub 기능을 통해 채팅 시스템, 다른 데이터베이스 앞단에 두어 사용하는 캐싱 계층, 단순한 키-값이 필요한 세션 정보 관리, 정렬된 셋(sorted set) 자료 구조를 이용한 실시간 순위표 서비스에 사용