분명 세션 들을때는 다 아는 것 같았는데 직접 모델링을 해보니 굉장히 어렵다는 것을 알게되었다. 복습 겸 관계형 데이터베이스 모델의 테이블끼리의 연결 관계 (one to one, one to many, many to many)와 우리 팀의 스타벅스 모델링 과제를 리뷰를 하려고 한다.

☘️ 1. Database?

데이터베이스란 공유하여 사용될 목적으로 통합하여 관리하는 데이터 집합을 의미한다.

어플리케이션에서의 메모리는 휘발성이기 때문에 데이터가 보존되지 않는다. 그러므로 애플리케이션을 종료하면 데이터를 읽어들일 수 없기 때문에 데이터의 장기간 보존을 위해서 데이터베이스가 필요하다.

🌵 2. RDBMS

RDBMS (Relative DataBase Management System)이란 관계형모델에 기초를 둔 시스템이다.

• 모든 테이블은 2차원 테이블로 표현된다.
• 컬럼은 테이블의 각 항목을 말한다.
• 로우는 각 항목들의 실제 값들이다.
• 각 로우는 저만의Primary Key (고유 키) 가 있다. primary key를 통해서 해당 로우를 찾거나 refer할 수 있다.

2-1. One to one

one to one 이란 각 테이블의 로우가 일대일 매칭이 되는 관계를 뜻한다. 예를 들어, 아래의 그림에서 각 user는 한가지의 user_profile만 가지고 있다.

2-2. One to many

하나의 주체가 여러개의 상태값을 가질 수 있는 형태를 말한다. 예를 들어 아이디 하나에 여러가지 주문이 있는 것이다. one to one과 다르게, 한명의 고객은 여러 주문을 넣을 수 있다.

2-3. Many to many

many to many는 테이블의 여러 row가 다른 테이블의 여러 row와 연결이 될 수 있을 때를 말한다. 예를 들어, 한명의 작가는 여러개의 책을 쓸 수 있고, 한개의 책은 여러 명의 작가에 의해 쓰일 수 있다.

☕ 3. 스타벅스 모델링 리뷰

다음은 우리 Foreign Key 팀의 모델링 과제이다. 처음에는 어떻게 갈피를 잡아야할지조차 모르다가 해냈다. 대단한 우리팀.

3.1 과제 설명

[ 데이터베이스 모델링 과제 안내]
스타벅스 음료 페이지를 모델링 해주세요.
⭐ 필수 구현 : 음료 이름, 카테고리, 영양 정보, 알러지, 음료 이미지, 음료 설명, 신상 여부
⭐ 구현 제외 사항 : 프로모션, 음료 사이즈
⭐ 도구 : Aquery ERD tools

아래는 스타벅스 음료 페이지이다:
https://www.starbucks.co.kr/menu/drink_list.do

밑의 사진과 같은 식으로 정보가 제공된다:

3.2 과제물

과제물 결과

아래는 우리팀 과제물이다. 밑에 가서 틀린 부분도 리뷰하겠다.

접근 방식

1. beverages 와 categories는 one to one 관계이다.

• 하나의 음료는 하나의 카테고리안에만 존재할 수 있다.
  예를 들어, 더블 에스프레소 프라푸치노는 프라푸치노라는 카테고리안에만 있다.
  

2. beverages 와 nutrition_profile은 one to one 관계이다.

• 하나의 음료는 한개의 영양정보만 가질 수 있다.
  영양정보 안에 칼로리, 포화지방, 단백질, 나트륨, 당, 카페인이 항목으로 있는 것이다.

3. beverages 와 allergies는 many to many 관계이다.

• 하나의 음료는 여러개의 알레르기 유발 요인를 가질 수 있고, 알러지 입장에서도 여러가지의 음료가 있을 수 있다.

예를 들어, 제주 쑥떡 크림 프라푸치노는 대두/우유/밀을 알레르기 유발 요인으로 가진다.
우유라는 알레르기 유발 요인은 제주 쑥떡 프라푸치노, 돌체 콜드 브루, 나이트로 바닐라 크림 등을 음료로 가진다.

4. beverages 는 name(음료 이름), image(음료 이미지), description(음료 설명)를 고유값으로 갖는다.

• 음료 하나당 무조건 음료 이름은 한개이다.
• 음료 하나당 이미지도 한개이다. (사실 아니지만 우리팀은 이때 이렇게 생각했다. 더 열심히 찾아보면 몇장씩 있는 음료도 있다고 한다 ㅎ)
• 음료 하나당 음료 설명도 다 한개이다. 당연히 제각각이다.
  고로 이건 따로 테이블을 만들지 않고 고유값 처리를 해주었다.

5. beverages 와 new_status(신상여부)는 one to one 관계이다.

• 음료 하나당 신상인지 아닌지를 true/false로 해주는 데이터타입을 찾지 못해서 (aquery에 boolean이 없더라.) 그래서 그냥 따로 테이블을 만들어 신상 음료들을 저장하는 방식으로 했다.

6. beverages 는 size와 one to one 관계이다.

• 왜인지는 모르겠지만 홈페이지 상으로는 한가지의 사이즈만 나와있다. 그래서 구현 예외사항인것 같으나 우리 팀은 포함하였다.

개선 여지

1. nutrition_profile 테이블을 보면 data type이 INT이다.
   이를 DECIMAL(10,2)로 바꾸어주는 것이 좋다. INT는 정수형이기 때문이다.
   밑의 콜드 브루를 보면 나트륨이 소수점 첫째자리까지 표현되어있는 것을 볼 수 있다.
   

2. naming을 확실하게 해야한다!

• beverages 테이블에서 category -> category_id, size -> size.id로 바꾸어주는 것이 바람직하다.

• categories 테이블에서 categories_name -> name 이 바람직하다.
  ( categories의 categories_name 보다 categories의 name이 더 간결하고 확실하다.)
  마찬가지로, allergies 테이블에서도 allergies-> name이 바람직하다.

3. image는 여러장이 있을 수 있다. one to many 관계이다. 그러므로 따로 테이블을 만들어주는 것이 좋다.

4. new_status 는 TINYINT를 통해 true/false로 나타낼 수 있다. 그렇다면 고유값으로 처리하여 beverages 테이블에 image, description 처럼 한 항목으로 넣어주는 것이 바람직하다.

5. logical name 에 설명을 해주는것이 좋다. 예를 들어, fat의 logical name 에는 '포화지방' 이라고 써준다.

잘한 점

1. null이 될수 없는, 반드시 필수적으로 있어야만 하는 항목들은 null 박스에 uncheck를 했다.

2. 테이블과 테이블 간의 관계를 잘 파악하여 전체적인 틀을 잘 잡았다.

3-3. 모범답안