
엔티티들은 대부분 다른 엔티티와 연관관계가 있다. 예를 들어 주문 엔티티는 어떤 상품을 주문했는지 알기 위해 상품 엔티티와 연관관계가 있고 상품 엔티티는 카테고리, 재고 등 또 다른 엔티티와 관계가 있다.
그런데 객체는 참조를 사용해서 관계를 맺고 테이블은 외래 키를 사용해서 관계를 맺는다 .이둘은 완전히 다른 특징을 가진다.
객체 관계 매핑(ORM)에서 가장 어려운 부분이 바로 객체 연관관계와 테이블 연관관계를 매핑하는 일이다. 시작하기전에 연관관계 매핑을 이해하기 위한 핵심 키워드들을 정리해보았다.
- 방향(Direction) : [단방향, 양방향]이 있다. 예를 들어 회원과 팀이 관계가 있을 때 회원 -> 팀 또는 팀 -> 회원 둘 중 한 쪽만 참조하는 것을 단방향 관계라 하고, 회원 ->팀, 팀->회원 양쪽 모두 서로 참조하는 것을 양방향 관계라 한다. 방향은 객체관계에만 존재하고 테이블 관계는 항상 양방향이다.
- 다중성(Multiplicity) : [다대일(N:1), 일대다(1:N), 일대일(1:1), 다대다(N:M)] 다중성이 있다. 예를 들어 회원과 팀이 관계가 있을 때 여러 회원은 한 팀에 속하므로 회원과 팀은 다대일 관계다. 반대로 한 팀에 여러 회원이 소속될 수 있으므로 팀과 회원은 일대다 관계다.
- 연관관계의 주인 : 객체를 양방향 연관관계로 만들면 연관관계의 주인을 정해야 한다.
단방향 연관관계
연관관계 중에선 다대일(N:1) 단방향 관계를 가장 먼저 이해해야 한다. 지금부터 회원과 팀의 관계를 통해 다대일 단방향 관계를 알아보자.
- 회원과 팀이 있다.
- 회원은 하나의 팀에만 소속될 수 있다.
- 회원과 팀은 다대일 관계다.
해당 그림을 분석해보자.
▼객체 연관관계
- 회원 객체는 Member.team필드(멤버변수)로 팀 객체와 연관관계를 맺는다.
- 회원 객체와 팀 객체는 단방향 관계다. 회원은 Member.team 필드를 통해서 팀을 알 수 있지만 반대로 팀은 회원을 알 수 없다. 예를 들어 member -> team의 조회는 member.getTeam()으로 가능하지만 반대 방향인 team -> member를 접근하는 필드는 없다.
▼ 테이블 연관관계
- 회원 테이블은 TEAM_ID 외래 키로 팀 테이블과 연관관계를 맺는다
- 회원 테이블과 팀 테이블은 양방향 관계다. 회원 테이블의 TEAM_ID 외래 키를 통해서 회원과 팀을 조인할 수 있고 반대로 팀과 회원도 조인할 수 있다. 예를 들어 MEMBER 테이블의 TEAM_ID 외래 키 하나로 MEMBER JOIN TEAM과 TEAM JOIN MEMBER 둘 다 가능하다
▼ 객체 연관관계와 테이블 연관관계의 가장 큰 차이
참조를 통한 연관관계는 언제나 단방향이다. 객체간에 연관관계를 양방향으로 만들고 싶으면 반대쪽에도 필드를 추가해서 참조를 보관해야 한다. 결국 연관관계를 하나 더 만들어야 한다. 이렇게 양쪽에서 서로 참조하는 것을 양방향 연관관계라 한다. 하지만 정확히 이야기하면 이것은 양방향 관계가 아니라 서로 다른 단방향 관계 2개다. 반면에 테이블은 외래 키 하나로 양방향으로 조인할 수 있다.
▼객체 연관관계 vs 테이블 연관관계 정리
- 객체는 참조로 연관관계를 맺는다.
- 테이블은 외래 키로 연관관계를 맺는다.
이 둘은 비슷해 보이지만 매우 다른 특징을 가진다. 연관된 데이터를 조회할 때 객체는 참조를 사용하지만 테이블은 조인을 사용한다.
순수한 객체 연관관계
순수하게 객체만 사용한 연관관계를 살펴보자. 아래는 JPA를 사용하지 않은 순수한 회원과 팀 클래스의 코드다.
public class Membmer {
private String id;
private String username;
private Team team;
public void setTeam(Team team) {
this.team = team;
}
//Getter, Setter ...
}
public class Team {
private String id;
private String name;
//Getter, Setter ...
}
//생성자(id, 이름)
Member member1 = new Member("member1", "회원1");
Member member2 = new Member("member2", "회원2");
Team team1 = new Team("team1", "팀1");
member1.setTeam(team1);
member2.setTeam(team1);
Team findTeam = member1.getTeam();
그림 5.2는 클래스 관계를 나타내고 그림 5.3은 인스턴스 관계를 나타낸다
그림 5.3을 보면 회원1과 회원2는 팀1에 소속했다. 그리고 다음 코드로 회원1이 속한 팀1을 조회할 수 있다.
Team findTeam = member1.getTeam();
이처럼 객체는 참조를 사용해서 연관관계를 탐색할 수 있는데 이것을 객체 그래프 탐색이라 한다.
테이블 연관관계
이번에는 DB 테이블의 회원과 팀의 관계를 살펴보자 아래는 회원 테이블과 팀 테이블의 DDL이다. 추가로 회원 테이블의 TEAM_ID에 외래 키 제약 조건을 설정했다.
CREATE TABLE MEMBER (
MEMBER_ID VARCHAR(255) NOT NULL,
TEAM_ID VARCHAR(255),
USERNAME VARCHAR255,
PRIMARY KEY (MEMBER_ID)
)
CREATE TABLE TEAM(
TEAM_ID VARCHAR(255) NOT NULL,
NAME VARCHAR255,
PRIMARY KEY (TEAM_ID)
)
ALTER TABLE MEMBERADD CONSTRAINT FK_MEMBER_TEAM
FOREIGN KEY (TEAM_ID)
REFERENCES TEAM
객체 관계 매핑
지금까지 객체만 사용한 연관관계와 테이블만 사용한 연관관계를 각각 알아보았다. 이제 JPA를 사용해서 둘을 매핑해보자.
@Entity
@Getter
@Setter
public class Member {
@Id
@Column(name = "MEMBER_ID")
private String id;
private String username;
//연관관계 매핑
@ManyToOne
@JoinColumn(name = "TEAM_ID")
private Team team;
//연관관계 설정
public void setTeam(Team team) {
this.team = team;
}
//Getter, Setter ...
}
@Entity
@Getter
@Setter
public class Team {
@Id
@Column(name = "TEAM_ID")
private String id;
private String name;
//Getter, Setter ...
}
코드를 분석하기 전에 먼저 그림 5.4의 [연관관계 매핑] 부분을 보자.
- 객체 연관관계: 회원 객체의 Member.team 필드 사용
- 테이블 연관관계: 회원 테이블의 MEMBER.TEAM_ID 외래 키 컬럼을 사용
Member.team과 MEMBER.TEAM_ID를 매핑하는 것이 연관관계 매핑이다. 연관관계 매핑 코드를 분석해보자.
@ManyToOne
@JoinColumn(name = "TEAM_ID")
private Team team;
회원 엔티티에 있는 연관관계 매핑 부분인데 연관관계를 매핑하기 위한 새로운 어노테이션들이 있다.
- @ManyToOne: 이름 그대로 다대일(N:1) 관계라는 매핑 정보다. 회원과 팀은 다대일 관계다. 연관관계를 매핑할 때 이렇게 다중성을 나타내는 어노테이션을 필수로 사용해야 한다.
- @JoinColumn(name="TEAM_ID"): 조인 컬럼은 외래 키를 매핑할 때 사용한다. name 속성에는 매핑할 외래 키 이름을 지정한다. 회원과 팀 테이블은 TEAM_ID 외래 키로 연관관계를 맺으므로 이 값을 지정하면 된다. 이 어노테이션은 생략할 수 있다.
연관관계 매핑 어노테이션을 자세히 알아보자.
@JoinColumn
@JoinColumn은 외래 키를 매핑할 때 사용한다. 아래 표에 주요 속성을 정리했다.
※@JoinColumn 생략
@JoinColumn을 생략하면 외래 키를 찾을 때 기본 전략을 사용한다.
- 기본전략: 필드명 + _ + 참조하는 테이블의 컬럼명 -> team_TEAM_ID 외래 키를 사용한다.
@ManyToOne
@ManyToOne 어노테이션은 다대일 관계에서 사용한다 아래 표에 주요 속성을 정리했다.
다음 코드는 targetEntity 속성의 사용 에시이다.
@OneToMany
private List<Member> members; //제네릭으로 타입 정보를 알 수 있다.
@OneToMany(targetEntity=Member.class)
private List members; //제네릭이 없으면 타입 정보를 알 수 없다.
연관관계 사용
연관관계를 등록, 수정, 삭제, 조회하는 예제를 통해 연관관계를 어떻게 사용하는지 알아보자.
저장
public static void testSave(EntityManager em) {
//팀1 저장
Team team1 = new Team("team1", "팀1");
em.persist(team1);
//회원1 저장
Member member1 = new Member("member1", "회원1");
member1.setTeam(team1); //연관관계 설정 member1 -> team1
em.persist(member1);
//회원2 저장
Member member2 = new Member("member2", "회원2");
member2.setTeam(team1); //연관관계 설정 member2 -> team1
em.persist(member2);
}
※주의 : JPA에서 엔티티를 저장할 때 연관된 모든 엔티티는 영속 상태여야 한다.
회원 엔티티는 팀 엔티티를 참조하고 저장했다. JPA는 참조한 팀의 식별자(Team.id)를 외래 키로 사용해서 적절한 등록 쿼리를 생성한다.
결과는 다음과 같다.
조회
연관관계가 있는 엔티티를 조회하는 방법은 크게 2가지다.
- 객체 그래프 탐색(객체 연관관계를 사용한 조회)
- 객체지향 쿼리 사용(JPQL)
방금 저장한 대로 회원1, 회원2가 팀1에 소속해 있 다고 가정하자.
▼객체 그래프 탐색
member.getTeam()을 사용해서 member와 연관된 team 엔티티를 조회할 수 있다.
Member member = em.find(Member.class, "member1");
Team team = member.getTeam(); //객체 그래프 탐색
//team.getName:팀1
이처럼 객체를 통해 연관된 엔티티를 조회하는 것을 객체 그래프 탐색이라 한다.
▼객체지향 쿼리 사용
객체지향 쿼리인 JPQL에서 연관관계를 어떻게 사용하는지 알아보자.
예를 들어 회원을 대상으로 조회하는데 팀1에 소속된 회원만 조회하려면 회원과 연관된 팀 엔티티를 검색 조건으로 사용해야 한다. SQL은 연관된 테이블을 조인해서 검색조건을 사용하면 된다. JPQL도 조인을 지원한다(문법은 약간 다르다.)
팀1에 소속된 모든 회원을 조회하는 예제를 보자
private static void queryLogicJoin(EntityManager em) {
String jpql = "select m from Member m join m.team t where t.name=:teamName";
List<Member> resultList = em.createQuery(jpql, Member.class)
.setParameter("teamName", "팀1")
.getResultList();
for (Member member : resultList) {
log.info("[query] member.username = " + member.getUsername());
}
}
JPQL의 from Member m join m.team t 부분을 보면 회원이 팀과 관계를 가지고 있는 필드(m.team)를 통해서 Member와 Team을 조인했다. 그리고 where 절을 보면 조인한 t.name을 검색조건으로 사용해서 팀1에 속한 회원만 검색했다.
다음 실행 JPQL을 보자. 참고로 :teamName과 같이 :로 시작하는 것은 파라미터를 바인딩받는 문법이다.
실행된 SQL과 JPQL을 비교하면 JPQL은 객체(엔티티)를 대상으로 하고 SQL보다 간결하다.
수정
팀1 소속이던 회원을 새로운 팀2에 소속하도록 수정해보자.
private static void updateRelation(EntityManager em){
//새로운 팀2
Team team2 = new Team("team2", "팀2");
em.persist(team2);
//회원1에 새로운 팀2 설정
Member member = em.find(Member.class, "member1");
member.setTeam(team2);
}
앞서 말했듯이 수정은 em.update() 같은 메소드가 없다. 단순히 불러온 엔티티의 값만 변경해두면 트랜잭션을 커밋할 때 플러시가 일어나면서 변경 감지 기능이 작동한다. 그리고 변경ㅎ사항을 DB에 자동으로 반영한다.
이것은 연관관계를 수정할 때도 같은데 ,참조하는 대상만 변경하면 나머지는 JPA가 자동으로 처리한다.
연관관계 제거
이번에는 연관관계를 제거해보자. 회원1을 팀에 소속하지 않도록 변경하자.
private static void deleteRelation(EntityManager em) {
Member member1 = em.find(Member.class, "member1");
member1.setTeam(null);
}
연관된 엔티티 삭제
연관된 엔티티를 삭제하려면 기존에 있던 연관관계를 먼저 제거하고 삭제해야 한다. 그렇지 않으면 외래 키 제약 조건으로 인해, DB에서 오류가 발생한다.
member1.setTeam(null);//회원1 연관관계 제거
member2.setTeam(null);//회원 2연관관계 제거
em.remove(team); //팀 삭제
양방향 연관관계
지금까지 회원에서 팀으로만 접근하는 다대일 단방향 매핑을 알아보았다. 이번에는 반대 방향인 팀에서 회원으로 접근하는 관계를 추가하자. 그래서 회원에서 팀으로 접근하다 반대 방향인 팀에서도 회원으로 접근할 수 있도록 양방향 연관관계로 매핑해보자.
먼저 객체 연관관계를 살펴보자. 그림5.5와 같이 회원과 팀은 다대일 관계다. 반대로 팀에서 회원은 일대다 관계다. 일대다 관계는 여러 건과 연관관계를 맺을 수 있으므로 컬렉션을 사용해야 한다. Team.members를 List 컬렉션으로 추가했다.
객체 연관관계를 정리하면 다음과같다.
- 회원 -> 팀(Member.team)
- 팀 -> 회원(Team.members)
테이블의 관계는 어떻게 될까? DB 테이블은 외래 키 하나로 양방향으로 조회할 수 있다. 두 테이블의 연관관계는 외래 키 하나만으로 양방향 조회가 가능하므로 처음부터 양방향 관계다. 따라서 DB에 추가할 내용은 전혀 없다.
회원 엔티티에는 연관관계가 설정되어있으므로 변경할 부분이 없다 팀 엔티티를 보자.
@Entity//일대다 양방향 Team
@Getter
@Setter
public class Team {
@Id
@Column(name = "TEAM_ID")
private String id;
private String name;
@OneToMany(mappedBy = "team")
private List<Member> members = new ArrayList<Member>();
//Getter, Setter ...
public Team(String id, String name) {
this.id = id;
this.name = name;
}
public Team() {
}
}
팀과 회원은 일대다 관계다. 따라서 팀 엔티티에 컬렉션인 List<Member> members를 추가했다. 그리고 일대다 관계를 매핑하기 위해 @OneToMany 매핑 정보를 사용했다.
mappedby 속성은 양방향 매핑일 때 사용하는데 반대쪽 매핑의 필드 이름을 값으로 주면 된다. 반대쪽 매핑이 Member.team 이므로 team을 값으로 주었다. mappedBy에 대한 내용은 연관관계의 주인에 연관이 있으므로 다음에 설명하겠다.
양방향 매핑을 완료했으니 이제부터 팀에서 회원 컬렉션으로 객체 그래프를 탐색할 수 있다. 이것을 사용해서 팀1에 소속된 모든 회원을 찾아보자.
일대다 컬렉션 조회
예제 5.12는 팀에서 회원 컬렉션으로 객체 그래프 탐색을 사용해서 조회한 회원들을 출력한다.
private static void biDirection(EntityManager em) {
Team team = em.find(Team.class, "team1");
List<Member> members = team.getMembers(); //(팀 -> 회원)
//객체 그래프 탐색
for (Member member : members) {
log.info("member.username = " + member.getUsername());
}
}
//결과
//member.username = 회원1
//member.username = 회원2
연관관계의 주인
@OneToMany는 직관적으로 이해가 될 것이다. 문제는 mappedby 속성이다. 단순히 @OneToMany만 있으면 되지 mappedBy는 왜 필요할까?
엄밀히 이야기하면 객체에는 양방향 연관관계라는 것이 없다. 서로 다른 단방향 연관관계 2개를 애플리케이션 로직으로 잘 묶어서 양방향인 것처럼 보이게 할 뿐이다. 반면에 DB 테이블은 앞서 설명했듯이 외래 키 하나로 양쪽이 서로 조인할 수 있다. 따라서 테이블은 외래 키 하나만으로 양방향 연관관계를 맺는다.
객체 연관관계는 다음과 같다.
- 회원 -> 팀 연관관계 1개(단방향)
- 팀 -> 회원 연관관계 1개(단방향)
테이블 연관관계는 다음과 같다.
- 회원 <-> 팀의 연관관계 1개(양방향)
다시 강조하지만 테이블은 외래 키 하나로 두 테이블의 연관관계를 관리한다. 엔티티를 단방향으로 매핑하면 참조를 하나만 사용하므로 이 참조로 외래 키를 관리하면 된다. 그런데 엔티티를 양방향으로 매핑하면 회원->팀, 팀->회원 두 곳에서 서로를 참조한다. 따라서 객체의 연관관계를 관리하는 포인트는 2곳으로 늘어난다.
엔티티를 양방향 연관관계로 설정하면 객체의 참조는 둘인데 외래 키는 하나다. 따라서 둘 사이에 차이가 발생한다. 그렇다면 둘 중 어떤 관계를 사용해서 외래 키를 관리해야 할까?
이런 차이로 인해 JPA에서는 두 객체 연관관계 중 하나를 정해서 테이블의 외래키를 관리해야 하는데 이것을 연관관계의 주인이라 한다
양방향 매핑의 규칙: 연관관계의 주인
양방향 연관관계 매핑 시 지켜야 할 규칙이 있는데 두 연관관계 중 하나를 연관관계의 주인으로 정해야 한다. 연관관계의 주인만이 DB 연관관계와 매핑되고 외래 키를 관리(등록, 수정, 삭제)할 수 있다. 반면에 주인이 아닌 쪽은 읽기만 할 수 있다.
어떤 연관관계를 주인으로 정할지는 mappedBy 속성을 사용하면 된다.
- 주인은 mappedBy 속성을 사용하지 않는다.
- 주인이 아니면 mappedBy 속성을 사용해서 속성의 값으로 연관관계의 주인을 지정해야 한다.
그렇다면 Member.team, Team.members 둘중 어떤 것을 연관관계의 주인으로 정해야 할까?
다음 두 코드를 보자.
- 회원 -> 팀 방향
class Member {
@ManyToOne
@JoinColumn(name = "TEAM_ID")
private Team team;
}
- 팀->회원 방향
class team{
@OneToMany(mappedBy = "team")
private List<Member> members = new ArrayList<Member>();
}
연관관계의 주인을 정한다는 것은 사실 외래 키 관리자를 선택하는 것이다. 여기서는 회원 테이블에 있는 TEAM_ID 외래 키를 관리할 관리자를 선택해야 한다.
그림 5.7을 보자. 만약 회원 엔티티에 있는 Member.team을 주인으로 선택하면 자기 테이블에 있는 외래 키를 관리하면 된다. 하지만 팀엔티티에 있는 Team.members를 주인으로 선택하면 물리적으로 전혀 다른 테이블의 외래 키를 관리해야 한다. 왜냐하면 이 경우 Team.members가 있는 Team 엔티티는 TEAM 테이블에 매핑되어 있는데 관리해야할 외래 키는 MEMBER 테이블에 있기 때문이다.
연관관계의 주인은 외래 키가 있는 곳
연관관계의 주인은 테이블에 외래 키가 있는 곳으로 정해야 한다. 여기서는 회원 테이블이 외래 키를 가지고 있으므로 Member.team이 주인이 된다. 주인이 아닌 Team.members에는 mappedBy="team" 속성을 사용해서 주인이 아님을 설정한다. 그리고 mappedBy 속성의 값으로는 연관관계의 주인인 team을 주면 된다. 여기서 mappedBy의 값으로 사용된 team은 연관관계의 주인인 Member 엔티티의 team 필드를 말한다.
정리하자면 연관관계의 주인만 DB 연관관계와 매핑되고 외래 키를 관리할 수 있다. 주인이 아닌 반대편은 읽기만 가능하고 외래 키를 변경하지는 못한다.
※DB 테이블의 다대일, 일대다 관계에서는 항상 다 쪽이 외래 키를 가진다. 다 쪽인 @ManyToOne은 항상 연관관계의 주인이 되므로 mappedBy를 설정할 수 없다. 따라서 @ManyToOne에는 mappedBy 속성이 없다.
양방향 연관관계 저장
양방향 연관관계를 사용해서 팀1, 회원1, 회원2를 저장해보자.
@Test
void testSave(){
EntityManager em = emf.createEntityManager(); //엔티티 매니저 생성
EntityTransaction tx = em.getTransaction(); //트랜잭션 기능 획득
try {
tx.begin(); //트랜잭션 시작
//팀1 저장
Team team1 = new Team("team1", "팀1");
em.persist(team1);
//회원1 저장
Member member1 = new Member("member1", "회원1");
member1.setTeam(team1); //연관관계 설정 member1 -> team1
em.persist(member1);
//회원2 저장
Member member2 = new Member("member2", "회원2");
member1.setTeam(team1); //연관관계 설정 member2 -> team1
em.persist(member2);
tx.commit();
// 테스트 부분
em.clear(); // 영속성 컨텍스트 초기화
Member retrievedMember1 = em.find(Member.class, member1.getId());
assertEquals("회원1", retrievedMember1.getUsername());
assertEquals("팀1", retrievedMember1.getTeam().getName());
} catch (Exception e) {
e.printStackTrace();
tx.rollback(); //트랜잭션 롤백
} finally {
em.close(); //엔티티 매니저 종료
}
emf.close(); //엔티티 매니저 팩토리 종료
}
양방향 연관관계는 연관관계의 주인이 외래 키를 관리한다. 따라서 주인이 아닌 방향은 값을 설정하지 않아도 DB에 외래 키 값이 정상 입력된다.
team1.getMembers().add(member1); //무시(연관관계의 주인이 아님)
이런 코드가 추가로 있어야 할 것 같지만 Team.members는 연관관계의 주인이 아니다. 주인이 아닌 곳에 입력된 값은 외래 키에 영향을 주지 않는다. 따라서 이 코드는 DB에 저장할 때 무시된다.
member1.setTeam(team1); //연관관계 설정(연관관계의 주인)
Member.team은 연관관계의 주인이다. 엔티티 매니저는 이곳에 입력된 값을 사용해서 외래 키를 관리한다.
양방향 연관관계의 주의점
양방향 연관관계를 설정하고 가장 흔히 하는 실수는 연관관계의 주인에는 값을 입력하지 않고, 주인이 아닌 곳에만 값을 입력하는 것이다. DB에 외래키 값이 정상적으로 저장되지 않으 이것부터 의심해보자.
주인이 아닌 곳에만 값을 설정하면 어떻게 되는지 예제로 알아보자.
@Test
void testSave(){
EntityManager em = emf.createEntityManager(); //엔티티 매니저 생성
EntityTransaction tx = em.getTransaction(); //트랜잭션 기능 획득
try {
tx.begin(); //트랜잭션 시작
//팀1 저장
Team team1 = new Team("team1", "팀1");
em.persist(team1);
//회원1 저장
Member member1 = new Member("member1", "회원1");
em.persist(member1);
//회원2 저장
Member member2 = new Member("member2", "회원2");
em.persist(member2);
f
//주인이 아닌곳에만 연관관계 설정
team1.getMembers().add(member1);
team1.getMembers().add(member2);
tx.commit();
// 테스트 부분
em.clear(); // 영속성 컨텍스트 초기화
Member retrievedMember1 = em.find(Member.class, member1.getId());
assertEquals("회원1", retrievedMember1.getUsername());
assertEquals("팀1", retrievedMember1.getTeam().getName());
} catch (Exception e) {
e.printStackTrace();
tx.rollback(); //트랜잭션 롤백
} finally {
em.close(); //엔티티 매니저 종료
}
emf.close(); //엔티티 매니저 팩토리 종료
}
DB에서 회원 테이블을 조회해보자. 회원을 조회한 결과는 다음과 같다.
외래 키 TEAM_ID에 team1이 아닌 null 값이 입력되어 있는데, 연관관계의 주인이 아닌 Team.members에만 값을 저장했기 때문이다. 다시 한 번 강조하지만 연관관계의 주인만이 외래 키의 값을 변경할 수 있다.
순수한 객체까지 고려한 양방향 연관관계
그렇다면 정말 연관관계의 주인에만 값을 저장하고 주인이 아닌 곳에는 값을 저장하지 않아도 될까? 사실은 객체 관점에서 양쪽 방향에 모두 값을 입력해주는 것이 가장 안전하다. 양쪽 방향 모두 값을 입력하지 않으면 JPA를 사용하지 않는 순수한 객체 상태에서 심각한 문제가 발생할 수 있다.
예를 들어 JPA를 사용하지 않고 엔티티에 대한 테스트 코드를 작성한다고 가정해보자. ORM은 객체와 관계형 DB 둘 다 중요하다. DB뿐만 아니라 객체도 함께 고려해야 한다.
@Test
void test순수한객체_양방향(){
Team team1 = new Team("team1", "팀1");
Member member1 = new Member("member1", "회원1");
Member member2 = new Member("member2", "회원2");
member1.setTeam(team1); //연관관계 설정 member1 -> team1
member2.setTeam(team1); //연관관계 설정 member2 -> team1
List<Member> members = team1.getMembers();
log.info("members.size = " + members.size());//결과 : members.size = 0
}
예제 코드는 JPA를 사용하지 않는 순수한 객체다. 코드를 보면 Member.team에만 연관관계를 설정하고 반대 방향은 연관관계를 설정하지 않았다. 마지막 줄에서 팀에 소속된 회원이 몇 명인지 출력해보면 결과는 0이 나온다. 이것은 우리가 기대하는 양방향 연관관계의 결과가 아니다.
양쪽 모두 관계를 설정한 코드를 보자
@Test
void test순수한객체_양방향2(){
Team team1 = new Team("team1", "팀1");
Member member1 = new Member("member1", "회원1");
Member member2 = new Member("member2", "회원2");
member1.setTeam(team1); //연관관계 설정 member1 -> team1
member2.setTeam(team1); //연관관계 설정 member2 -> team1
team1.getMembers().add(member1); //연관관계 설정 team1 -> member1
team1.getMembers().add(member2); //연관관계 설정 team1 -> member2
List<Member> members = team1.getMembers();
log.info("members.size = " + members.size());//결과 : members.size = 2
}
양 쪽 모두 관계를 설정했다 결과도 기대했던 2가 출력된다. 객체까지 고려하면 이렇게 양쪽 다 관계를 맺어야 한다. 이제 JPA를 사용해서 완성한 예제를 보자.
@Test
void testORM_양방향(){
Team team1 = new Team("team1", "팀1");
em.persist(team1);
Member member1 = new Member("member1", "회원1");
em.persist(member1);
Member member2 = new Member("member2", "회원2");
em.persist(member2);
member1.setTeam(team1); //연관관계 설정 member1 -> team1
member2.setTeam(team1); //연관관계 설정 member2 -> team1
team1.getMembers().add(member1); //연관관계 설정 team1 -> member1
team1.getMembers().add(member2); //연관관계 설정 team1 -> member2
List<Member> members = team1.getMembers();
log.info("members.size = " + members.size());//결과 : members.size = 2
Member retrievedMember1 = em.find(Member.class, member1.getId());
assertEquals("회원1", retrievedMember1.getUsername());
assertEquals("팀1", retrievedMember1.getTeam().getName());
}
양쪽에 연관관계를 설정했다. 따라서 순수한 객체 상태에서도 동작하며, 테이블의 외래 키도 정상 입력된다. 물론 외래 키의 값을 연관관계의 주인인 Member.team 값을 사용한다.
- Member.team: 연관관계의 주인, 이 값으로 외래 키를 관리한다.
- Team.members: 연관관계의 주인이 아니다. 따라서 저장 시에 사용되지 않는다.
앞서 이야기한 것처럼 객체까지 고려해서 주인이 아닌 곳에도 값을 입력하자.
결론: 객체의 양방향 연관관계는 양쪽 모두 관계를 맺어주자.
연관관계 편의 메소드
양방향 연관관계는 결국 양쪽 다 신경 써야 한다. 다음처럼 member.setTeam(team)과 team.getMembers().add(member)를 각각 호출하다보면 실수로 둘 중 하나만 호출해서 양방향이 깨질 수 있다.
양방향 관계에서 두 코드는 하나인 것처럼 사용하는 것이 안전하다. Member 클래스의 setTeam() 메소드를 수정해서 코드를 리팩토링 해보자.
public void setTeam(Team team) {
this.team = team;
team.getMembers().add(this);
}
setTeam() 메소드 하나로 양방향 관계를 모두 설정하도록 변경했다. 연관관계를 설정하는 부분을 수정하자.
void teamORM_양방향_리팩토링(){
Team team1 = new Team("team1", "팀1");
em.persist(team1);
Member member1 = new Member("member1", "회원1");
Member member2 = new Member("member2", "회원2");
member1.setTeam(team1); //연관관계 설정 member1 -> team1
member2.setTeam(team1); //연관관계 설정 member2 -> team1
em.persist(member1);
em.persist(member2);
Member retrievedMember1 = em.find(Member.class, member1.getId());
assertEquals("회원1", retrievedMember1.getUsername());
assertEquals("팀1", retrievedMember1.getTeam().getName());
}
이렇게 한 번에 양방향 관계를 설정하는 메소드를 연관관계 편의 메소드라고 한다.
연관관계 편의 메소드 작성 시 주의사항
사실 setTeam() 메소드에는 버그가 있다.
member1.setTeam(teamA);
member1.setTeam(teamB);
Member findmember = teamA.getMember(); //member1이 여전히 조회된다.
먼저 member1.setTeam(teamA)를 호출한 직후 객체 연관관계인 그림을 보자.
다음으로 member1.setTeam(teamB)을 호출한 직후 객체 연관관계인 그림을 보자.
무엇이 문제인지 보이는가? teamB로 변경할 때 teamA ->member1 관계를 제거하지 않았다. 연관관계를 변경할 때는 기존 팀이 있으면 기존 팀과 회원의 연관관계를 삭제하는 코드를 추가해야 하낟. 따라서 다음 코드처럼 기존 관계를 제거하도록 수정해야 한다.
public void setTeam(Team team) {
//기존 팀과 관계를 제거
if (this.team != null) {
this.team.getMembers().remove(this);
}
this.team = team;
team.getMembers().add(this);
}
이 코드는 객체에서 서로 다른 단방향 연관관계 2개를 양방향인 것처럼 보이게 하려고 얼마나 많은 고민과 수고가 필요한지 보여준다. 반면에 관계형 DB는 외래 키 하나로 문제를 단순하게 해결한다. 정리하자면 객체에서 양방향 연관관계를 사용하려면 로직을 견고하게 작성해야 한다.
정리
단방향 매핑과 비교해서 양방향 매핑은 복잡하다. 연관관계의 주인도 정해야 하고, 두 개의 단방향 연관관계를 양방향으로 만들기 위해 로직도 잘 관리해야 한다. 중요한 사실은 연관관계가 하나인 단방향 매핑은 언제나 연관관계의 주인이라는 점이다. 양방향은 여기에 주인이 아닌 연관관계를 하나 추가했을 뿐이다. 결국 단방향과 비교해서 양방향의 장점은 반대방향으로 객체 그래프 탐색 기능이 추가된 것 뿐이다. 내용을 정리하면 다음과 같다.
- 단방향 매핑만으로 테이블과 객체의 연관관계 매핑은 이미 완료되었다.
- 단방향을 양방향으로 만들면 반대방향으로 객체 그래프 탐색 기능이 추가된다.
- 양방향 연관관계를 매핑하려면 객체에서 양쪽 방향을 모두 관리해야 한다.
비즈니스 로직의 필요에 따라 다르겠지만 우선 단방향 매핑을 사용하고 반대 방향으로 객체 그래프 탐색 기능(JPQL 쿼리 탐색 포함)이 필요할 때 양방향을 사용하도록 코드를 추가해도 된다.
출처
김영한, "자바 ORM 표준 JPA 프로그래밍(2015)", 에이콘출판사
'Database' 카테고리의 다른 글
JPA 고급 - Fetch 전략 Eager, Lazy (0) | 2024.08.01 |
---|---|
JPA - 프록시 개념과 활용 방법 (0) | 2024.07.28 |
엔티티 매핑 (1) | 2024.01.24 |
영속성 관리 (1) | 2024.01.21 |
JPA를 활용한 애플리케이션 개발해보기 (1) | 2024.01.21 |

포스팅이 좋았다면 "좋아요❤️" 또는 "구독👍🏻" 해주세요!