나의 4번째 공부 기록공간 - 기본 Part : 데이터베이스 (1)

백엔드 직무에서 데이터베이스가 굉장히 중요하다는 말을 많이 들었고, 부트캠프하면서도 느꼈었던 부분이다. 그렇기 때문에 좀더 집중해서 들어야겠다는 마음이 많이 들었다.
이 강의에서는 관계형 데이터베이스와 SQL문을 실무에서 많이 쓰인다고 강조했다.
그러면 데이터베이스 강의로 넘어가보자.

---

< 데이터베이스 >

• 데이터 베이스개론
  -Database(DB): 전자적으로 저장되고 사용되는 관련있는 데이터(같은 출처나 같은 목적, 같은 서비스 아래서 생성되는 데이터)들의 조직화(내가 찾고자하는 데이터를 빠르게 찾아주고 불필요한 데이터가 중복되는 것을 제거, 데이터의 불일치를 예방해줌)된 집합.

• DBMS(Database management systems)
  : 사용자에게 DB를 정의하고 만들고 관리하는 기능을 제공하는 소프트웨어 시스템.(MySQL이 여기에 해당됨)=> DB를 정의하다 보면 부가적인 데이터가 발생함. 이것을 'metadata=catalog'라 부르고 이 또한 DBMS를 통해 저장/관리된다.

• metadata: 데이터를 설명하기 위한 데이터. 사진으로 예를 들면 사진해상도, 언제 찍었는지 등등(메타데이터 안에는 데이터의 유형, 데이터베이스 구조, 제약조건, 보안,저장,인덱스, 사용자 그룹 등의 내용이 들어간다.)

• Database system: database + DBMS + 연관된 어플리케이션들
  => 줄여서 DB라고도 부름.

• DB 시스템 흐름
  사용자/운영자 => 어플리케이션 프로그램 =DB에 접근하기 위한 쿼리(요청)=> DB Manager가 쿼리 파악 => Metadata 확인 => 실제 데이터 확인 => 다시 어플리케이션 프로그램에 돌려줌.

• data models:
  DB 구조를 기술하는 데 사용될 수 있는 개념들이 모인 집합
  => DB 구조(데이터 유형,데이터 관계, 제약사항 등)를 추상화해서 표현할 수 있는 수단을 제공 => 모델링
  data model은 여러 종류가 있다. DB에서 읽고 쓰기 위한 기본적인 동작들도 포함됨.

< data models 분류 >

• conceptual(high-level): 비개발자도 쉽게 이해.추상화 가장 높게.ERD
• logical: 디테일하게 DB를 구조화(데이터가 컴퓨터에 저장될 때의 구조와 크게 다르지 않음)할 수 있는 개념들을 제공 => 백엔드에서 많이 사용(relational data model -> DBMS도 관계형데이터 모델에 대부분 맞춰짐)
• physical(low-level): 데이터 포맷,데이터 순서,index 등...

• DB Schema
  : 데이터 모델을 바탕으로 DB의 구조를 기술한 것. 스키마는 DB 설계할 때에 정해지며 자주 수정이 안됨.
• Database state: DB 실제 데이터는 꽤 자주 바뀔 수 있다.=> 특정 시점에 DB에 있는 데이터를 Database state라 함.

< 데이터베이스 구조 >
=> Three-schema architecture:
database system을 구축하는 architecture 중의 하나.
유저 어플리케이션으로부터 물리적인 database를 분리시키는 목적. 각각의 level마다 Schema가 정의되어 있다.

• three-level schema => 목적: 안정적으로 Database system을 운영하기 위해서 사용되는 구조. 각 level을 독립시켜 다른 level에 영향을 주지 않는다.
  1) external schema: 실제 사용자가 바라보는 schema.특정 각각 유저들이 필요로 하는 데이터만 표현하고 그 외 데이터는 숨긴다.
  2) conceptual schema: 각각의 유저마다 필요로 하는 데이터들이 달라져서 internal level에 중복되는 Data가 많아짐 => conceptual schema의 등장: 전체 DB에 대한 구조를 기술.entity,데이터타입, relationship, user operation들, 데이터 제약사항들에 집중
  3) internal schema: 데이터가 존재하는 곳. 실제 물리적 저장장치와 가장 가깝게 있는 Schema.실체가 있는 내용을 기술.

< Database 언어 >
DDL,SDL(relational DB에서는 parameter가 대신해줌),VDL,DML => 다 종합해서 SQL이 역할을 대신해준다.

< 관계형 데이터베이스 >
: 우선 Domain을 정의함 => Domain은 어떤 값으로 이루어진 집합.
동일한 Domain이 같은 relation에서 중복되서 사용되어도 역할(목적)이 다를 수 있다.
역할을 표시하기 위해서 relational Data model에서느 attribute 개념이 등장.

relational Data model에서 tuple을 table로 표시.
attribute: relation에서 부여된 역할
tuple: attribute 각각의 하나하나로 이루어진 리스트 => 이 전체를 relation(table이라고 함)

• relation에는 이름이 있음.

(정리) : relational data model

domain => set of atomic(더이상 나누어질 수 없는 값) values
domain name => domain 이름
attribute => domain이 relation에서 맡은 역할 이름.
tuple => 각 attribute의 값으로 이루어진 리스트, 일부 값은 Null일 수 있다.
relation => set of tuples
relation name => relation의 이름

relation Schema: relation의 구조를 나타냄.
relation의 이름과 attributes 리스트로 표기됨.
attributes와 관련된 제약사항들도 표시함.

degree of relation: relation Schema에서 attribute의 수

< relational database의 정의 >
relational data model에 기반하여 구조화된 database.
relational database는 여러개의 relation으로 구성된다.

relational database schema: relation Schemas set + integrity constraints set

< relation의 특징들 >
relation은 중복된 tuple을 가질 수 없다.
relation의 tuple을 식별하기 위해 attribute의 부분집합을 key로 설정함. -> id를 통해서 각 tuple을 유니크하게 구분하여 식별할 수 있음.
relation에서 tuple의 순서는 중요하지 않다.
하나의 relation에서 attribute의 이름은 중복되면 안 된다.
하나의 tuple에서 attribute의 순서는 중요하지 않다.
attribute는 atomic(더 이상 나누어질 수 없는)해야 한다.

Null의 의미 => 중의적인 표현이기 때문에 최대한 지양함
값이 존재하지 않는다.
값이 존재하나 아직 그 값이 무엇인지 알지 못한다.
해당 사항과 관련이 없다.

< Keys >

superkey: relation에서 tuple을 유니크하게 식별할 수 있는 attributes set(attribute들의 집합.어떤 것인지 참조하면 알 수 있다.)
candidate key: 어느 한 attribute라도 제거하면 유니크하게 tuple들을 식별할 수 없는 superkey. => key or minimal superkey라고 부름./ 독립적으로 하나하나가 tuple들을 식별할 수 없을 때.
primary key: relation에서 tuple들을 유니크하게 식별하기 위해 선택된 candidate key. -> 보통 attribute의 숫자가 적은 것을 primary key로 선택함.
unique key: primary key로 선택되지 못한 candidate 키들. alternate key
foreign key: 다른 relation의 PK를 참조하는 attribute들의 집합.

< constraints >
뜻 : relational database의 relation들이 언제나 항상 지켜줘야하는 제약사항.

-종류-
implicit constraints : relational data model 자체가 가지는 constraints / relation은 중복되는 tuple을 가질 수 없다. / relation 내에서는 같은 이름의 attribute를 가질 수 없다.
schema-based constraints : 주로 DDL을 통해 Schema에 직접 명시할 수 있는 constraints. / explicit constraints.
1)domain constraints : attribute의 value는 해당 attribute의 domain에 속한 value여야 함.
2)key constraints: 서로 다른 tuple은 같은 value의 key를 가질 수 없다.
3)Null value constraints: attribute가 Not null로 명시됐다면 Null을 값으로 가질 수 없다.
4)entity integrity constraints: primary keysms value에 Null을 가질 수 없다. 여러 PK가 Null을 가지면 tuple을 유니크하게 식별이 불가능하기 때문.
5)referential integrity constraints: FK와 PK와 도메인이 같아야 하고, PK에 없는 값들을 FK가 값으로 가질 수 없다.

constraints가 있는 이유는 데이터베이스가 일치된 형태로 존재하고 데이터의 일관성을 보장하기 위해.
백엔드 업무 시 service단에서 이 constraints를 위반하면 에러를 주는데 이를 잘 핸들링해야 한다.

< SQL로 데이터 처리하기 >

• 데이터 생성하기

• SQL의 기본개념(Structured Query Language)
  : 현업에서 쓰이는 relational DBMS의 표준언어. 종합적인 database 언어: DDL+DML+VDL

< SQL 주요 용어 >
relational data model => SQL

• relation => table
• attribute => column
• tuple => row
• domain => domain

• SQL에서 relation이란? multiset(=bag) of tuples @SQL => 중복된 tuple을 허용한다.(set과 multiset 다름: 중복허용)

< database 정리하기 >

:SHOW DATABASES 입력하면 MySQL 안에 어떤 DB 있는지 알려줌.
:CREATE DATABASE 원하는 이름 - 데이터베이스가 생긴다.
:SELECT database() - 지금 사용하겠다고 선택한 DB를 확인해 볼 수 있음. 처음에는 NULL이 뜸.
:USE 사용하고자하는DB이름 - DB 설정.
:DROP DATABASE DB이름 - DB 삭제문법

• DATABASE vs SCHEMA
  => MySQL에서는 DATABASE와 SCHEMA 같은뜻을 의미. 하지만 다른 RDBMS에서는 서로 다른 의미임.

< table 정의하기 >
: Primary key키에 밑줄(언더바)을 해줌 => 그 테이블의 각각의 tuple을 식별하기 위해서 사용되는 key.
<테이블 만드는 예시>
create table DEPARTMENT (
이름 데이터타입 각 설정들) => 각 줄은 각각의 attribute를 나타냄.

<attribute data type: 숫자>
-정수(1~8byte) :TINYINT~MEDIUMINT
-부동소수점 방식: 실수를 저장할 때 사용. 고정 소수점 방식에 비해 정확하지 않음.
-고정소수점 방식: 실수를 정확하게 저장할 때 사용(DECIMAL or NUMERIC):MySQL에서는 두개가 동일함.
ex) DECIMAL(5,2) -> (Precision: 전체숫자에서 몇자리인지(전체숫자가 몇개인지), Scale: 소수점이하 몇자리까지 표현할지)
)

< attribute data type: 문자열 >
-고정크기 문자열:CHAR(n) => 최대 몇개의 '문자'를 가지는 문자열을 저장할지를 지정. 저장될 문자열의 길이가 최대길이보다 작으면 나머지는 space로 채워서 저장함.
MySQL에서 시간적인 성능이 CHAR가 더 좋다. 가변적인 것은 VACHAR 권장.문자열 크기가 고정된것은 CHAR 권장.
-가변크기 문자열:VARCHAR(n) =>최대 몇개의 '문자'를 가지는 문자열을 저장할지를 지정. 저장될 문자열의 길이만큼만 저장.
-사이즈가 큰 문자열: MEDIUMTEXT,LONGTEXT를 고려.

< attribute data type: 날짜와 시간 >
-날짜:년/월/일 => DATE
-시간: 시/분/초 => TIME
-날짜와 시간: 날짜+시간 => DATETIME, TIMESTAMP-> Time-zone이 반영됨(UTC로 저장됨)

< 그 외 Data type >
-byte-string(보안과 관련해 암호화키를 byte-string으로 저장.) => BINARY /VARRINARY, BLOB TYPE
-boolean type -> true/false를 저장. => MySQL에는 없어서 TINYINT(0과 1로 저장)로 대체.
-위치관련 => 위치관련 정보를 저장 => GEOMETRY...etc
-JSON => JSON 형태의 데이터를 저장.
{"name":"messi","age":38} => JSON

• primary key의 제약사항

• 중복된 값을 가질 수 없으며, NULL도 값으로 가질 수 없다.
• attribute 하나로 구성될 때 : attribute 선언할 때 한번에 같이 선언.
• attribute 두개 이상으로 구성될때: 테이블 아랫쪽에 primary key라고 선언하고, primary key를 구성하는 attribute name을 적어줘야 함.

*UNIQUE KEY의 제약사항
-UNIQUE로 지정된 attribute(s)는 중복된 값을 가질 수 없다. NULL은 중복허용 할 수도 있음(MySQL은 허용함)
-UNIQUE KEY 선언하는 방법은 PRIMARY KEY랑 동일함.

*NOT NULL 제약사항
-해당 attribute NULL을 값으로 가질 수 없음.
=> 작성법: Attribute Name, TYPE, Not Null 적어준다.
(보통 NOT NULL과 UNIQUE를 같이 많이 씀)

• attribute DEFAULT: attribute의 default값을 정의할 때 사용.
  새로운 tuple을 저장할 때 해당 attribute에 대한 값이 없다면 default로 저장.
  -> DEFAULT '저장값' 으로 작성.

• CHECK constraint => attribute의 값을 제한하고 싶을 때 사용.

• attribute 하나로 구성될 때 : CHECK (조건)
• attribute 두개 이상으로 구성될때: CHECK 따로 만듬

• FOREIGN KEY => attribute(s)가 다른 table의 primary key나 unique key를 참조할때 사용.
  FOREIGN KEY 선언법 => FOREIGN KEY(A) references TABLE(attribute B)
  on delete reference-option on update reference-option.
  (이 포레인키A는 B를 참조. 삭제/수정되었을 때 어떻게 할 것인가.)

• reference-option
  1.CASCADE => 참조값 삭제/변경 그대로 반영.
  2.SET NULL => 참조값 삭제/변경 NULL로 변경.
  3.RESTRICT => 참조값 삭제/변경 NULL 금지
  4.NO ACTION => RESTRICT와 유사 (MySQL에서는 3,4번 똑같음)
  : 한 트랜잭션 안에 여러개의 SQL문이 존재 => 실행되는 동안에는 참조값이 삭제/변경 허용. 하지만 트랜잭션 끝나고 나서는 constraint 위반하면 No action
  5.SET DEFAULT => => 참조값 삭제변경되면 default값으로 변경
  (MySQL에서 지원하는 문법은 1,2,3번)

• constraint 이름 명시하기
  : 이름을 붙이면 어떤 constraint를 위반했는지 쉽게 파악이 가능.
  constraint를 삭제하고 싶을 때 해당이름으로 삭제 가능. =>constraint 위반 시에 위반 내용을 바로 명시적으로 확인이 가능.

• 참조할 table이 아직 생성이 안 되어서 FOREIGN KEY를 못 걸어줄 때, 나중에 FOREIGN KEY를 걸어줘야 함.

*ALTER TABLE table이름 변경내용
:table이 생성되고 난 뒤에 table schema의 변경이 필요할 때 사용됨.
종류가 많다.
(중요) ALTER TABLE은 서비스 중인 table의 schema를 변경하는 것이라면 변경작업 때문에 서비스의 백엔드에 영향이 없을지 검토 후에 변경하는 것이 중요.
=> 서비스를 안정적으로 유지하면서 개발을 잘해야 함.

• DROP TABLE table의이름 => table 삭제할 때에 사용.

• 중요점 => 만들 때는 서비스의 스펙이나 데이터 일관성, 편의성, 확장성 등등을 종합적으로 고려하여 DB 스키마 적절히 정의하는 것이 중요.
  시니어 개발자와 주니어 개발자를 가르는 큰 점이 DB를 얼마나 잘 설계하는가 이다.

< SQL로 데이터 생성/수정/삭제하기 >
1. 데이터 생성하기

• INSERT statement
  : INSERT INTO table_name VALUES(comma-separated all values)
  INSERT INTO table_name(attributes list: 내가 원하는 것만 넣을때) VALUES(attributes list 순서와 동일하게 comma-separated values);
  INSERT INTO table_name VALUES(...,..),(...,..),(...,..);

2. 데이터 수정하기

• UPDATE statement
  : UPDATE table_name(s) SET attribute=value[,attribute=value...(두개 이상 동시에)][WHERE condition(s)]=> 없다면 모든 tuple들 수정.

3. 데이터 삭제하기

• DELETE statement
  : DELETE FROM table_name [WHERE condition(s)]=>
  (굉장히 중요!: 데이터 수정/삭제 할 시에 where절 빼면 전체가 수정/삭제될 수 있으니 항상 조심해야 함!)