[DB] AQueryTool : 스타벅스 모델링

AQueryTool을 사용해서, 스타벅스 음료 페이지의 정보를 관계형 데이터 모델로 제작해 본 과제(실습)였다.

---

🧑‍💻 스타벅스 모델링 과제

출처 : 스타벅스 공식 홈페이지 (https://www.starbucks.co.kr/menu/drink_view.do?product_cd=9200000002487)

 

- 아이디어

• 네비게이션 바의 MENU -> 음료(대분류), 다시 음료(대분류) -> 콜드 브루 등(중분류) 이렇게 두 개의 카테고리의 필요성을 느꼈다.
• 음료 페이지를 켜서, 컬럼이 필요할만한 데이터들을 선정했다. (이미지, 이름, 설명, 사이즈 등)
• 고유 데이터는 기본적으로 items 테이블에 넣겠지만, 중복요소들은 one to many, many to many 등으로 별도 table을 만들겠다.

 

- 수행결과

 

0. Main_Categories, Sub_Categories : MENU-음료-콜드브루 같은 카테고리 분류를 위한 테이블 (One to Many)

• id : 프라이머리 키 값
• name : 카테고리 명
• main_id : Sub_Categories 에서 Main_Categories의 프라이머리 키(id)를 가져와서 활용.

1. Items 테이블 : 음료 고유 정보들을 할당했다. 중복되거나(Sizes, Allergies) 컬럼이 길어지는(Nutritions) 정보는 별도 테이블로 연결

• id : 프라이머리 키 값 / Allergies, Nutritions, Limited 테이블들과 many to many 연결에도 사용됨
• main_id : 포린 키 값. Main_Categories 테이블과 one to many 연결(Sub_Categories 경유)
• sub_id : 포린 키 값. Sub_Categories 테이블과 one to many 연결
• image : 음료 이미지. 미디어 파일이기 때문에 자료형을 BLOB 설정
• name_kr, name_en : 음료 이름
• desc_short : 음료 밑의 간단한 description
• size_id : 포린 키 값. Sizes 테이블과 one to many 연결
• desc_long : 음료 최하단 긴 description. 글길이가 길 것을 가정해 자료형을 MEDIUMTEXT 설정
• price : 음료 가격에 대한 컬럼. 실제 스타벅스 음료는 사이즈별로 다르기에, many to many 로 연결되는 것이 맞다고 생각한다
• region_jeju : 제주 한정음료 여부. boolean 값을 표현하기 위해 자료형을 TINYINT(0,1)로 설정

2. Sizes 테이블 : 음료 사이즈 정보가 중복되어 별도 테이블화 (One to Many)

• id : 프라이머리 키 값 / Nutritions 테이블과는 many to many 연결에도 사용
• size : 음료 사이즈 값 (tall, grande, venti 등)
• amount_ml, amount_oz : 사이즈에 해당하는 용량값

3. Limited 테이블 : 시즌 한정음료 여부가 중복되어 별도 테이블화 (One to Many)

• id : 프라이머리 키 값
• limited_edition : 시즌 한정음료 여부. boolean 값을 표현하기 위해 자료형을 TINYINT(0,1)로 설정
• name_event : 시즌 이벤트 명 (해당없음, 크리스마스, 할로윈 등)
• date_start, date_end : 시진 이벤트 기간. 날짜값을 저장하므로 자료형을 DATE 설정

4. Nutritions 테이블 : 영양소 정보가 6가지로 컬럼이 길어져 별도 테이블화. 본래는 One to One 관계

  * Sizes 테이블과 연결시켜 용량별 다른 영양소 값을 다층적이로 관리하기 위해 수정, Many to Many가 되었다.

• id : 프라이머리 키 값
• nutritions 1~6 : 각 영양소 종류에 해당하는 양

5. Allergies 테이블 : 알레르기 유발요소가 서로 중복되어 별도 테이블화 하였다. (Many to Many)

• id : 프라이머리 키 값 / Items 테이블과 many to many 연결
• allergy_ingredient : 알레르기 유발 성분 값 (우유, 두유, 대두 등)

---

🧐 리뷰 및 소감

 

1. Nutritions 테이블 분리에 대해

 

영양성분들은 각 음료들의 고유 데이터이므로 items 테이블에 포함되어도 상관은 없다. 하지만, 1) 테이블의 크기도 커지는 것을 방지하고, 2) 비슷한 정보들의 모음을 별도관리 할 수 있는 장점으로 인해, 별도 테이블로 분리해 One to One 관계 설정 하는것을 선호한다.

 

2. One to Many 관계설정 오류

 

items 테이블 각 음료들의 Many인 Sizes, Limited 테이블과의 관계설정 방법이 잘못되었다.

One(items)의 프라이머리 키와, Many(Sizes, Limited)의 새로 생성한 포린 키(item_id)를 연결해야 한다. (Categories - items 참고)

 

3. images 테이블 분리

 

어떤 음료들은 이미지를 2개 이상 가지고 있었다. 또 추가 이미지 란이 있기에, 확장성을 고려하면 images 테이블 분리가 합리적이다.

 

- 소감

 

멘토 준님의 설명 덕분에, RDBMS 관계설정의 원리라던가 Many to Many 의 관계에 대한 이해가 조금이나마 도움되었다. ✊✊

백엔드(서버 사이드)와 관련성이 큰 내용이지만, 결국 그 정보들의 API를 가공하는 것이 프론트엔드의 몫이고, 기본적인 데이터베이스 관계설정의 이해가 백엔드와의 원활한 소통과 추후 풀스택 발전의 기저가 될 것이라 생각한다!