DB(Database)란 컴퓨터 시스템에 저장된 정보 또는 데이터의 집합을 의미한다. 일반적으로 프론트엔드 개발자는 DB를 설계할 일이 거의 없지만, 개발자라면 기본적으로 DBMS에 대한 지식을 갖추고 있어야 협업이 수월하다고 한다. 이번 세션에서는 데이터베이스가 무엇인지, 어떤 종류가 있는지에 대해서 배우고, 스타벅스 음료에 관한 정보를 팀으로 모델링해보았다.
관계형 데이터베이스에는 one to one 테이블, one to many 테이블, many to many 테이블이 있다. 각각의 테이블 연결 방식과 그 목적에 대한 이해가 부족한 상태에서 DB 모델링을 하자니 생각보다 까다로웠다. 웹사이트에 정보가 정리되어 있는데 뭘 더 해야 하는지도 이해가 되지 않았다. 그러나 스터디를 통해 백엔드 팀원분의 명쾌한 설명 덕분에 우리는 다음과 같이 첫 DB 모델링을 할 수 있었다.
1. 데이터베이스 모델링 결과
1. 맨 왼쪽 테이블
- 각 아이템의 속성이 아이템마다 고유한 값을 가지고 있다. 예를 들어 칼로리, 나트륨, 이미지 등은 일반적으로 다른 음료들과 중복되는 값이 아니다. 따라서 각 음료가 고유한 값을 가지는 항목만을 모두 모아서 한 테이블에 정리했다.
2. 중간의 두 개 테이블
- '중간다리' 역할이자 many to many 테이블이다. 각 아이템이 어떤 속성에 대한 값을 여러 개 가지고 있을 때 이 테이블을 통해 데이터를 확인할 수 있다.
- 알러지 유발 성분을 예로 들자면, 어떤 음료는 대두만 해당하는데, 어떤 음료는 대두와 밀, 우유 세 가지 성분을 모두 가지고 있을 수 있다.
- 책 출판을 예로 들자면, 어떤 저자는 책을 2권 썼을 수 있고, 어떤 저자는 책을 50권 쓸 수 있다.
- 두 가지 예시 모두, 어떤 아이템이 가장 많은 데이터의 가짓수를 가지고 있다고 해서 그 아이템을 기준으로 테이블의 로우를 무한정 늘려나갈 수는 없다. 따라서 알러지 정보의 primary key와 각 음료의 아이디에 해당하는 primary key를 참조하도록 하고, 마찬가지 방식으로 책 정보와 저자의 아이디를 참조하도록 중간다리 역할을 하는 many to many 테이블을 두는 것이 효율적이다.
3. 오른쪽의 네 개 테이블
- 다른 테이블에서 참조해 갈 정보들이다. 예를 들어 알러지 종류, 음료의 카테고리, 스페셜 시즌 종류, 판매지역 등을 이러한 테이블로 구성해, one to many 구조로 다른 테이블이 foreign key로 가져다 쓸 수 있도록 만들어 놓았다.
이렇게 1차적으로 DB모델링에 대한 개념을 잠은 후, 조금 더 수정을 하여 완성을 한 결과는 다음과 같다.
2. 데이터베이스 모델링 피드백 내용 정리
데이터 모델링 피드백 세션 내용을 정리하면 다음과 같다.
1. 테이블을 어떻게 나눠야 할지 막막할 때는
- 먼저 한 번 다 쭉 적어보는 것으로 시작 -> 데이터가 중복돼서 들어가 있는 항목이 있다면(카테고리) -> category라는 테이블을 하나 만들어서, 콜드브루와 에스프레소, 프라푸치노와 같은 카테고리를 숫자로 나타낸다. -> category의 primary key, 개별 음료의 primary key를 가져다 foreign key로 쓰는 테이블을 만든다.
2. Boolean 데이터의 경우에는
- 신상 여부 등에 관한 데이터는 'is_new'또는 'has_options'와 같은 항목 이름으로 true/false boolean 타입이기 때문에, 따로 테이블을 만들지는 않고 음료 table에 넣어주는 경우가 많다.
3. 제품마다 고유한 정보라도 모델링 방식은 달라질 수 있다.
- 이미지 url, description의 경우에는 고유하기 때문에 고유한 값만 들어가는 drink 테이블에 들어갈 수 있다.
- 제품 하나 당 이미지 url이 여러 개일 경우에는 이미지 테이블을 따로 빼 주어야 한다. 이번 경우에는 그럴 필요는 없었다.
- 영양정보같은 엄청 상세한 내용은 따로 떼어서 one to one 관계로 테이블을 만들어준다.
빵굽는 프론트엔드 개발자