주문(order)엔티티클래스파일에서

실습

 

order_id

-DB컬럼의 id이름을 테이블명으로 가져와 테이블명_id형태로 설정해준다.

DBA포지션 엔지니어가 이러한 형태로 설정해주는 것을 원한다.

 

참고

엔티티의 식별자는 id를 사용하고 PK 컬럼명은 member_id를 사용했다. 엔티티는 타입(여기서는 Member)이 있으므로 id 필드만으로 쉽게 구분할 수 있다. 테이블은 타입이 없으므로 구분이 어렵다. 그리고 테이블은 관례상 테이블명 + id를 많이 사용한다. 참고로 객체에서 id 대신에 memberId를 사용해도 된다. 중요한 것은 일관성이다.

 

-@ManyToOne : 주문과 회원의 관계, 다대 1관계를 설정해주는 어노테이션

-@JoinColumn(name = "member_id")

*@JoinColumn 어노테이션은 외래 키를 매핑 할 때 사용

*name 속성에는 매핑 할 외래키(연관관계주인) 이름지정

-member_id = foregien key(외래키)

-주문회원테이블에서 주문회원에 대한 정보를 매핑

 

 

 

회원엔티티클래스(RealMember)에서

어노테이션 설정

-@OneToMany : 회원과 주문의 관계, 1대 다 관계를 설정해주는 어노테이션

-@OneToMany (mapped by = "member")

*foreign key가 있는 order클래스에 있는 member가 연관관계의 주인이다.

*mapped by - order 테이블에 있는 member필드에 의해 맵핑된 거울일 뿐이야라는 뜻

*여기에 무엇을 넣는다고 해서 order에 있는 member필드의 foreign key 값이 변경되지

 않는다.

*order엔티티클래스에 있는 order테이블에 있는 member필드 값을 변경하면

 member_idforeign key 값이 변경된다.

 

 

연관관계의 주인설정이 필요한 이유

연관관계 맵핑 분석을 다시 확인해보자

회원과 주문

-회원도 오더로 갈 수 있고, 오더도 회원으로 갈 수 있도록 설계 했다.(양방향 연관관계)

-일대다, 다대일의 양방향 관계다. 따라서 연관관계의 주인을 정해야 한다.

 관계형데이터베이스에서는 1대 다의 관계에서는 다에 무조건 외래키가 있게 된다.

 외래 키가 있는 주문을 연관관계의 주인으로 정하는 것이 좋다.

 

이유

-주문클래스에서 멤버값을 바꾸거나, 멤버클래스에서 오더값을 바꿀 수도 있기 때문에

 JPA는 혼란스러울 수 있다.

-회원엔티티로 본다면 Order도 멤버정보를 가지고 있고, Member도 주문정보를 가지고 있

 다. 데이터베이스에서 MemberOrder테이블에서 볼 때에 foreign keyOrder테이블에

 한 개 밖에 없는 상태이다.

-추후 일어날 수 있는 문제라고 한다면, 회원과 주문테이블 관계를 바꾸고 싶을 때 foreign

 key를 변경해야 하는 상황에 처하게 된다.

-Member테이블에도 orders라는 컬렉션 필드가 있는거고, Order테이블에도 member라는

 필드가 있어 JPA에서는 둘다 정보를 확인해서 값을 바꾸어야 하나라는 혼란에 빠진다.

 즉, 어디에 값이 바뀌었을 때 foreign key를 바꾸어야 하는지에 대한 혼란을 겪게 된다.

-극단적으로 Order엔티티에서는 member 값을 세팅했는데, Member엔티티에서 order 값을

 세팅 안한다던가, Member엔티티에서는 order값을 넣었는데, Order엔티티에서는 member

 값을 안넣었다던가 하는 경우가 생기면, JPA는 둘중에 무엇을 믿고 order테이블의 foreign

 key 값을 업데이트를 해야 하지?라고 혼란을 겪는다.

 

여기서 foreign keyupdate하게 하기 위해서 JPA에서 둘중에 하나를 선택하라고 약속을 했다. 엔티티에서의 객체는 변경 포인트가 두군데이지만, 테이블은 foreign key하나만 변경하면 되기 때문에, 쉽게 맞추기 위해 규칙을 정했다.

둘중에 하나를 주인이라는 개념으로 잡으면 되는데 이것이 연관관계의 주인이다.

Member엔티티에서 ordersOrder엔티티에서나 member중에 값이 바뀌었을 때에 foreign key를 바꿀 거야 라는 것을 결정을 하는 것이 연관관계의 주인이다.

 

그렇다면 연관관계의 주인은 누구로 하는가?

-foreign key가 가까운 테이블(Order)을 확인하고 Member_id를 연관관계주인이 있는 곳으

 로 맵핑을 하면 된다.

-Order엔티티의 member가 가까우니 여기를 연관관계주인으로 정한다.

-이렇게 하지 않으면 member의 무언가를 바꾸었는데, Order테이블에 무언가/foregin키가

 업데이트 되어버려서 있는 의도치 않은 일이 일어난다. 성능이슈가 생길 수도 있다.

 Member정보를 변경했는데, orders의 값이 바뀌지하고 헷갈리게 되어버린다.

-foreign key가 있는 Order테이블에 있는 member를 바꾸니까 order테이블에 있는 컬럼이

 바뀌는구나 하고 이해하기도 관리하기도 쉬워진다. 이렇게 규칙을 정하지 않으면 Member

 보를 변경했는데, orders의 값이 바뀌지하고 헷갈리게 된다.

1.3 회원테이블분석

Member 테이블

Member_ID

NAME

|CITY : VALUE TYPE/임베디드 타입 그대로 필드로 내려온 것이다.

|STREET : VALUE TYPE/임베디드 타입 그대로 필드로 내려온 것이다.

|ZIPCODE : VALUE TYPE/임베디드 타입 그대로 필드로 내려온 것이다.

 

설명

-1:1 맵핑이다.

-이름과 임베디드 타입인 주소(Address), 그리고 주문(orders) 리스트를 가진다.

 

Delivery 테이블

Delivery_ID

STATUS

CITY : VALUE TYPE/임베디드 타입 그대로 필드로 내려온 것이다.

STREET : VALUE TYPE/임베디드 타입 그대로 필드로 내려온 것이다.

ZIPCODE : VALUE TYPE/임베디드 타입 그대로 필드로 내려온 것이다.

 

설명

-회원 엔티티의 Address 임베디드 타입 정보가 회원 테이블에 그대로 들어갔다.

이것은 DELIVERY 테이블도 마찬가지다.

 

ITEM 테이블

ITEM_ID(상품 ID)

-상속관계 맵핑 기본편에서 설명한 3가지 전략중 가장 단순한 싱글테이블 전략을 사용했다.

 싱글테이블전략은 한테이블에 DTYPE으로 구분해서 다 넣는다.

 일반적으로 성능이 잘 나온다.

-단점이라하면 필드에 ARTIST,ETC,AUTHOR,ISBN,DIRECTOR,ACTOR 전부 섞여서 싱글테

 이블에 들어간다.

-앨범, 도서, 화 타입을 통합해서 하나의 테이블로 만들었다. DTYPE 컬럼으로 타입을 구분한

 다.

 

Orders 테이블

ORDER_ID (주문 ID)

MEMBER_ID (Foreign Key, 회원 ID)

DELIVERY_ID (Foreign Key, 배송 ID)

 

참고

-테이블명이 ORDER가 아니라 ORDERS인 것은 데이터베이스가 order by 때문에 예약어로 잡고 있는 경우가 많다.

 그래서 관례상 ORDERS를 많이 사용한다.

 

주문상품테이블

주문상품 ORDER_ITEM

ORDER_ITEM_ID

ORDER_ID (FK)

ITEM_ID (FK)

ORDERPRICE (주문한 상품가격)

COUNT (주문한 상품 개수)

 

카테고리(CATEGORY)

CATEGORY_ID

PARENT_ID (FK)

NAME

CATEGORY_ITEM

CATEGORY_ID (FK)

ITEM_ID (FK)

 

설명

-객체에서는 카테고리가 아이템리스트를 가져도 되고

아이템이 카테고리리스트를 가져도 된다.

양쪽 컬렉션을 만들면 객체는 다대 다로 만들 수 있지만

관계형데이터베이스는 일반적 설계로는 그렇게 할 수 없다.

중간에 매핑 테이블(CATEGORY_ITEM)을 두어,

1(CATEGORY) (CATEGORY_ITEM) 관계 및 다대(CATEGORY_ITEM) 1(ITEM)로 풀어

낸다.

 

참고

*강의에서는 객체를 구분하기 위해 DB에 대문자를 사용했다.

-실제 코드에서는 DB에 소문자 + _(언더스코어) 스타일을 사용하겠다.

-데이터베이스 테이블명, 컬럼명에 대한 관례는 회사마다 다르다.

 보통은 대문자 + _(언더스코어)나 소문자 + _(언더스코어) 방식 중에 하나를 지정해서

 일관성 있게 사용한다. 강의에서 설명할 때는 객체와 차이를 나 타내기 위해 데이터베이스

 테이블, 컬럼명은 대문자를 사용했지만, 실제 코드에서는 소문자 + _(언더스코 어) 스타일을

 사용하겠다.

 

1-2. 회원 엔티티 분석

1.회원(Member)엔티티

 

회원(Member)

id: Long

-회원엔티티에 공통속성은 id가 다 있다.

-id=pk generating 해주는 id값 데이터베이스

 pk(id)long 값으로 해놓았다.

 

name: String

-이름(string)

 

address: Address

-임베디드 타입(내장값타입)인 주소(Address : 설계도 하기 그림참고-value type address)

 

orders : List

-그리고 주문(orders) 리스트를 가진다.

 

2.주문 엔티티

 

주문(Order)

id

member : Member(회원정보)

orderItems : list (주문목록)

delivery : Delivery(배송정보)

orderDate : Date(주문한날짜)

status : OrderStatus(주문상태-주문,취소 등등)

 

-한 번 주문시 여러 상품을 주문할 수 있으므로 주문과 주문상품(OrderItem)은 일대다 관계 다.

-주문은 상품을 주문한 회원과 배송 정보, 주문 날짜, 주문 상태(status)를 가지고 있다.

-주문 상태는 열 거형을 사용했는데 주문(ORDER), 취소(CANCEL)을 표현할 수 있다.

 

3.주문상품 엔티티

 

주문상품(OrderItem)

-주문한 상품 정보와 주문 금액(orderPrice), 주문 수량(count) 정보를 가지고 있다.

 (보통 OrderLine, LineItem 으로 많이 표현한다.)

-주문상품을 추가한 다른 이유는 한번 주문시 여러 개의 상품을 담을 수 있는데

 주문시점시 주문한 상품의 개수 및 주문한 상품 가격정보가 필요하기 때문이다.

 

4.배송 엔티티

 

배송(Delivery)

id

order : order(주문정보, 배송지주소 아님)

address : Address(배송지주소-value type 값타입 주소를 재활용)

status : DeliveryStatus(배송현황)

 

-배송(Delivery): 주문시 하나의 배송 정보를 생성한다. 주문과 배송은 일대일 관계다.

-주문시 하나의 배송 정보를 생성한다. 주문과 배송은 일대일 관계다.

 

5.상품엔티티

 

상품(Item)

id

name (상품이름)

price: int (상품가격)

stockQuantity (상품재고)

categories: List(어느 카테고리에 매핑 되어 있는지에 대한 정보)

 

상품엔티티와의 상속관계

-상속관계Album, Book, Movie들이 있고,

 개별속성들이 상속관계로 다음과 같이 표현되어 있다.

Album - artist, etc

Book - author, isbn

Movie - director, actor

 

-이름, 가격, 재고수량(stockQuantity)을 가지고 있다.

 상품을 주문하면 재고수량이 줄어든다.

 상품의 종류로는 도서, 음반, 화가 있는데 각각은 사용하는 속성이 조금씩 다르다.

 

6. 카테고리엔티티

 

카테고리(Category)

id

name

items: List(카테고리가 가지고 있는 리스트)

parent: Category

(계층구조로 되어 있다. 내 부모가 누구인데, 자식(속성)은 여러개의 구조로 되어 있다라는 형태, 부모는 한개)

child: List

 

-카테고리(Category): 상품과 다대다 관계를 맺는다. parent, child로 부모, 자식 카테고리를

 연결한다.

 

7. 주소엔티티

 

주소(Address)

-값 타입(임베디드 타입)이다. 회원과 배송(Delivery)에서 사용한다.

 

 

설계구성도는 JPA에서 다룰 수 있는 모든관계개념들을 모두 넣어두었다.

1. MemberOrder - 1대 다 관계

2. Orderdelivery - 11 관계

3. OrderOrderItem - 1대 다 관계

4. OrderItemItem - 다대 1 관계

5. ItemAlbum,Book,Movie - 상속관계

6. CategoryItem - 다대 다 관계

 

실무에서 사용하기 애매한 것들

-Categoryitem의 다대 다 관계(JPA@다대다관계)는 실제운영에서 사용하면 안된다.

 1대 다 또는 다대 1 관계로 풀어내야 한다.

-MemberOrder 1대 다 관계가 아닌, 시스템적으로는 동등한 관계로 보고 고민해야 한다.

-회원을 통해서 주문이 일어난다가 아니라, 주문을 생성할 때 Member가 필요하다라고 생각을 해야 한다.

-쿼리가 일어날 때도 주문 내역이 필요할 때 멤버를 찾아서 거기에 있는 주문 리스트를 가져 오는 것이 아니라,

 order에서도 필터링 조건에 멤버가 들어간다.

-그래서 사실상 1대 다의 컬렉션은 필요없다..

 자세한 것은 기본편강의에서 다루었다.

 

참고

회원이 주문을 하기 때문에, 회원이 주문리스트를 가지는 것은 얼핏 보면 잘 설계한 것 같지만,

객체 세상은 실제 세계와는 다르다. 실무에서는 회원이 주문을 참조하지 않고, 주문이 회원을 참조하는 것으로 충분하다. 여기서는 일대다, 다대일의 양방향 연관관계를 설명하기 위해서 추가했다.

+ Recent posts