[Database] 스타벅스 서비스 모델링

스타벅스 음료 페이지 모델링

필수 구현 사항 :
음료, 카테고리, 영양 정보, 알러지, 음료 이미지, 음료 설명, 신상 여부

초기에 구상한 모델은 위와 같다.

• 음료 테이블 column :
  카테고리, 영양 정보, 알러지 유무 및 요인, 음료 이미지, 음료 설명, 신상 여부

• 카테고리 - 음료 : 일대다

• 음료 - 영양 정보 : 일대일

• 음료 - 알러지 : 다대다

1. 한 카테고리에는 여러 음료수가 포함될 수 있으나 한 음료는 한 가지의 카테고리만 가질 수 있으므로 일대다로 판단하였다.
2. 한 음료에 대한 영양 정보(숫자)는 한 가지만 존재하므로, 일대일 관계로 판단하였다.
3. 알러지의 경우, 한 음료가 한 가지 알러지 요인만 포함할 수도, 복수의 요인을 포함할 수도, 어떤 알러지 요인도 포함하지 않을 수도 있다. 또한 여러 알러지 요인이 각각 여러 음료에 포함될 수 있으므로. 음료와 알러지 데이터의 관계는 다대다인 것으로 판단하였다. 따라서 중간 테이블을 만들어주었다.

모델링 세션 이후, 새롭게 알게 되거나 궁금했던 점은 다음과 같다.

1. 음료 이미지
   음료 이미지의 경우, 한 음료가 한 장만 가지는 '썸네일 이미지'와 여러 장을 가질 수 있는 '제품 이미지'로 나눌 수 있다.
   썸네일 이미지의 경우 음료와 일대일 관계, 제품 이미지의 경우 음료와 일대다 관계가 될 것이다.
2. 신상 여부?
   처음엔 위와 같이 boolean으로 처리했으나, 이럴 경우 이력 관리 시 신상 여부를 판단하기 위해 매일같이 데이터를 전부 스캔해야 할 수가 있다.
   따라서 '생성 시점' column을 만들어 관리한다면, 생성 후 일정 시간이 지나면 자동으로 신상이 아니도록 바뀌는 등의 로직을 걸어 훨씬 용이하게 관리할 수 있다.
3. 알러지 유발 요인 유무 여부
   이 경우 boolean으로 유무 여부를 판단한 후 데이터를 보내는 방법은 오히려 번거롭다. 알러지 관련 테이블에 값이 null인 키를 만들어 값이 null일 경우 유발 요소가 없다고 표시되는 등의 로직을 거는 편이 훨씬 불필요한 행동을 줄일 수 있다.

세션 후 다시 구축해본 데이터베이스는 다음과 같다.