[JPA] 연관관계 매핑 기초

Swim Lee·2021년 1월 28일
2

JPA

목록 보기
6/10
post-thumbnail

들어가며..

이번에 다루는 내용이 객체와 관계형 데이터베이스의 패러다임의 차이에서 오는 것 중에서 제일 어려운 내용.

객체가 지향하는 패러다임과 관계형 데이터베이스가 지향하는 패러다임의 차이가 있기 때문에 둘 사이의 차이에 의한 극심한 어려움이 있다.

목표

  • 객체와 테이블 연관관계의 차이를 이해
  • 객체의 참조와 테이블의 외래 키를 매핑
    • 객체의 경우 참조(Reference)를 이용하여 연관된 객체를 쭉 탐색할 수 있다.
    • 테이블의 경우 외래키로 조인을 하여 연관된 테이블을 탐색한다.
  • 용어 이해
    • 방향(Direction) : 단방향, 양방향
    • 다중성(Multiplicity) : 다대일(N:1), 일대다(1:N), 일대일(1:1), 다대다(N:M) 이해
    • 연관관계 주인(Owner) : 객체 양방향 연관관계는 관리 주인이 필요

연관관계가 필요한 이유

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

👩🏻‍🤝‍🧑🏻예제 시나리오

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

객체를 테이블에 맞추어 모델링

연관관계가 없는 객체

▶ 객체에는 연관관계가 없다. 😨

참조 대신에 외래키를 그대로 사용

@Entity
public class Member {

    @Id @GeneratedValue
    private Long id;
    
    @Column(name = "USERNAME")
    private String name;
    private int age;
    
    @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());

//연관관계가 없음
Team findTeam = em.find(Team.class, team.getId());

▶ member를 조회해왔음에도 불구하고, member가 속한 팀을 알기 위해서는 또 member가 가진 team_id(FK)로 테이블을 검색해서 가져와야한다.

▶ 연관관계가 없기 때문, 객체지향스럽지 않은 방식

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

  • 테이블은 외래키로 조인을 사용해서 연관된 테이블을 찾는다.
  • 객체는 참조를 사용해서 연관된 객체를 찾는다.

테이블과 객체 사이에는 이런 큰 간격이 있다.

데이터 중심(테이블 중심) 설계의 문제점

  • 현재 방식은 객체 설계를 테이블 설계에 맞춘 방식
  • 테이블의 외래키를 객체에 그대로 가져온다
  • 객체 그래프 탐색이 불가능

단방향 연관관계

객체 지향 모델링

객체 연관관계 사용

  • Team의 Id가 아닌 Team의 참조값을 그대로 가져온다.
  • Member 객체의 Team 레퍼런스와 MEMBER 테이블의 TEAM_ID(FK)를 매핑해야한다.

객체의 참조와 테이블의 외래키를 매핑

@Entity 
public class Member {
   
   @Id @GeneratedValue
   private Long id;
   
   @Column(name = "USERNAME")
   private String name;
   private int age;
   
   //@Column(name = "TEAM_ID")
   //private Long teamId;
   
   @ManyToOne
   @JoinColumn(name = "TEAM_ID")
   private Team 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에 team 참조를 저장하면, JPA가 DB에 엔티티 저장할 때 알아서 team 엔티티에서 PK값을 꺼내서 Member 테이블의 FK컬럼에 저장한다.

참조로 연관관계 조회 - 객체 그래프 탐색

//조회
Member findMember = em.find(Member.class, member.getId());

//참조를 사용해서 연관관계 조회
Team findTeam = findMember.getTeam();

연관관계 수정

//새로운 팀 B
Team teamB = new Team();
teamB.setName("TeamB");
em.persist(teamB);

//회원1에 새로운 팀B 설정
member.setTeam(teamB);
  • 더티 체킹을 이용한 연관관계 수정

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

양방향 매핑

  • 테이블 연관관계는 그대로이다. 왜냐하면 테이블은 외래키로 조인해서 연관관계를 만들기 때문에 테이블의 연관관계는 외래키하나에 양방향이 다 있는 것이다.
  • 하지만 객체는 참조를통해 연관관계 설정하기 때문에, Team에서 member로 가려면 Team에도 member에 대한 참조 넣어줘야한다.

Member 엔티티는 단방향과 동일, Team 엔티티는 컬렉션 추가

@Entity
public class Team {
    
    @Id @GeneratedValue
    private Long id;
    
    private String name;
    
    //ArrayList로 초기화해두는 것은 관례 (add할 때 NPE 안뜨니까)
    @OneToMany(mappedBy = "team")
    List<Member> members = new ArrayList<Member>();
    ...
}

반대 방향으로 객체 그래프 탐색

//조회
Team findTeam = em.find(Team.class, team.getId());

int memberSize = findTeam.getMembers().size(); //역방향 조회

연관관계 주인과 mappedBy

객체와 테이블 간에 연관관계를 맺는 차이를 이해해야 한다.

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

  • 객체 연관관계 = 2개
    • 회원 ➡ 팀 연관관계 1개 (단방향)
    • 팀 ➡ 회원 연관관계 1개 (단방향)
    • 단방향 연관관계가 2개 있는 것이다. 이것을 우리는 억지로 양방향이라고 부르고 있는 것.
    • 객체 세상에서는 양방향 연관관계를 맺으려면, 참조가 양쪽 객체에 있어야한다.
  • 테이블 연관관계 = 1개
    • 회원 ↔ 팀 연관관계 1개 (양방향, 사실 방향이 없는 것)
    • 외래키 값 하나로 테이블을 조인하면 양쪽의 연관관계가 끝이난다.

객체의 양방향 관계

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

테이블의 양방향 연관관계

  • 테이블은 외래키 하나로 두 테이블의 연관관계를 관리
  • 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;

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

  • 객체에는 두 가지 참조값이 있다.
    • Member ➡ Team 참조값
    • Team ➡ Member 참조값
  • 둘중 어떤 것이랑 테이블의 외래키를 매핑해야하는가?
    • Member에 있는 team값이 바뀌었을 때 외래키 값을 업데이트 해야하나.
    • Team에 있는 members값이 바뀌었을 때 외래키 값을 업데이트 해야하나.
  • 그냥 두 개의 참조값 다 매핑하면 안되나?
    • 극단적으로 Member에 있는 team에는 값을 넣고, Team에 있는 members에는 값을 넣지 않는다면?
    • 반대로 Member에 있는 team은 값을 넣지 않고, Team에 있는 members에만 값을 넣는다면?
    • 아니면 둘 다 값을 넣는다면?
    • 무엇을 기준으로 해야하지? 😨
  • 따라서 규칙이 생김
    • 둘 중 하나로 외래키를 관리해야 한다!!
    • 그것이 바로 연관관계의 주인!!

연관관계의 주인(Owner)

🔴 양방향 매핑 규칙

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

🟠 누구를 주인으로?

  • 외래키가 있는 곳을 주인으로 정해라!(다대일에서는 다쪽!)
  • 여기서는 Member.team이 연관관계의 주인!

왜 외래키가 있는 쪽을 연관관계의 주인으로 정하는 것인가?

  • 일단 외래키가 있는 쪽의 테이블에 대응되는 엔티티에 있는 참조를 연관관계의 주인으로 정하는 것이 헷갈리지 않는다.
  • 만약 외래키가 있는 곳이 아닌 Team.members를 연관관계의 주인으로 정한다면?
  • Team에 있는 members를 수정했는데, update쿼리는 다른 테이블(MEMBER)에 날라간다. ➡ 벌써 헷갈린다! 😵
  • 뒤에 나오지만 성능이슈도 있다.

외래키가 있는 쪽을 연관관계의 주인으로 설정하면 많은 것들이 해결된다.

  • DB 입장에서는 다대일 관계에서 외래키가 있는 쪽이 다고 외래키가 없는 쪽이 일이다.
  • DB의 N쪽이 무조건 연관관계의 주인이 된다.
  • 객체에서는 @ManyToOne, @XXXToOne 쪽이 무조건 연관관계의 주인이 된다.
  • 연관관계 주인은 비즈니스적으로 큰 의미는 없다. 자동차와 바퀴가 있다고 하면, 비즈니스적으로는 당연히 자동차가 중요하지만, 연관관계의 주인은 바퀴이다. (그정도로 의미 없다는 뜻)
  • 다만 설계상 외래키 있는 쪽에 연관관계 주인이 있어야 설계가 깔끔해진다.
  • 엔티티랑 테이블이 매핑이 되있는 같은 곳에서 연관관계가 관리가 된다.
  • 그래야 내가 Member를 바꿨더니 MEMBER 테이블에 업데이트 쿼리 나가는구나 직관적으로 인식이 됨.

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

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

Team team = new Team();
team.setName("TeamA");
em.persist(team);

Member member = new Member();
member.setName("member1");

//역방향(주인이 아닌 방향)만 연관관계 설정
team.getMembers().add(member);

em.persist(member);

  • 연관관계의 주인만이 외래키 값을 등록 수정할 수 있다.
  • 연관관계의 주인이 아닌쪽은 조회만 가능하다.
  • JPA에서 update나 insert할 때는 mappedBy 된 쪽은 아예 안본다.
  • mappedBy는 그냥 읽기 전용, 가짜 매핑인 것이다.

🟧 양방향 매핑시 연관관계의 주인에 값을 입력

Team team = new Team();
team.setName("TeamA");
em.persist(team);

Member member = new Member();
member.setName("member1");

team.getMembers().add(member);
//연관관계의 주인에 값 설정
member.setTeam(team);

em.persist(member);

순수한 객체 관계를 고려하면 항상 양쪽 다 값을 입력해야 한다.

  • 위의 코드에서 team도 영속성 컨텍스트에 들어가있다.
  • 연관관계의 주인에만 값 설정해주면 영속성 컨텍스트에 있는 team 객체의 members 컬렉션은 여전히 비어있는 상태다. (물론 커밋시점에 연관관계의 주인에 의해서 DB에는 업데이트 쿼리 날아간다.)
  • 따라서 트랜잭션안에서 영속성 컨텍스트 flush하고 clear 되기 전에 해당 컬렉션 조회한다면 정상적인 결과가 출력되지 않는다.
  • 또 하나의 문제점은 나중에 테스트 케이스 작성할 때이다.
  • 테스트 케이스 작성시 JPA 없이도 동작하게 순수 자바 코드로도 작성한다.
  • 그런 케이스에도 대비하기 위해서는 양쪽 다 입력해주는 것이 맞다.

🟨 결론

  • 양방향 연관관계 매핑에서는 순수 객체 상태를 고려해서 항상 양쪽에 값을 설정하자!
  • 연관관계 편의 메소드를 생성하자
  • 양방향 매핑시에 무한루프를 조심하자
    예) toString(), lombok, JSON 생성 라이브러리

🟩 정리

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

연관관계 주인 정하는 기준

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

해당 게시글은 인프런 김영한님의 <자바 ORM 표준 JPA 프로그래밍 - 기본편>을 듣고 정리한 내용입니다.

profile
백엔드 꿈나무 🐥

0개의 댓글