자바 ORM 표준 JPA 기본편 - 연관관계 매핑 기초

[김영한님의 자바 ORM 표준 JPA 프로그래밍 - 기본편을 학습 후 정리한 글입니다.]

목표

1. 객체와 테이블 연관관계의 차이를 이해
2. 객체의 참조와 테이블의 외래 키를 매핑
3. 용어 이해
   • 방향(Direction) : 단방향, 양방향
   • 다중성(Multiplicity) : 다대일(N:1), 일대다(1:N), 일대일(1:1), 다대다(N:M) 이해
   • 연관관계의 주인(Owner) : 객체 양방향 연관관계는 관리 주인이 필요

 

연관관계가 필요한 이유

'객체지향 설계의 목표는 자율적인 객체들의
협력 공동체를 만드는 것이다.'

by 객체지향의 사실과 오해

예제 시나리오

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

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

아래는 회원과 팀을 나타내는 클래스입니다.

 @Entity
 public class Member { 
 @Id @GeneratedValue
 private Long id;
 @Column(name = "USERNAME")
 private String name;
 @Column(name = "TEAM_ID")
 private Long teamId; 
 … 
 } 
 @Entity
 public class Team {
 @Id @GeneratedValue
 private Long id;
 private String name; 
 … 
 }

 

아래는 팀과 회원을 저장하는 코드입니다.

//팀 저장
 Team team = new Team();
 team.setName("TeamA");
 em.persist(team);
 //회원 저장
 Member member = new Member();
 member.setName("member1");
 member.setTeamId(team.getId());
 em.persist(member);

 

위와 같은 상황에서 회원의 팀을 찾으려면 아래와 같이 코드를 짤 수밖에 없습니다.

 //조회
 Member findMember = em.find(Member.class, member.getId()); 
 //연관관계가 없음
 Long findTeamId = findMember.getId();
 Team findTeam = em.find(Team.class, team.getId());

 

연관관계가 없으므로, member의 team을 가져오려면

member를 가져오고, id를 가져오고, 다시 팀을 가져와야 하는...

이렇게 되면 회원의 팀 하나를 가져오기 위해 많은 비용이 발생하게 됩니다.

즉 객체 지향스럽지 않은 코드가 되는 상황.

 

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

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

단방향 연관관계

 

• Member가 이전과 달리 Team의 id값이 아닌, Team의 참조값을 가져온다.
• 객체 지향 모델링(ORM 매핑)

 //팀 저장
 Team team = new Team();
 team.setName("TeamA");
 em.persist(team);
 
 //회원 저장
 Member member = new Member();
 member.setName("member1");
 member.setTeam(team); //단방향 연관관계 설정, 참조 저장
 em.persist(member);
 
 //조회
 Member findMember = em.find(Member.class, member.getId()); 
 //참조를 사용해서 연관관계 조회
 Team findTeam = findMember.getTeam();

 

단방향 연관관계를 맺고 member에서 member.getTeam()을 통해 Team을 바로 조회할 수 있게 되었다.

 

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

기존의 단방향 연관관계에서는 Memeber의 getTeam()을 통해 Team에 접근할 수 있었지만, Team을 통한 Member에 접근할 수 있는 방법은 없다.

 

하지만 FK를 갖고 있다면 양쪽 모두에서 서로에게 접근이 가능하다.

(Member에서는 team의 객체, Team쪽에서는 members인 List 참조값)

//멤버 클래스
@Entity
 public class Member { 
 @Id @GeneratedValue
 private Long id;
 @Column(name = "USERNAME")
 private String name;
 private int age;
 @ManyToOne
 @JoinColumn(name = "TEAM_ID")
 private Team team;
 …
 
 //팀 클래스
 @Entity
 public class Team {
 @Id @GeneratedValue
 private Long id;
 private String name;
 @OneToMany(mappedBy = "team")
 List<Member> members = new ArrayList<Member>();
 … 
 }

 //조회
 Team findTeam = em.find(Team.class, team.getId()); 
 int memberSize = findTeam.getMembers().size(); //역방향 조회

 

연관관계의 주인과 mappedBy

• JPA에서 연관관계에 대해 제일 어려운 개념.
• mappedBy는 처음에는 이해하기 어렵다.
• 객체와 테이블간에 연관관계를 맺는 차이를 이해해야 한다.

객체의 양방향 관계

• 객체의 양방향 관계는 사실 양방향 관계가 아니라 서로 다른 단뱡향 관계 2개다.
• 객체를 양방향으로 참조하려면 단방향 연관관계를 2개 만들어야 한다.

A > B (a.getB())

B > A (b.getA())

테이블의 양방향 연관관계

• 테이블은 외래 키 하나로 두 테이블의 연관과계를 관리한다.
• MEMBER.TEAM_ID 외래 키 하나로 양방향 완관관계를 가질 수 있음.(양쪽으로 조인 가능)

SELECT * 
FROM MEMBER M
JOIN TEAM T ON M.TEAM_ID = T.TEAM_ID

SELECT * 
FROM TEAM T
JOIN MEMBER M ON T.TEAM_ID = M.TEAM_ID

 

위 그래프에는 참조값이 2개(team, members)가 있다.

MEMBER 테이블의 FK(TEAM_ID)는 member의 team을 업데이트 했을 때 수정이 되어야할까?

Team 테이블의 members를 업데이트 했을 때 수정이 되어야할까?

 

결론은 둘 중 하나로 외래 키를 관리해야 한다.

 

연관관계의 주인(Owner)

양방향 매핑 규칙

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

그래서 누구를 주인으로?

• 외래 키가 있는 곳을 주인으로 정한다.

예제에서는 Member.team이 연관관계의 주인이다.

 

양방향 매핑시 가장 많이 하는 실수

> 연관관계 주인에 값을 입력하지 않음

 Team team = new Team();
 team.setName("TeamA");
 em.persist(team);
 Member member = new Member();
 member.setName("member1");
 //역방향(주인이 아닌 방향)만 연관관계 설정
 team.getMembers().add(member);
 em.persist(member);

 

<실행 결과>

 

 

team.getMembers().add(member);을 넣지 않는다면 어떤 문제가 생길까?

> DB에 반영하는 부분에는 문제가 없을 것이다. 하지만, 영속성 컨텍스트의 1차 캐시에 저장된 team의 members에는 해당 Member가 초가되지 않은 상태가 된다. 이런 상황에서 team.members를 사용하게 되면 DB에서 조회하는 게 아닌 1차 캐시에서 꺼내 사용하기 때문에 해당 member가 추가되지 않는 결과가 나오게 되는 문제가 생기게 된다.

 

결론 : 양방향 매핑시 연관관계의 주인에 값을 입력해야 한다.

순수한 객체 관계를 고려하면 양쪽 모두 값을 입력하는 것이 좋다.

 

양방향 연관관계 주의

1. 연관관계 편의 메소드를 생성

public void changeTeam(Team team) {
     this.team = team;
     team.getMembers().add(this);
 }

• Team을 설정하는 시점에서 team에 Member도 같이 추가된다.
• 연관관계 편의 메소드같은 옵셔널 메소드는 관례적으로 쓰이는 Getter, Setter가 아닌 사용자 정의 메소드로 정의해주는 게 좋다.

2. 양방향 매핑시에 무한 루프를 조심하자

예) toString(), lombok, JSON 생성 라이브러리

 

양방향 매핑 정리

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

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

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

마무리

최근에 JPA를 배우면서 DB 설계의 중요성을 많이 배우고 가는 거 같다.

MyBatis로 학원 프로젝트를 진행하면서 상품의 재고 조회를 위해 재고 테이블의 관련된 모든 정보(N대N,1대N)를 assosiation과 collection으로 연결한 적이 있었는데, 강의에서 나온 거와 같이 스택오버플로우(양방향 매핑시 발생하는 오류)가 발생하면서 프로그램이 다운된 적이 있었다.

이를 해결하기 위해 @JsonIgnore 어노테이션을 사용하거나, 원하는 데이터만 추출해주는 Dto를 생성하는 등 다양한 방법을 사용해봤지만 또 다른 문제가 발생하여 결국 해결하지 못하고 양방향 매핑을 모두 단방향 매핑으로 수정한 기억이 있다.

이처럼 설계 단계에서 단방향 매핑으로 연결한 후 필요한 부분만 양방향 매핑을 했었다면 시간적으로 많이 단축을 했을텐데 아쉬운 부분이 많이 남는 거 같다.

하지만 프로젝트 경험이 부족했기 때문에 어쩔 수 없는 부분이라 생각하고 지금부터라도 토이 프로젝트를 하든, 실무 경험을 한다면 설계 단계에서 정말 많은 시간을 투자하고 고민을 많이 할 거 같다.

 

결론은 객체는 가급적 단방향으로 설계하고, 어플리케이션 개발 단계에서 양방향을 생각해도 늦지 않다!