도메인 모델 , 테이블 설계

1. 도메인 모델

---

• 회원과 주문의 관계 : 1 대 N
• 주문과 배송의 관계 : 1 대 1
• 카테고리와 상품의 관계 : N 대 N
• 주문과 상품의 관계 : N 대 N
  - 그러나 다대다 관계는 관계형 DB, entity에서도 사용하지 않음
  - 1 대 N 관계로 풀기 위한 중간에 주문 상품이 존재.
• 상품을 도서 음반 영화 각각 상속 받음.

 

 

2. 엔티티 분석

---

• Member : id(PK), 이름, 입베디드 타입인 Address, Order List를 가진다.
• Order : 한 번 주문 시 여러 상품 주문 가능함. 따라서 Order와  OrderItem을 일대다 관계.
  Order는 Item을 주문한 회원과 배송 정보, 주문 날짜, 주문 상태를 가지고 있다.
  주문 상태는 열거형을 사용 --> 주문(Order), 취소(CANCLE)을 표현.
• OrderItem : 주문한 상품 정보와 주문 금액, 주문 수량 정보를 가지고 있다.
• Item : 이름, 가격, 재고수량을 가지고 있음. 상품을 주문하면 재고수량이 줄어듦.
• Delivery : 주문시 하나의 배송 정보를 생성한다. 주문과 일대일 관계
• Category : 상품과 다대다 관계. Parent, Child로 부모 자식 카테고리를 연결함.
• Address : imbedded 타입이다. 회원과 배송에서 사용함.
• 실제 운영에서 다대다 쓰면 안됨.
• 가급적 단방향 관계 사용.
• 실무에서는 회원이 주문을 참조하지 않고, 주문이 회원을 참조하는 것 만으로도 충분.

 

3. 회원 테이블 분석

---

• MEMBER : 회원 엔티티의 Address 임베디드 타임 정보가 회원 테이블에 반영됨.
• ITEM : 싱글 테이블 전략, DTYPE 컬럼으로 타입을 구분함.
• CATEGORY_ITEM : 객체는 다대다 연관관계 가능. 그러나 관계형 데이터베이스는 불가.
  따라서 MAPPING TABLE 필요함.

 

4. 연관관계 매핑 분석

---

• 회원 & 주문 
  - 일대다, 다대일 양방향 관계
  - 양방향 관계는 연관관계의 주인을 정해햐 한다.
  - 이 때 외래키(FK)를 가지고 있는 주문을 연관관계의 주인으로 정함.
  - 따라서 Order.member(엔티티)를 ORDERS.MEMBER_ID(테이블) 외래키와 매핑한다.
   --> @Joincolumn(name="member_id")
  - Member의 orders는 mappedBy로 연관관계의 거울임. 단순하게 읽기만함. 
  - 연관관계 주인쪽에 값을 세팅해야 값이 변경됨.

  mappedBy()

• 주문상품과 주문
  - 다대일 양방향 관계
  - 연관관계의 주인은 FK가 있는 주문상품.
  - OrderItem.order를 ORDER_ITEM.ORDER_ID 외래키와 매핑함.
• 주문상품과 상품
  - 다대일 단방향 관계
  - Order.Item을 ORDER_ITEM.ITEM_ID외래키와 매핑함.
• 주문과 배송
  - 일대일 양방향 관계이다.
  - Order.delivery를 ORDERS.DELIVERY_ID외래 키와 매핑함.
• 카테고리와 상품
  - @ManyToMany를 사용해서 매핑.
• 외래 키가 있는 곳을 연관관계의 주인으로 정해라.
  연관관계의 주인은 단순히 외래 키를 누가 관리하냐의 문제임.
  비즈니스상 우위에 있다고 주인이 아님.

 

5. 연관관계 주인

• 외래 키가 있는 곳을 연관관계의 주인.
• @JoinColumn : 엔티티와 테이블을 FK로 연결
  - Order.member(엔티티)를 ORDERS.MEMBER_ID(테이블) 외래키와 매핑
  - @Joincolumn(name="member_id")
• @OneToMany(mappedBy = "") : 내가 many측 어떤 column에 매핑됨?