※원래 주문 모듈을 분석할 순서인데 상품 모듈을 먼저 정의하기로 했다. 왜냐하면 주문은 회원과 상품 간의 관계를 의미하기 때문이다. 또한 무통장 입금을 제외한 대부분의 결제 방식이 주문과 동시에 결제가 이루어지므로 주문/결제를 동시에 분석하기로 했다.
1단계: 상품 데이터 나열하기
회원 데이터 설계 때와 동일하게 상품 관련 데이터를 나열했다. 관련 데이터는 카페24의 상품관리>상품등록 메뉴에서 상품 등록 시 입력해야 하는 데이터를 기준으로 했다.
- 구분: 상품 등록을 위한 데이터들은 기본 정보, 배송 정보, 판매 정보 등으로 구분할 수 있다. 이들은 성격에 따라 각각의 테이블로 분리할 수 있다. (회원 정보를 기본 정보와 로그 정보로 구분했던 것처럼)
- 용도: 사용자에게 노출하기 위한 값인지, 내부 운영 관리를 위한 값인지 구분했다. 기본적으로는 모두 운영을 위해 필요한 데이터라고 할 수 있지만 모든 데이터를 사용자에게 노출하는 것은 아니다. 따라서 상품 리스트 페이지나 상세 페이지 기획 시 어떤 데이터를 사용자에게 노출할지 결정하는데 있어 참고할 수 있을 것이다.
- 등록 방법: 카페24 상품 등록의 경우 간단/일반/스마트모드 등록이 가능하다. 상품 특성상 반복 입력하는 작업이 많기 때문에 간단 입력을 추가로 제공하는데, 이 간단 입력 데이터가 상품을 구성하는 가장 최소한의 데이터라고 할 수 있다.
(=>진열상태/판매상태/상품분류 선택/상품명/상품 요약설명/상품 상세설명/판매가/옵션 사용/이미지 등록)
- 필수 입력: 상품을 구성하는 최소 데이터는 다시 디폴트 설정/필수/선택 입력으로 구분된다. 디폴트 설정은 미등록/미입력 등의 값으로 디폴트 값이 설정되어 있는 항목을 말한다. (=>진열상태/판매상태/상품분류 선택/옵션 사용) 선택 입력 값은 최초 등록 시 입력하지 않아도 상품 등록이 가능한 항목이다. (=>상품 요약설명/상품 상세설명/이미지 등록) 따라서 이들을 제외한 상품 구성 데이터 중 관리자가 직접 입력해야 하는 최소한의 필수 입력 값은 붉은색으로 표시했다.
(=>상품명/판매가)
- 그외: 공급가는 일반/스마트 모드에서 필수 입력 값이다. 또한 해외 배송 상품의 경우 HS코드와 해외 통관용 상품 구분값이 필수 입력 값이다.
2단계: 상품 테이블 구성하기
앞서 상품을 구성하는 최소한의 데이터를 정의했었다. (진열상태/판매상태/상품분류 선택/상품명/상품 요약설명/상품 상세설명/판매가/옵션 사용/이미지 등록)
그렇다면 이 데이터들이 각각 어떤 테이블에서 왔을지 생각했다. 우선 상품 기본정보 테이블이 있을 것이고 카테고리는 코드를 부여하여 별도의 테이블로 구성한다.
판매 정보는 별도의 테이블로 생각했는데 일단 가격 변경이력을 관리하지 않는다면 상품 기본정보에 포함시켜도 무방하다고 판단했다. 상품의 노출 여부도 처음에 별도의 테이블로 생각했다가 상품 기본정보에서 valid 값을 Y/N로 체크하면 될 것 같아서 분리하지 않았다.
할인 정보는 별도의 테이블로 구성했다. 카페24의 경우 할인을 별도로 관리한다. 상품별 할인을 적용하더라도 할인 항목을 생성해서 상품에 적용하는 것이지, 상품마다 별도로 할인율을 적용하는 것이 아니다. (종속 관계의 차이라고 할 수 있다) 따라서 할인을 종료하고 싶을 때 할인율을 삭제하는 것이 아니라 할인 적용여부를 on/off 하는 방식을 적용할 수 있는 것이다.
또 하나의 이슈가 옵션 정보인데 옵션 역시 별도의 테이블로 구성하고 싶었다. 가령 색상 옵션과 사이즈 옵션은 범용되므로 어떤 상품에서도 불러올 수 있는 것이다. 아래 게시글은 옵션 테이블에 대한 내용인데
댓글에서 옵션 테이블을 다음과 같이 조언했다.
--
상품코드(FK)
옵션구분(PK)
옵션별가격(Not Null)
비고
--
다음의 자료에서도 옵션 테이블에 대한 정의는 같았다.
결론적으로 내가 생각했던 할인 테이블 같은 형태는 아니었다. 상품 코드를 외래키로 참조하는 형태였다.
그외 상품 데이터와 관련이 있다고 예상되는 테이블 목록은 다음과 같다.
- 상품 이미지 테이블
- 재고 테이블
- 상품 제작 정보 테이블
- 이용안내 테이블
- 배송 정보 테이블
- 연관 상품 테이블
- 검색엔진 테이블
3단계: 테이블 간 관계 설정하기
이제 테이블들을 서로 연결해주면 된다. 연결 관계는 다음의 블로그를 참고했다. 전체 ERD에서 상품 테이블 부분을 보면 옵션, 가격, 이미지, 카테고리 등으로 상품 테이블을 독립적으로 정의했음을 알 수 있었다.
마치며
회원 데이터 설계 때보다는 아주 조금 덜 삽질했다. 확실히 옵션 데이터 같은 경우는 DB 설계 시 개발자들도 어려움을 겪는 것 같았다. 일단은 옵션을 관리할 수 있는 범위까지 완성했는데 더 들어가면 옵션에 따른 가격 차이까지 확장할 수 있을 것 같다. (추가금액 컬럼을 생성하면 될 듯?)
다른 사람들이 설계한 ERD를 보면서.. 기획에 정답이 없다고들 하지만 개발 역시 정답이 없다는 생각이 들었다. 같은 결과물을 목표함에도 불구하고 접근 방식이 다양했다. (그리고 결국 결과물도 천차만별이다) 그래서 이게 맞는건지.. 나만 이렇게 어려운지.. 쓸데없는 삽질이 아닌지.. 다들 같은 생각을 하지 않을까 싶다.
사용툴: MySQL, PowerPoint
참고자료
'서비스 기획 > 바닥부터 이커머스 시스템 기획' 카테고리의 다른 글
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 |
댓글