☕️ 스타벅스 코리아 페이지 음료 모델링

• 스타벅스 코리아 페이지에서 음료 카테고리를 선정해서 모델링을 해봤다.

최종 모델링

테이블

• 음료 카데 고리를 구성하는 부분을 크게 4가지로 나누었다.

1. 음료
2. 영양정보
3. 카테고리
4. 알레르기 정보

음료 테이블(drinks)

• 일단 맨처음에는 음료를 중심으로 생각을 했다.
  모든 요소가 음료와 관련되어있으므로 어떠한 칼럼은 음료 테이블에 포함시키고 어떤 항목은 음료 테이블과 분리를 시킬지에 대한 고민이 곧 이번 모델링의 핵심이었다.

• 최종적으로 음료테이블에는 음료이름, 음료설명, 카테고리아이디, 신상품 여부, 영어이름이 되었다.

• 하나씩 이유를 살펴보자

이미지 컬럼을 테이블을 따로 분리

• 이미지테이블은 처음에 설계할 때 음료 테일블에 포함되어있었다.
  왜냐하면 음료 하나당 이미지는 하나이고 고유 하기때문이다.

• 하지만 나눈이유는 음료테이블을 조회했을 때 url의 길이가 기니까 보기 불편하니까 나눠야한다는 생각으로 나누었다. 또 뭔가 이미지 파일은 따로 둘 것 같은 느낌적인 느낌이 있었다.

• 정확한이유는 모델링 리뷰시간에 알게 되었다.
  이미지가 지금은 한개이지만 나중에 하나 더 늘어날 경우도 생각해야하므로 확장성을 위해서 테이블을 분리하는게 좋다고 했다.
  지금 홈페이지에서는 음료가 일대일로 사용하지만 홈페이지가 아닌 관리자 페이지에서는 여러개가 있을 수 있기 때문에 테이블을 나누는게 좋다고 했다.

• 하지만 내가 생각한 이미지url의 길이가 길어서 조회에 불편할거란 가설은 틀렸고 길이가 긴건 아무런 문제가 도지 않느다고 한다.

데이터 모델링을 할때는 데이터를 사용하는 입장에 무게를 두기보단 오직 데이터의 관계와 데이터 자체에 중점을 둬야한다.

영양 테이블(1:1)

• 영양테이블도 나눌지 말지에 대한 고민이 거의 위화도 회군을 하는 이성계의 마음이었다.

• 영양테이블은 각 음료마다 고유한 속성을 가진다. 칼로리 나트륨 단백질 당류 등등 이런 수치들은 음료하나의 고유한 속성인데 이녀석들을 영양정보로 묶어서 나눌지 큰 고민을 했다.

• 결국 나누기로 결정했다.
  이 테이블 또한 이미지 필드와 같은 맥락으로(이미지는 로우의길이가 길어진다고 생각) 조회할 때 테이블의 칼럼이 너무 많아지기때문에 나누었다.

• 이 테이블도 나누어도 되고 안나누어도 됐었다. 하지만 컬럼의 수가 많은 건 문제는 아니더라도 깔끔하지 못하다고 했다.

빨간선?? 파란선??

• 폭탄을 해체 하는 마음으로 고민한 또 하나의 문제는
  음료 칼럼에 nutririon_id컬럼을 만들어서 영양테이블을 참조하냐?
  영양 테이블에 drinks_id칼럼을 만들어서 음료테이블을 참조하냐?

• 이 고민을 해결하려고 데이터 베이스 정규화도 찾아보고 했지만 뾰족한 해답은 못찾았다.
  그래서 가설을 하나 세웠다.

음료칼럼에 nutrtion_id를 만들어서 영양테이블을 참조하게 되면 음료칼럼에 row를 지우면영양테이블은???? 존재이유가 사라진다.

• 즉, 영양테이블에 drinks_id를 두어서 음료테이블을 참조하면 음료테이블이 지워지면 영양테이블도 지워도 되고 영양테이블의 컬럼이 없어지면 연결된 음료테이블은 상관이 없기 때문에 아! 이거다 싶었다.

• 하지만 틀렸다. 원투원(1:1)은 둘 중 어느하나에 해도 상관이 없었다.
  ......

• 그렇다면 아까 내가 세운가설은???
  데이터베이스 테이블을 만들 때 설정에서 정할 수 있다.

정리

위에 설명한 문제의 근본적인 원인은 원투원관계는 테이블을 나눠도 그만 안나눠도 그만이기 때문에 (물론 이유가 있으면 나누지만) 자꾸 나눌까 말까하는 이유에 대해서 이상한 가설을 세웠다.

• 원투원 관계는 누가 누구를 참조하던 상관이 없다. (장고에서는 역참조를 하면 불편하므로 호출되는족에 포린키를 두는 게 편하다고 한다)

• 이제 원투원 관계는 헷갈리지 않겠다!

카테고리 테이블 (1:n)

• 카테고리 테이블은 명확한 이유가 있었기 때문에 나누기가 쉬웠다.

• 음료 테이블의 항목 140개는 8개의 카테고리로 나눌 수 있다.
  즉, 카테고리 테이블과 음료 테이블은 1:n 관계다.

• 역으로 카테고리테이블이 음료테이블을 참조한다면 카테고리 테이블에는 140개의 행이 들어가고 name항목은 중복되는 행이 많아진다.

• 그리고 애시당초 둘의 관계는 1:n이라서 이렇게 해야한다.

알러지 테이블 (N:M)

• 알러지 테이블을 처음 설계 했을 때는 1:n관계로 생각을 했다.
  

• 하지만 짜고 보니 1:n으로 하면 심각한 오류가 있다는 사실을 알게 되었다.

• 알러지 요소가 두개이상인 음료는 알러지를 표기 하기위해 중복해서 써야한다!!
  정말 말도 안되기 때문에 당장 N:M으로 찢어버렸다.

• 알러지와 음료의 관계만을 표현하는 drink_alergy테이블을 생성함으로써 각 테이블에 중복되는 로우가 없게 된다.

후기

• 모델링을 하면서 정말 많은 생각을 할 수 있었고 개념으로만 배우던 걸 실제로 활용하면서 고민하니까 데이터베이스 이론이 체화된 것 같다.