데이터베이스 수업 기말 팀 프로젝트가 시작되었다. 우리 팀은 온라인 의류 쇼핑몰을 주제로 잡았다. 1주차에는 개념적+논리적 설계 및 간단한 API 명세서를 작성하였다. 나는 주문 파트를 맡았다.
1. ERD
주문과 관련된 엔티티들만 ERD를 작성하였다. 아래는 ERD를 설계해보며 어려웠던 점을 기록하였다.
- 배송지 주소
- 여러 값을 가질 수 있는 배송 주소 엔티티가 따로 있기에 주문 엔티티에도 배송지주소 속성을 넣어야 하는지 의문이 들었다.
- 그냥 배송 주소 의 ID를 외래키로 참조하면 되지 않나?라 생각했는데 사용자가 중간에 주소를 수정하거나 삭제하면 과거의 주문 내역을 조회했을 때 배송지가 바뀌어 있거나 조회되지 않을 수 있는 상황이 발생할 수 있다. 그래서 주문 속성에 ‘주문시점 주소’를 추가하였다.
- 총 주문 금액
- 굳이 속성으로 넣어야 되나? 고민했는데, 매번 함수를 써서 계산하면 성능이 아주 안 좋아질 수 있겠다 생각이 들었다. 그래서 미리 계산 후 속성으로 넣는 게 좋은 방향인 것 같다.
- 추가로 개별 상품 가격의 합과 주문 테이블의 총액이 일치하는지 비교하면 데이터에 오류가 없는지 확인도 해볼 수 있다.
- 마지막으로 우리 db 설계에서 배송비가 회원 등급마다 다르므로 미리 계산해두는게 안전할 것 같다.
- 운송장 번호
- 회의에서는 운송장 번호를 ‘주문날짜+주문아이디’로 하기로 했었는데, 이건 그냥 주문 번호같은 느낌이 들었다.
- 운송장 번호는 택배사에서 발급해주는거니까 운송장 번호를 넣을거면 택배사 엔티티도 필요한 것 같은데, 지금 설계에서는 업체도 후순위기도 하고 실제 배송 추적 시스템까지 만들건 아니기 때문에 그냥 뺐다.
2. 논리적 설계
위에 ERD를 바탕으로 논리적 설계를 하였다.
주문
주문 (주문ID(PK), 회원ID(FK), 주문일자, 주문시점 배송지, 총결제금액)
-
주문ID (BIGINT): NOT NULL, AUTO_INCREMENT
-
회원ID (BIGINT): NOT NULL
- 회원ID 참조(FK)
-
주문일자(DATETIME(6)): NOT NULL
-
주문시점 배송지 (VARCHAR(255)): NOT NULL
-
총결제금액(INT): NOT NULL
-
참조 무결성:
- ON DELETE: RESTRICT
- 회원 삭제 시 회원의 상태를 “탈퇴”로 변경
- 주문 자체는 삭제하지 않는걸로
- ON DELETE: RESTRICT
주문목록
주문목록(주문목록ID(PK), 주문ID(FK), 상품ID(FK), 주문상태ID(FK), 수량, 주문시점 가격)
-
주문목록ID (BIGINT): NOT NULL, AUTO_INCREMENT
-
주문ID (BIGINT): NOT NULL
- 주문ID 참조 (FK)
-
상품ID (BIGINT): NOT NULL
- 상품ID 참조 (FK)
-
주문상태ID (BIGINT): NOT NULL
- 상태ID 참조 (FK)
-
수량 (INT): NOT NULL, DEFAULT 1
-
주문시점 가격 (INT): NOT NULL
-
참조 무결성:
- ON DELETE: CASCADE ⇒ 주문 삭제 시 주문목록도 삭제
- ON DELETE: RESTRICT ⇒ 상품 삭제 시도해도 막음
- ON DELETE: RESTRICT ⇒ 주문상태 삭제 시도해도 막음
주문상태
주문상태(상태ID(PK), 상태명)
- 상태ID (BIGINT): NOT NULL, AUTO_INCREMENT
- 상태명 (VARCHAR(50)): NOT NULL
3. API 명세서 작성
주문이 생성(create)될 때, 클라이언트가 보낸 상품 배열 데이터를 바탕으로 주문목록 테이블에도 일괄적으로 삽입(insert)이 되어야 한다. 또한 회원이 본인의 '전체 주문 내역 목록'을 조회하는 것과 특정 주문 클릭 시 '상세 내역'을 조회하는 read가 각각 필요하다. 마지막으로 주문 전체 최소를 할 경우의 update가 필요하다.
주문상품은 주문이 들어오면 자동으로 주문상품도 같이 생성되어야 하므로 주문상품의 create는 필요없다. 그리고 고객입장에서는 개별적으로 생성/삭제할 일이 없다. admin이 주문상태를 변경시켜 줄 때와 사용자가 개별 상품을 주문 취소할 때만 update가 필요하다. 논리적으로 삭제는 필요하지 않다. Admin 권한이 필요한 행위는 URI 최상단에 /admin을 붙여 사용자 API와 명확히 분리하였다.
주문상태는 룩업 테이블이니 API 명세서를 따로 작성할 필요가 없다.
