✔️ Team Assignment
ERD 구성도로 스타벅스 모델링
스타벅스의 음료 에 관한 정보를 팀별로 모델링하기
참고할 Starbucks 사이트
ERD란?
ERD는 Entity Relationship Diagram의 약자로,
데이터베이스 구조를 한 눈에 알아보기 위해 그려놓는 다이어그램, ER Diagram으로도 말한다.
ERD는 정확히 언제 사용할까?
데이터베이스 사용시 수정이 필요할 때 ERD로 먼저 파악, 확인하면 어느 부분을 수정해야 할지 비교적 쉽게 반영할 수 있고 데이터의 특징을 바로 볼 수 있어 개발 전 데이터베이스의 구조를 잡고 진행해야 한다.
ERD 용어 정리
Table name : 테이블 이름
Table logical name : 테이블 설명
PK : Primary Key (메인키) 설정
AI : Auto Increment (숫자 자동 증가)설정
FK : Foreign Key(외래키) 설정
NULL : 체크 시 NULL 허용
Logical Name : 컬럼 설명
Name : 컬럼 이름
Type : 데이터의 타입
필수 구현
음료, 카테고리, 영양정보, 알러지, 음료 이미지, 음료설명, 신상여부
- 메뉴 & 카테고리 : 한 가지의 메뉴는 여러 카테고리를 가진다.
- 카테고리 & 제품 : 한 가지의 카테고리는 여러 제품들을 가진다.
- 제품 상세 정보 : 음료 하나는 음료의 설명, 이미지, 신상 여부가 포함된다.
- 하나의 음료는 여러 알러지 정보를 가지고 있을 수 있다.
- 하나의 알러지 정보 또한 여러 음료를 가질 수 있다.
- 하나의 음료는 한가지의 영양 정보 세트를 가질 수 있다.
음료
이름
모두 다른 값이므로 drinks표 자체 name 속성값으로 부여
음료 이미지
(one-to-one) 이미지는 이미지 링크와 drinks img_Id값 연동
만약 이번 모델링이 아닌, 이미지가 N개가 된다면?
(one-to-many) 음료 1:N이 관계가 되고 테이블을 분리해야 한다.
음료 설명
one to one drinks > drinkDes
카테고리
one-to-many 카테고리마다 프라임키를 주는 방식으로 음료에 키를 부여 (에스프레소 : 1)
영양정보
(one-to-many) 1개의 음료당 6가지의 정보가 1세트가 된다. 음료에 대한 설명은 음료마다 다르기 때문에 참조하지 않는다.
알러지
Allergie의 테이블 연결에 많이 고민했었는데,
알러지마다 프라임키를 주는 방식으로 음료에 그 키를 부여했지만,
다른 테이블 여러개에 연결 될 가능성이 있는 경우는 1:N 관계가 된다.
(카페 라떼 : 1, 슈크림라떼 : 1)(one-to-many)
신상 여부
신메뉴 : 신상 / 기존 메뉴 두 개로 나눠서 음료에 키를 부여 (슈크림 라떼 : 1)(one-to-many)
모델링 리뷰 중 알게 됐는데, 신상 여부는0 아니면 1이다.
TINYINT의 범위가 INT보다 작아 신상품 테이블을 따로 생성할 필요 없이 drinks 테이블에 is_new를 생성, T/F값을 TINYINT로 수정하였다.
크기비교
int = inteager
Tinyint < Smaling < Int < Bigint
최종 스타벅스 모델링
📄 References
