3 Tier Architecture
| Client | Server | DB |
|---|---|---|
| 서버에 요청 | DB에 쿼리를 보내고 받은 결과를 클라에 응답 | 쿼리문을 토대로 필터링을 해서 서버에 응답 |
데이터베이스가 필요한 이유
1. In-Memoery
JavaScript에서 데이터를 다룰 때에는 프로그램이 실행될 때에만 존재하는 데이터
=> JavaScript에서 변수를 만들어 저장한 경우, 프로그램이 종료될 때 해당 프로그램이 사용하던 데이터도 사라진다. 이 말은 변수 등에 저장한 데이터가 프로그램 실행에 의존
2. File I/O
파일을 읽는 방식으로 작동하는 형태
단점: 항상 모든 데이터를 가져온 뒤 서버에서 필터링 필요, 복잡하고 데이터량이 많아질수록 데이터를 불러들이는 작업이 점점 힘들어지고 비효율적
DB: 한번에 여러 개의 테이블을 가질 수 있기 때문에 SQL 을 활용해 데이터를 불러오기 수월
=> 필터링 외에도 File I/O로 구현이 힘든 관리를 위한 여러 기능들을 가지고 있는 데이터에 특화된 서버(영속성)
관계형 데이터베이스
관계형 데이터베이스에서는 테이블의 구조와 데이터 타입 등을 사전에 정의하고, 테이블에 정의된 내용에 알맞은 형태의 데이터만 삽입 가능
관계형 데이터베이스는 행(row)과 열(column)로 구성된 테이블에 데이터를 저장한다. 각 열은 하나의 속성에 대한 정보를 저장하고, 행에는 각 열의 데이터 형식에 맞는 데이터가 저장
관계형 데이터베이스에서는 SQL을 활용해 원하는 정보를 쿼리 가능 => 스키마가 뚜렷하게 보인다 => 관계형 데이터베이스에서는 테이블 간의 관계를 직관적으로 파악가능
ex) 대표적인 관계형 데이터베이스는 MySQL, Oracle, SQLite, PostgresSQL, MariaDB 등
특징
1. 데이터 저장(Storage)
관계형 데이터베이스는 SQL을 이용해서 데이터를 테이블에 저장 => 미리 작성된 스키마를 기반으로 정해진 형식에 맞게 데이터를 저장
2. 스키마(Schema)
SQL을 사용하려면, 고정된 형식의 스키마가 필요 => 처리하려는 데이터 속성별로 열(column)에 대한 정보를 미리 정해두어야 함 => 스키마는 나중에 변경할 수 있지만, 이 경우 데이터베이스 전체를 수정하거나 오프라인(down-time)으로 전환할 필요
3. 쿼리(Querying)
관계형 데이터베이스는 테이블의 형식과 테이블간의 관계에 맞춰 데이터를 요청해야 한다. 그래서 정보를 요청할 때, SQL과 같이 구조화된 쿼리 언어를 사용
4. 확장성(Scalability)
일반적으로 SQL 기반의 관계형 데이터베이스는 수직적으로 확장 => 높은 메모리, CPU를 사용하는 확장 => 데이터베이스가 구축된 하드웨어의 성능을 많이 이용하기 때문에 비용이 많이 듬
SQL 기반의 관계형 데이터베이스를 사용하는 케이스
- 데이터베이스의
ACID성질을 준수해야 하는 경우 - 소프트웨어에 사용되는 데이터가 구조적이고 일관적인 경우
데이터베이스 설계
스키마: 데이터베이스에서 데이터가 구성되는 방식과 서로 다른 엔티티 간의 관계에 대한 설명(데이터베이스의 청사진) / 엔티티(Entity)는 고유한 정보의 단위
- 데이터(data): 각 항목에 저장되는 값
- 테이블(table; 또는 relation) : 사전에 정의된 열의 데이터 타입대로 작성된 데이터가 행으로 축적
- 칼럼(column; 또는 field) : 테이블의 한 열
- 레코드(record; 또는 tuple) : 테이블의 한 행에 저장된 데이터
- 키(key) : 테이블의 각 레코드를 구분할 수 있는 값(고유한 값) => 기본키(
primary key)와 외래키(foreign key) 등
테이블 관계 종류
1:1 관계
하나의 레코드가 다른 테이블의 레코드 한 개와 연결된 경우
1:N 관계
하나의 레코드가 서로 다른 여러 개의 레코드와 연결된 경우 => 관계형 데이터베이스에서 가장 많이 사용
M:N 관계
여러 개의 레코드가 다른 테이블의 여러 개의 레코드와 관계가 있는 경우
M:N(다대다) 관계를 위해 스키마를 디자인할 때에는, Join 테이블을 만들어 관리
다대다 관계는 두 개의 일대다 관계와 그 모양이 같다.
다대다 관계를 위한 테이블을 조인 테이블 / 조인 테이블을 생성하더라도, 조인 테이블을 위한 기본키가 있어야함
자기참조 관계(Self Referencing Relationship)
같은 테이블 내에서의 관계
Foreign Key: 다른 테이블과 참조되는 키
Primary Key: 기본 키(고유) / 다중키 가능
REFERENCES 라고 하는 SQL을 사용해서 FOREIGN KEY로 다른 테이블과 관계를 형성
데이터베이스 정규화(Database Normalization)시 고려사항
1. Data Redundancy
데이터 중복(data redundancy)은 실제 데이터의 동일한 복사본이나, 부분적인 복사본
장점: 중복으로 데이터를 복구할 때에 더 수월
단점: 일관된 자료 처리의 어려움, 저장 공간 낭비, 데이터 효율성 감소
2. Data Integrity
데이터 무결성(data integrity)은 데이터의 수명 주기 동안 정확성과 일관성을 유지하는 것
=> 입력된 데이터가 오염되지 않고, 입력된 그대로 데이터를 사용할 수 있다
3. Anomaly
데이터 이상 현상(anomaly)은 기대한 데이터와 다른, 이상 현상
1. 갱신 이상(update anomaly)
갱신 이상(update anomaly)은 여러 행(레코드)에 걸쳐 동일한 데이터가 있을 때, 어떤 행을 갱신해야 하는지 논리적인 일관성이 없는 경우에 발생
2. 삽입 이상(insertion anomaly)
삽입 이상(insertion anomaly)은 데이터를 삽입하지 못하는 경우
3. 삭제 이상(deletion anomaly)
삭제 이상(deletion anomaly)은 데이터의 특정 부분을 지울 때 의도치 않게 다른 부분도 함께 지워지는 이상 현상
SQL
SQL(Structured Query Language) : 구조화된 쿼리(저장되어있는 정보를 필터하기 위한 질문) 언어
=> 데이터베이스용 프로그래밍 언어 => 데이터베이스에 쿼리를 보내 원하는 데이터만 추출하거나 수정 가능
데이터가 구조화된(structured) 테이블을 사용하는 주로 관계형 데이터베이스에서 사용
SQL 문법
SELECT는 데이터셋에 포함될 특성을 특정 -*는 와일드카드 (wildcard) 로 전부 선택할 때에 사용
FROM뒤에는 결과를 도출해낼 데이터베이스 테이블을 명시
WHERE은 필터 역할을 하는 쿼리문(optional)
ORDER BY는 돌려받는 데이터 결과를 어떤 기준으로 정렬하여 출력할지 결정(optional)
LIMIT은 결과로 출력할 데이터의 갯수를 정할 수 있다.(optional)
쿼리문에서 사용할 때에는 가장 마지막에 추가
SELECT DISTINCT유니크한 값을 받고 싶을 때 사용
INNER JOIN이나JOIN둘 이상의 테이블을 서로 공통된 부분을 기준으로 연결LEFT OUTER JOIN: LEFT INCLUSIVE을 실행
RIGHT Outer JOIN: RIGHT INCLUSIVE을 실행
CASE
CASE 를 사용하면, 특정 조건에 따라 다른 결과를 받을 수 있다.
CASE, WHEN(조건), THEN(결과), ELSE(나머지), END(CASE 종료)
IN은 특정한 값이 서브쿼리에 있는지 확인 가능 /NOT IN은 반대
EXISTS또는NOT EXISTS는 돌려받은 서브쿼리에 존재하는 레코드를 확인
조회하려는 레코드가 존재한다면 참(TRUE)을, 그렇지 않은 경우에는 거짓(FALSE)을 리턴
- DROP vs TRUNCATE vs DELETE
| * | DROP | TRUNCATE | DELETE |
|---|---|---|---|
| 실행 시 | 테이블 정의 자체 삭제 | 테이블을 초기 상태로 만듦 | 데이터만 삭제 |
| 예제 | DROP TABLE STUDENT; | TRUNCATE TABLE STUDENT; | DELETE FROM STUDENT; |
| 로그 | 남기지 않음 | 남기지 않음 | 남김 |
| 속도 | 빠름 | 빠름 | 느림 |
SUBQUERY
쿼리문을 작성할 때, 포함할 수 있는 다른 쿼리문을 SUBQUERY(서브쿼리)
서브쿼리는 실행되는 쿼리에 중첩으로 위치해, 정보를 전달 / 서브쿼리는 소괄호로 감싸야 함
서브쿼리의 결과는 개별 값이나 레코드 리스트 / 서브쿼리의 결과를 하나의 칼럼으로 사용가능
FROM에도 서브쿼리를 사용가능
SQL 내장함수
집합연산: 레코드를 조회하고 분류한 뒤, 특정 작업을 하는 연산
GROUP BY: 데이터를 조회할 때 그룹으로 묶어서 조회
HAVING: GROUP BY 로 조회된 결과를 필터링
COUNT(): 레코드의 갯수를 헤아릴 때 사용
SUM(): 레코드의 합을 리턴
AVG(): 레코드의 평균값을 계산하는 함수
MAX(),MIN(): 각각 레코드의 최대값과 최소값을 리턴
SELECT문 실행/동작 순서
FROM => WHERE => GROUP BY => HAVING => SELECT => ORDER BY
SQL 문법 종류
1. Data Definition Language(DDL)
DDL(Data Definition Language)은 데이터를 정의할 때 사용하는 언어
데이터베이스의 테이블과 같은 오브젝트를 정의할 때 사용
예) CREATE, DROP 등
2. Data Manipulation Language(DML)
DML(Data Manipulation Language)은 데이터베이스에 데이터를 저장할 때 사용하는 언어
예) INSERT, DELETE, UPDATE 등
3. Data Control Language(DCL)
DCL(Data Control Language)은 데이터베이스에 대한 접근 권한과 관련된 문법
예) GRANT, REVOKE 등
4. Data Query Language(DQL)
DQL(Data Query Language)은 정해진 스키마 내에서 쿼리할 수 있는 언어
예) SELECT 등
5. Transaction Control Language(TCL)
TCL(Transaction Control Language)은 DML을 거친 데이터의 변경사항을 수정할 수 있다.
예) COMMIT, ROLLBACK 등
트랜잭션 / ACID
트랜잭션: 데이터베이스의 상태를 변환시키는 논리적 기능을 수행하기 위해 행해지는 하나 이상의 쿼리를 모아 놓은 하나의 작업 단위(여러 개의 작업을 하나로 묶은 실행 유닛)
=> 작업이 하나라도 실패를 하게 되면 트랜잭션도 실패이고, 모든 작업이 성공적이면 트랜잭션 또한 성공
=> 데이터베이스 트랜잭션은 ACID라는 특성을 가짐
ACID는 데이터베이스 내에서 일어나는 하나의 트랜잭션(transaction)의 안전성을 보장하기 위해 필요한 성질
1. Atomicity(원자성)
하나의 트랜잭션 내에서는 모든 연산이 성공하거나 모두 실패해야 한다.
SQL에서도 마찬가지로 특정 쿼리를 실행했는데 부분적으로 실패하는 부분이 있다면, 전부 실패하도록 구현되어 있다. 때때로 충돌 요인에 대해서 선택지를 제공한다.
2. Consistency(일관성)
하나의 트랜잭션 전 후에 데이터베이스의 일관성 상태가 유지되어야 한다.
=> 트랜잭션이 일어난 이후의 데이터베이스는 데이터베이스의 제약이나 규칙을 만족해야 한다
3. Isolation(격리성, 고립성)
각각의 트랜잭션은 독립적 => 서로의 연산을 확인받거나 영향을 줄 수 없다.
4. Durability(지속성)
하나의 성공된 트랜잭션에 대한 로그가 기록되고 영구적으로 남는다.
