교육받고 있는 과정의 팀 프로젝트로 쇼핑몰 웹사이트를 만들고 있고 거의 다 완성하였다.
이 과정에서 내가 작성한 코드나, 공부한 것 등을 정리하려고 한다.
사용자 페이지와 관리자 페이지를 나누어서 개발했고 나는 사용자 기능에선 주문/결제, 배송지 등록/관리, 주문리스트/주문상세 관련 기능 맡았다.
관리자 기능에선 실시간 매출 데이터 분석, 상품관리와 공지/이벤트관리를 맡아 개발하였다.

ERD란?

'Entity Relationship Diagram' 의 약자로 이름 그대로 Entity 들의 관계를 나타내는 다이어그램이다.
여기서 Entity는 보통 데이터를 뜻하니, 데이터들의 관계를 나타낸 도표를 의미한다.

쇼핑몰 ERD 설계

쇼핑몰에는 상품, 고객, 주문과 관련된 데이터들이 있을 것이고, 이것들의 관계와 그렇게 설계한 이유를 정리하려고 한다.

전체적인 ERD 구성으로 색상별로 연관된 기능을 정리하였다.
기본적으로 모든 테이블이 고유번호를 Primary Key로 갖고 있게 하여, 그 Key를 이용해 테이블의 조회나 테이블끼리의 JOIN에 이용할 수 있게 하였다.
이 Primary Key는 중복되어 들어가면 안되고, 사용자나 관리자가 임의로 지정하면 오류가 뜰 수 있기 때문에 SEQUENCE를 이용하여 자동으로 숫자가 증가하게 설정하였다.

회원

기본적으로 ID가 될 이메일과 비밀번호와 개인정보들, 그리고 정지여부, 탈퇴여부가 있다.
특이한 점으로는 비밀번호는 회원가입 페이지에서 8~20글자로 제한할 것인데 VARCHAR(150)으로 크게 주었다.
그 이유는 SpringSecurity의 Bcrypt를 이용하여 암호화를 할 경우 길이가 ~60정도로 늘어나기 때문에, 암호화를 할 것이라면 넉넉하게 잡는 것이 좋을 것 같았다.
성별은 주민등록번호 뒷자리로 판단하여 1,3이면 남성이고 2,4면 여성으로 분류할 것이다.
정지나 탈퇴는 실제로 database에서 회원의 정보를 삭제하지 않고 해당 필드의 값으로 분류하려고 만들었다.
정지나 탈퇴 시 database에서 실제로 해당 회원의 데이터를 지우면 회원과 연관된 주문상세, 후기, 문의 등등의 다양한 데이터에 영향을 주거나 제대로 작동하지 않을 수 있기 때문이다.
따라서 정지여부, 탈퇴여부의 필드를 만들어서 분류하는 것이 안전하게 데이터를 관리하는 방법일 것이다.

배송지

배송지 테이블에는 특별한 점은 없고, 회원이 배송지를 등록하게 만들어 그것을 조회할 것이기 때문에 회원 고유번호만 외래키로 지정하여 받았다.
기본배송지여부는 'Y'면 view에서 기본으로 보여지고, 'N'이면 view에 아무것도 보여주지 않으려고 만들었다.

주문과 주문상세

기본적으로 주문상세에 주문번호를 외래키로 하여 하나의 주문에 여러개의 주문상세가 들어갈 수 있게 설계하였다.
이렇게 해야 주문 데이터 하나에 여러개의 상품에 대한 정보를 저장할 수 있고 주문/결제 기능을 구현할 때도 편리하게 할 수 있다.
주문상세에서 상품 Key를 가져왔는데도 가격을 저장한 이유는 상품의 가격은 관리자가 수시로 바꿀 수 있지만, 이미 주문한 내역에는 예전 가격이 저장되어야하기 때문에 따로 저장해놓게 하였다.
주문테이블에 배송지 관련해서도 배송지 Key를 외래키로 가져오지 않고 직접 저장한 이유는 사용자가 배송지는 삭제하거나 수정을 쉽게 할 수 있는데,이미 주문한 데이터에는 예전 데이터로 저장되어야하기 때문에 필드를 따로 만들었다.

상품과 카테고리

카테고리는 1차 카테고리와 2차 카테고리로 분류할 수 있게 하려고 self 참조를 시켰다. 이 때, 1차 분류만 있을 수도 있기 때문에 2차 카테고리는 NULL 허용으로 하였다.
(예: 갈비=1차:한식, 김치찌개=1차:한식,2차:찌개)
상품에도 삭제여부가 있는데, 이는 위에 설명한 회원의 탈퇴여부와 비슷하다.
상품을 삭제한다고 database에서도 데이터를 삭제하게 되면 해당 상품을 참조한 테이블에서 오류가 생길 수도 있기 때문에 실제로 삭제하지 않고 삭제여부라는 필드를 만들어서 분류하였다.

장바구니

장바구니도 사실상 하나의 장바구니에 여러개의 상품을 담는 것이 아니라, 여러개의 데이터를 생성하여 회원 Key로 묶어서 사용한다.
이렇게 하여도 장바구니는 구매하거나, 사용자 View에서 데이터를 삭제하거나 하면 해당 데이터가 없어지기에 일시적으로 데이터를 저장하는 용도로 사용되어 많은 데이터가 쌓이지는 않는다.

찜

찜 테이블은 특이한 점은 없고, 회원 Key와 상품 Key를 참조하는 것으로 존재하지 않는 데이터가 들어가는 것을 막은 정도이다.

문의 및 후기

처음에는 문의 테이블과 후기 테이블을 따로 만드려고 생각했었다.
하지만 사실상 문의 테이블과 후기 테이블에 필요한 필드들이 거의 비슷하기 때문에, 종류(ntype)라는 필드를 만들어 문의와 후기를 분류하기로 하였다.

댓글

댓글은 딱히 특이한 점이 없는 테이블이다.

관리자

관리자는 계획할 때부터 회원가입이나 탈퇴 페이지를 만들지 않고, 개발자쪽에서 직접 처리하는 방식으로 하려고 계획하였다. 그래서 최소한의 필요한 필드만 존재하게 되었다.

공지사항, 이벤트

공지사항과 이벤트도 필요로하는 필드와 로직 등이 비슷하기 때문에 문의 및 후기와 같은 방식으로 ntype 필드로 글의 종류를 분류하여 구현하였다.