연관관계 매핑시 고려사항 3가지가 있다.
다대일: @ManyToOne
일대다: @OneToMany
일대일: @OneToOne
다대다: @ManyToMany
테이블) 외래키 하나로 양쪽 조인이 가능하기 때문에 사실 방향이라는 개념이 없다.
객체) 참조용 필드가 있는 쪽으로만 참조 가능하다.
한쪽만 참조하면 단방향, 양쪽이 서로 참조하면 양방향
관계형 DB에서는 외래키가 항상 N측에 있어야 맞는 설계이다.
다대일의 경우, 외래키가 있는 곳에 참조를 걸고, 연관관계 매핑을 하면 된다.
✅ 다대일 단방향
정리
- 가장 많이 사용하는 연관관계
- 다대일의 반대는 일대다
다대일 단방향에서 반대쪽(Team)에도 참조를 추가하면 된다.
중요한 점은 이 반대쪽 참조를 추가한다고 해서 테이블에 영향을 전혀 주지 않는다는 것이다.
정리
- 외래키가 있는 쪽이 연관관계의 주인이다.
- 양쪽을 서로 참조하도록 개발한다.
(권장❌ 모델, 실무에서 거의 사용하지 않는다.) 1측이 연관관계의 주인이다.
✅ 일대다 단방향
Team의 members가 연관관계의 주인이다.
Team의 members를 변경했을 때, 다른 테이블(MEMBER)의 외래키에 UPDATE를 해줘야 한다.
(따라서 TEAM 테이블 말고도 MEMBER 테이블에 추가적으로 UPDATE 쿼리가 날아가게 된다.)
정리
- 일대다 단방향은 일대다(1:N)에서 일(1)이 연관관계의 주인
- 테이블 일대다 관계는 항상 다(N) 쪽에 외래 키가 있음
- 객체와 테이블의 차이 때문에 반대편 테이블의 외래 키를 관리하는 특이한 구조
- @JoinColumn을 꼭 사용해야 함. 그렇지 않으면 조인 테이블 방식을 사용함(중간에 테이블을 하나 추가함)
일대다 단방향 매핑의 단점
엔티티가 관리하는 외래키가 다른 테이블에 있음
연관관계 관리를 위해 추가로 UPDATE SQL 실행
결론: 일대다 단방향 매핑보다는 다대일 양방향 매핑을 사용하자 !
✅ 일대다 양방향
• 이런 매핑은 공식적으로 존재X
• @JoinColumn(insertable=false, updatable=false)
• 읽기 전용 필드를 사용해서 양방향 처럼 사용하는 방법
• 다대일 양방향을 사용하자
일대일 관계는 그 반대도 일대일
주테이블이나 대상테이블 중에 외래키 선택 가능
외래키에 데이터베이스 유니크 제약조건 추가
✅ 일대일: 주테이블에 외래키 단방향
✅ 일대일: 주테이블에 외래키 양방향
✅ 일대일: 대상테이블에 외래키 단방향
✅ 일대일: 대상테이블에 외래키 양방향
주테이블(주로 참조하는 테이블)에 외래키
주객체가 대상 객체의 참조를 가지는 것처럼, 주테이블에 외래키를 두고 대상 테이블을 찾음
객체지향 개발자 선호
JPA 매핑 편리
장점: 주테이블만 조회해도 대상 테이블에 데이터가 있는지 확인 가능
단점: 값이 없으면 외래키에 null 허용
대상테이블에 외래키
대상 테이블에 외래키가 존재
전통적인 데이터베이스 개발자 선호
장점: 주테이블과 대상테이블을 일대일에서 일대다 관계로 변경할 때 테이블 구조 유지
단점: 프록시 기능의 한계로 지연로딩으로 설정해도 항상 즉시 로딩됨(프록시는 뒤에서 설명)
(실무에서 쓰면 안되는 연관관계 매핑이다.)
관계형 데이터베이스는 정규화된 테이블 2개로 다대다 관계를 표현할 수 없음
연결 테이블을 추가해서 일대다, 다대일 관계로 풀어내야 함
객체는 컬렉션을 사용해서 객체 2개로 다대다 관계 가능
📝 다대다
@ManyToMany 사용
@JoinTable로 연결 테이블 지정
다대다 매핑: 단방향, 양방향 가능
😕 다대다 매핑의 한계
편리해 보이지만, 실무에서 사용 ❌
연결 테이블이 단순히 연결만 하고 끝나지 않음
주문시간, 수량 같은 데이터가 들어올 수 있음
💙 다대다 한계 극복
연결 테이블용 엔티티 추가 (연결 테이블을 엔티티로 승격)
@ManyToMany -> @OneToMany, @ManyToOne
배송, 카테고리 추가 - 엔티티
• 주문과 배송은 1:1(@OneToOne)
• 상품과 카테고리는 N:M(@ManyToMany)
배송, 카테고리 추가 - ERD
배송, 카테고리 추가 - 엔티티 상세
N:M 관계는 1:N, N:1로
• 테이블의 N:M 관계는 중간 테이블을 이용해서 1:N, N:1
• 실전에서는 중간 테이블이 단순하지 않다.
• @ManyToMany는 제약: 필드 추가X, 엔티티 테이블 불일치
• 실전에서는 @ManyToMany 사용 X
Delivery.class
package hellojpa;
import javax.persistence.Entity;
import javax.persistence.GeneratedValue;
import javax.persistence.Id;
import javax.persistence.OneToOne;
@Entity
public class Delivery {
@Id @GeneratedValue
private Long id;
@OneToOne(mappedBy = "delivery")
private Order order;
private String city;
private String street;
private String zipcode;
private DeliveryStatus status;
}
Order.class
@OneToOne
@JoinColumn(name = "DELIVERY_ID")
private Delivery delivery;
Categroy.class
package hellojpa;
import javax.persistence.*;
import java.util.ArrayList;
import java.util.List;
@Entity
public class Category {
@Id
@GeneratedValue
private Long id;
private String name;
@ManyToOne
@JoinColumn(name="PARENT_ID")
private Category parent;
@OneToMany(mappedBy = "parent")
private List<Category> child = new ArrayList<>();
@ManyToMany
@JoinTable(name = "CATEGORY_ITEM",
joinColumns = @JoinColumn(name = "CATEGORY_ID"),
inverseJoinColumns = @JoinColumn(name = "ITEM_ID"))
private List<Item> items = new ArrayList<>();
}
Item.class
@ManyToMany(mappedBy = "items")
private List<Category> categories = new ArrayList<>();
@JoinColumn
@ManyToOne - 주요 속성
@OneToMany - 주요 속성