개념적 모델링 실습

쇼핑몰 초기 기능 명세서

• 회원 기능: 가입, 탕퇴, 여러 배송지 관리, 기본 배송지 설정 등
• 판매자 기능
  • 누구나 우리 쇼핑몰에 입점해서 제품을 판매할 수 있는 오픈마켓
  • 외부 판매자 입점, 판매자 별 상품 등록 및 관리, 판매자 정보 관리(상호명, 사업자번호 등) 판매자 정산 등
• 상품 및 카테고리 기능: 상품 등록, 카테고리 관리, 가격/재고 변경 등
• 장바구니 가능: 상품 담기, 수량 조절 등
• 주문 기능: 장바구니에 담긴 여러 상품을 한 번에 주문, 배송지 선택, 쿠폰 적용, 주문 상태 관리 등
• 결제 기능: 신용카드, 계좌이체 등 다양한 결제 수단 연동
• 배송 기능: 배송 상태 추적(준비 중, 배송 중, 완료), 운송장 번호 관리
• 리뷰 기능: 구매 완료 상품에 대한 별점 및 리뷰 자성
• …등등

1단계: 핵심 요구 사항 다시 정의하기 (MVP)

• 외부 판매자 기능: 1차 목표는 우리 회사 상품을 온라인으로 판매하는 것이기 때문에 제외
• 쿠폰, 리뷰, 복잡한 카테고리: 일단 업성도 주문은 가능. 2차 오픈 기능으로 미룸
• 장바구니 기능: 매우 중요하지만 클라이언트 측에시 임시 보관하도록 구현 하는 것으로 설계

쇼핑몰 MVP 기능 명세서

• 회원: 고객이 가입하고 자신의 정보를 관리할 수 있어야 한다.
• 상품: 우리가 판매할 상품을 등록하고 관리할 수 있어야 한다.
• 주문: 회원이 상품을 구매할 수 있어야 한다.
• 결제: 주문에 대한 결제 정보를 기록하고 관리할 수 있어야 한다.
• 배송: 결제가 완료된 주문의 배송 상태를 관리할 수 있어야 한다.

2단계; 핵심 엔티티 도출

• 회원(Member): 서비스를 사용하는 고객
• 상품(Product): 판매의 대상이 되는 물건
• 주문(Order): 회원의 구매 활동 결과
• 결제(Payment): 주문에 대한 지불 정보
• 배송(Delivery): 주문된 상품의 물리적 이동에 대한 정보

도출된 핵심 엔티티: 회원, 상품, 주문, 결제, 배송

3단계: 속성 정의 및 관계 설정

속성

• 회원(Member): 회원id, 로그인id, 비밀번호, 이메일, 주소
• 상품(Product): 상품id, 상품명, 상품 가격, 재고 수량
• 주문(Order): 주문id, 주문 상태, 배송지 주소, 주문 일시
• 결제(Payment): 결제id, 결제 수단, 결제 금액, 결제 상태, 결제 일시
• 배송(Delivery): 배송id, 배송 상태, 운송장 번호

관계

• 회원과 주문의 관계: 1:N
• 주문과 결제의 관계: 1:1
• 주문과 배송의 관계: 1:1
• 주문과 상품의 관계: M:N

4단계: M:N 관계 해소와 연관 엔티티

두 엔티티의 관계 속에서만 의미를 가지는 속성이 있는가?

• 주문 수량
  • 주문 하나에는 상품이 여러 개 일 수 있으니, 특정 상품의 ㅅ량을 저장할 수 없다
• 주문 당시 가격
  • 상품 가격은 언제든 바뀔수 있음
  • 주문이 일어난 시점의 가격을 어딘가에 저장 해야함

주문 수량과 주문 당시 가격은 주문과 상품의 관계 속에서만 의미를 갖는 데이터입니다.

M:N 관계를 해소하고, 추가적인 데이터를 담을 새로운 테이블이 필요합니다.

연관 엔티티 추천 이름 및 특징

• 연결 강조
  • 주문 상품(order_product)
    • 주문과 상품 테이블을 직접적으로 연결한다는 관계를 이름에 명시적으로 보여줌
    • 매우 직관적이고 단순하여 관계를 파악하기 쉽다는 장점이 있음
• 의미 있는 이름
  • 주문 항목(order_item)
    • 주문에 포함된 항목이라는 의미를 가장 명확하게 전달
    • 실제 쇼핑몰 비즈니스 로직과 용어가 일치하여 이해가 쉬움
  • 주문 상세(order_detail)
    • 주문의 상세 내역이라는 의미로 order_item과 거의 동일한 의미로 널리 사용
    • 주문에 속한 각 상품 정보를 상세히 나타낸다는 점을 강조

실무에서는 의미 있는 이름을 사용하는 것이 좋습니다.

5단계: 개념적 모델 ERD 작성

개념적 모델링에서 외래 키를 생략한 이유

원칙: 특정 기술과 독립적인 설계

개념적 모델은 데아터의 구조와 관계를 큰 그림에서 이해하기 위한 설계도 입니다. 이 단계에서는 어떤 DB 기술을 사용할지 결정하지 않았다고 가정합니다.

• 외래 키의 정체: 외래 키는 테이블 간의 관계를 연결하기 위해 사용하는 RDBMS 전용 기술
• 개념적 모델의 목표: 특정 기술에 얽매이지 않는, 순수한 데이터의 논리적 구조를 표현
• 관계 표현 방식: 따라서 개념적 모델에서는 외래키 대신 선을 사용해 회원과 주문 같은 데이터간의 관계를 표현

현실: 실용성을 고려한 접근

• 예상된 기술: 대부분 프로젝트는 처음부터 RDBMS 사용을 염두에 두고 모델링을 시작
• 효율성: 어차피 나중에 외래키를 추가할 것이므로, 설계 초기 단계부터 외래 키를 포함하면 전체 개발 과정이 더 효율적

실무에서는 개념적 모델링 단계임에도 불구하고 실용적인 관점에서 외래 키를 미리 포함하는 경우가 훨싼 많음

더 나아가서 처음부터 개념적 모델링 + 논리적 모델링을 함께 진행하기도 함

참고

• https://www.inflearn.com/course/김영한-실전-데이터베이스-설계1편