🍀e-commerce 도메인 설계(1)

RDB

우리가 흔히 웹서비스라고 부르는 서비스의 대부분은 RDB를 이용한다.

RDB가 무엇이고, 왜 이걸 쓰는지에 대해서는 따로 정리할 예정이다.

RDB = Relational DataBase은 말 그대로 관계형 데이터 베이스라고 부른다.
관계형 데이터 베이스의 여러 특징이 있다.

1. 데이터를 테이블 단위로 관리한다.
2. 각 테이블은 다른 테이블과 관계를 가질 수 있다.
3. 확장성이 높고, 체계적으로 관리가 가능하다.

ㄴ 지나치게 간단하게 요약했는데

많은 웹 서비스들이 RDB를 사용하는 이유는 확장성이 높고 체계적이기 때문이다.
실제로 그냥 데이터베이스하면 대부분 RDB이다.

NoSql을 요즘에는 많이 사용한다고는 하는데, 웹서비스에서는 특수한 경우에만 사용하는 듯하다.

---

RDB 설계 ?

우리는 e-commerce 서비스를 만들고자 한다.
그러면 이 서비스를 유지하기 위한 데이터베이스가 필요하다.
이 데이터 베이스에 어떤 테이블들이 있어야 하고, 각 테이블에는 어떤 컬럼들이 있어야 할지를 결정하는게
DB의 설계작업이다.

지난 요구사항 분석에서 나온 요구사항들을 바탕으로 데이터 베이스를 설계해보자.

---

요구사항

고객 입장
고객은 회원가입과 로그인이 가능하다.
고객은 자신의 주소와 개인정보를 등록할 수 있다.
고객은 하나씩의 장바구니를 갖는다.
고객은 원하는 상품을 원하는 수량으로 장바구니에 담을 수 있다.
이때 주문은 장바구니 단위로 할수도 있고, 개별 주문도 가능하다.
자신이 주문한 상품들과 배송 현황을 확인 할 수 있다.

운영진 입장
판매자, 회원, 상품, 배송 업체, 카테고리의 CRUD가 가능해야 한다.
상품과 카테고리를 연결할 수 있어야 한다.
해당 상품을 배송할 배송 업체를 고를 수 있어야 한다.
판매자, 회원, 상품, 배송 업체, 주문, 카테고리의 통계성 조회가 가능해야 한다.

---

기본 테이블

위의 요구사항을 바탕으로 나온 기본적인 테이블들이다.

기본 테이블 리스트

1. USER(고객) 테이블
2. CART(장바구니) 테이블
3. SELLER(판매자) 테이블
4. DELIVERY_SERVICE(배송 업체) 테이블
5. PRODUCT(상품) 테이블
6. ORDER(주문) 테이블
7. CATEGORY(카테고리) 테이블
8. DELIVERY(배송 테이블)

* 굳이 장바구니 테이블을 만드는 이유는 장바구니에 담긴 상품들의 총합 등의 데이터가 필요할 수 있기 때문이다.

하지만 이 테이블들로 완전하게 기능을 구현하기는 어렵다.
예를 들어보자.

1. 장바구니-상품
   하나의 장바구니에 여러 상품을 담을 수 있다. 또 하나의 상품은 여러 장바구니에 담길 수 있다.
   즉 다대다의 관계를 표현할 수 있어야 한다.
   기존의 장바구니 테이블과 상품 테이블로는 다대다의 관계를 표현하기 어렵다.
   당연히 다대다를 매핑할 수 있는 중간 테이블이 있어야 한다.
   따라서 추가로 장바구니-상품 테이블을 만들어야 한다.

2. 주문-상품
   한번 주문할때 여러 상품을 동시에 주문할 수 있다.
   또 하나의 상품은 여러 주문들에 담길 수 있다.
   기존의 주문 테이블과 상품 테이블로는 다대다의 관계를 표현하기 어렵고,
   당연히 다대다 매핑을 위한 중간 테이블이 있어야 한다.
   따라서 주문-상품 테이블을 추가로 만들어야 한다.

3. 카테고리-상품
   하나의 상품은 여러 카테고리에 담길 수 있다.
   하나의 카테고리는 여러 상품을 담을 수 있다.
   다대다 관계이고, 이 관계도 마찬가지로 일대다- 다대일 관계로 풀기 위해서
   중간 테이블 카테고리-상품을 만들어야 한다.

결과적으로는

1. USER(고객) 테이블
2. CART(장바구니) 테이블
3. SELLER(판매자) 테이블
4. DELIVERY_SERVICE(배송 업체) 테이블
5. PRODUCT(상품) 테이블
6. CATEGORY(카테고리) 테이블
7. ORDER(주문) 테이블
8. DELIVERY(배송) 테이블
9. CART_PRODUCT(장바구니-상품) 테이블
10. ORDER_PRODUCT(주문-상품) 테이블
11. CATEGORY_PRODUCT(카테고리-상품) 테이블

이렇게 11개의 테이블이 필요하다 ! -> 물론 더 추가될 수 있다. 그때그때 추가하도록 하자.

---

연관관계 매핑과 중간 테이블

각 테이블의 관계를 명시해야 한다.

1. 고객 - 주문
   하나의 고객은 여러 주문을 가질 수 있다. 하나의 주문은 하나의 고객을 가진다.
   즉, 일대다 관계이다.
2. 고객 - 장바구니
   하나의 고객은 하나의 장바구니를 가진다. 하나의 장바구니도 하나의 고객을 가진다.
   일대일관계이다.
3. 판매자 - 상품
   하나의 판매자는 여러 상품을 가질 수 있다. 하나의 상품은 하나의 판매자를 가진다.
   즉, 일대다 관계이다.
4. 주문 - 주문-상품 - 상품
   하나의 주문은 여러개의 상품을 가질 수 있고, 하나의 상품은 여러개의 주문을 가질 수 있다.
   즉 다대다 관계이다. 그리고 이 다대다 관계를 풀기 위해서 중간 테이블인 주문-상품 테이블을 갖는다.
   중간 테이블을 고려하면, 다대다 관계는 일대다-다대일 관계로 풀 수 있다.
5. 장바구니 - 장바구니-상품 - 상품
   하나의 장바구니는 여러 상품을 담을 수 있고, 하나의 상품은 여러 장바구니에 담긴다.
   즉 다대다 관계이다. 그리고 다대다 관계를 풀기 위해서 중간 테이블인 장바구니를 갖는다.
   마찬가지로 일대다-다대일 관계로 풀면 된다.
6. 상품 - 배송업체
   하나의 상품은 하나의 배송업체를 갖는다. 배송업체는 여러 상품을 갖는다.
   즉 다대일 관계이다.
7. 상품 - 카테고리-상품 - 카테고리
   하나의 상품은 여러 카테고리에 담길 수 있고, 하나의 카테고리 안에 여러 상품을 담을 수 있다.
   따라서 다대다 관계이고 마찬가지로 일대다-다대일 관계로 풀면 된다.
8. 주문-상품 - 배송
   주문-상품은 하나의 배송을 가진다. 하나의 배송은 하나의 주문-상품을 가진다.
   일대일 관계이다.

결론
1. 모든 관계를 일대다로 풀었다. 다대다 관계도 결국에는 일대다 다대일로 풀린다.

최종적으로 나오는 도메인 모델은 다음과 같다.

---

테이블 구성

이제 실제로 하나의 테이블에 어떤 데이터가 들어가야 할지 = 어떤 컬럼을 만들지 생각해보자.

이 부분은 e-commerce라면 필요할 만한 데이터를 생각해서 작성했다.

고객 테이블에 필요한 데이터

1. 이름
2. 주소 (~시 ~구 ~동)
3. 상세 주소 (~아파트 ~동 ~호)
4. 핸드폰 번호
5. 이메일
6. 회원가입 시간
7. 가장 최근 로그인 시간

판매자 테이블에 필요한 데이터

1. 판매자 개인 이름
2. 업체 이름
3. 판매자 핸드폰 번호
4. 업체 번호
5. 사업자 등록 번호
6. 판매자 등록 시간
7. 판매자 정보 수정 시간

상품 테이블에 필요한 데이터

1. 상품 이름
2. 상품 설명
3. 상품 가격
4. 상품 재고
5. 상품 등록 시간
6. 상품 정보 수정 시간

장바구니 테이블에 필요한 데이터

1. 담은 상품 개수
2. 총 합계 금액
3. 장바구니 변경 시간

배송업체 테이블에 필요한 데이터

1. 배송업자 개인 이름
2. 업체 이름
3. 배송업자 핸드폰 번호
4. 업체 번호
5. 사업자 등록 번호
6. 등록 시간
7. 배송업체 정보 수정 시간

주문 테이블

1. 주문 총 합계 금액
2. 주문 시간
3. 주문한 상품들 총 개수
4. 주문 상태(결제 완료, 결제 취소)

카테고리 테이블

1. 카테고리 이름
2. 카테고리 설명
3. 카테고리 등록 시간
4. 카테고리 정보 수정 시간
5. 해당 카테고리에 담긴 상품 수

장바구니-상품 테이블

1. 등록 시간
2. 수정 시간

주문-상품 테이블

1. 등록 시간
2. 수정 시간

배송 테이블

1. 배송 상태(배송 시작전, 시작, 완료)
2. 배송 주소
3. 배송 상세 주소

카테고리-상품 테이블

1. 등록 시간
2. 수정 시간

이정도면 충분한것 같다..! -> 물론 생각이 나는게 있으면 추가하겠습니다. 아마 조회성 api랑 페이지 만들면서 더 추가할것 같습니다.

물론 이런 의문을 가질 수도 있다.

• 회원가입한다면서 토큰 테이블은 어디갔어..? -> 차후에 추가하겠습니다.
• fk, pk는 어디갔어..? -> 이것도 ERD 그리면서 마저 추가할 생각입니다.

전체적으로 내가 생각했던 요구사항들이 부족할 수 있다.
여기서 추가하면 정말 끝도 없이 추가할 수 있다.
예를 들어서,

1. 고객은 하나의 주소만을 가지지 않는다. 고객의 주소가 여러개를 저장할 수 있어야 된다!
2. 모든 상품이 다 저런 형식인가 ? 카테고리에 따라서 상품의 데이터가 달라질 수도 있다!
   그러면 상품 테이블을 부모로, 카테고리 마다 다른 테이블을 자식으로 만들어야 된다!
3. 로그인 전에 장바구니에 담고 로그인하면 합집합으로 자동 추가되야 한다 !
4. 상품마다 배송업체를 정하는 것보다, 고객이 배송업체를 선택해야 하는게 아니냐 !
5. 등등,,,,,

ㄴ 다 맞습니다. 그런데 이거까지 고려해서 하면 너무 시간이 오래 걸리고, 이건 서비스가 복잡해지는 과정이라고 생각합니다.
여기서 하는건 정말 간단한 서비스라고 생각하면 좋을것 같다 !
그래도 나름 확장성을 고려했음을 봐줬으면 좋겠다..!
사실 이미 어드민 3개를 합친다는것부터 좀 이상하다...

다음 게시글에서는 정의한 도메인 구조와 데이터들을 갖고 엔티티 모델과 실제 테이블을 그려보겠습니다.

* 참고로 그림은 대부분 draw.io를 통해서 그린다 !