여기서 관계란, 데이터들 간의 관계를 뜻한다.
id
,책 제목
,작가
,출판사
,가격
)primary key
)를 보유하고 있다. 이와 같은 pk(primary key)
를 통해 특정 로우를 찾거나 인용하는 게 가능하다.1. One to One(일대일)
- ex) 대한민국 사람은 주민등록번호를 오로지 단 한개만 가질 수 있다; 서로가 서로의 오로지 한 로우에만 연결될 수 있음.
2. One to Many(일대다)
- ex) 두 마리의 반려동물(다)을 기르고 있는 주인(일); 로우 하나에 다른 테이블의 로우 여러개가 연결될 수 있음.
3. Many to Many(다대다)
- ex) 한 작가는 여러 권의 책을 쓸 수 있다. + 한 책에도 작가는 여러명이 될 수 있다. 중복되는 데이터를 서로 다른 데이터로 인식하는 것을 방지하기 위해 다대다 관계가 필요함.
외래키(foreign key)
란, 두 테이블을 서로 연결하는 데 사용되는 키를 뜻함.
-> normalization(정규화)
의 필요성이라고 볼 수 있다.
db.diagram
으로 스타벅스 음료 페이지 모델링음료
, 카테고리
, 영양 정보
, 알러지
, 음료 이미지
, 음료 설명
, 신상 여부
스타벅스 홈페이지에 들어가 음료
카테고리
부터 찾았다. 처음에는 음료
카테고리 부분을 구현하기 위해 beverages
라는 테이블을 만들고 눈에 보이는대로 무작정 콜드브루
, 브루드 커피
, 에스프레소
... 를 전부 다 입력했다가 데이터를 입력하는 게 아니라는 피드백을 받고 싹 다 지웠다.
id
, categories_id
, beverages_id
등)을 생성해서 관계가 있는 테이블들끼리 링크를 걸어줬다.description
테이블도 따로 생성했다가 상세설명(description)같은 경우에는 음료마다 상세설명이 각기 다 다를 것이기 때문에 굳이 별도의 테이블로 빼지 않고 beverages
테이블 안에 포함시키는 것이 효율적일 것이라는 피드백을 받고 description
을 beverages
테이블 안으로 집어넣었다.allergies
테이블 안에는 우유
, 대두
, 우유, 대두
와 같이 동일한 데이터를 갖고 있는 음료들이 많기 때문에 일대다 관계를 형성하는 것보다는 다대다 관계를 맺는 게 추후에 기능적인 부분을 구현하는 것을 포함한 유지보수가 용이하다는 설명을 듣고 beverages
와 allergies
테이블 사이에 beverages_allergies
테이블을 위치시켜 연결해주었다. ex)
우유
알러지를 유발할 수 있는 음료들을 모두 모아주는 기능을 구현하고자 할 때,우유
라는str
을 파싱하여 한 곳에 집어넣고 도출하는 것보다는 다대다 관계로 데이터를 관리하여우유, 대두
+우유
데이터를 한번에 도출하는 것이 기능적인 면에서 훨씬 효율적임.
신상여부
를 알기 위해서는 해당 메뉴가 신상이 맞는지/아닌지를 가려내는 boolean
데이터를 사용하는 것보다는 datetime
데이터를 이용하여 특정 날짜를 기준으로 신상메뉴를 판별하는 게 더 논리적이다.drink_images
테이블 안의 sequence
는 몇번째 사진을 썸네일로 할지 고정시키기 위함이다. (썸네일은 생각도 못했는데(!))
💬 데이터베이스 수업을 들은 후,
주로 백엔드 쪽에서 다루는 부분이긴 하지만 그래도 함께 이해하고 있는 게 나중에 프론트 작업을 할 때 용이하겠다는 생각이 들었다. 그리고 알고는 있었지만 생각보다 훨씬 더 논리적인 사고를 요구하는 분야라는 것을 다시 느꼈다... 어려워🥲
foreign key
의 사용 이유?는 아직 이해가 잘 가지 않는다. 조금 더 찾아봐야 할 듯.