JPA - 연관관계 매핑 기초(2) : 양방향 연관관계와 연관관계의 주인 (1)

양방향 연관관계와 연관관계의 주인 (1) - 기본

 

 

 

Member의 엔티티는 단방향과 동일

 

 

Team 엔티티는 컬렉션 추가

 

※ mappedBy

mappedBy는 반대편에 어느 컬럼과 매핑되었는가를 정의해주면 된다.

mappedBy는 연관관계의 주인이 아니라는 뜻도 내포되어 있다.

mappedBy는 읽기만 가능하다 (ReadOnly)

 

 

 

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

 

 

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

객체 연관관계 = 2개

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

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

 

테이블 연관관계 = 1개

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

테이블에서는 FK 값 하나로 양방향 연관관계 가질 수 있다. (양쪽으로 JOIN가능)

 

객체의 양방향 관계

• 객체의 양방향 관계는 사실 양방향 관계가 아니라 서로 다른 단방향 관계가 2개다.

• 객체를 양방향으로 참조하려면 단방향 연관관계를 2개 만들어야 한다.

 

테이블의 양방향 연관관계

• 테이블은 외래 키 하나로 두 테이블의 연관관계를 관리한다.

• MEMBER의 TEAM_ID 외래 키 하나로 양방향 연관관계를 가진다. (양쪽으로 JOIN할 수 있다.)

 

양방향의 딜레마

두 객체를 참조방향을 양쪽으로 만들어놨다. 생각해보자.

멤버에 팀을 넣고, 팀에 멤버를 넣는다. 두 군데 모두 넣어 주는데 둘 중에 뭘로 연관관계를 매핑해야 할까?

1. 멤버의 팀을 업데이트 했을때, FK 업데이트? = member.setTeam(team)
2. 팀의 멤버를 업데이트 했을때, FK 업데이트? = team.getMembers().add(member)

데이터베이스에서는 객체가 참조를 어떻게 하던, FK값만 업데이트 되면 된다.

 

단방향 연관관계 매핑에서는 참조와 외래 키만 업데이트 하면 됐지만, 양방향 관계 매핑에서는 다르다.

이것이 객체와 테이블의 가장 큰 패러다임의 문제이다.

 

 

연관관계의 주인 (Owner)

연관관계의 주인은 패러다임의 문제를 해결하기 위해 만들어진 개념이다. (양방향에서만 나오는 개념)

 

• 객체의 두 관계중 하나를 연관관계의 주인으로 지정한다.

• 연관관계의 주인만이 외래 키를 관리한다. (등록, 수정)

• 주인이 아닌쪽은 읽기만 가능하다. (Read-Only)

• 주인은 mappedBy 속성을 사용하지 않는다.

• 주인이 아니면 mappedBy 속성으로 주인 지정한다.

• ★★★ N : 1 관계에서 FK는 Many가 가져간다. ★★★

• ★★★ 외래 키(FK)가 있는 곳으로 주인으로 정해라. 그렇지 않으면 헷갈린다. (또한 성능이슈도 없다.) ★★★

 

 

 

 

---

 

양방향 관계는 자주사용해도 되는가?

양방향은 지양하고 단방향을 지향하는게 Best

 

객체의 참조와 테이블의 외래키 차이점

양방향은 둘의 관계에서 두 객체 모두 다른 객체를 참조할 수 있는 형태이다.

하지만 앞서 배운 단방향 연관관계에서 DB 테이블의 변화는 없다.

사실 테이블의 연관관계에서는 방향이라는 개념이 없다. 테이블의 연관관계에서는 외래키 하나만 있어도 양방항이 된다. 하지만 객체세계에서는 작업이 필요하다.

 

양방향 연관관계에서의 다중성 정의

Member과 Team객체의 양방향 연관관계에서 다중성 정의는 양쪽에 해야한다.

Member(N)의 Team객체에 @ManyToOne를 달아주고, Team(1)의 List<Members>에는

@OneToMany(mappedBy = "team")을 달아준다.

 

※ 출처 - 인프런 김영한 JPA