JPA 연관관계 매핑 기초

목표

• 객체와 테이블 연관관계의 차이를 이해
• 객체의 참조와 테이블의 외래 키를 매핑

목차

• 연관관계가 필요한 이유
• 단방향 연관관계
• 양방향 연관관계와 연관관계의 주인

---

연관관계가 필요한 이유

'객체지향 설계의 목표는 자율적인 객체들의 협력 공동체를 만드는 것이다.'   - 조영호(객체지향의 사실과 오해)

 

예제 시나리오

1. 회원과 팀이 있다.
2. 회원은 하나의 팀에만 소속될 수 있다.
3. 회원과 팀은 다대일 관계다.

- 객체를 테이블에 맞추어 모델링(연관관계가 없는 객체)

- 객체를 테이블에 맞추어 모델링(참조 대신에 외래 키를 그대로 사용)

Member.java

Team.java

외래 키 식별자를 직접 다룰 수밖에 없음

객체를 테이블에 맞추어 데이터 중심으로 모델링하면, 협력 관계를 만들 수 없다.

• 테이블은 외래 키로 조인을 사용해서 연관된 테이블을 찾는다.
• 객체는 참조를 사용해서 연관된 객체를 찾는다.
• 테이블과 객체 사이에는 이런 큰 간격이 있다.

- 객체 지향 모델링(객체 연관관계 사용)

Member.java

@ManyToOne - 한팀에 여러 맴버가 있으므로 Member 입장에서 N:1이므로 ManyToOne이다.

@JoinColumn - 이름 그대로 조인하는 칼럼 이름 명시

 

JpaMain.java

전에는 teamId로 연관관계가 매핑되어 있어 teamId로 team 테이블에서 find 해서 가져와야 했다면 객체 연관관계로 매핑하면 getTeam으로 바로 꺼내올 수 있다. 

 

양방향 연관관계와 연관관계의 주인

테이블은 같은 경우는 TEAM_ID(FK) 하나로 Member, Team에서 서로 매핑되는 정보를 알 수 있었다. 하지만 객체에서는 단반향 일 때는 Member에서 Team 객체를 추가해서 알 수 있었지만 Team에서는 알 수 있는 방법이 없다.

 

Team.java

이제는 반대 방향일 때의 사용자의 팀을 가져올 수 있다. 

 

객체와 테이블이 관계를 맺는 차이

객체 연관관계 = 2개

회원 -> 팀 연관관계 1개(단방향)

팀 -> 회원 연관관계 1개(단방향)

 

테이블 연관관계 = 1개

회원 <-> 팀의 연관관계 1개(양방향)

 

연관관계 주인(Owner)

양방향 매핑 규칙

• 객체의 두 관계중 하나를 연관관계의 주인으로 지정
• 연관관계의 주인만이 외래 키를 관리(등록, 수정)
• 주인이 아닌쪽은 읽기만 가능
• 주인은 mappedBy 속성 사용X
• 주인이 아니면 mappedBy 속성으로 주인 지정

누구를 주인으로?

외래 키가 있는 곳을 주인으로 정해라

 

양방향 매핑시 가장 많이 하는 실수.. (연관관계의 주인에 값을 입력하지 않음)

JpaMain.java

H2 DB

TEAM_ID에 NULL값이 들어간다.

원인 : mappedBy는 읽기 전용 변경할 때는 아예 보지를 않는다.

Team.java

JpaMain.java

양방향 매핑시 연관관계 주인에 값을 입력해야 한다. (순수한 객체 관계를 고려하면 항상 양쪽다 값을 입력해야 한다.)

 

양방향 매핑 정리

• 단방향 매핑만으로도 이미 연관관계 매핑은 완료
• 양방향 매핑은 반대 방향으로 조회(객체 그래프 탐색) 기능이 추가된 것 뿐
• JPQL에서 역방향으로 탐색할 일이 많음
• 단방향 매핑을 잘 하고 양방향은 필요할 때 추가해도 됨(테이블에 영향을 주지 않음)

연관관계의 주인을 정하는 기준

• 비즈니스 로직을 기준으로 연관관계의 주인을 선택하면 안됨
• 연관관계의 주인은 외래 키의 위치를 기준으로 정해야함 

 

 

참고 - 인프런 강의(자바 ORM 표준 JPA 프로그래밍 - 기본편, 김영한)