데이터베이스 기본 개념
우리가 사용하는 정보의 총 집합 또는 데이터의 집합이라 할 수 있다 (저장소)
한 개의 DB가 한 테이블과 비슷한 형태로 생겼다.
DB를 왜 쓰는가?
- 데이터를 오랜기간 저장 및 체계적으로 보존하기 위해서
- RAM(가상 메모리)처럼 컴퓨터를 끄고 켰을 때 없어지지않고 하드디스크에 저장한 것처럼 남아있지 않고 휘발성 요소라 없어지게 된다.
- 메모리는 속도가 엄청 빠름, 효율이 좋음
비관계형 데이터베이스 (NoSQL)
- 엑셀시트와 비슷함
- 특정 비고를 개인으로 첨가할 수 있음
- DB간의 관계가 없음
장점
- 구조를 먼저 정하지 않아 데이터의 구조 변화에 유연 => 확장하기 비교적 쉬움
- 그러므로 방대한 양의 데이터를 저장하는데 유리
단점
- 트랜잭션(일련의 작업들을 한번에 하나의 unit으로 실행하는것) 안되거나 불안정
- 데이터의 완전성(모든게 참인 경우)이 덜 보장
관계형 데이터베이스 (RDBMS)
(Relation DataBase Management System)
- 관계형 데이터 모델에 기초를 둔 DB (ex: MySQL, Postgres, Oracle DB)
- 여러개의 DB가 관련이 되어있는 것
장점
- 데이터를 더 효율적, 체계적으로 저장하여 관리할 수 있다.
- 미리 데이터들의 구조(테이블 스키마)를 정의 함으로써 데이터의 완전성을 보장할 수 있다.
단점
- 테이블 구조 변화 등에 유연하지 않다.
- 미리 정의 되어있다 보니 단순히 서버 늘리는 것 만으로 확장이 쉽지 않고 서버의 성능 자체도 높여야 한다.
- Scale up (서버의 성능을 높이는 것)으로 확장성이 됨
특징
- 모든 데이터는 2차원 테이블로 표현할 수 있다.
- column: 테이블의 각 항목
- row : 각항목의 값
- Primary Key: 고유 값 (숫자)
연결되는 방법
주 테이블에서 가지고 있는 PK키를 연결 시킬 테이블에 참조 값으로(FK)로 받아 연결한다
일대일 관계 (One to One)
A 테이블 하나의 row와 하나의 B 테이블 row가 서로 연결 되는 것
일대다 관계 (One to Many)
A 테이블 데이터가 여러 개의 B 테이블 데이터와 연결되어있는 경우, B 테이블 데이터는 오로지 하나의 A 테이블 데이터와 연결된다.
PK 값이 FK이 되었을 때 B 테이블이 A 테이블을 참조한다.
FK가 중복이 되어야한다.
다대다 관계 (Many to Many)
하나의 A 테이블 데이터가 여러 개의 B 테이블 데이터가 연결되고, 하나의 B 테이블 데이터가 여러 개의 A 테이블 데이터가 연결된다.
중복되는 데이터 cell에서 유니크 값만 바뀌고 여러 줄로 적게되지 유니크 값을 같은 cell에 적을 수 없다. => Notmailzation: 중간 테이블을 만들어서 각각의 FK를 주어짐으써 둘 테이블 데이터가 참조해서 연결할 수 있게 만든다.
one to one 관계가 아닌 복잡하게 다른 관계의 방법으로 만드는가?
-
하나의 테이블에 모든 정보를 다 넣으면 동일한 정보들이 불필요하게 중복되어 저장되기에 디스크를 오버해서 사용하고 잘못된 데이터가 저장 될 가능성이 높아지게 때문
(ex: 고객의 아이디는 동일하지만 다른 데이터의 row를 가지고 있을 때) -
여러 테이블에 나누어서 저장한후 필요한 테이블 끼리 연결 시키면 중복된 데이터를 저장하지 않음으로 디스크를 더 효율적으로 쓰고, 부분적으로만 내용이 다른 데이터가 생기는 문제가 없어집니다.
-
normalization(정규화)라 부른다.
과제
스타벅스 코리아 음료 페이지를 모델링 하기
FE 3명 / BE 3명에서 팀을 짜서 스타벅스 코리아 음료 페이지만 모델링 해야하는데 처음 해보는거라 쉽지도 않고 one to many 개념과 many to many가 헷갈렸고 '멘토님이 one to many로 구조를 짜주세요!'라고 하셔서 분명 알러지는 겹치는게 많아 many to many를 해야 더 장점이 많아질 것 같은데 일부러 꼬아서 문제를 낸거라 생각해 모든 구조를 one to many로 하였다.
그래서 겹치는 부분을 중간 테이블에서 각 참조키를 받는 형태인 Many to Many가 아닌 one to Many로 하기위해서 생각한 방법은
1. 각각 다른 알러지 테이블을 만들어 속한 것은 true값을 받고 아닌 것은 false로 받는 것
👉 알러지가 7 ~ 8 종류가 있었는데 각 table을 만들고 그 값을 제외하고 fasle로 줘야하기 때문에 데이터를 잡아 먹지 않을까?라는 의문을 품었다.
2. 알러지의 경우의 수를VARCHAR()로 문자형식을 써줘서 참조키를 쓰는 것
👉 경우의 수가 너무 많아 지긴 하지만 하나의 table, column에 쓸 수 있어 알러지가 많아지면 이 방법이 더 낫겠다는 생각이 들었다.
하지만 결론적으로 하면서도 생각든건 겹치는게 많은 항목들은 Many to Many로 구조를 짜서 디스크를 더 효율적이고 부분적으로 다른 데이터가 생겼을 때 쓰면 좋은 것 같다.
