스타벅스 음료 데이터 모델링

스타벅스 음료 페이지를 모델링하는 팀 과제를 받았다. 직전의 수업에서 들은 테이블간 상호관련성 판단에 중심을 두고 상의했다.

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

구현 제외 사항: 프로모션, 음료 사이즈

 

1. 데이터 성질 파악

2. 팀 회의를 통해 추가적인 정보 습득, 모델링 상의

3. 모델 제출 후 리뷰

4. 리뷰 내용을 반영하여 모델 수정

이후 장고에 이 모델을 넣을 예정이다.

1. 데이터 성질 파악

팀 회의에 들어가기 전에 스타벅스 음료 페이지에 있는 여러 음료들을 들여다보고 대략적인 성질을 파악했다.

음료 이름 - 고유.

카테고리 - 전체상품 제외 9종. 교집합 데이터가 있는지 모르겠다.

영양정보 - 1회제공량 kcal 등 6종. 각각 int data를 갖고 있음.

알레르기 유발 요인 - 우유 또는 아무것도 없는 예시 관찰함. 이 외의 다른 유발 요인이 있는지 조사 필요.

이미지 - 대개 1개지만 3개 있는 음료도 있다.

음료 설명 - 음료 이름에 따른 text.

신상 여부 - yes or no

2-1. 팀 회의를 통해 추가적인 정보 습득

여럿이 머리를 모아 각기 파악한 데이터의 성질에 대한 정보를 합쳤다. 위에서 없던 추가 정보가 생겼다.

카테고리 - 교집합 데이터 없다.

알레르기 유발 요인 - 밀, 토마토, 대두 등이 발견됨.

2-2. 모델링 상의

음료 이름이 다른 데이터와 어떤 연관성을 갖는지 상의했다.

음료 이름과 1:1로 이어지는 것 - 음료 설명, 신상 여부

음료 이름과 1:M으로 이어지는 것 - 카테고리, 음료 이미지

음료 이름과 N:M으로 이어지는 것 - 영양 정보, 알레르기 유발 요인

 

영양 정보와 알러지의 경우 데이터들을 하나의 column으로 담고 중간 테이블을 만들어 조합+데이터 구조로 할지,

단백질, 카페인 등을 각각 column으로 주고 1:1로 연결할지 고민이 됐다.

알레르기 유발 요인은 1:1로 연결할 경우 모든 요인을 전부 column으로 만들어줘야 되는데, 알레르기 유발 요인 전부를 알아낼 수 없었기에 빠르게 N:M으로 결론내렸다.

영양 정보는 내가 N:M으로 밀어붙였는데 아래 리뷰에서 나오겠지만 스타벅스의 경우 영양 정보를 한 세트로 보고 1:1로 하는 게 더 적당하다. 기억에 더 잘 남겠다.

팀 제출 모델

3. 모델 제출 후 리뷰

리뷰에 들어가기 전 셀프 리뷰를 잠깐 하면서 null 여부에 대한 고려를 하지 않았다는 걸 깨달았다.

다른 팀 리뷰를 보고 얻은 것

boolean(yes or no) 데이터의 type으로는 BIT 보다는 TINYINT를 추천해주셨다.

진행/변동 상황을 기입하는 테이블은 logs로 따로 분리한다. 이번 과제에서는 불필요하다.

이미지는 대개 url 형태로 들어간다. 이미지 파일 그 자체가 들어가는 경우도 있는데, BLOB type을 사용한다.

영양 정보와 가격의 type으로는 INT보다는 DECIMAL을 쓰는 게 적절하다.

영양 정보에는 단위 필요하다는 걸 의식하자. 

 

명명에 있어서는 컨벤션(규칙. 협업하면서 일관된 코드 스타일을 유지시키기 위함)을 신경쓰자.

- 테이블의 이름은 영어 소문자로 쓰고 복수형을 사용한다.

- column의 이름은 영어 소문자로 쓰고 띄어쓰기 대신 언더바(_)를 넣고 단수형을 사용한다. 뜻이 명확하게 쓰자.

- pk로 부여된 단순 번호 id column명에는 테이블 이름이 꼭 필요하진 않다. 그냥 id로 쓰자.

- boolean 데이터가 들어간 column명은 is_new 이런 식으로 만든다.

리뷰 때 피드백 받은 것

처음 시작할 때는 한 테이블에 다 넣고 점차 쪼개가는 게 좋다. 한 데 묶여있어도 되는 1:1 관계인 정보를 여러 테이블로 나누는 기준은 밀접성과 같은 스타일인지이다. 배송정보와 결제정보같이 다른 스타일의 정보는 다른 테이블로 분리하는 게 좋다. 새 테이블로 나누는 것도 리소스 소모다.

url의 type으로는 VARCHAR 길이 1000 ~ 2000 정도가 적절하다.

테이블이나 column 명명할 때 info, data를 넣는 건 피하자. 범용되거나 포괄적이다.

영양 정보에 들어가는 데이터는 숫자+단위 형태이다. 숫자와 단위를 같이 넣을 거라면 VARCHAR로 한다. 숫자만 넣을 거라면 DECIMAL로 한 뒤 단위를 넣은 column을 따로 만들어 연결해야 된다.

음료 배합 비율이 잘 변하지 않아 영양 정보의 변동 가능성이 낮을 때는 영양 정보 전체를 한 세트로 보아 1:1 관계로 보는 쪽을 선호한다.

수정한 결과

개인 수정 모델

장고에 모델을 넣은 뒤 테스트해볼 게 있어서 카테고리의 상위인 메뉴 테이블을 추가했다.

감상

모델링에 답은 없지만 best practice는 있으니 다른 사람들이 한 모델링을 많이 봐야된다. 모델링 구조 사이트

난 테이블을 너무 쪼개는 경향이 있다.

페이지는 기획따라 변하지만 DB는 오래 가니까 DB 모델링을 할 땐 페이지보다는 데이터간의 관계 그 자체에 집중해야 된다는 말씀이 인상 깊었다. 

 

이제 이 모델을 장고에 넣어야겠다.