4. JPA와 연관 관계 매핑 1

연관관계 매핑은 왜 필요할까?

객체지향의 모델링과 데이터베이스의 모델링은 분명한 차이가 존재한다.

 

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

그렇기 때문에 우리는 데이터베이스 상의 1:M , 1:1 , M:M 등의 관계를 객체지향에 맞춰 매핑을 해줘야한다.

 

이러한 테이블이 존재할때 우리는 이걸 어떻게 객체지향스러운 방식으로 풀지 알아야 한다.

 

멤버 테이블에서 teamId를 가지고 있으니 Member의 필드로 teamId를 가지도록 하면 될까? 싶지만 그렇지 않다.

조회를 하거나 insert 할때 Member의 경우 teamId를 알고있어야 해당 쿼리가 가능해질것이다.

따라서 필드에 teamId를 가지기 보다는 직접 team 객체를 포함하도록 만들어 주는것이 객체지향스러운 방법이다.

 

멤버엔티티

팀 엔티티

1:M & M:1 어노테이션은 DB에서 관계를 배웠다면 쉽게 이해할 수 있는 내용이다.

 

멤버 엔티티의 JoinColumn(name = "TEAM_ID")는 DB 테이블에서의 FK를 의미하며 Team 엔티티의 pk 컬럼명과 일치시켜 주면 된다.

 

하지만 Team 엔티티의 1:M 어노테이션에는 mappedBy 라는 알수없는 친구가 있다.

 

mappedBy

mappedBy란 주인(FK)에 의해 매핑된 테이블이다.

 

DB에서는 관계는 양방향이 가능하다. 하지만 객체지향에서 그 양방향을 똑같이 구현할 수 있을까?

위의 엔티티들은 양방향처럼 보이지만 사실은 멤버에서 팀으로 가는 방향과 팀에서 멤버로 가는 두개의 단방향 관계가 존재한다.

 

따라서 그 관계의 외래키를 관리하는 주인이 필요하다!

 

그럼 누가 주인이 되어야할까?

 

양방향 연관관계 주인의 조건

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

위 내용을 보았을때 누가 주인일까? 4번 조건을 보면 명확히 보이지만 Member 엔티티의 필드 team이 주인이 된다.

 

그래서 누가 주인?

외래 키가 있는 곳을 주인으로 정한다!
'다' 쪽이 주인이 된다. (DB테이블에서 M쪽이 주인)

 

DB상에선 항상 '다' 쪽이 FK를 가지기 때문에 이와 같이 양방향 연관 관계의 주인은 '다' 쪽을 주인으로 설정해주면 된다.

 

 

양방향 연관관계의 주의사항  

무엇이 잘못됐을까? 

이 관계는 양방향 연관관계이다. 하지만 멤버에는 team을 설정해줬지만 team에는 member를 설정해주지 않았다.

따라서 항상 양쪽에 값을 설정해줘야한다. 

 

값을 설정해줄때 setter를 쓰면 당연히 편하겠지만 연관관계 편의 메서드를 따로 생성하여 하나의 관계를 설정할때 나머지도 같이 해주는 편이 가장 간단하다.

 

위와 같이 두 엔티티중 한 곳에 연관관계 편의 메서드를 만들어주면 좋다.

 

 

항상 DB에 맞게 양방향 관계로 설계해야할까?

그렇지는 않다. 

우선 단방향으로 관계를 설정하고 양방향 연관 관계가 필요할때, 즉 양방향으로의 조회가 모두 필요할때 그때 추가해주는것이 바람직하다.