ERD 다이어그램

---

3차 ERD

예약 테이블과의 연관 카디널리티 분석

(AS-IS)

• 예약:유저 = 1:1
• 예약:콘서트 = 1:1
• 예약:콘서트 날짜 = 1:1
• 예약:콘서트 좌석 = 1:1

(TO-BE)

• 예약:유저 = 1:N
• 예약:콘서트 = N:1
• 예약:콘서트 날짜 = N:1
• 예약:콘서트 좌석 = 1:1

---

2차 ERD

• 테이블개수 추가

---

1차 ERD

테이블 간의 관계

• 유저:예약 = 1:N
• 콘서트:날짜 = 1:N
• 콘서트:좌석 = 1:N
• 날짜:좌석 = 1:N
• 예약:콘서트 = 1:1
• 예약:날짜 = 1:1
• 예약:좌석 = 1:1
• 결제:예약 = 1:1

Enum 상태 정의

• 토큰상태
  • ACTIVE: 활성화된 토큰
  • WAITING: 대기상태 대기열 토큰
• 예약 상태
  • PENDING_PAYMENT : 결제대기
  • CONFIRMED : 예약확정
  • CANCELED : (유효시간 만료로 인한) 임시예약 취소

1차 설계 고민포인트

• User 테이블 설계 : 초기 유저 테이블 스키마에 대기열토큰, 토큰상태 을 넣는 편일까요?
• 대기열큐를 DB에 나타내야된다면 넣는다면 테이블을 생성해서 넣어야하나요?
• 스케줄러: 시퀀스다이어그램에서는 스케줄러를 정의했는데 ERD 에서도 필요할까요?
• Concert 테이블 설계 - 1안과 2안 중 ERD 피드백을 받고 싶습니다.
  • 개인적으로 ERD를 보완하고 싶고 잘하고 싶어서 설계가 너무 오버엔지니어링하거나 테이블이 많은지 피드백을 받고 싶습니다.
  • Concert 테이블 설계에 두가지 방안이 나왔는데 고민이 되었습니다.

    • 1안: 콘서트(concert) 테이블과 콘서트 시작날짜(dates) 테이블로 분리되는 경우

    • 2안: 콘서트(concert) 테이블안에 시작날짜(start_date)가 컬럼으로 들어있는 경우

    • CGV 영화예매를 참고해봤는데요, 영화선택 > 영화관 선택 > 날짜 선택 > 상영시작시간 선택 > 좌석선택 > 결제 순으로 되어있습니다.

      • 동일한 콘서트 더라도 날짜마다 다르기 때문에 영화테이블, 날짜테이블로 나타냈습니다.

    예를들어 concert_id =1 인 콘서트에서 현재기준으로 예약가능한 날짜 조회를 했을때, concert_id =1 에 해당되는 날짜가 나오므로 dates 테이블을 분리하는 방안 1안을 사용했습니다.

    API 설계했을때 콘서트 예약 가능한 날짜 목록 조회 ([GET] /concerts/{concert_id}/dates)를 concert_id 하나만으로 날짜를 불러올 수 있게끔 하기 위해서 입니다.

    다만 설계방안 2안으로 하게된다면 동일한 콘서트인데도 날짜가 다르기때문에 id만으로 호출하기가 어려운거같다는 생각이 들었습니다.

    방안2를 사용하게되면 좋은점은 관련된 필드를 테이블로 쪼개서 테이블개수가 늘어나는 이슈를 방지할 수 있다고 생각합니다.