STUDY - DataBase

📒 데이터베이스

📕 데이터베이스의 기본

1. DB 정의

• 일정한 규칙으로 구조화되어 저장되는 데이터의 모음

• 특징

  • 실시간 접근 및 동시 공유 가능

• 사용 이유

  • DB 존재 이전에는 파일 시스템 이용하여 데이터 관리
  • 데이터를 각각 파일 단위로 저장하여 처리하기 위한 독립 애플리케이션과 상호 연동 필요
  • 문제점 : 데이터 종속성, 데이터 중복성, 데이터 무결성 보장X

• 데이터베이스 특징

  • 데이터의 독립성 (데이터 수정해도 관련된 응용프로그램 수정할 필요X)
  • 데이터의 무결성
  • 데이터의 보안성
  • 데이터의 일관성
  • 데이터 중복 최소화

• 데이터베이스 성능

  • 디스크 I/O 어떻게 줄이느냐에 따라 달라짐 (순차 I/O가 랜덤 I/O보다 빠름)

  📖 참고 📖 디스크 I/O

  • 디스크 드라이브의 플래터(원판)을 돌려서 읽어야 할 데이터가 저장된 위치로 디스크 헤더를 이동시킨 다음 데이터를 읽는 것
  • 데이터를 읽는데 걸리는 시간은 디스크 헤더를 움직여서 읽고 쓸 위치로 옮기는 단계에서 결정됨
  • 디스크의 성능은 디스크 헤더의 위치 이동 없이 얼마나 많은 데이터를 한 번에 기록하는냐에 따라 결정
  • 데이터베이스 쿼리 튜닝을 통해 랜덤 I/O 자체를 줄여줌

2. DBMS 정의 (DataBase Management System)

• 데이터베이스를 제어, 관리하는 통합 시스템
• DBMS마다 정의된 Query를 통해 삽입, 삭제, 수정, 조회 수행
• 예시 : Node.js 혹은 PHP(응용 프로그램)에서 MySQL(DBMS)을 이용하여 DB 안에 있는 데이터 사용하여 데이터 관련 로직 구축

3. 엔터티 (Entity)

• 사람/장소/물건/사건/개념 등 속성을 지닌 명사
• 종류
  • 약한 엔터티 : 고유하게 식별하기 위해서 다른 엔터티 타입으로부터 키 애트리뷰트를 가져옴 (자체적으로 키를 보유하지 못한 엔터티)
  • 강한 엔터티 : 기본키를 가진 엔터티
• 🗒️ 예시 : 회원

4. 릴레이션 (Relation)

• DB에서 정보를 구분하여 저장하는 기본 단위
• 데이터베이스에서 엔터티 정보가 릴레이션으로 관리
  • 관계형 데이터베이스 : 테이블
  • NoSQL 데이터베이스 : 컬렉션

📖 참고 📖 테이블과 컬렉션 차이

• 데이터베이스마다 계층적인 구조 이름 차이
• ✏️ MySQL(RDBMS)의 구조
  • 레코드 ➡️ 테이블 ➡️ 데이터베이스
• ✏️ MongoDB(NoSQLDB)의 구조
  • 도큐먼트 ➡️ 컬렉션 ➡️ 데이터베이스

5. 속성

• 릴레이션에서 관리하는 구체적이며 고유한 이름을 갖는 정보
• 🗒️ 예시 : 이름, 아이디, 주소, 전화번호, 성별

6. 도메인

• 릴레이션에 포함된 각각의 속성이 가질 수 있는 값의 집합
• 🗒️ 예시 : (성별의 경우) {남, 여}

7. 필드와 레코드

• 필드 : 필드의 열(column)단위의 속성 데이터

• 레코드 : 필드의 행(row)단위의 데이터

  • 튜플과 동일

• 🗒️ 예시 : '책' 엔터티 정의하고, 테이블 생성

  • (1) 속성 정의
    • 이름, 저자의 ID, 출판년도, 장르, 생성일시, 업데이트 일시
  • (2) 속성에 맞는 타입 정의
    • id(책의 아이디) : INT
    • title(책의 제목) : VARCHAR(255)
    • author_id(책의 저자 아이디) : INT
    • publishing_year(책의 출판년도) : VARCHAR(255)
    • genre(책의 장르) : VARCHAR(255)
    • created_at(생성 일시) : DATETIME
    • updated_at(업데이트 일시) : DATETIME
  • (3) 해당 테이블 MySQL로 구현

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

8. 필드 타입 종류

• DB마다 타입에 차이가 있음 (MySQK기준 설명)

• (1) 숫자 타입

  • 종류 : TINYINT, SMALLINT, MEDIUMINT, INT, BIGINT
  • 범위 : 4바이트, -21억 ~ 21억

• (2) 날짜 타입

  • 종류 : DATE, DATETIME, TIMESTAMP
  • 범위
    • DATE : 날짜 부분 O, 시간 부분 X (3바이트, 1000-01-01 ~ 9999-12-31)
    • DATETIME : 날짜/시간 부분 O (8바이트, 1000-01-01 00:00:00 ~ 9999-12-31 23:59:59)
    • TIMESTAMP : 날짜/시간 부분 O (4바이트, 1970-01-01 00:00:01 ~ 2038-01-19 03:14:07)

• (3) 문자 타입

  • 종류 : CHAR, VARCHAR, TEXT, BLOB, ENUM, SET
  • 범위
    • CHAR : 테이블 생성시 선언한 길이로 고정 (0 ~ 255바이트)
    • VARCHAR : 입력된 데이터에 따라 용량을 가변(실제 바이트 + 길이 기록용 1바이트)하여 저장 (0 ~ 65,635바이트)
    • TEXT : 게시판 본문 저장 등 큰 문자열 저장
    • BLOB : 이미지, 동영상 등 큰 데이터 저장 (대신 VARCHAR로 이미지 파일 경로 올림)
    • ENUM : x-small/small/medium/large/x-large 중 단일 선택 (리스트에 없는 잘못된 값 선택시 빈 문자열 삽입) (0 ~ 65,535개 요소)
    • SET : 여러 개 데이터 선택 및 비트 단위 연산 가능 (0 ~ 64개 요소)

9. 관계

• 테이블간 서로의 관계가 정의되어 있음
• 관계 종류
  • 1:1 관계
    • 🗒️ 예시 : 유저당 유저 이메일
  • 1:N 관계 (한 개체가 다른 많은 개체 포함하는 관계)
    • 🗒️ 예시 : 유저당 선택한 여러개 상품
  • N:M 관계
    • 🗒️ 예시 : 학생과 강의 (학생이 여러 강의 듣고, 강의당 여러 학생 포함)
      

10. 키

• 테이블 자체의 인덱스
• 키 종류
  • 슈퍼키 : 유일성(중복X)
  • 후보키 : 유일성 + 최소성(필드 조합X, 최소 필드만 사용하여 키 형성 가능)
  • 기본키 : 데이터 고유하게 존재하는 속성, 유일성 + 최소성 + 중복 X
  • 대체키 : 후보키 중 기본키로 선택되지 못한 키
    
  • 자연키 : 속성 중 중복된 값을 제외한 속성 (변할 수 있음)
  • 인조키 : 인위적으로 생성한 고유 식별자 (보통 기본키로 설정됨)
  • 외래키 : 다른 테이블의 기본키를 그대로 참조 (중복 O)

📘 ERD (Entity Relationship Diagram)

1. ERD 정의

• 데이터베이스 구축시 기초적인 뼈대 역할 (릴레이션 간 관계 정의)

• 시스템의 요구 사항 기반으로 작성됨

• 🗒️ 예시 : 영업부서의 ERD

  • (1) 요구 사항 정의
    • 영업사원은 0 ~ n명의 고객을 관리한다.
    • 고객은 0 ~ n명의 주문을 넣을 수 있다.
    • 주문에는 1 ~ n개의 상품이 들어간다.

2. 쇼핑몰 ERD 구축

• mysql 서버 + workbench 다운로드

https://dev.mysql.com/downloads/windows/installer/8.0.html https://dev.mysql.com/downloads/workbench/

• show database; 쿼리 정상 작동시 OK

https://github.com/wnghdcjfe/csnote/blob/main/ch4/sample.sql

3. ERD 분석

CREATE TABLE `customers` (
`customerNumber` int(11) NOT NULL,
`customerName` varchar(50) NOT NULL,
`contactLastName` varchar(50) NOT NULL, `contactFirstName` varchar(50) NOT NULL,
`phone` varchar(50) NOT NULL,
`addressLine1` varchar(50) NOT NULL,
`addressLine2` varchar(50) DEFAULT NULL,
`city` varchar(50) NOT NULL,
`state` varchar(50) DEFAULT NULL,
`postalCode` varchar(15) DEFAULT NULL,
`country` varchar(50) NOT NULL,
`salesRepEmployeeNumber` int(11) DEFAULT NULL, `creditLimit` decimal(10,2) DEFAULT NULL,
PRIMARY KEY (`customerNumber`),
KEY `salesRepEmployeeNumber` (`salesRepEmployeeNumber`), CONSTRAINT `customers_ibfk_1` FOREIGN KEY
(`salesRepEmployeeNumber`) REFERENCES `employees`
(`employeeNumber`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

• decimal(10, 2) = 소수 부분을 포함한 실수의 총 자리수 10자리, 2개의 소수를 가지는 실수

• 인덱싱을 할 키를 1개 더 생성하고, salesRepEmployeeNumber를 외래키로 설정함

• orderdetails

  • 복합키 (orderNumber + productCode)
  • 1주문(orderNumber)안에 있는 상품 코드 개수가 많을 수 있기 때문에 복합키 필요

4. MySQL CRUD 실습

https://www.w3schools.com/mySQl/

// 테이블 생성 Create CREATE TABLE Persons (
    PersonID int,
    LastName varchar(255),
    FirstName varchar(255),
    Address varchar(255),
    City varchar(255)
);
// 테이블 조회 : Read
SELECT *
INTO newtable [IN externaldb] FROM oldtable
WHERE condition;
// 테이블 업데이트 : Update ALTER TABLE Customers
ADD Email varchar(255);
// 테이블 제거 : Delete DROP TABLE Shippers;

📕 트랜잭션

1. 트랜잭션 정의

• (사용자 입장) 작업의 논리적 단위, (시스템 입장) 데이터를 접근 또는 변경하는 프로그램의 단위
• DB에서 논리적 기능을 수행하고, DB 상태를 변화시키는 작업의 단위
• 질의어(SQL)를 이용하여 데이터베이스에 접근하는 것 (여러 개의 쿼리를 하나로 묶는 단위)
• 기능
  • 작업의 완전성 보장
  • 완벽하게 처리하지 못할 경우 원 상태로 복구해서 작업의 일부만 적용되지 않게 만드는 기능

📖 참고 📖 Query

• ✏️ 정의
  • DB에 특정 데이터를 요청하는 일
  • query = 질의문 = SQL
• ✏️ 종류
  • SELECT
  • DELETE
  • UPDATE

📖 참고 📖 트랜잭션과 Lock 차이

• ✏️ Transaction : 데이터 정합성을 보장하는 기능
  • 하나 혹은 여러개의 변경 작업을 수행하는 쿼리에 관계없이
  • 논리적인 작업이 100% 적용되거나 아무것도 적용되지 않도록 보장함
• ✏️ Lock : 동시성 제어하는 기능
  • 여러 커넥션에서 동시에 동일한 자원(레코드/테이블)을 요청할 경우
  • 순서대로 한 커넥션만 변경하게 해줌

2. commit과 rollback

• 데이터 무결성 보장 및 데이터 변경 사항을 쉽게 확인 가능 (작업 그룹화)

• 트랜잭션으로 묶는 로직에 외부 API호출 자제

• commit

  • 여러 쿼리가 성공적으로 처리되었다고 확정하는 명령어
  • 트랜잭션 단위(update, insert, delete 등)로 수행
  • 변경된 내용이 DB에 영구적으로 저장됨
  • 커밋 수행 = 트랜잭션 성공적으로 수행

• rollback

  • 트랜잭션 처리 전 상황으로 복귀(취소)하는 일
  • 에러 및 이슈 발생시 이전으로 돌림

3. 트랜잭션 전파 (Transaction Propagation)

• 트랜잭션 시작

  • 트랜잭션 수행시 Connection 객체를 가져와 사용
  • setAutoCommit(false)로 트랜잭션 시작을 선언 (JDBC 기본 설정으로 DB작업 수행 직후 자동 커밋 옵션 활성화 되어있어서 false로 설정함)

• 트랜잭션 종료

  • 시작되면 commit() 또는 rollback() 호출될 때까지 하나의 트랜잭션

• 트랜잭션 전파

  • 트랜잭션이 진행중일 때 추가 트랜잭션 진행을 어떻게 할지 결정하는 것

  • 여러 트랜잭션을 하나의 트랜잭션으로 묶음

  • 기존 트랜잭션에 참여 / 별도의 트랜잭션으로 진행 / 에러 발생시킴

  • Spring 프레임워크에서 @Transactional 애너테이션을 통해 여러 쿼리 코드를 1개의 트랜잭션으로 처리함

  @Service
  @Transactional(readOnly = true)
  public class MemberService{
  	private final MemberRepository memberRepository;
    
    public MemberService(MemberRepository memberRepository) {
    	this.memberRepository = memberRepository;
     }
  }

  • 트랜잭션 전파 사용시 논리 트랜잭션 개념 사용됨
    
  • 물리 트랜잭션 : 실제 데이터베이스에 적용되는 트랜잭션 (Connection을 통해 commit/rollback하는 단위)
  • 논리 트랜잭션 : 스프링이 트랜잭션 매니저를 통해 트랜잭션을 처리하는 단위

• 🗒️ 예시 : 게시판에 글 작성하는 기능

  • 글을 임시 저장하는 기능(A)이 글 작성 중간에 수행되고, 동시에 로깅(B)을 해야하는 상황
  • 만약, 로깅(B) 작업에서 예외 발생될 경우, 트랜잭션 전파 옵션이 Defaul이면 로깅(B)이 Rollback 진행되면서 임시 저장 기능(A)도 함께 Rollback 발생
  • 하지만, 위의 경우 A가 Rollback 되면 안되기 때문에, 트랜잭션 전파 속성 설정 필요함

📖 참고 📖 트랜잭션 전파 속성

• REQUIRED
  • 트랜잭션이 필요하고, 없으면 새로 만듦 (Default 속성)
  • 기존 트랜잭션 없음 : 새로운 트랜잭션 생성함
  • 기존 트랜잭션 있음 : 기존 트랜잭션에 참여함
  • 기본적으로 논리 트랜잭션 2개를 묶어 1개의 물리 트랜잭션을 사용함
    • 모든 논리 트랜잭션이 커밋되어야 물리 트랜잭션 커밋됨
    • 하나의 논리 트랜잭션이라도 롤백되면 물리 트랜잭션 롤백됨
  • 트랜잭션 매니저에 의해 관리되는 논리 트랜잭션이 존재하므로 커밋 총 2회(내부 1회, 외부 1회) 실행
    
• REQUIRES_NEW
  • 항상 새로운 트랜잭션이 필요함
  • 기존 트랜잭션 없음 : 새로운 트랜잭션 생성
  • 기존 트랜잭션 있음 : 기존 트랜잭션을 보류시키고 새로운 트랜잭션 생성함
  • 외부/내부 트랜잭션을 완전히 분리하는 전파 속성 (내부 트랜잭션 롤백이 외부 트랜잭션 롤백에 영향 X)
  • 각각 트랜잭션 별로 커밋과 롤백이 수행됨 (각각의 DB Connection 사용됨, 1개의 HTTP 요청에 대해 2개의 Connection 사용)
  • 내부 트랜잭션이 처리 중일 경우, 외부 트랜잭션이 대기함 (DB Connection 고갈 주의)
    
• SUPPORTS
  • 트랜잭션이 있으면 지원함 (트랜잭션이 없어도 됨)
  • 기존 트랜잭션 없음 : 트랜잭션 없이 진행함
  • 기존 트랜잭션 있음 : 기존 트랜잭션에 참여함
• MANDATORY
  • 트랜잭션이 의무임 (트랜잭션 반드시 필요함)
  • 기존 트랜잭션 없음 : illegalTransactionStateException 예외 발생
  • 기존 트랜잭션 있음 : 기존 트랜잭션에 참여함
• NOT_SUPPORTED
  • 트랜잭션을 지원하지 않음 (트랜잭션 없이 진행함)
  • 기존 트랜잭션 없음 : 트랜잭션 없이 진행함
  • 기존 트랜잭션 있음 : 기존 트랜잭션을 보류시키고 트랜잭션 없이 진행함
• NEVER
  • 트랜잭션을 사용하지 않음 (기존 트랜잭션도 허용하지 X)
  • 기존 트랜잭션 없음 : 트랜잭션 없이 진행
  • 기존 트랜잭션 있음 : illegalTransactionStateException 예외 발생
• NESTED
  • 중첩(자식) 트랜잭션 생성함
  • 기존 트랜잭션 없음 : 새로운 트랜잭션을 생성함
  • 기존 트랜잭션 있음 : 중첩 트랜잭션을 만듦
  • 독립적인 트랜잭션(REQUIRES_NEW)이 아닌 이미 진행중인 트랜잭션에 중첩(자식) 트랜잭션 생성
    • 부모 트랜잭션의 영향(커밋과 롤백)은 받지만, 외부에 영향을 주지 않음
    • 중첩 트랜잭션이 롤백이 되어도 외부 트랜잭션은 커밋 가능하지만, 외부 트랜잭션이 롤백될 경우 중첩 트랜잭션도 함께 롤백됨

4. 트랜잭션 특징 (ACID)

• (1) 원자성 atomicity
  • 트랜잭션이 DB에 모두 반영되거나, 전혀 반영되지 않음 (All or Nothing)
  • 트랜잭션 중간에 문제 발생할 경우, 트랜잭션에 해당하는 어떠한 작업도 수행되지 않고 아무런 문제가 발생하지 않았을 경우에만 모든 작업 수행함
• (2) 일관성 consistency
  • 트랜잭션 작업 처리의 결과가 항상 동일함 (허용된 방식으로만 데이터 변경 가능)
  • 트랜잭션이 일어나기 전의 상황과 동일하게 데이터의 일관성 보장
• (3) 격리성 isolation
  • 하나의 트랜잭션은 다른 트랜잭션에 끼어들 수 없음 (간섭 불가능)
  • 각각의 트랜잭션은 서로의 간섭없이 독립적으로 수행
• (4) 지속성 durability
  • 트랜잭션이 성공적으로 완료되면 영구적으로 결과에 저장됨 (commit)

📖 참고 📖 무결성

• 데이터의 정확성, 일관성, 유효성을 유지하는 것

5. 트랜잭션의 격리 수준

• 트랜잭션이 순차적으로 실행될 경우 : 격리성⬆️, 동시성⬇️, 성능⬇️
• 격리 수준 단계
  • Serializable : 이상현상 발생 X (격리성⬆️)
  • Repatable Read : 팬텀 리드 발생 가능
  • Read Commited : + 반복 가능하지 않은 조회 발생 가능
  • Read Uncommited : + 더티 리드 발생 가능 (격리성⬇️)

Isolation Level	Dirty reads	Non-repeatable reads	Phantoms
Read Uncommited	May occur	May occur	May occur
Read Commited	Don't occur	May occur	May occur
Repeatable Read	Don't occur	Don't occur	May occur
Serializable	Don't occur	Don't occur	Don't occur

• 격리 수준 설정

set session transaction isolation level read uncommitted;

• Serializable

  • 커밋 완료된 데이터만 조회 가능
  • 트랜잭션을 순차적으로 진행 (간섭 발생 X)
  • 여러 트랜잭션이 동시에 같은 행에 접근 불가

• Repatable Read

  • 커밋 완료된 데이터만 조회 가능
  • 같은 행을 반복해서 조회하더라도 동일한 결과 보장
  • 한 트랜잭션에서 수정한 행을 다른 트랜잭션이 수정 불가 / 새로운 행 추가 가능 (➡️ 팬텀 리드 발생)
  • MySQL8.0의 innoDB의 기본값

• Read Commited

  • 커밋 완료된 데이터만 조회 가능
  • 같은 행을 반복해서 조회하더라도 동일한 결과 보장X
  • 한 트랜잭션에서 수정한 행을 다른 트랜잭션이 수정 + 새로운 행 추가 가능 (➡️ 팬텀 리드, 반복 가능하지 않은 조회 발생)
  • PostgreSQL, SQL Server, 오라클의 기본값

• Read Uncommited

  • 커밋하지 않은 데이터 조회 가능
  • 속도 가장 빠름

6. 트랜잭션 이상 현상

• (1) 팬텀 리드(Phantom reads)

  • 한 트랜잭션 내에서 동일한 쿼리를 2번 이상 보냈을 때 (다른 트랜잭션의 영향으로) 조회 결과가 다름
  • 🗒️ 예시 : 새로운 레코드 추가 및 삭제되어 발생
    

• (2) 반복 가능하지 않은 조회 (Nonrepatable Reads)

  • 한 트랜잭션 내의 같은 행에 2번 이상 조회가 발생 했을 때, 그 값이 다른 것
  • 🗒️ 예시 : 트랜잭션 A는 SELECT하는 구문이고, 트랜잭션 B는 데이터 변경하는 구문일 경우 트랜잭션 A는 B때문에 반복 수행시 다른 결과 가져옴
    

• (3) 더티 리드 (Dirty Reads)

  • 한 트랜잭션이 다른 트랜잭션의 아직 커밋되지 않은 데이터를 읽음
  • 🗒️ 예시 : 트랜잭션 A가 데이터를 변경하고, 커밋하기 전에 트랜잭션 B가 데이터를 읽을 경우 잘못된 데이터 읽음
    

📖 참고 📖 트랜잭션 사용시 주의

• 트랜잭션은 꼭 필요한 최소한 코드에만 적용하기
• 일반적으로 DB Connection 개수는 제한적이므로, 각 단위 프로그램에서 Connection 소유 시간이 길어지면 사용 가능한 여유 Connection 개수가 줄어듦
• 따라서, 트랜잭션 범위 최소화

📕 관계형데이터베이스와 NoSQL 차이

1. RDBMS (관계형 데이터베이스 관리 시스템)

• SQL언어를 사용해 테이블, 행, 열의 형식으로 데이터를 저장하는 데이터베이스

• 종류 : MySQL, PostgreSQL, 오라클(PL/SQL), SQL Server(T-SQL), MSSQL(SQL)

• DBMS와 차이점

  • 테이블간 관계(외래키 등)를 맺고 있어 DBMS보다 효율적으로 데이터 관리 가능

• 장점

  • 데이터 중복 없음
  • 명확한 데이터 구조 보장

• 단점

  • 시스템이 커질 경우 JOIN문이 많은 복잡한 쿼리
  • 스키마로 인해 데이터 구조 유연하지X (변경시 어려움)
  • 성능 향상을 위해서는 서버 성능 향상시키는 Scale-up만 지원 (비용 크게 늘어남)

• 사용 : 데이터 구조 명확하여 변경될 여지가 없고, 명확한 스키마가 중요한 경우 사용

2. NoSQL 데이터베이스

• SQL언어 사용하지 않는 다른 형태의 데이터 저장 기술
• 종류 : MongoDB, redis
• RDBMS와 차이점
  • 데이터 일관성은 포기하지만, 비용을 고려하여 여러 대에 데이터 분산 저장
• 장점
  • 유현한 스키마, 확장성
  • 대량의 분산된 데이터를 저장하고 조회에 용이
  • 성능 향상을 위해서 데이터를 여러 곳에 분산하는 Scale-out도 가능
  • 쓰기/읽기 성능 특화, 2차 인덱스 지원, 오토 샤딩 지원
• 단점
  • 데이터 중복 발생 가능 (중복된 데이터 변경시 모든 컬렉션 수정 필요)
  • 스키마가 존재하지 않아, 명확한 데이터 구조를 보장 X
• 사용 : 정확한 데이터 구조 알 수 없고, 데이터 변경/확장될 수 있는 경우

📖 참고 📖 저장 방식에 따른 NoSQL 분류

• ✏️ Key-Value Model
  • Redis
  • 키 1개로 데이터 1개 저장/조회하는 단일 키-값 구조
  • 장점 : 단순한 저장 구조, 고속 읽기 및 쓰기에 최적화
  • 단점 : 복잡한 조회 연산 지원X, 1개의 서비스 요청에 다수의 데이터 조회/수정 연산 발생하면 트랜잭션 처리가 불가능하여 데이터 정합성 보장 못함
  • 사용 : 사용자의 프로필 정보, 웹 서버 클러스터를 위한 세션 정보, URL 단축 정보 저장
• ✏️ Document Model
  • MongoDB
  • 키 1개에 구조화된 문서를 저장/조회 (관계형 데이터베이스와 유사)
  • 키는 문서에 대한 ID로 표현됨
  • 저장된 문서는 컬렉션으로 관리하고, 문서 저장과 동시에 문서 ID에 대한 인덱스 생성
  • 인덱스 사용하여 O(1) 시간 안에 문서 조회 가능
  • B-Tree 인덱스 사용하여 2차 인덱스 생성함 (크기 커질수록 새로운 데이터 입력/삭제시 성능 저하됨)
  • 사용 : 중앙 집중식 로그 저장, 타임라인 저장, 통계 정보 저장
• ✏️ Column Model
  • Google의 빅테이블
  • 1개의 키에 여러 개의 컬럼 이름과 컬럼 값의 쌍으로 이루어진 데이터 저장/조회
  • 빅테이블 개념 (Row Key, Column Key, Column Family 등) 사용
  • 컬럼 단위로 저장, 컬럼 이름, 컬럼 값, 타임스탬프로 구성됨 (모든 컬럼은 항상 타임 스탬프 값과 함께 저장)
  • 읽기보다 쓰기에 최적화 (빠른 시간 안에 대량의 데이터 입력/조회하는 서비스 구현시 적합)
  • 데이터를 먼저 커밋로그와 메모리에 저장한 후 응답하여 빠른 응답속도 제공
  • 사용 : 채팅 내용 저장, 실시간 분석을 위한 데이터 저장소

3. MySQL

• 대부분 운영체제와 호환되고, 가장 많이 사용하는 데이터베이스
• 특징
  • C, C++로 만듦
  • B-트리 기반의 인덱스
  • 스레드 기반의 메모리 할당 시스템
  • 매우 빠른 조인
  • 최대 64개의 인덱스
  • 대용량 데이터베이스를 위해 설계됨
  • 롤백, 커밋, 이중 암호 지원 보안
• MySQL의 스토리지 엔진 아키텍처
  • 모듈식 아키텍처로 쉽게 스토리지엔진 바꿀 수 있음
  • 데이터 웨어하우징, 트랜잭션 처리, 고가용성 처리 가능
  • 스토리지 엔진 위에 커넥터 API 및 서비스 계층을 통해 MySQL 데이터베이스와 쉽게 상호 작용 가능
• 쿼리 캐시 지원
  • 입력된 쿼리문에 대한 전체 결과 집합을 저장함
  • 사용자가 작성한 쿼리가 캐시에 있는 쿼리와 동일하면, 서버는 단순히 구문 분석, 최적화 및 실행을 건너뛰고 캐시의 출력만 표시함

4. PostgreSQL

• MySQL 다음으로 많이 사용하는 데이터베이스 (인프랩에서 사용)
• 특징
  • 디스크 조각이 차지하는 영역 회수할 수 있는 장치(VACUUM) 있음
  • 최대 테이블 크기 32TB
  • SQL뿐만 아니라 JSON을 이용하여 데이터 접근 가능
  • 지정 시간에 복구하는 기능
  • 로깅, 접근제어, 종합된 트랜잭션, 백업 가능

📖 참고 📖 JSON (JavaScript Object Notation)

• 사람이 읽을 수 있는 텍스트를 사용하여 데이터 저장, 전송, 공유하는 표준 파일 형식
• JSON 파일은 .json 확장자로 저장
• JavaScript에서 파생되지만, 언어 독립적인 데이터 형식
  

5. MongoDB

• wiredtiger 엔진이 기본으로 장착된 키-값 데이터 모델에서 확장된 document 기반의 데이터베이스
• 특징
  • JSON을 이용하여 데이터 접근 가능 (Binary JSON 형태(BSON)로 저장됨)
  • 확장성이 뛰어나고, 빅데이터 저장시 성능이 좋음
  • 고가용성, 샤딩, 레플리카셋 지원
  • 스키마를 정하지 않고 데이터 삽입 가능 (다양한 도메인의 DB를 기반으로 분석 및 로깅 구현시 편리)
  • document 생성할 때마다 다른 컬렉션에서 중복된 값을 갖기 힘든 ObjectID 생성됨
  • ObjectID(기본키) : 유닉스 시간 기반의 타임스탬프(4바이트). 랜던값(5바이트), 카운터(3바이트)로 구성
    

5. MongoDB 특징

• (1) Key와 value 형태의 document

  • _id 형태의 고유한 아이디
  • key의 길이도 DB에 저장
  • JSON 형태로 쿼리 생성 및 매개변수로 받아 BSON형태로 DB에 삽입/추출 가능
  • type 변환 일어나지 X (데이터 주고받을 때 성능 향상)

• (2) 스키마 없이 삽입 가능

  • 스키마 없이 데이터 모델 구현하지 않고, 유연하게 데이터 삽입 가능
  • document로 칼럼이름도 바이트에 추가됨 (key-value 형태라서)
  • 🗒️ 예시 : char[14] 김수현 or name:김수현 저장할 경우
    • RDBMS : 14바이트
    • MongoDB : 16바이트 (comments : string)

• (3) 데이터의 조합함수 지원

  • 함수로 데이터 추출하고, 조합하여 압축된 결과값 생성
  • 함수 예시 : min, max, aggregate, mapReduce

• (4) 이중화 지원과 샤딩

  • 운영서버의 경우 멈추면 안되기 때문에 서버 이중화 필요 ➡️ ReplicaSet 이용해 이중화
  • 데이터 양이 많은 경우 ➡️ 샤딩을 통해 collection 분할하여 관리

• (5) JSON 형태의 Data

  • BSON 형태로 저장
  • JSON 형태로 값 추출
  • JSON Object를 매개변수로 받아 저장

• (6) 2차원 좌표 인덱싱

  • geoSpartial 인덱스 사용하여 2차원 좌표 인덱싱 가능

• (7) collection join

  • $lookup을 통한 collection join 가능

• (8) B-tree를 적용한 인덱싱

📖 참고 📖 스키마

• 데이터베이스를 구성하는 속성, 관계 등 데이터 값이 갖는 type을 명시한 것

6. redis

• 인메모리 데이터베이스, 키-값 데이터 모델 기반의 데이터베이스
• 특징
  • 데이터 타입 : 문자열(기본, 최대 512MB까지 저장), set, hash
  • pub/sub 기능
  • 채팅 시스템, 다른 데이터베이스 앞단에 두어 사용하는 캐싱 계층. 단순한 키 값이 필요한 세션 정보 관리, 정렬된 set 자료 구조를 이용한 실시간 순위표 서비스에 사용

📕 스토리지엔진 (= Database Engine)

1. Storage Engine 정의

• DBMS가 DB에 데이터를 삽입/추출/업데이트/삭제시 사용되는 기본 소프트웨어 컴포넌트
• 🗒️ 예시 : MySQL에서 테이블 생성하면, 실제로 서버상에는 .frm 파일 생성됨
  • 스토리지 엔진이.frm 파일에 접근하는 속성 설정함
• DBMS는 동일한 DB 내에 다중 저장 엔진 지원
  • 동일 DB의 테이블마다 다르게 지정 가능 (MyISAM or InnoDB)

📖 참고 📖 Stroge Engine 역할

• transaction manager : 트랜잭션 스케줄링 및 DB 상태의 논리적 일관성 보장
• lock manager : 트랜잭션에서 접근하는 DB 객체에 대한 잠금 제어, 동시성 제어 (무결성 보장)
• access method : 디스크에 저장된 데이터에 대한 접근 및 저장 방식 정의 (힙 파일/B-Tree/LSM 트리 등 자료구조 사용)
• buffer manager : 데이터 페이지를 메모리에 캐시
• recovery manager : 로그 우지 관리, 장애 발생시 시스템 복구
  

2. innoDB

• 외래키를 가지는 트랜잭션 지원 스토리지 엔진
• MySQL8.0 기본 스토리지 엔진 (MyISAM으로 변경 가능)
• 장점
  • ACID 트랜잭션 지원
  • 큰 가용성 제공 (데이터베이스 크기가 큼)
  • 행, 인덱스 조회 캐싱 : 엔진 자체 내에서 행 캐시와 인덱스 캐시 결합하여 수행
  • 잠금 수준 : 행 수준 잠금 사용 (높은 동시성 처리 및 안정적)
  • 자동 데드락 감지 (감지시 변경된 레코드가 가장 작은 트랜잭션을 rollback하여 데드락 풀기)
  • 자동 장애 복구 (완료하지 못한 트랜잭션이나 손상된 데이터 페이지 자동 복구)
• 단점
  • 데이터 저장 비율 낮고, 데이터 로드 속도 느림
• 사용
  • 트랜잭션 처리, 대용량 데이터 다룰 때 편리
  • 데이터 입력 및 수정이 자주 일어나고, 다중 사용자 및 동시성이 높은 OLTP 애플리케이션에 적합

📖 참고 📖 OLTP (온라인 트랜잭션 처리)

• 여러 사용자가 실시간으로 DB 데이터 갱신, 조회하는 단위의 작업을 처리하는 방식
• 동시에 발생하는 다수의 트랜잭션을 실행하는 데이터 처리 유형
• 예시 : 온라인 뱅킹, 쇼핑, 주문 입력, 텍스트 메시지 전송

3. MyISAM

• 트랜잭션이 지원하지 않는 스토리지 엔진
• 장점
  • 구조 단순, 조회(SELECT) 쿼리시 빠름 (테이블에 ROW COUNT 저장함)
  • 데이터 저장에 실제 제한이 없고, 효율적으로 저장됨
  • 행, 인덱스 조회 캐싱 : 파일 시스템 블록 캐시에 의존
  • Full-text 검색 가능
• 단점
  • 잠금 수준 : 테이블 수준의 잠금 제공 (특정 행 수정할 경우 테이블 전체에 Lock 걸어 다른 사람 작업 못함)
  • 트랜잭션이 없어 작업도중 문제 생겨도 DB에 저장됨 (데이터 무결성 보장X)
• 사용
  • 트랜잭션 필요 없고, 조회기능 많을 때 편리
  • 정적인 데이터 저장하고, 자주 읽기 작업 일어날 경우 적합

4. wiredtiger

• MongoDB의 기본 스토리지 엔진
• LSMTree(로그 기반 병합트리) 이용
• 특징
  • 느린 읽기 성능 (보완하기 위해 블룸 필터 사용)
  • 저장 성능 향상
  • 체크포인트
    • 60초 간격으로 생성
    • 새로운 체크포인트 작성하는 동안 오류 발생하더라도 이전 체크포인트에서 복구 가능
  • 저널링 (로그)
    • 체크포인트 간의 모든 데이터 수정 사항 유지
    • 체크포인트 사이에 종료되면 저널을 사용하여 마지막 체크포인트 이후 수정된 모든 데이터 재생산 가능
  • 압축
    • WiredTiger 통해 모든 컬렉션 및 인덱스 압축 지원
  • 메모리
    • 약 50% 메모리 차지
    • RAM 최소 256MB 필요
    • 🗒️ 예시 :4GM의 RAM이 있는 시스템
    • WiredTiger 캐시 = 1.5GB 사용 (0.5 * (4GB - 1GB) = 1.5GB)

📕 인덱스

1. index 개념

• 데이터를 빠르게 찾을 수 있는 장치
• DBMS도 DB 테이블의 모든 데이터를 검색해서 원하는 결과를 빠르게 가져오기 위해, 칼럼의 값과 해당 레코드가 저장된 주소를 키와 값의 쌍으로 인덱스 생성
• 🗒️ 예시 : 책의 마지막 장에 있는 찾아보기
  • 책의 본문 속에 찾고자 하는 항목 을 빠르게 찾음
  • 인덱스를 설정하면 테이블 안에서 데이터 빠르게 찾기 가능

2. index 구조

• 균형잡힌 B-Tree 기반 구축
  • (트리 생성시) 대수확장성 특징으로 빠르게 찾기 가능
• 탐색 시간 : 평균 O(log N)

📖 참고 📖 대수확장성

• ✏️ 개념
  • 트리 깊이가 리프 노드 수에 비해 매우 느리게 성장함
  • 인덱스가 1 깊이씩 증가 ➡️ 최대 인덱스 항목의수는 4배씩 증가

📖 참고 📖 깊이

• 루트 노드로부터 특정 노드까지의 최단 거리
• 트리에서의 깊이는 노드마다 다름

3. B-Tree

• 이진 트리를 확장해 하나의 노드가 가질 수 있는 자식 노드의 최대 2보다 큰 트리 구조 (균형 잡힌 트리)
• 칼럼의 값을 변형하지 않고, 원래의 값을 이용하여 인덱싱하는 알고리즘
• 구성
  • 루트 노드
  • 리프 노드
  • 브랜치 노드
    
• 🗒️ 예시 : E 찾을 경우
  • 테이블 전체 탐색x
  • E가 있을 법한 리프 노드를 통해 탐색
  • 노드를 나눠 5번 ➡️ 2번만에 탐색 가능
    
• 🗒️ 예시 : 키 57 찾을 경우
  • 루트 노드 ➡️ 브랜치 노드 ➡️ 리프 노드 순으로 탐색
  • 57보다 같거나 클 때까지 <= 기반 검색
  • 마지막 리프 노드에 도달하여 57 데이터 포인터를 통해 결괏값 반환

📖 참고 📖 Hash 인덱스 알고리즘

• 칼럼의 값으로 해시 값을 계산해서 인덱싱하는 알고리즘 (값을 변형)
• 매우 빠른 검색 지원
• 특정 문자로 시작하는 값으로 검색을 하는 전방 일치 등 값의 일부만 검색하고자 할 때는 사용 불가
• 메모리 기반 데이터베이스에서 많이 사용
• 등호(=)연산이 아닌 부등호 연산의 경우 문제 발생

4. 최적화 기법

• 최적화 기법은 DB마다 다르지만 기본 구조는 유사함 (MongoDB 기준으로 설명)

• (1) 인덱스 = 비용

  • 인덱스는 2번 탐색하도록 강요
  • index list ➡️ collection 순으로 탐색 (관련 읽기 비용 발생)
  • ➕ collection 수정시 index도 수정 필요
  • ➕ B-Tree 높이 균형 조절 비용
  • collection 양 많을수록 인덱스 사용시 비효율적

• (2) 항상 테스팅 필수

  • 인덱스 최적화 기법은 서비스 특징(객체의 깊이, 테이블의 양 등)에 따라 달라짐
  • 🗒️ 예시 : MySQL 테스팅 방법

  EXPLAIN
  SELE

• (3) 복합 인덱스는 같음 > 정렬 > 다중 값 > 카디널리티 순서

  • 여러 필드를 기반으로 조회시 복합 인덱스 생성하는데, 생성 순서에 따라 인덱스 성능 달라짐
  • 같음을 비교(== 혹은 equal)하는 쿼리 먼저 인덱스로 설정
  • 정렬에 쓰는 필드 그 다음 인덱스로 설정
  • 다중 값 출력해야 하는 필드(> 혹은 < 등 많은 값 출력해야 하는 쿼리에 쓰는 필드) 나중에 인덱스로 설정
  • 카디널리티 높은 순서로 인덱스 생성
    • 🗒️ 예시 : age와 email 필드가 있을 경우
    • email 카디널리티(값의 유니크한 정도) 높으니 먼저 인덱스 생성

5. clustered index 와 non-clustered index 차이

• 클러스터형 인덱스

  • 기본키 값이 비슷한 레코드끼리 묶어서 저장하는 것
    • 기본키 값에 의해 레코드 저장 위치가 결정
    • 기본키 값이 변경되면 레코드의 물리적인 저장 위치 또한 변경되어야함
  • 보통 테이블의 기본키로 설정 (유일성, 최소성 만족)
  • 테이블당 1개
  • 데이터페이지가 정렬되어 저장, 인덱스 페이지의 리프노드에 "데이터 페이지" 저장 (탐색 빠름)
  • 데이터 추가할 때마다 테이블 정렬 필요 (삽입/삭제/수정 느림)
  • 인덱스의 순서와 데이터 순서가 일치함
    

• 클러스터형 인덱스 생성 방법

  • primary key : 클러스터형 인덱스

  • alter table add primary key

• 보조인덱스

  • 인덱스로 설정하는 필드의 속성이 중요
    • title, author 순서로 인덱스 설정할 경우 SELECT 질의에 따라 생성 효과 달라짐
    • title SEARCH시 index 생성 효과 있지만, author만으로 SEARCH시 index 효과 없음
  • 클러스터형키가 복합키가 될 수 있지만, 보통 보조인덱스로 복합키 사용
  • 테이블당 여러개
  • 인덱스 페이지 리프노드에 실제 데이터가 아닌 데이터 페이지에 관련된 포인터 저장
  • 정렬되어 있지 않음 (탐색 느리고, 삽입/삭제/수정 빠름)
  • 인덱스의 순서와 데이터 순서가 일치하지 않음
    

• 보조 인덱스를 만드는 방법

  • 무조건 primary key로 설정한다고 해서 클러스터형 인덱스로 설정되지X

  • create index ..
    alter table add index

6. MongoDB, Node.js 설치

• (1) MongoDB 설치
  

• (2) Node.js 설치
  

• (3) mongoose 라이브러리 설치 : Node.js환경에서 MongoDB에 접속하기 위한 역할

npm install mongoose

• (4) 실행

node mongo_index.js

📕 조인

1. join 개념

• 2개 이상의 테이블을 묶어 원하는 데이터 추출

• 종류

  • (1) 내부 조인 (inner join)

    • 왼쪽/오른쪽 일치하는 행만 표기 (교집합)
    • 두 테이블에 모두 지정한 열의 데이터 존재해야 함

      SELECT <열 목록>
      				 FROM <첫 번째 테이블>
      		INNER JOIN <두 번째 테이블>
      ON <조인 조건>
      				[WHERE 검색 조건]
      				#INNER JOIN을 JOIN이라고만 써도 INNER JOIN으로 인식합니다.

  • (2) 왼쪽 조인 (left outer join)

    • 왼쪽 테이블 기준으로 오른쪽 테이블 일치하는 레코드로 집합 생성
    • 오른쪽에 일치하는 항목이 없을 경우 null

  • (3) 오른쪽 조인 (right outer join)

    • 오른쪽 테이블 기준으로 왼쪽 테이블 일치하는 레코드로 집합 생성
    • 왼쪽에 일치하는 항목이 없을 경우 null

  • (4) 합집합 조인 (full outer join)

    • 양쪽 테이블에서 일치하는 레코드로 집합 생성
    • 일치하는 항목이 없을 경우 누락된 쪽에 null 값 포함되어 출력

  • 외부 조인 (outer join)

    • 두 테이블을 조인할 때, 1개의 테이블에만 데이터가 있어도 결과가 나옴

    			SELECT <열 목록>
    			FROM <첫 번째 테이블(LEFT 테이블)>
     <LEFT | RIGHT | FULL> OUTER JOIN <두 번째 테이블(RIGHT 테이블)>
      ON <조인 조건>
    			[WHERE 검색 조건]

  • 상호 조인 (cross join)

    • 한 쪽 테이블의 모든 행과 다른 쪽 테이블의 모든 행을 조인

    SELECT *
    			FROM <첫 번째 테이블>
    CROSS JOIN <두 번째 테이블>

  • 자체 조인 (self join)

    • 자신이 자신과 조인한 의미로, 1개의 테이블을 사용함

    SELECT <열 목록>
    			FROM <테이블> 별칭A
    INNER JOIN <테이블> 별칭B
    			[WHERE 검색 조건]

• SQL Join Visualizer 이용하여 편리하게 실행 가능

2. 중첩 루프 조인, 정렬 병합 조인, 해시 조인 차이점

• 중첩 루프 조인 (NLJ, Nested Loop Join)
  • 중첩 for문같은 원리로 조인
  • 랜덤 접근에 대한 비용 증가 (대용량 테이블에서 사용X)
  • 🗒️ 예시 : t1, t2 테이블 조인할 경우
    • 첫 번째 테이블에서 행을 한 번에 하나씩 읽고,
    • 그 다음 테이블에서도 행을 하나씩 읽은 후
    • 조건에 맞는 레코드를 찾아 결과값 반환
  • 블록 중첩 루프 조인 (BNL, Block Neted Loop) : 조인할 테이블을 작은 블록으로 나눠 블록 하나씩 조인
• 정렬 병합 조인
  • 각 테이블을 조인할 필드 기준으로 정렬 후 조인 작업 수행
  • 조인할 때 사용할 적절한 인덱스가 없을 경우, 대용량 테이블 조인할 경우 사용
  • <, > 조건에 많이 쓰임
• 해시 조인
  • 해시 테이블 기반으로 조인
  • 2개 테이블 조인시 1개의 테이블이 메모리에 온전히 들어가면 중첩 루프 조인보다 효율적
  • 2개 테이블 조인시 바이트상 더 작은 테이블을 해시테이블로 만들어 조인
  • == 조건(동등 조건)에만 사용
  • MySQL의 해시 조인 단계 : 빌드 단계 / 프로브 단계로 나뉨
    • 빌드 단계 : 입력 테이블 중 하나를 기반으로 메모리 내 해시 테이블 빌드함 (조인에 사용되는 필드가 해시 테이블의 키로 사용됨)
    • 프로브 단계 : 레코드 읽기 시작하고, 일치하는 레코드를 찾아 결과값으로 반환 (해시 함수 > 해시값 > 매칭레코드)

📕 데드락

1. deadlock 개념

• DB에서 교착 상태 : 2개 이상의 트랜잭션이 서로 잠금을 포기하기를 기다리는 상태

• 🗒️ 예시 : accounts테이블과 order테이블이 있을 경우

  • transaction A : accounts테이블의 일부 행에 잠금을 건 상태로 order테이블 일부 행을 업데이트하면 완료
  • transaction B : order테이블 잠금한 상태로 accounts테이블항목이 필요
  • 둘 중 하나를 중단하지 않는 한 모든 활동 중단되는 상태

2. 교착상태 감지

• 대규모 DB의 경우 감지할 경우 비용 많이 발생 -> 교착상태 방지 사용

• (1) 교착상태 감지 및 timeout

  • 일정 시간(timeout)이후 트랜잭션이 실행되지 않았을 경우 롤백

• (2) 그래프 기반으로 사이클 탐색

  • 그래프 내에 사이클 형성될 경우 교착상태 발생 가능
    

3. 교착상태 방지

• 최대한 교착상태가 일어나지 않도록 방지

• (1) 격리수준 변경

  • 격리 수준을 행 수준 잠금 또는 격리 수준을 조정함
  • serializable이 아닌 이상 모든 교착상테 완전히 제거 불가

• (2) 서비스의 로직을 교차되지 않게 수정

  • 서비스의 논리 구조 변경
  • accounts > order 처럼 서로 교차되지 않고 일관성 있도록 변경

• (3) wait-die 또는 wound wait 방법

  • 타임스탬프 기반으로 트랜잭션을 대기/선점/종료하는 방식
  • Wait-Die 방식 (트랜잭션 방지를 위한 비선점기법)
  • 🗒️ 예시 : 트랜잭션 T5, T10, T15에 각각 타임스탬프 있다고 가정
    • T5 -> T10 보유한 데이터 항목 요청시 : T5 대기
    • T15 -> T10 보유한 데이터 항목 요청시 : T15 죽음
  • Wound-Wait (교착상태 방지를 위한 선점 기법)
  • 🗒️ 예시 : 트랜잭션 T5, T10, T15에 각각 타임스탬프 있다고 가정
    • T5 -> T10 보유한 데이터 항목 요청시 : T10 (강제) 선점 및 일시 중단
    • T15 -> T10 보유한 데이터 항목 요청시 : T15 대기

📖 참고 📖 TIMESTAMP

• 타임스탬프 값은 1970-01-01 00:00:01 UTC 부터 시작하는 초수를 나타냄

📕 정규화

1. 정규화 과정

• 릴레이션 간의 잘못된 함수종속 관계로 인해 생긴 데이터베이스 이상 현상을 해결하는 과정
• 저장 공간을 효율적으로 사용하기 위해 릴레이션 분리하는 과정
  

2. 이상현상 (anomaly)

• 원인 : 불필요한 데이터 중복 발생

• 개념 : 릴레이션에 데이터 삽입, 갱신, 삭제 연산 수행시 부작용 발생

• (1) 삽입 이상

  • 불필요한 데이터도 같이 삽입해야함

• (2) 갱신 이상

  • 중복 레코드가 있고, 일부만 변경해 데이터 자체가 불일치되는 문제

• (3) 삭제 이상

  • 레코드 삭제시 필요한 데이터까지 함께 삭제됨

3. 함수적 종속성 (Functional Dependency)

• 릴레이션간의 관련성을 함수 종속성을 통해 파악하고, 이를 기준으로 릴레이션 분리(정규화) 필요함
• 어떤 릴레이션을 구성하는 속성의 부분집합이 X, Y일 때,
  • 하나의 X에 대해 Y가 하나라면,
  • X가 Y를 함수적으로 결정한다 (Y가 X에 함수적으로 종속되어 있다)
  • X : 결정자, Y : 종속자
• 릴레이션의 속성 값을 기반으로 결정하면 안되고, 속성 자체의 특성을 기반으로 결정함
• X->Y 관계에서 결정자 X는 기본키, 후보키가 아닐 수 있음
• 🗒️ 예시 : 이름과 등급은 아이디에 함수적 종속성을 갖는 경우
  
  • 아이디 -> 이름, 아이디 -> 등급
  • 아이디 -> {이름, 등급}
• 종류
  • 완전함수종속 : Y가 X 전체에 종속됨
  • 부분함수종속 : Y가 X 일부에 종속됨

4. 제1정규형

• 릴레이션의 모든 도메인이 더이상 분해될 수 없는 원자값만으로 구성되어야 한다.
• 릴레이션의 속성 값 중에서 1개의 기본키에 대해 2개 이상의 값을 가지는 반복 집합이 있다면 제거
• 🗒️ 예시
  
• 📌 발생 이상 현상
  • 삽입 이상 : 학생이 새 과목 수강신청시, 반드시 학과와 지도교수 필요 (불필요한 정보 삽입)
  • 삭제 이상 : 300번 학생이 C400 과목 취소시 해당 과목 정보 모두 삭제
  • 갱신 이상 : 100번 학생이 지도교수 변경시 P1 행을 찾아 모두 변경 필요
• 📌 이상현상 발생 이유
  • 기본키가 아닌 속성들이 완전 함수 종속되지 못하고, 부분함수 종속됨
  • 기본키 : {학번, 과목번호}, 지도교수와 학과가 부분함수 종속
    

5. 제2정규형

• 릴레이션이 제1정규형이며, 기본키가 아닌 모든 속성이 기본키에 완전 함수 종속되어있다.
  

• 각 속성들이 완전함수 종속되도록 릴레이션 분리

  • 분해한 릴레이션은 조인이 가능해야함
  • 조인되었을 때 분해 전의 릴레이션들로 복원이 가능해야함 (무손실 분해)
  • 🗒️ 예시
    

• 📌 발생 이상 현상

  • 삽입 이상 : 지도교수가 학과에 소속되어 있음을 추가할 때 반드시 지도학생 필요 (불필요한 정보 삽입)
  • 삭제 이상 : 300번 학생 삭제하는 경우, P3 교수의 학과 정보 삭제
  • 갱신 이상 : 지도교수의 학과가 변경되는 경우 모두 찾아서 변경 필요

• 📌 이상현상 발생 이유

  • 이행적 함수 종속 (transitive functional dependency)
    • A -> B이고, B -> C일 때, ➡ A -> C일 경우 이행적 함수 종속
    • 학번 -> 지도교수, 지도교수 -> 학과 ➡ 학번 -> 학과
      

6. 제3정규형

• 릴레이션이 제2정규형이며, 기본키가 아닌 모든 속성이 기본키에 이행적 함수 종속을 만족하지 않는 상태이다.
  

• 이행적 함수 종속 관계에 있는 속성을 분리

  • 기본키 이외의 속성이 다른 속성 결정할 수 없음
  • 🗒️ 예시
    
    

• 📌 발생 이상 현상

  • 삽입 이상 : 새로운 교수가 특정 과목을 담당하는 정보 추가하려면, 적어도 한 명 이상의 수강 학생 필요 (불필요한 정보 삽입)
  • 삭제 이상 : 학번 100이 C234 과목을 취소하려면, P2가 C234 과목을 담당하는 정보도 삭제됨
  • 갱신 이상 : P1 과목이 변경되면, P1인 행을 찾아서 변경해야 함

• 📌 이상현상 발생 이유

  • 결정자가 후보키로 취급되지 않음
  • 후보키는 이 릴레이션에서 {학번, 과목명}, {학번, 담당교수}
  • 담동교수만으로 후보키 안됨 (후보키가 아닌데 과목명 결정 가능하므로, 결정자에 속함)

7. 보이스/코드 정규형 (BCNF)

• 릴레이션이 제3정규형이고, 모든 결정자가 후보키인 상태이다.
  • 보통 하나의 릴레이션에 여러 개의 후보키가 존재할 수 있는데, 제3정규형보다 엄격함
• 🗒️ 예시 : 강사는 후보키가 아님에도 불구하고 수강명을 결정하는 결정자 역할을 함
  • 담당 교수가 후보키가 되도록 릴레이션 분해
  • 기본키 : {학번, 담당교수} 담당교수 -> 과목명
    

8. 정규화 과정 필요성

• 단점
  • 릴레이션(테이블)을 나누는 과정에서 성능⬇️
  • 조인이 많이 필요하는 쿼리일 경우, 비정규화 필요
• 장점
  • 중복 데이터가 제거됨에 따라 스토리지에 대한 전체 메모리 요구량⬇️
  • 테이블 오류 가능성⬇️