스타벅스 서비스 모델링

• 필수 구현 사항 : 음료, 카테고리, 영양 정보, 알러지, 음료 이미지, 음료 설명, 신상 여부
• 구현 제외 사항 : 프로모션, 음료 사이즈

우리 팀의 모델링

1. 1대1 관계인 데이터를 전부 음료 테이블에 포함하면 전체적인 데이터를 한 눈에 파악 가능한 장점이 있어 다 넣어줬다. (특히, 자주 조회하는 데이터일 경우는 한 테이블에 모두 포함되도록 하는 것이 좋다.)

2. 모델링 초반에는 음료 이미지를 음료와 1대1 관계의 데이터로 생각하고 음료테이블에 포함시켰지만, 이미지는 추후 확장성을 고려해 별개의 테이블로 생성했다. (이미지의 개수가 2개 이상이 될 경우를 대비)

3. 알러지는 음료와 다대다 관계이므로 중간테이블을 작성해서 두 테이블을 연결했다.

4. 각 테이블을 계층화해서 더 상위 테이블이 PK를 갖고 하위 테이블에 FK를 포함시켜 (하위테이블 → 상위테이블)의 방향을 갖게 설정하였다. 하지만 그 반대의 방향이어도 상관은 없다.

5. 영양 정보는 음료와 1대1 관계이기 때문에 음료 테이블에 영양 정보를 모두 포함시켜줬다. 대신, 사이즈를 고려하게 되면 1대1 관계에서 1대다 관계로 달라지기 때문에 외부테이블에 작성한다.

모델링 코드

Table drinks {
  id int [pk, increment]
  korean_name varchar
  english_name varchar
  drink_info text
  is_new tinyint
  category_id int
}

Table categories {
  id int [pk, increment]
  name varchar
}

Table images {
  id int [pk, increment]
  image_url varchar
  drink_id int
}

Ref: "drinks"."category_id" > "categories"."id"
Ref: "images"."drink_id" > "drinks"."id"

Table allergies {
  id int [pk, increment]
  name varchar
}

Table allergy_drink {
  id int [pk, increment]
  drink_id int
  allergy_id int
}

Ref: "drinks"."id" < "allergy_drink"."drink_id"
Ref: "allergies"."id" < "allergy_drink"."allergy_id"

Table nutritions {
  id int [pk, increment]
  kcal decimal
  sugar decimal
  protein decimal
  sodium decimal
  fat decimal
  caffeine decimal
  drink_id int
}

Ref: "drinks"."id" - "nutritions"."drink_id"