Database

[kibitzing]

Database를 배워보자 총 31강, 매일 하나씩 11월 15일 전 완강 목표!

https://www.youtube.com/watch?v=aL0XXc1yGPs&list=PLcXyemr8ZeoREWGhhZi5FZs6cvymjIBVe

[kibitzing]

1강, 오 엄청 알차다. 쭉 오버뷰 해주시는 느낌

• VDL, DDL, DML등 처음 보는 용어들이 있다. -> language들인데 RDB에서는 SQL이 셋 모두의 역할을 한다고 함
• 스키마도 그냥 스키마인줄 알았는데, external, internal 그리고 conceptual로 레이어가 나눠져 있구나.
  • 이 레이어 분리하는 걸 three-schema architecture라고 함
• 데이터 모델도 세 종류, physical, logical, conceptual (기획레벨)
• 데이터 모델이란? DB 구조를 기술하는데 사용되는 개념들의 집합, 데이터들을 잘 모델링(추상화)해둔 내용들이라고 볼 수 있다.
• DB의 정의: 전자적으로 저장되고 사용되는 관련있는 데이터들의 구조화된 집합
• 조금 써보기도 했고 좀 안다고 생각했는데, 아는게 매우 적고 배워야 할게 매우 많구나.

[kibitzing]

2강

여러 개념들을 머리에 때려박아 넣어주심..ㄷㄷㄷ

먼저 튜플 개념. cartesian product 쉽게 생각해서 DB의 한 행 (row)는 하나하나가 다 tuple이다. relation = set of tuple set 이니까 당연히 중복 안됨, 순서 중요하지 않음 수학에서 관계를 어떻게 표현하지? 생각해보면 가장 쉽고 간단한게 한데 묶어놓는 것일 거 같다.

relational data model은 이 relation이라는 개념을 가지고 데이터를 모델링한 것

주요 개념들

domain: set of atomic values

• 정의역, 어떤 값들이 올 수 있는지, class 같은 것

domain name: domain 의 이름 attribute: 도메인이 하는 (relation에서 맡은) 역할 (목적), 역할의 이름 = attribute 이름 tuple: 각 attribute 값들로 이뤄진 리스트 relation = set of tuple relation name

relation scheme: relation name + attribute list e.g. STUDENT(id, name, grade, ...)

degree of relation = len(attribute list)

relational DB: relational data model에 기반으로 구조화된 DB, 여러개의 relation으로 구성됨

RDB = relation scheme + integrity constraints set

relation은 set이므로 중복 불가, 각 tuple은 unique

• attribute 중복 불가, 순서는 안 중요
• attribute는 atomic 해야함, composite, multivalued는 허용 안됨, 실무에서는???)

Key

superkey: unique, minimum 은 아님, 전체 튜플은 슈퍼키 candidate key: minimal superkey, 그냥 key라고도 불림

• id 는 기본적으로 candidate key primary key: candidate key 중에 선택되는 것, 어떤 것으로 유니크하게 식별하는데 사용할 것인가? 보통 가장 attribute 수가 적은 것으로 고름 unique key: 선택되지 못한 candidate key foreign key: 다른 relation의 PK를 참조하는 attributes set

Constraints

• implicit constraints: RDB면 지켜야하는 것, 튜플 중복 불가, attribute 중복 불가 등
• explicit (schema based) constraints: 직접 명시한 제약들
  • domain constrainst: 당연히 정의역 안에서 값을 취해야함
  • 서로 다른 튜플은 같은 키를 가지면 안 됨 (unique option)
  • Null value constraints (Null 없음)
  • entity integrity constraints: primary 키는 원래 null 안 됨 (뭐가 프라이머리 키가 될지 지정안해주면 모르니 explicit이라 하는듯?)
  • referential integrity constraint: 참조하려는 녀석이 존재해야함

[kibitzing]

3강 SQL 쭈루룩 (1/2)

• RDB마다 조금씩 다름
  • 개념 (Database vs Scheme)
  • 데이터 타입 (MEDIUM INT 같은 거)

데이터 타입 쭉 훑어 보기

• 실수가 완전 정확해야하면 고정소수점 데이터 타입 사용 (DECIMAL or NUMERIC)
  • (precision, scale) = (총 자릿수, 소수점 이하 자릿수)
  • 표준 스펙: DECIMAL은 자릿수 좀 넘어가도 봐줌
• 문자열
  • 고정크기 문자열: CHAR, CHAR(n), 나머지 공간은 스페이스로 채움
  • 가변크기 문자열: VARCHAR, VARCHAR(n), 최대를 선언하긴 하는데, 저장할 때 채워서 저장하지는 않는다
  • 항상 VARCHAR가 좋은가? 구현에 따라 다를 수 있음 (PostgresQL은 그렇다고 함, mysql은 가능하면 CHAR 아니면 VARCHAR 쓰라고 함)
  • 사이즈가 큰 문자열: TINYTEXT, TEXT, MEDIUMTEXT, LONGTEXT 등등.. 포스트그레스는 only TEXT
• 날짜, 시간: DATE, TIME, DATETIME, TIMESTAMP, TIMESTAMP는 시간대 영향 받음
• byte-string: 암호 같은거 저장, BINARY, VARBINARY, BLOB
• boolean: MySQL은 없어서 TINYINT 사용
• 위치: GEOMETRY
• JSON

[kibitzing]

3강 SQL 쭈루룩 (2/2)

오늘도 매우 유익하다..

여러 constraints & option

• PRIMARY KEY: not null + unique
• UNIQUE: null 도 허용 안할 때도 있고 하나만 허용할 때도 있다, 널인 데이터도 두개면 안되는 ㅎㅎ
• NOT NULL
• CHECK
• DEFAULT option

CHECK(start_date < end_date)

PRIMARYKEY(empl_id, proj_id) 이렇게도 됨

• foreign key
  • cascade, set null, restrict, no action, default
  • 애초에 없으면 참조 안 됨
  • 삭제하거나 변경할 때,
  • 같이 변하거나, 널로 재설정 되거나, 못바꾸게 하거나, SQL동작 중에만 바꿀 수 있게 하거나, 디폴트로 바꾸거나

on delete OPTION on update OPTION

FOREIGN KEY (dept_id) references DEPARTMENT(id)
on delete SET NULL on update CASCADE,
CHECK(salary >= 5k)

constraint 에 이름 붙이기

age CONSTRAINT age_over_20 CHECK(age > 20)

• 이름 붙여 놓으면 어떤 constraint 위반했는지 에러메시지에서 알려줌
• 붙이는게 좋다.
• 안붙여도 show create table <table 이름>; 하면 어떤거 위반했는지 알려주긴 함

ALTER TABLE department ADD FOREIGN KEY(leader_id)
REFERENCES employee(id)
on update CASCADE
on delete SET NULL;

이런식으로 테이블 스키마 변경할 때 사용

• ALTER TABLE
  • ADD, RENAME COLUMN, MODIFY COLUMN, RENAME TO, ... 물론 삭제도 가능
  • 서비스 중인 DB 변경할 때는 위험함..
  • 영향 없는지 잘 확인해야함..!

테이블 삭제: DROP

• 완벽한 룰은 없다.
• 스펙, 데이터 일관성, 편의성, 확장성 등등을 종합적으로 고려해서 DB 스키마 적절하게 정의하는게 중요!!