[BONBON] ERD 구성

🧩 ERD 구성

• 본사와 가맹점을 중심으로 ERD를 짰다.
• 사용자 계정의 삭제, 추가 로직 때문에 테이블 구성에 대한 고민을 꽤 오래 했었다.

---

계정 관리 ERD

• 가맹점주는 user 테이블에서 user_id를 외래키로 받고, franchise 테이블에서 franchise_id 또한 외래키로 받는다.
• 지역 별 담당자의 경우 사용자 테이블에서 user_id를 외래키로 받고, region 테이블에서 지역 코드인 region_code를 외래코드로 받는다.
• 본사에서 사용자 계정을 삭제할 때 가맹점주의 경우 가맹점주 튜플을 지운 뒤 사용자 튜플을 지우고, 가맹점은 가맹점주 없는 채로 유지되도록 했다. (가맹점주가 바뀌는 공백 상태도 있을테니..)
• 지역 별 담당자의 경우도 위와 동일하게 본사에서 삭제할 경우 담당자 테이블의 튜플을 지운 뒤, 사용자 테이블의 튜플을 삭제하고 해당 지역의 가맹점들은 해당 지역구의 담당자가 비어있는 채로 유지되도록 설정했다.

---

매출 분석 ERD

• 매출 분석 및 예측 테이블은 위와 같이 구성했다.

• 초기 ERD 설계에서는 판매 및 매출 예측 결과를 별도의 테이블로 저장하는 구조를 고려했다. 예측 결과를 정형화된 형태로 관리하고, 다른 서비스나 시스템에서 재사용 가능하도록 하려고 했다.

• 실제 구현 단계에서 Prophet 기반의 시계열 예측 모델을 사용하면서, 예측 결과를 실시간 혹은 요청 시 동적으로 생성하여 활용하는 방식이 더 유연하고 효율적이라고 판단해서 매출 예측, 판매 예측 목록 테이블은 실제 개발 때 쓰지는 않았다.

• 예측 결과의 활용 빈도나 정기 저장의 필요성이 낮았기 때문에, 별도 테이블을 구성하는 대신 결과를 캐싱하거나, 요청 시 생성하여 응답하는 방식으로 구현했다.

• 저장 비용을 줄이고 시스템 복잡성을 낮춰 예측 실시간성 및 정확성을 높일 수 있기는 했으나 역시 테이블을 다 만들어놓고 안쓰려니 약간 아깝긴 했다.

---

재고 관리 ERD

• 본사에서 전체 재고를 관리, 가맹점은 본사에 해당 원재료의 재고를 신청
• 가맹점이 본사에 입금해야 할 금액은, '가맹점 재고 신청 내역'을 기준으로 자동 산정되는 구조로 설계했다. 이후 자동 청구/정산 시스템 확장 및 순매출 자동 계산 시스템으로의 확장까지 생각했다.
• 재고 쪽은 원재료를 바탕으로 해당 원재료들의 수량에 따른 메뉴 상세 테이블과 메뉴 테이블을 연결했다. 원재료 테이블과 메뉴가 다대다 관계여서 메뉴 상세 테이블을 추가해야 했다. 원두 하나로 라떼나 커피와 같은 여러 가지 메뉴가 나올 수 있고, 메뉴 하나에 우유, 원두 등과 같은 여러 원재료들이 필요하기 때문이다.
• 메뉴 카테고리 역시 카테고리와 메뉴 사이 다대다 관계 해소를 위한 테이블이다.

👓 ERD 설계를 마쳤으니 본격적으로 개발에 돌입해보자.