우리가 사용하는 정보의 총 집합 또는 데이터의 집합이라 할 수 있다 (저장소)
한 개의 DB가 한 테이블과 비슷한 형태로 생겼다.
- 엑셀시트와 비슷함
- 특정 비고를 개인으로 첨가할 수 있음
- DB간의 관계가 없음
(Relation DataBase Management System)
- 관계형 데이터 모델에 기초를 둔 DB (ex: MySQL, Postgres, Oracle DB)
- 여러개의 DB가 관련이 되어있는 것
주 테이블에서 가지고 있는 PK키를 연결 시킬 테이블에 참조 값으로(FK)로 받아 연결한다
A 테이블 하나의 row와 하나의 B 테이블 row가 서로 연결 되는 것
A 테이블 데이터가 여러 개의 B 테이블 데이터와 연결되어있는 경우, B 테이블 데이터는 오로지 하나의 A 테이블 데이터와 연결된다.
PK 값이 FK이 되었을 때 B 테이블이 A 테이블을 참조한다.
FK가 중복이 되어야한다.
하나의 A 테이블 데이터가 여러 개의 B 테이블 데이터가 연결되고, 하나의 B 테이블 데이터가 여러 개의 A 테이블 데이터가 연결된다.
중복되는 데이터 cell에서 유니크 값만 바뀌고 여러 줄로 적게되지 유니크 값을 같은 cell에 적을 수 없다. => Notmailzation: 중간 테이블을 만들어서 각각의 FK를 주어짐으써 둘 테이블 데이터가 참조해서 연결할 수 있게 만든다.
하나의 테이블에 모든 정보를 다 넣으면 동일한 정보들이 불필요하게 중복되어 저장되기에 디스크를 오버해서 사용하고 잘못된 데이터가 저장 될 가능성이 높아지게 때문
(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로 구조를 짜서 디스크를 더 효율적이고 부분적으로 다른 데이터가 생겼을 때 쓰면 좋은 것 같다.