JPA #6 다양한 연관관계 매핑 (1:N, N:1, N:N)

📌 연관관계 애노테이션

참고로 이런 1:1, N:1 조건을 행의 개수 비율 제약 조건 ( Cardinality Raito Constraint ) 이라고 한다.

JPA에서 사용법은 정말 간단하긴 하다.

• 다대일: @ManyToOne 
• 일대다: @OneToMany 
• 일대일: @OneToOne 
• 다대다: @ManyToMany

 

참고로 각 애노테이션의 옵션은 아래와 같다.

fetch와 cascade는 다음 글에서 설명할 예정이니, 간단하게 보고 넘어가자

 

@ManyToOne

mappedBy가 없다. 항상 Many쪽이 연관관계의 주인이 되어야한다.

 

@OneToMany

 

@JoinColumn (외래키 매핑 용도)

 

@JoinTable ( N:N 관계 사용시 조인테이블 지정 )

@JoinTable(name="JOIN_TABLE") 이렇게 사용함. 그 외는 다대다 관계를 사용할 일이 없으므로 생략.

 

복습

💭 mappedBy를 안하면? 매핑 테이블이 생긴다.
: DB는 외래키 하나로 양방향 참조가 가능하다.
: JPA(객체)는 참조에 방향이 있다. 단방향이다.

: DB 에는 컬렉션이라는 개념이 없다. 외래키만 있을 뿐이다.
: JPA 입장에서는 어쩔 수 없이, 매핑 테이블로 컬렉션을 구현한다.
: 외래키로 구현하고 싶다면? -> mappedBy

 

# DB 칼럼명을 적으셔야 해요.

참고로 '외래키가 참조하는 테이블의 칼럼명'은 DB 칼럼명을 의미한다. 자바 코드를 의미하는게 아니다.

하지만 그냥 카멜케이스로 쓰는 경우가 많아 자바 코드 칼럼명인줄 착각하는 경우가 있다. 이는 SpringPhysicalNamingStrategy 가 기본으로 적용되어있어 @JoinColumn에 사용되는 DB 칼럼명 카멜케이스 (team_my_id -> teamMyId) 로 입력해도 변환해주기 때문이다.

• JoinColumn(name="내 DB 테이블 외래키 명", referencedColumnName="참조할 DB 테이블 PK 명") 이 기본 사용법이다
• name을 생략하면 {필드명 _ 참조 테이블 PK명 }으로 매핑된다. *주의* 복합 외래키인경우, 조인문이나 키순서가 바뀌는 버그 있음
• referencedColumnName 을 생략하면 { 참조 테이블 PK명  }를 사용한다.
• name과 referencedColumnName은 DB 칼럼명을 그대로 적어야하지만, 카멜케이스로 적어도 매핑해준다. ( myId -> my_id )
  그렇게 사용할 일은 없겠지만, PhysicalNamingStrategy 구현체를 까보면 my_familyMotherId_type 이렇게 섞어도 잘 매핑한다.

📌 @OneToMany

앞선시간에 Member기준으로 단방향 (@ManyToOne)으로 연관관계 주인을 설정했었다.

@Entity
public class Member {
 
    @Id
    @GeneratedValue
    private Long id;
    
    @ManyToOne
    @JoinColumn(name = "TEAM_ID")
    private Team team;
	
}

DB에서는 이게 자연스러운 방법.

 

 

그런데 이는 비즈니스마다 다르다. Team으로 Member를 조회하는 서비스일 수도 있다.

쉽게말해서 Team은 Member 정보를 알아야하지만, 반대로 Member는 Team의 정보가 필요없는 경우.

이 경우 연관관계 주인은 Team이 되고, 일대다 (@OneToMany) 관계가 된다.

@Entity
public class Team {

    @Id
    @GeneratedValue
    @Column(name = "TEAM_ID")
    private Long id;

    @OneToMany
    @JoinColumn(name = "TEAM_ID") // 이게 없으면 테이블을 추가로 만들어서 사용하게된다.
    List<Member> members = new ArrayList<Member>();

    private String name;
…
}

 

* 참고로 @JoinColumn을 사용하지 않으면, 기본 처리방식이 조인하는게 아니라서 중간에 테이블을 추가해서 처리한다.

조인하지 않고 DB에 team_member라는 테이블을 멋대로 추가해버린다.

비즈니스나 객체는 이런 일이 가능하다. 하지만 DB는 설계상 불가능하다. Member(Many)쪽에 외래키가 있을 수 밖에 없다. 즉 Team 관계(외래키)를 변경하면 수많은 Member에 UPDATE 쿼리가 나가게 된다.

team.getMembers.add(member); 를 해보면 멤버 테이블에 업데이트 쿼리가 나간다.

 

다대일 쿼리와 다르게 자신이 아닌 다른 테이블까지 수많은 쿼리를 날려야한다는 단점이 있다.

이는 Team을 수정했는데 Member까지 변경이 전파되는 것이다. 실무에서는 수많은 테이블을 사용할 건데 매번 1:N인지 N:1인지 확인해가면서 조회하는건 객체지향적이지도 않고, 사실상 불가능하다.

 

그래서 실무에서는 Team ➡ Member 조회가 필요한 경우, 차라리 다대일 양방향(@ManyToOne)을 쓰는걸 권장한다. [ 양방향 vs 일대다 ] 의 선택은 조금 애매한 부분이지만, 트레이드 오프를 고려해보면 거의 대부분은 이게 맞다.

 

 

✔ @OneToMany를 양방향처럼 쓰는 방법

🙄 : ?? 무지성으로 양쪽에 @JoinColumn 붙이면 안되나요?

사용 시 JPA에서 오류를 띄우며, 된다고 하더라도 절대 사용해서는 안되는 코드이다.

JPA에서는 양방향 관계에서 [연관관계의 주인]을 한쪽으로 지정한다.
그 이유는 양쪽을 주인으로 지정하는게 불가능해서 그런게 아니라, 예측할 수 없는 동작을 초래하기 때문이다.

* 실제로 스프링에서 사용하면, 컴파일은 되지만 실행시 아래와 같이 오류뜨며 앱이 꺼진다.

2022-01-30 17:32:12.955 ERROR 24436 
---[  restartedMain] j.LocalContainerEntityManagerFactoryBean :
  Failed to initialize JPA EntityManagerFactory:
    Associations marked as mappedBy must not define database mappings like @JoinTable or @JoinColumn: Team.members

즉, 양쪽에 @JoinColumn을 쓰면 양쪽 다 [연관관계의 주인]이 되어버리고, 이는 예측할 수 없는 동작 => 오류를 만들어낸다. 그래서 사용하지 못하게 막는 것이다.

반면 mappedBy는 한쪽을 읽기전용(가짜매핑)으로 만들어버려서 외래키 하나로 양쪽 참조가 가능하게 해준다.
물론 주인이 아닌쪽은 외래키 수정이 불가능하지만.

https://stackoverflow.com/questions/14012494/hibernate-joincolumn-in-both-entities-for-1-m-relationship

Hibernate @JoinColumn in both entities for 1-m relationship

 

 

JPA에서 공식적으로 제공해주는 기능은 없다. 왜냐하면 @ManyToOne 에는 mappedBy라는 옵션이 없기 때문.

 

다만 꼼수로 비슷하게 만들 수는 있는데  일대다(@OneToMany)를 사용하는데 양방향으로 조회하고 싶다면 아래와 같이 하면된다.

정확히는 양방향 매핑은 아니고, 양쪽을 주인으로 설정 후, 한쪽을 읽기전용으로 만듦.

@Entity
public class Member{
	
    @ManyToOne // JoinColumn을 주인이 아닌쪽에도 지정하되, 수정을 막아 DB 읽기전용으로 만들어버린다.
    @JoinColumn(insertable = false, updateable= false)
    private Team team;
}

@Entity
public class Team {

    @Id
    @GeneratedValue
    @Column(name = "TEAM_ID")
    private Long id;

    @OneToMany // Team이 주인이기 때문에 members에 (mappedBy = "team")을 걸지 않는다.
    @JoinColumn(name = "TEAM_ID")
    List<Member> members = new ArrayList<Member>();

    private String name;
…
}

이런 걸 알려주는 이유는 실무에서 서비스가 복잡해지면 이런 테크닉이 가끔 필요할 때가 있다.

 

 

📌 @OneTOOne

애노테이션만 다를 뿐, @ManyToOne과 사용법은 같다.

@Entity
public class Member{
    @OneToOne
    @JoinColumn(name="LOCKER_ID");
    private Locker locker;
}

@Entity
public class Locker{
    @OneToOne(mappedBy = "locker") // member.locker
    private Member member;
}

참고로 DB에서의 일대일 관계는, 외래키에 유니크 제약조건(FK, UNI)이 추가가 된 것이다.

 

별로 중요하지는 않지만, 단방향인 경우 Member➡Locker 처럼, 주 테이블(PK)에서 타겟 테이블(FK)로 참조는 가능하다.

PK를 가진 주 테이블인 Member가 외래키를 관리하는건 가능하다.

 

하지만 반대의 경우는 JPA에서 지원해주지 않는다. DB 구조상 불가능하니까.

불가능. Locker가 FK를 이용해 Member의 외래키를 변경하는 건 DB 구조상 불가능하다.

 

 

필요하다면 양방향으로 사용하자. 다만 양방향일 때에는 DB에 외래키는 어디에 둬야하는가? 는 고민거리이긴 하다.

• 객체지향적으로 생각해보면, Member가 외래키를 가지고있는게 사용하기도 편하고 성능적으로 유리하다.
• 하지만 장기적인 관점에서 [ 하나의 Locker가 여러개의 Member를 가질 수도 있다 ]는게 추가 될 수 있음을 고려하면 Locker가 외래키를 가지고 있는게 DB를 유연하게 사용할 수 있다.

둘 다 장단점이 있긴하다. 크게 중요하지 않다면 [ 주 테이블이 외래키를 관리 ] 하는게 개발하기 편하다.

 

장단점을 정리해보면 아래와 같다.

• 주 테이블에 외래키 (개발자가 선호)
  장점 : 객체지향적으로 개발하기 좋다. 주 테이블만 조회해도 타겟 테이블에 데이터가 있는지 확인 가능하다.
  단점 : 값이 없다면 외래 키에 null이 들어갈 수 있다. ( Member는 Locker가 없을 수도 있다. Locker= null)
  
  
• 타겟 테이블에 외래키 (DBA가 선호)
  장점 : 테이블간의 관계를 변경할 때 DB 테이블 구조를 변경할 필요가 없다. (유연하다.)
  단점 : 프록시 기능의 한계로, Lazy Loading으로 설정해도 항상 즉시로딩 된다. ( Locker는 Member가 반드시 있어야한다. 즉 대상 테이블에 쿼리를 날려 존재여부를 확인해야 하니 지연로딩이 불가능 )

 

 

📌 ManyToMany

다대다 관계는 맘 편하게 들으면 된다. 거의 사용할 일 없다.

DB를 공부해봤으면 알겠지만. N:N관계는 정규화를 이용해 테이블을 만들어 1:N N:1 관계로 바꾸는게 맞기 때문이다.

 

다만 DB에서 가능한게 JPA에서 불가능하면 이상하므로, 지원은 해준다.

JPA에서 N:N 관계는 중간에 숨겨진 조인테이블을 만들어서 관리한다.

까먹었을까봐 다시 보여주는 ERD 그리는 방법

컬렉션은 바로 조회하고, 실제 DB는 숨겨진 조인테이블을 이용한다.

@Entity
public class Member{

    @ManyToMany
    @JoinTable(name = "MEMBER_PRODUCT") // 조인테이블 이름을 적어준다.
    private List<Product> products = new ArrayList<>();
}

@Entity
public class Product {

    @Id
    @GeneratedValue
    private Long id;
    
    @ManyToMany(mappedBy = "product")
    private List<Product> members = new ArrayList<>();

}

 

하지만 이렇게 숨겨진 조인테이블을 사용할 이유도 없고, 실제로 사용할 일도 없다.

ManyToMany 관계는 아래와 같이 아예 새로운 Entity를 만들어서 1:N, N:1 관계로 변경하도록 하자.

아래처럼 중간 테이블의 키를 [Member + Product]로 사용하기 보다는 별도의 id를 가지는게 비즈니스적으로 유연하다.

@Entity
public class MemberProduct {

    @Id
    @GeneratedValue
    private Long id; // 이렇게 PK를 따로 가지고 있는게 유연한 개발이 가능하다.

    @ManyToOne
    @JoinColumn(name = "MEMBER_ID")
    private Member member;

    @OneToMany
    @JoinColumn(name = "PRODUCT_ID")
    private Product product;

    private LocalDateTime orderDateTime;
    //...
}

 

📌 모든 연관관계 사용해보기

비즈니스를 아래와 같이 구현한다고 할 때

실제 테이블과 엔티티는 아래와 같다. 그림을 참조해서 직접 만들어보도록 하자.