맘 같아서는 당장 장고 프로젝트에서 모델링(models.py) 코드 작업을 하고 싶다.
하지만, ERD구성도를 작성하지 않고 모델링을 하면 수많은 수정사항이 발생하기도 하고, 이후에 참조하게 될 데이터베이스가 엉망으로 돼 버린다.
따라서, ERD구성도 작성이 매우매우 중요하다.
앞으로 사용하게 될 데이터베이스에 데이터를 효과적으로 저장하고 읽을 수 있도록 구축해야 한다.
ERD구성도 작성을 위해 아래의 AQUERYTOOL을 사용했다.
https://aquerytool.com/
COFFEE,
MENU,
STORE,
RESPONSIBILITY,
MY STARBUCKS REWARDS,
WHAT'S NEW
이렇게 총 6개의 카테고리로 나누어져 있다.
main_categories
이름으로 테이블을 명명하겠다.
하지만 이번 실습은 MENU 카테고리만 진행하겠다.
(프론트엔드의 데이터 요청 -> (백엔드) 서버에서 음료 데이터 정보 response 하기 위한 API 실습이 주 목적이기 때문이다.)
중점적으로 다룰 부분은 위 그림의 좌측에 표시한 음료 MENU다.
음료를 drinks라고 명명하겠다.
drinks에는 위 그림에서 확인할 수 있듯이 총 9가지의 서브 카테고리를 갖는다.
- 콜드브루
- 브루드 커피
- 에스프레소
- 프라푸치노
- 블랜디드
- 스타벅스 피지오
- 티(티바나)
- 기타 제조 음료
- 스타벅스 주스(병음료)
스타벅스 피지오를 클릭하면 다음과같이 5개의 메뉴가 있다.
이 음료들은 스타벅스 피지오 카테고리 안에 있는 음료들이다.
그렇다면 (1), (2) 까지의 흐름 flow상
drinks >> 스타벅스 피지오 >> 매직 팝 스플래쉬 피지오, 블랙 티 레모네이드 피지오, 쿨 라임 피지오, 패션 탱고 티 레모네이드 피지오, 핑크 자몽 피지오
가 있는 것이다.
"음, drinks
라는 테이블에는 스타벅스 피지오를 포함한 9개의 커피 카테고리(category
)가 필요하겠군!"
"그리고, 각 category
엔 그 카테고리에 해당되는 음료들이 있겠군!"
drinks와 9개의 카테고리는 one to many 데이터 연결관계를 갖는다.
그리고 각 카테고리와 음료수들 역시 one to many 데이터 연결관계를 갖는다.
이번엔 '매직 팝 스플래쉬 피지오'라는 음료를 자세히 보자.
이 음료는 바로 위에서 살펴봤던 스타벅스 피지오라는 카테고리에 포함된
음료 5가지 중 하나다.
이미지
, 영문이름
, 음료설명
, 판매 장소
, 제품 영양 정보
(그리고 알레르기 유발요인
이 있는 음료도 있다.), 사이즈
각 음료 단품은 아래의 정보들로 구성되어 있다.
- 이미지
- 영문이름
- 판매장소 (나와 있지 않는 경우도 있다. 나와 있지 않은 경우는 전 매장 판매 제품임)
- 제품설명
- 제품 영양 정보
- 알레르기 유발요인 (나와 있지 않는 경우도 있다.)
- 사이즈
그건 바로 데이터 연결관계다.
(1) '제품과 이미지는 어떤 데이터 연결관계인가?'
one to many
one to one으로 하려고 했으나,
다른 음료의 경우 서로 다른 두 이미지가 나온 음료도 있었다.
좀더 일반적으로 바라보자면,
만약 사진을 2개로 넣는 것으로 서비스가 바뀌면
테이블을 수정해야하는 일이 발생한다.
[보충설명]
위의 두 제품처럼 이미지가 두개인 음료가 있다.
메인에 보이는 큰 크기의 사진과 좌측하단의 음료의 이미지는 동일하다.
그러나 우측하단의 이미지는 새로운 이미지다.)
(2) '제품과 영문이름은 어떤 데이터 연결관계인가?'
one to one
(3) '제품과 판매장소는 어떤 데이터 연결관계인가?'
many to many
스타벅스 음료들을 하나하나 확인해봤다.
나와 있지 않는 경우는 모든 매장에서 판매
라벤더 카페 브레베
라는 음료의 경우 :
[더종로R,청담스타R,한강진역R,홍대입구역사거리R,이대R 전용음료]
럼샷 코르타도라는 음료
의 경우 :
[더종로R,청담스타R,한강진역R,홍대입구역사거리R 전용음료]
원래는 one to one 또는 one to many가 아닐까 생각했다.
가장 처음 찾아본 음료인 스타벅스피지오의 경우
용인에버랜드R 매장
이라고 적혀 있었기 때문이다.
그래서 아메리카노는 '모든 매장', 스타벅스 피지오는 '용인에버랜드R매장' 과 같은 방식으로 진행하려고 했었다.
하지만 위에서 언급한 라벤더 카페 브레베의 경우만 보더라도
더종로R, 청담스타R, 한강진역R, 홍대입구역사거리R, 이대R 에서 판매되고 있었다.
정리해보면, 음료 A가 여러 매장에서 판매될 수 있고,
특정 스타벅스지점
에서만 구입할 수 있는 음료들
도 있다.
테이블 내 한 필드가 있다고 했을때, 한 셀에는 하나의 값만 입력돼야 한다.
그런데, one to one으로 하게되면 위 규칙에 위배된다.
또한, one to many의 경우를 고려해봐도
이미 제주 지역 매장들에서 제공하는 특별한 음료수들이 있다.
ex) 제주에 있는 스타벅스 지점에서만 특별히 아래의 음료들을 구매할 수 있다.
제주 까망 크림 프라푸치노, 제주 쑥떡 크림 프라푸치노, 제주 유기농 말차로 만든 크림 프라푸치노, 제주 청보리 크림 프라푸치노 등
(4) '제품과 음료설명은 어떤 데이터 연결관계인가?'
one to many
이것 역시 one to one으로 착각하기 쉽다.
하지만, 역시 홈페이지를 잘 확인해보면 one to many임을 알 수 있다.
제주 쑥떡 크림 프라푸치노 음료
의 경우
제품에 대한 설명(상단, 하단)이 일치한다.
하지만,
초콜릿 크림 칩 프라푸치노 음료
의 경우
상단의 설명과 하단의 설명이 상이하다.
따라서, one to many 데이터 연결관계로 설정했다.
(5) '제품과 영양정보는 어떤 데이터 연결관계인가?'
one to one
(6) '제품과 알레르기 유발요인은 어떤 데이터 연결관계인가?'
many to many
바로 위 그림인 초콜릿 크림 칩 프라푸치노의 알레르기 유발요인은
대두/우유/밀
이다.
그리고 제주 유기농 말차로 만든 크림 프라푸치노
음료의
알레르기 유발요인은우유
다. (바로 아래 이미지 확인)
즉, 음료 A는 알레르기 유발요인이 없을 수도, 한개만 있을 수도, 여러 개 있을 수도 있다.
또한 알레르기 성분 중 하나인 '우유'는 여러 개의 음료들에 유발요인으로 들어가기도 한다.
따라서, many to many로 지정했다.
(6) '제품과 사이즈는 어떤 데이터 연결관계인가?'
one to one
이번에도 역시 메뉴들을 하나하나 확인해봤다.
ex) 자바 칩 프라푸치노
는 톨 사이즈에 대한 정보만 나와있지,
Grande로 주문했을 경우의 사이즈 정보는 나와있지 않다.
aquerytool(https://aquerytool.com/)을 이용하여
ERD 구성도를 그렸다.
그리고 아래와 같이 완성하였다.
다음 포스트엔 ERD구성도를 기반으로 웹스크래핑을 하도록 하겠다.