데이터베이스 설계를 해보고 싶어서 얕은 지식이지만 시작해봤다.
간단하게, 카페 앱에서 지점을 선택하고 메뉴를 주문, 결제하는 과정을 설계해본다.
1. 요구사항 분석
간략하게 주요 기능을 찾아봤다.
앱의 기능을 사용해 보면 더 찾기 쉽다. 투썸 하트 앱을 참고했다.
요구사항 명세서에서 개체와 속성, 관계를 추출해준다.
2. 개념적 설계
추출한 것들로 개념 ERD를 그려준다. (보기 쉽게 속성은 제외함)
테이블이 너무 많으면 복잡해져서
메뉴가 지점별로 다르면 지점과 메뉴가 다대다인데, 일단 모든 지점 메뉴가 같다고 진행
쿠폰도 할인 쿠폰, 잔액 쿠폰, 기프티콘마다 관계가 다른데 일단 잔액 쿠폰만 진행
3. 논리적 설계
ERD에서 관계들 릴레이션 스키마 변환 규칙 적용해서 외래키 지정
사이즈 추가 금액과 원두 추가 금액이 겹쳐서 일단 정규화 해봤는데,
이렇게 분리하면 테이블이 많아져서 join이 복잡해진다.
회원 테이블만 테이블 명세서를 만들어봤다.
4. 물리적 설계
MySQL Workbench로 만든 물리 ERD
5. 구현
테이블에 값을 INSERT하고 회원가입, 주문, 결제, 정보 조회 해봤다.
회원등급과 하트개수는 default값이 들어가도록 해봤다.
주문, 주문상세, 결제, 장바구니, 회원번호는 auto_increment 옵션으로 자동증가하게 해봤다.
주문을 외래키로 가지는 자식 테이블에 on DELETE cascade 옵션으로
주문이 제거되면 주문상세, 장바구니도 연쇄삭제 되도록 해봤다.
데이터 조회 결과
조인을 사이즈와 원두 가격때문에 2개가 늘어나서 5번을 해야했는데,
몇 개의 조인까지가 적당하고 성능에 얼마나 영향을 주는 지는 잘 모르겠다.
트랜잭션을 저렇게 쓰는게 맞는지 데이터 조회를 올바르게 한 것인지는 모르겠다.
설계한 것을 실제로 사용해 보면서 많이 깨달았다.
실패한 ERD
처음 요구사항 분석을 단순하게 생각해서 장바구니를 결제, 쿠폰을 결제에 적용 이런 식으로 했다가 다시 처음부터 해야 하는 불상사가 발생했다. 요구사항 분석이 엄청 중요하다고 느낌
쿠폰, 주문 상세, 장바구니, 지점 메뉴, 등 헷갈리는 것이 많다.
세세하게는 안 하고 큰 기능들만. 퍼스널 옵션까지 하면 너무 복잡해져서 몇몇 기능들은 제외했다.
찜 같은 건 제외, 서브 카테고리 제외, 사이즈별로 영양성분이 다른 것 생략
할인 쿠폰 - 회원 다대다 생략, 잔액 쿠폰은 회원당 하나지만, 이벤트 쿠폰 같은 건 하나의 쿠폰을 여러 회원에게 제공한다. 할인 쿠폰 같은 경우 쿠폰 테이블에서 할인율 20%인 A 쿠폰이 있고 회원 번호 1에게 A 쿠폰 제공 하나의 쿠폰은 여러 회원에게 제공, 하나의 회원이 여러 쿠폰을 가질 수 있음(다대다), 쿠폰_회원 테이블에서 (1, A) 이런 식으로 해야 하는데 테이블 많아져서 생략
금액 관련 속성에서 계산되는 속성 결제 총 금액이나, 장바구니에 총 수량은 뺐다.
메뉴 x 수량 + 추가 금액으로 구할 수 있음, 결제 수단별 혜택 pass
아쉬운 부분은 많지만, 설계하는 것에 의의를 뒀다.
설계에 정답이 없어서 더 어려운 것 같다.
직접 설계해 보고 사용하는 게 정말 많이 도움이 된다.
추상적이던 데이터베이스가 어느 정도 보인다.
