웹 디자이너가 템플릿을 바로 작업할 수 있게 해줬더니 DB가 죽었어요 (1)

쇼핑몰을 개발하기로 했다. 요구사항은 다음과 같다.

상품을 여러 분류로 나누고, 각 분류에는 여러 개의 상품을 목록으로 보여준다. 각 상품은 여러 분류에서 보이도록 할 수 있다.

회원은 상품을 구매할 수 있고, 구매 여부와 상관없이 각 상품에 대해 평가와 평점을 남길 수 있다.

관리자는 분류별, 상품별, 회원별로 구매 목록과 평가, 평점을 볼 수 있다. 여러 명의 관리자가 있다. 관리자는 상품 관리, 발주, 문의 대응 등으로 담당 업무가 나뉜다.

상품과 분류

• 상품(Product)과 분류(Category) 엔티티를 추가.

각 분류에는 여러 개의 상품을 목록으로 보여준다

• 분류에 여러 상품을 볼 수 있도록 릴레이션을 추가.

각 상품은 여러 분류에서 보이도록 할 수 있다

• 하나의 상품을 여러 분류에서도 볼 수 있도록 하려면, 분류 : 상품은 M : N 관계로 변경한다.

회원은 상품을 구매할 수 있다

• 회원(Customer)이 상품(Product)을 구매(Order)하면 기록이 남는다.
• 한 상품을 여러 회원이 구매할 수도 있고, 한 회원이 한 상품을 여러번 구매할 수도 있다.
  • 한번에 한 종류의 상품만 살 수 있다고 가정한다.
  • 한번의 주문에서 여러 종류의 상품을 구매할 수도 있지만, 지나치게 복잡해지므로 무시한다.

구매 여부와 상관없이 각 상품에 대해 평가와 평점을 남길 수 있다

• 상품(Product)에 대해 평가(Review)와 평점(Score)을 따로, 한번씩만 남길 수 있다고 가정한다.
  • 평가와 평점을 한 엔티티에서 관리하면서 평가만 남기거나 평점만 남기거나 둘을 함께 남기는 방식을 사용할 수도 있지만, 구현이 복잡해지니 따로 정의한다.
• 회원이 서비스에서 할 수 있는 행동이 늘어나면 늘어날수록 복잡해진다.

관리자는 분류별, 상품별, 회원별로 구매 목록과 평가, 평점을 볼 수 있다

이 요구사항은 엔티티의 종류나 관계가 바뀌지 않는다.

여러 명의 관리자가 있다

• 관리자(Admin)가 여러 명이 있다.

관리자는 상품 관리, 발주, 문의 대응 등으로 담당 업무가 나뉜다

• 상품 담당자는 상품(Product)과 분류(Category)를 관리한다.
  • 재고관리나 수량 한정 행사 같은 것까지 생각하면 너무 복잡해지니 생략.
• 발주 담당자는 발주내역(Invoice)를 관리한다.
  • 발주할 때마다 발주처를 등록하거나 발주처 하나가 한가지 상품만 취급하거나 한번에 한가지 상품만 발주하지는 않는다. 하지만 너무 복잡하니 생략.
• 문의 담당자는 고객문의(Inquiry)를 관리한다.
  • 대응이 한번에 끝나지 않고 몇 번에 걸쳐 처리해야 할 수도 있고, 그 사이에 회원 반응이 필요할 수도 있다. 하지만 복잡하니 생략.