요구사항 분석
기능 목록(화살표 클릭)
회원 기능
상품 기능
주문 기능
기타 요구사항
도메인 모델과 테이블 설계
회원, 주문, 상품의 관계: 회원은 여러 상품을 주문할 수 있다. 그리고 한 번 주문할 때 여러 상품을 선택할 수 있으므로 주문과 상품은 다대다 관계다 하지만, 이런 다대다 관계는 관계형 데이터베이스는 물론이고 엔티티에서도 거의 사용하지 않는다. 따라서 그림처럼 주문상품이라는 엔티티를 추가해서 다대다 관계를 일대다, 다대일 관계로 풀어낸다.
상품 분류: 상품은 도서, 음반, 영화로 구분되는데 상품이라는 공통 속성을 사용하므로 상속 구조로 표현했다.
회원 엔티티 분석
1.
회원(Member): 이름과 임베디드 타입의 주소(Address), 그리고 주문(orders)리스트를 가진다.
2.
주문(Order)한 번 주문시 여려 상품을 주문할 수 있으므로 주문과 주문상품(OrderItem)은 일대다 관계이다. 주문은 상품을 주문한 회원과 배송 정보, 주문 날짜, 주문 상태(status)를 가지고 있
주문 상태는 열거형을 사용했는데 주문(ORDER), 취소(CANCEL)을 표현할 수 있다.
3.
주문상품(OrderItem): 주문한 상품 정보와 주문 금액(orderPrice), 주문 수량(count)정보를 가지고 있다.(보통 OrderLine, LineItem 으로 많이 표현한다.)
4.
상품(Item):이름, 가격, 재고수량(stockQuantity)을 가지고 있따. 상품을 주문하면 재고수량이 줄어든다. 상품의 종류로는 도서, 음반, 영화가 있는데 각각은 사용하는 속성이 조금씩 다르다.
5.
배송(Delivery):주문시 하나의 배송 정보를 생성한다. 주문과 배송은 일대일 관계다.
6.
카테고리(Category):상품과 다대다 관계를 맺는다(parent, child)부모, 자식 카테고리를 연결한다.
7.
주소(Address):값 타입(임베디드 타입)이다. 회원과 배송(Delivery)에서 사용한다.
참고: 회원이 주문을 하기 때문에, 회원이 주문리스트를 가지는 것은 얼핏 보면 잘 설계한 것 같지만, 객체 세상은 실제 세계와는 다르다. 실무에서는 회원이 주문을 참조하지 않고, 주문이 회원을 참조하는 것으로 충분하다
여기서는 일대다, 다대일의 양방향 연관관계를 설명하기 위해서 추가했다.
회원 테이블 분석
1.
MEMBER: 회원 엔티티의 Address임베디드 타입 정보가 회원 테이블에 그대로 들어갔다.
이것은 DELIVERY테이블도 마찬가지다.
2.
ITEM: 앨범, 도서, 영화 타입을 통합해서 하나의 테이블로 만들었다. DTYPE컬럼으로 구분한다.
참고: 테이블명이 ORDER가 아니라 ORDERS인 이유는 order by 예약어 때문
연관관계 매핑 분석
1.
회원과 주문: 일대다, 다대일의 양방향 관계이다. 따라서 연관관계의 주인을 정해야 하는데,
외래 키가 있는 주 문을 연관관계의 주인으로 정하는 것이 좋다.
그렇기 때문에 Order.member가 ORDERS.MEMBER_ID외래키와 매핑한다.
2.
주문상품과 주문: 다대일 양방향 관계다. 외래 키가 주문상품에 있으므로 주문상품이 연관관계의 주인.
그러므로 OrderItem.order를 ORDER_ITEM.ORDER_ID 외래 키와 매핑한다.
3.
주문과 배송: 일대일 양방향 관계다. Order.delivery를 ORDERS_DELIVERY_ID 외래 키오 매핑한다.
4.
카테고리와 상품: @ManyToMany를 사용해서 매핑한다.(실무에서는 @ManyToMany 사용 X)
