[ERD 설계] 오늘의집 - ERD 설계

ERD 설계는 '생활코딩 - 관계형 데이터 모델링' 강의 내용을 참고하여 진행하였다.

1. 필요한 Entity 뽑아내기

• 오늘의집 페이지는 이미 완성된 웹페이지이기 때문에 화면 자체를 기획자로부터 넘겨받은 스토리보드, 기획서라고 생각하고 ERD 모델을 구상하기로 하였다. 여러 페이지를 띄워놓고 묶을 수 있는 덩어리, 속성으로 Entity 와 Attribute 선택, 모든 것들을 Attribute에 포함하지는 않고 프로젝트에 필요한 일부만 옮기기로 하였다.

1. 사용자와 관련된 페이지들

회원가입 & 회원정보수정 & 마이페이지 홈

마이페이지 스크랩북 & 판매자 정보

판매자 신청화면

2. 판매글과 관련된 페이지들

카테고리 상세정보 & 1,2,3차 카테고리에 따른 세부 카테고리

판매글 클릭 페이지 & 판매글 리뷰 영역

판매글 페이지 문의 영역 & 상품 문의 페이지

주문 배송 내역 조회 페이지

---

2022.01.09. 프로젝트를 진행한 과정, 얻어간 점들을 남기기 위해 수정된 방향이 있을 경우 이전 방법에 어떠한 문제가 있었는지, 어떻게 수정하였는지도 함께 남기기로 하였다.

< 1주차 ERD 설계 중 발견한 문제점 >

1. 생활코딩 - 관계형 데이터 모델링 강의의 ERD 설계를 오늘의집 전체 페이지에 적용하려고 하니 너무나 기능이 많고 복잡하게 얽혀있어 Entity / Attribute / Relation 을 뽑아내기 쉽지 않았다. ERD 를 그리기 이전에 뭔가 정리하는 과정이 선행되어야 할 것 같다는 느낌이 들었다.
2. 다른 글을 참고하여보니 이 서비스가 처리해야하는 데이터를 파악하고, 데이터베이스의 용도를 파악하는 요구사항을 먼저 받고, 이 요구사항 명세서로부터 필요한 정보들을 뽑아내어 데이터 모델링을 진행하는 것이라고 한다. 아래는 '참고한 링크들' 에 있는 페이지들을 참고하였다.

https://velog.io/@jcinsh/%EB%8D%B0%EC%9D%B4%ED%84%B0%EB%B2%A0%EC%9D%B4%EC%8A%A4-%EC%8A%A4%ED%83%80%EB%B2%85%EC%8A%A4-%EA%B3%BC%EC%A0%9C

데이터베이스 ERD 설계 : 스타벅스 과제

https://velog.io/@doryyy/TIL-%EB%8D%B0%EC%9D%B4%ED%84%B0-%EB%AA%A8%EB%8D%B8%EB%A7%81

[TIL] 데이터 모델링

https://velog.io/@sunnysideup/4.-%EB%8D%B0%EC%9D%B4%ED%84%B0-%EB%AA%A8%EB%8D%B8%EB%A7%81-%EC%8B%A4%EC%8A%B5

5. 데이터 모델링 : 실습

https://velog.io/@hion8800/e-commerce-%EB%8D%B0%EC%9D%B4%ED%84%B0-%EB%AA%A8%EB%8D%B8%EB%A7%81-%EA%B3%B5%EB%B6%80

e-commerce 데이터 모델링 공부

---

때문에 페이지를 보며 정확히 어느 기능까지 구현할 것인지 팀원과 논의 후, 최대한 디테일하게 요구사항 명세서를 먼저 작성하였다. 요구사항 명세서에 대한 자세한 형식이나 방식은 잘 알지 못하여 일단 데이터베이스가 처리해야하는 데이터 위주로 작성하였다...(사용자, 스토어 관련 기능만 작성, 커뮤니티 부분 명세서는 다른 팀원이 맡았다.)

1. 요구사항 분석하기

• 회원가입에는 이메일, 비밀번호, 생년월일, 닉네임, 약관동의가 필요하다. (필수항목)
• 회원가입한 회원은 선택적으로 성별을 설정할 수 있다. (선택항목)
• 회원은 다른 사용자와 팔로우 - 팔로잉 관계를 맺을 수 있다.
• 회원은 관심있는 상품, 사진, 집들이, 노하우 글들을 '스크랩북' 으로 저장하여 쉽게 찾아볼 수 있도록 관리할 수 있다. (상품, 스토리, 노하우로 분류하기로 결정)
• 회원은 관리자와 일반 회원으로 나뉜다.
• 회원은 판매자가 될 수 있으며, 이 때 회사이름, 대표자이름, 사업장소재지, 고객센터 전화번호, E-mail, 사업자 등록번호 정보를 추가적으로 받는다.
• 회원가입을 할 때 이메일, 닉네임에 대해, 판매자 전환할 때 회사이름에 대해 중복 확인을 해야한다.
• 상품은 카테고리, 브랜드명, 이름, 대표이미지, 할인율, 가격, 별점, 리뷰, 배송방법(무료, 유료), 여러가지 옵션들, 옵션에 따라 달라지는 가격, 상품 관련 문의 정보를 갖는다.
• 카테고리는 1, 2, 3차 카테고리가 있으며, 카테고리를 선택할 때마다 해당 카테고리가 가지는 필터로 상품을 다시 한 번 필터링할 수 있다. (1, 2, 3 차 카테고리 분류까지만 우선 구현, 각 카테고리별 필터링은 추후 논의)
• 리뷰는 회원닉네임, 별점, 날짜, 회원이 선택한 옵션, 이미지, 글, 도움이 돼요(좋아요 기능과 같은) 정보를 갖는다.
• 문의는 회원닉네임, 구매여부(구매, 비구매), 날짜, 카테고리, 상품 및 옵션 (선택 안 함 가능), 문의 내용, 답변유무(답변완료, 미답변) 정보를 가진다.
• 주문은 주문번호, 날짜, 상품이름, 옵션, 가격, 개수, 주문상태여부(취소, 환불, 교환, 배송중, 배송완료, 배송중), 배송방법(유료, 무료), 판매대표자 이름, 판매자 전화번호, 리뷰, 배송지(받는 사람, 연락처, 주소, 배송메모) 정보를 가진다. 
• 배송지는 배송지명, 이름(실명), 전화번호, 주소, 기본배송지여부(T, F) 정보를 갖는다.

  ---

   
• 커뮤니티에서 게시글은 썸네일(대표이미지)과 제목만 표시된다. (몇 개까지 노출할 것인지 추후 논의)
• 커뮤니티는 카테고리로 분류된다. (스토리, 노하우, 리뷰, Q&A, 이벤트 등)
• 커뮤니티 글은 게시글 번호, 카테고리, 제목, 본문, 작성자, 작성일, 썸네일(대표이미지), 좋아요, 스크랩, 댓글, 대댓글, 조회수, 이미지에 포함된 상품 연결 링크를 갖는다. (좋아요, 스크랩 중 스크랩 횟수만 표기, 대댓글의 겨우 일단은 생략, 구현해보도록 노력, 이미지에 포함된 상품 연결 링크는 조금 더 찾아보고 논의)
• 회원은 글쓰기 버튼을 통해 글의 카테고리(스토리, 노하우)를 선택할 수 있으며, 제목, 본문을 작성, 본문 내 이미지를 첨부할 수 있다. (태그된 상품은 해당 상품 판매페이지로 이동하는 링크 제공, 방법 찾아보기)  
• 회원은 본인의 글을 삭제, 수정할 수 있다.
• 커뮤니티 글 중 ‘스토리’ 는 한 명의 회원만 작성, 수정이 가능하다.
• 커뮤니티 글 중 ‘노하우’ 는 복수의 회원이 작성, 수정이 가능하다.
• 이벤트 페이지의 경우, 게시글은 관리자만 남길 수 있다.
• 하나의 커뮤니티 글에 n명의 유저가 m개의 댓글을 달 수 있다.
• 댓글은 댓글아이디, 게시글번호, 작성자, 작성일, 본문을 가진다.
• 회원은 자신의 댓글을 삭제, 수정할 수 있다.
• Q&A의 경우, 댓글은 관리자만 달 수 있다.
• 하나의 댓글에 여러 개의 대댓글이 달릴 수 있다.
• 대댓글은 댓글아이디, 게시글 아이디, 본문, 작성자, 작성일자로 구성된다.
• 대댓글은 댓글과 마찬가지로 댓글아이디로 식별된다.

※ ERD 설계 과정에서 요구사항 명세서를 수정한 부분들이 있어 차이가 있을 수 있습니다.

2. ERD 모델 설계

2022.01.12. ERD모델을 설계할 때 생각보다 서비스적인 부분에서 많은 결정이 필요했다.

• 회원은 게시글에 무한히 이미지를 첨부할 수 있게할 것인가, 제한할 것인가
• 판매자는 상품에 무한히 이미지를 첨부할 수 있게할 것인가, 제한할 것인가
• 판매자는 상품의 옵션은 계층형으로 무한히 존재할 수 있게 할 것인가, 옵션의 레벨을 제한할 것인가
• 상품의 카테고리는 계층형으로 무한히 존재할 수 있게 할 것인가, 레벨을 제한할 것인가
• 게시글과 댓글을 작성한 회원이 회원탈퇴를 했을 때, 해당 글을 유지할 것인가, 삭제처리 할 것인가

이렇게 최종적으로 ERD 를 그리며 확장성과 삭제, 수정에 대한 종속성 등 어떻게 서비스를 제공할 것인지에 대해 결정해야할 부분이 이렇게 많을 줄 몰랐다. 단순히 데이터를 잘 저장하기만 하면 되는 줄 알았는데, 데이터 저장 방식을 결정하는 순간부터 서비스의 방향이 결정됨을 깨달을 수 있었던 좋은 경험이었다....(ERD 설계에 이렇게 오래 걸릴 줄은 몰랐다..)

https://www.erdcloud.com/u/domo7304

ERDCloud

해당 링크로 들어가서 today-house 를 클릭하면 자세한 ERD 를 확인할 수 있다.

완성된 ER diagram...

상품 옵션 및 카테고리 등 계층형 데이터 구조 저장 방식에 대해 참고한 링크글

https://tecoble.techcourse.co.kr/post/2021-09-03-hierarchy-data-with-rdb/

관계형 DB에서 계층적인 데이터 관리하기

https://coderedirect.com/questions/252518/adjacency-list-model-vs-nested-set-model-for-mysql-hierarchical-data

https://www.mysqltutorial.org/mysql-adjacency-list-tree/

Managing Hierarchical Data in MySQL Using the Adjacency List Model

https://www.programmersought.com/article/15841713237/

Database recursive query: MySQL VS Sequelize - Programmer Sought

https://hyeyun133.tistory.com/entry/04-%EC%83%81%ED%92%88-%EB%8D%B0%EC%9D%B4%ED%84%B0-%EC%84%A4%EA%B3%84

04. 상품 데이터 설계

https://okky.kr/article/415296

OKKY | 테이블을 어떻게 짜야 할지 모르겠네요...

https://www2.slideshare.net/HanSungKim4/db-project-gmarket?from_action=save 

DB Project - Gmarket