[영화 예매 웹사이트] 클래스 다이어그램

---

• User 클래스와 Profile 클래스: 일대일 / 한 사용자는 하나의 프로필을 가진다.
• User 클래스와 Reservation 클래스: 일대다/ 한 사용자는 여러 개의 예약을 가질 수 있다.
• Reservation 클래스와 Showtime 클래스: 일대다/ 하나의 상영에 여러 개의 예약이 가능하다.
• Reservation 클래스와 Seat 클래스: 일대다/ 하나의 예약은 하나의 좌석을 가질 수 있지만 좌석은 여러개의 예약을 가질 수 있다.
• Reservation 클래스와 Payment 클래스: 일대일 / 한 예약은 하나의 결제 정보만 가진다.
• Payment 클래스와 User 클래스: 의존관계 - 결제 클래스는 사용자 클래스에 의존하여 사용자 정보를 가져온다.
• Movie와 Showtime: 일대다 / 한 영화는 여러 개의 상영 정보를 가질 수 있다.
• Theater와 Showtime: 일대다 / 한 상영관은 여러 개의 상영 정보를 가질 수 있다.
• DiscountPolicy와 Profile: 일대다 / 하나의 할인 정책은 여러 사용자의 프로필에 적용될 수 있다.
• UserService와 User: 의존관계 - 유저서비스 클래스는 사용자 클래스의 기능을 사용하여 로그인, 회원가입등을 처리.
• ReservationService와 Reservation: 연관관계 - 예약 서비스는 예약 클래스와 밀접하게 관련되어 있다.
• PaymentService와 Payment: 연관관계 - 결제 서비스는 결제 정보와 밀접하게 관련되어 있다.

---

클래스 다이어그램을 만들어 보았다. 조금 더 고민해 본 후에 수정하여 다시 업로드할 계획이다.

정리하며 보니 관계가 잘못 표기된 곳도 있고, 다대다 관계도 잘 풀어내야겠다.

https://app.diagrams.net/ 에서 만들었다.

 

---

2024-05-31 클래스 다이어그램 수정

 

1) 프로필의 discountRate: Float 삭제

개인별 할인률 계산 대신, 모든 등급의 고정 할인률 표시.

 

2) 같은 membershipTier로 이름 통일

user의 membershipTier와 profile의 tier는 같은 속성이다.

데이터 일관성을 우선하여 user테이블에서만 해당 속성을 쓸까 고민하였지만, 프로필이 자주 조회될 것으로 예상되어 

현재 구조 유지.

+ tier는 매달 초에 한 번만 변경되므로, 정기적으로 일관성을 확인해 문제를 최소화한다.

 

3) User 테이블의 name을 Profile 테이블로

name같은 경우에는 프로필 조회시에만 쓰이기 때문.

 

2024-6-4 클래스 다이어그램 수정

4) Movie 테이블 간소화

Movie 테이블 같은 경우 원래는 크롤링을 통해 정보를 가져오는 연습을 하고자 하였으나, 이는 다 만들고 나서 여유 있을 때 해보기로 함. 그닥 중요한 정보는 아니기에 간소화.

 

5) Theater -> ScreeningRoom

여러개의 극장이 아닌 하나의 극장에 여러개의 상영관으로 변경. 그에 따른 필드 수정

 

6) 중복된 필드 제거

Showtime과 Seat 그리고 Theater의 같은 기능을 하는 필드 존재. 필요한 Seat에만 적용함.(사용 가능 좌석 status)

---