[JPA] 연관관계 매핑 기초

 

 

연관관계 매핑 기초

#JPA/기본

/연관관계가 필요한 이유

• 객체지향 설계의 목표는 자율적인 객체들의 협력 공동체 를 만드는 것이다
• /객체를 테이블에 맞추어 데이터 중심으로 모델링하면, 협력 관계를 만들 수 없다.

/단방향 연관관계

• /객체 지향 모델링

@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;
...

(연관관계 저장)

//팀 저장
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();

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

• /양방향 매핑
  • 테이블 연관관계에는 외래 키 하나로 양방향이 다 있는 것이다. FK만 있으면 다 할 수 있다.
  • 객체는 다르다. 단방향에서는 일에서 다로 갈 수 있는 방법이 없다.
  • /@OneToMany: @OneToMany(mappedBy = “team”)
    • 내가 어떤 것과 연결되어 있는지를 mappedBy 속성을 통해 지정해준다.
    • 나의 반대편에는 내가 Member.team이라는 변수와 연결되어 있다. 연관관계 주인이 Member.team이다~
    • mappedBy를 붙여주면 FK가 생성되지 않음. mappedBy를 만약 안붙이면, FK가 존재하는 DDL이 나가게 되고, 결국에는 Team, Member 각각의 FK를 위한 조인 테이블이 생기게 된다.
    • mappedBy를 붙여주기 때문에 FK를 관리하지 않는다는 것을 알게되고, 해당 엔티티를 수정할 때 다른 테이블에 쿼리가 나가지 않게 된다.
    • mappedBy=“team” 에서 “team”이라는 값 때문에, 어떤 속성에 Team 엔티티의 외래 키가 존재하는지 알 수 있게 된다.(Member의 team 필드에 내 엔티티의 외래 키가 있다.)
    • 결론.
      • @OneToMany는 여러 엔티티를 참조하는 컬렉션이다라는 것을 알려주는 역할.
      • mappedBy는 FK를 관리하지 않는다는 것을 알려주고, mappedBy의 값인 필드 “team”은 순방향과 Inverse 방향의 매핑이 일치하도록 해준다.
• /연관관계의 주인과 mappedBy
  • /객체와 테이블이 관계를 맺는 차이
    • /객체의 양방향 관계
      • 객체의 양방향 관계는 사실 양방향 관계가 아니라 서로 다른 단뱡향 관계 2 개다.
      • 객체를 양방향으로 참조하려면 단방향 연관관계를 2 개 만들어야 한다.
  • /테이블의 양방향 연관관계
    • 테이블은 외래 키 하나 로 두 테이블의 연관관계를 관리
    • MEMBER.TEAM_ID 외래 키 하나로 양방향 연관관계 가짐 (양쪽으로 조인할 수 있다.)
  • /둘 중 하나로 외래 키를 관리해야 한다. (객체 기준)
    • 객체에서 외래 키를 관리한다는 거는, 양방향 관계에서 한쪽에서만 필드를 수정하겠단 말.
  • /연관관계의 주인(Owner)
    • /양방향 매핑 규칙 (읽기, 외래 키 관리, mappedBy)
    • /누구를 주인으로?: “다(FK)”
      • 일쪽에는 FK가 없다. 일쪽에서 반대편을 수정해도 FK가 없으니까 테이블에선 연관관계가 바뀌지가 않는다.
        • DB 입장: 다쪽에서 일쪽을 관리한다.
        • 객체 입장: 양쪽에서 서로 필드를 가지고 있다. 한쪽에서 양쪽의 필드에 접근해 수정해주면 된다.
        • 다쪽에서 수정하면 FK도 바뀌고, 객체도 바뀐다.
        • 일쪽에서 수정하면 FK가 안바뀜.
• /양방향 매핑시 가장 많이 하는 실수
  • : 연관관계의 주인에 값을 입력하지 않음
    • /양방향 매핑시 연관관계의 주인에 값을 입력해야 한다.
  • 객체에서 연관관계 주인에 있는 필드만 수정해버림
    • 반대편에서 접근할 때 문제가 발생할 수 있음.
    • 가끔가다 한쪽만 수정해도 DB에 flush가 나가 FK가 업데이트되고 1차 캐시 동기화가 되서 문제 없이 조회되는 경우가 있는데, 이는 거의 운빨이라고 봐도 무방… 반드시 양방향에선 양쪽 필드 다 수정해야 한다.
      • 만약 하나의 트랜잭션 내에서 역방향 조회가 된다면, flush가 나가지 않은 상태에서 조회를 하게 될 것이다. 이러면 문제가 발생한다.
      • flush가 나간 이후라면, 역방향으로 조회했을 때 영속성 컨텍스트에서 로딩해오므로 문제가 발생하지 않는다는 말임. 이는 되게 운적인 요소!
  • 연관관계 편의 메서드는 한쪽에만 두자. 무한루프에 빠질 수 있다.
• /양방향 매핑 정리
  • 중요!! 단방향 매핑만으로도 이미 연관관계 매핑은 완료
  • 양방향 매핑은 반대 방향으로 조회(객체 그래프 탐색) 기능이 추가된 것 뿐
  • JPQL에서 역방향으로 탐색할 일이 많음
  • 단방향 매핑을 잘 하고 양방향은 필요할 때 추가해도 됨 (테이블에 영향을 주지 않음)
• /연관관계의 주인을 정하는 기준
  • 비즈니스 로직을 기준으로 연관관계의 주인을 선택하면 안됨
  • 연관관계의 주인은 외래 키의 위치를 기준으로 정해야함
• 핵심은 최대한 단방향으로 하지만, 실무에서 양방향으로 설계하게 되는 경우가 많다.

 

Ref) 김영한 자바 ORM 표준 JPA 프로그래밍 - 기본편