본문 바로가기
서비스 기획/바닥부터 이커머스 시스템 기획

04. 상품 데이터 설계

2020. 12. 29.

※원래 주문 모듈을 분석할 순서인데 상품 모듈을 먼저 정의하기로 했다. 왜냐하면 주문은 회원과 상품 간의 관계를 의미하기 때문이다. 또한 무통장 입금을 제외한 대부분의 결제 방식이 주문과 동시에 결제가 이루어지므로 주문/결제를 동시에 분석하기로 했다.

1단계: 상품 데이터 나열하기

회원 데이터 설계 때와 동일하게 상품 관련 데이터를 나열했다. 관련 데이터는 카페24의 상품관리>상품등록 메뉴에서 상품 등록 시 입력해야 하는 데이터를 기준으로 했다.

- 구분: 상품 등록을 위한 데이터들은 기본 정보, 배송 정보, 판매 정보 등으로 구분할 수 있다. 이들은 성격에 따라 각각의 테이블로 분리할 수 있다. (회원 정보를 기본 정보와 로그 정보로 구분했던 것처럼)
- 용도: 사용자에게 노출하기 위한 값인지, 내부 운영 관리를 위한 값인지 구분했다. 기본적으로는 모두 운영을 위해 필요한 데이터라고 할 수 있지만 모든 데이터를 사용자에게 노출하는 것은 아니다. 따라서 상품 리스트 페이지나 상세 페이지 기획 시 어떤 데이터를 사용자에게 노출할지 결정하는데 있어 참고할 수 있을 것이다.
- 등록 방법: 카페24 상품 등록의 경우 간단/일반/스마트모드 등록이 가능하다. 상품 특성상 반복 입력하는 작업이 많기 때문에 간단 입력을 추가로 제공하는데, 이 간단 입력 데이터상품을 구성하는 가장 최소한의 데이터라고 할 수 있다.
(=>진열상태/판매상태/상품분류 선택/상품명/상품 요약설명/상품 상세설명/판매가/옵션 사용/이미지 등록)
- 필수 입력: 상품을 구성하는 최소 데이터는 다시 디폴트 설정/필수/선택 입력으로 구분된다. 디폴트 설정은 미등록/미입력 등의 값으로 디폴트 값이 설정되어 있는 항목을 말한다. (=>진열상태/판매상태/상품분류 선택/옵션 사용) 선택 입력 값은 최초 등록 시 입력하지 않아도 상품 등록이 가능한 항목이다. (=>상품 요약설명/상품 상세설명/이미지 등록) 따라서 이들을 제외한 상품 구성 데이터 중 관리자가 직접 입력해야 하는 최소한의 필수 입력 값은 붉은색으로 표시했다.
(=>상품명/판매가)
- 그외: 공급가는 일반/스마트 모드에서 필수 입력 값이다. 또한 해외 배송 상품의 경우 HS코드와 해외 통관용 상품 구분값이 필수 입력 값이다.


2단계: 상품 테이블 구성하기

앞서 상품을 구성하는 최소한의 데이터를 정의했었다. (진열상태/판매상태/상품분류 선택/상품명/상품 요약설명/상품 상세설명/판매가/옵션 사용/이미지 등록)

그렇다면 이 데이터들이 각각 어떤 테이블에서 왔을지 생각했다. 우선 상품 기본정보 테이블이 있을 것이고 카테고리는 코드를 부여하여 별도의 테이블로 구성한다.

판매 정보는 별도의 테이블로 생각했는데 일단 가격 변경이력을 관리하지 않는다면 상품 기본정보에 포함시켜도 무방하다고 판단했다. 상품의 노출 여부도 처음에 별도의 테이블로 생각했다가 상품 기본정보에서 valid 값을 Y/N로 체크하면 될 것 같아서 분리하지 않았다.

할인 정보는 별도의 테이블로 구성했다. 카페24의 경우 할인을 별도로 관리한다. 상품별 할인을 적용하더라도 할인 항목을 생성해서 상품에 적용하는 것이지, 상품마다 별도로 할인율을 적용하는 것이 아니다. (종속 관계의 차이라고 할 수 있다) 따라서 할인을 종료하고 싶을 때 할인율을 삭제하는 것이 아니라 할인 적용여부를 on/off 하는 방식을 적용할 수 있는 것이다.

또 하나의 이슈가 옵션 정보인데 옵션 역시 별도의 테이블로 구성하고 싶었다. 가령 색상 옵션과 사이즈 옵션은 범용되므로 어떤 상품에서도 불러올 수 있는 것이다. 아래 게시글은 옵션 테이블에 대한 내용인데

 

OKKY | 테이블을 어떻게 짜야 할지 모르겠네요...

첫번째 테이블 입니다. create table new_product ( id int, product_code int, product_name varchar(100) not null, product_desc tinyint not null, product_img_name varchar(100) not null, product_comment var

okky.kr

댓글에서 옵션 테이블을 다음과 같이 조언했다.
--
상품코드(FK)
옵션구분(PK)
옵션별가격(Not Null)
비고
--

다음의 자료에서도 옵션 테이블에 대한 정의는 같았다.

 

DB Project - Gmarket

Database project for gmarket

www.slideshare.net

결론적으로 내가 생각했던 할인 테이블 같은 형태는 아니었다. 상품 코드를 외래키로 참조하는 형태였다.

그외 상품 데이터와 관련이 있다고 예상되는 테이블 목록은 다음과 같다. 
- 상품 이미지 테이블
- 재고 테이블
- 상품 제작 정보 테이블
- 이용안내 테이블
- 배송 정보 테이블
- 연관 상품 테이블
- 검색엔진 테이블


3단계: 테이블 간 관계 설정하기

이제 테이블들을 서로 연결해주면 된다. 연결 관계는 다음의 블로그를 참고했다. 전체 ERD에서 상품 테이블 부분을 보면 옵션, 가격, 이미지, 카테고리 등으로 상품 테이블을 독립적으로 정의했음을 알 수 있었다.

 

데이터베이스 :: 오픈마켓(OpenMarket) ERD 정리

이번에는 오픈마켓(OpenMarket) ERD(Entity-Relationship Diagram)을 정리해보려고 한다. 오픈마켓의 특징은 유저 테이블이 판매자와 구매자로 나뉘며 각각 요구 되는 데이터가 다르다는 점이다. 그렇기 때

wave1994.tistory.com

마치며
회원 데이터 설계 때보다는 아주 조금 덜 삽질했다. 확실히 옵션 데이터 같은 경우는 DB 설계 시 개발자들도 어려움을 겪는 것 같았다. 일단은 옵션을 관리할 수 있는 범위까지 완성했는데 더 들어가면 옵션에 따른 가격 차이까지 확장할 수 있을 것 같다. (추가금액 컬럼을 생성하면 될 듯?)
다른 사람들이 설계한 ERD를 보면서.. 기획에 정답이 없다고들 하지만 개발 역시 정답이 없다는 생각이 들었다. 같은 결과물을 목표함에도 불구하고 접근 방식이 다양했다. (그리고 결국 결과물도 천차만별이다) 그래서 이게 맞는건지.. 나만 이렇게 어려운지.. 쓸데없는 삽질이 아닌지.. 다들 같은 생각을 하지 않을까 싶다.
사용툴: MySQL, PowerPoint

참고자료

 

개인 마트 관리 시스템 DB 설계하기 (ERD 만들기, DB 구조, a.k.a 쇼핑몰DB)

개인 마트 관리 시스템 DB 테이블 설계하기 이 포스트를 계속 수정하면서 "마트 관리 애플리케이션"의 테이블을 만들어 볼 예정이다. 사촌 형 부탁으로 마이크로 애플리케이션을 만들기 때문에

jeong-pro.tistory.com

 

02. 쇼핑몰 DB ERD 설계

ERD를 그려서 의존관계를 표현하면서 설계하기가 쉽지 않았다 쇼핑몰을 참고해서 이것저것 테이블을 만들다가 너무 복잡해져버렸다;; 그래서 일단 고객, 주문, 상세 위주로 간단하게 작성하고

dionysus2074.tistory.com

 

데이터베이스 ERD 설계 : 스타벅스 과제

스타벅스 홈페이지 메뉴에서 음료, 푸드, 상품, 카드 총 4개 카테고리가 있습니다. 이 중 음료 카테고리를 지금 홈페이지에 있는 것처럼 띄우려면 어떻게 데이터베이스를 설계해야 하는지에 대

velog.io

 

'서비스 기획 > 바닥부터 이커머스 시스템 기획' 카테고리의 다른 글

06. 상품 플로우차트  (0) 2021.01.03
05. 상품 정책 정의  (0) 2020.12.31
03. 회원 플로우차트  (0) 2020.12.27
02. 회원 정책 정의  (0) 2020.12.21
01. 회원 데이터 설계  (0) 2020.12.18

댓글