JPA 다양한 연관관계 매핑 - 다대일, 일대다, 일대일, 다대다

출처 : 자바 ORM 표준 JPA 프로그래밍 인프런 강의

 

JPA 게시글은 대부분 인프런의 김영한님의 강의인 '자바 ORM 표준 JPA 프로그래밍' 기반으로 내용을 정리했습니다.

 

JPA 다양한 연관관계 매핑

연관관계 매핑시 고려사항 

• 다중성
  • 다대일 : @ManyToOne
  • 일대다 : @OneToMany
  • 일대일 : @OneToOne
  • 다대다 : @ManyToMany
  • 다대다 관계는 실무에서 사용하지 않는다. 대부분 다대일 > 일대다 > 일대일 순으로 실무에서 자주 사용한다.
• 단방향, 양방향
  • 테이블
    • 외래키 하나로 양쪽 조인 가능 -> 사실 방향이라는 개념이 없다.
  • 객체
    • 참조용 필드가 있는 쪽으로만 참조 가능
    • 한쪽만 참조하면 단방향
    • 양쪽이 서로 참조하면 양방향
• 연관관계의 주인
  • 테이블은 외래키 하나로 두 테이블이 연관관계를 맺음
  • 객체 양방향 관계는 A->B, B->A 처럼 참조가 두군데에서 일어난다.
  • 연관관계의 주인 : 외래키를 관리하는 참조
  • 주인의 반대편 : 외래키에 영향 X, 단순 조회만 가능하다. mappedBy 속성을 사용하여 연관관계의 주인 필드의 이름으로 매핑한다.

 

 

다대일(N:1)

데이터베이스 설계 시 다대일의 경우 항상 다쪽에 외래키가 존재해야 한다. 만약 일쪽에 외래키가 존재한다면 이는 그냥 설계 자체가 잘못된 것이다.

다대일 단방향

다대일 단방향

가장 많이 사용하는 연관관계이며 다대일 연관관계의 반대 관계는 일대다(1:N)이다.

다대일 양방향

다대일 양방향

외래키를 가진 쪽이 연관관계의 주인이 되며 양쪽을 서로 참조하도록 개발하여야한다.

 

 

일대다(1:N)

일대다 단방향

이 모델은 딱히 권장하지 않는 모델이다.

• 일대다 단방향은 일대다에서 일(1)이 연관관계의 주인이 된다.
• 테이블 일대다 관계는 항상 다(N) 쪽에 외래키가 존재한다.
• 객체와 테이블의 차이 때문에 반대편 테이블의 외래키를 관리하는 특이한 구조이다.
  • 연관관계 관리를 위해 추가로 UPDATE SQL을 실행한다.
• @JoinColumn을 꼭 사용해야한다. 그렇지 않으면 조인 테이블 방식을 사용(중간에 테이블 하나 추가)한다.
• 일대다 단방향 매핑보다는 다대일 양방향 매핑을 사용하는 것이 좋다.

 

일대다 양방향

• 이런 매핑은 공식적으로 존재하지는 않는다.
• @JoinColumn(insertalbe = false, updatable = false)를 사용한다.
• 읽기 전용 필드를 사용해서 양방향처럼 사용하는 방법이다.
• 다대일 양방향을 사용하는게 더 좋다.

 

일대일(1:1)

• 일대일 관계는 그 반대 관계도 일대일이다.
• 대칭적인 구조이기 때문에 외래키를 어떤 테이블에 넣어도 상관 없음
  • 주 테이블에 외래키를 넣을 수 있다.
  • 대상 테이블에 외래키를 넣을 수 있다.
• 외래키에 데이터베이스 유니크(Unique) 제약 조건 추가

주 테이블에 외래키 단방향

다대일(@ManyToOne) 단방향 매핑과 유사하다.

 

주 테이블에 외래키 양방향

다대일 양방향 매핑처럼 외래키가 있는 곳이 연관관계의 주인이 된다. 반대편은 똑같이 mappedBy를 적용한다.

 

대상 테이블에 외래키 단방향

단방향 관계는 JPA에서 지원하지 않는다.

 

대상 테이블에 외래키 양방향

사실 일대일 주 테이블에 외래키 양방향과 매핑 방법이 같다.

뭔가 주 테이블과 대상 테이블이 별 차이 없어보이지만 정리를 해보면 그래도 어느정도 차이가 존재한다.

• 주 테이블에 외래키
  • 주 객체가 대상 객체의 참조를 가지는 것처럼 주 테이블에 외래키를 두고 대상 테이블을 찾는다.
  • 객체지향 개발자가 선호하는 방식이다.
  • JPA 매핑이 편리하다
  • 장점 : 주 테이블만 조회해도 대상 테이블에 데이터가 있는지 확인이 가능하다.
  • 단점 : 값이 없으면 외래키에 null이 허용된다.
• 대상 테이블에 외래키 
  • 대상 테이블에 외래키가 존재하는 방식이다.
  • 전통적인 데이터베이스 개발자가 선호하는 방식이다.
  • 장점 : 주 테이블과 대상 테이블을 일대일에서 일대다 관계로 변경할 때 테이블 구조를 유지한다.
  • 단점 : 프록시 기능의 한계로 지연 로딩으로 설정해도 항상 즉시 로딩이 된다.

 

 

다대다(N:M)

다대다는 실무에서 사용하지 않는다.

• 관계형 DB는 정규화된 테이블 2개로 다대다 관계를 표현할 수 없다.
• 연결 테이블을 추가해서 일대다, 다대일 관계로 풀어내야하는게 맞다.

• 객체는 컬렉션을 사용해서 객체 2개로 다대다 관계가 가능은 하다.

• @ManyToMany 애노테이션을 사용한다.
• @JoinTable로 연결 테이블을 지정한다.
• 단방향, 양방향이 가능하다.

 

왜 실무에서 사용하지 않을까?

• 뭔가 각 객체에 상대 컬렉션을 만들어 참조해 편리해보이지만 실무에서 사용하지 않는다.
• 연결 테이블이 단순히 연결만하고 끝나지 않는다.
• 주문시간, 수량 같은 데이터가 들어올 수 있다.
  • 테이블에 주문 수량이나 주문 날짜 같은 컬럼을 추가하면 @ManyToMany를 사용할 수 없다. 주문 엔티티나 상품 엔티티에는 추가한 컬럼들을 매핑할 방법이 없기 때문이다.

 

다대다 한계 극복

• 연결 테이블용 엔티티를 추가한다. (연결 테이블을 엔티티로 승격)
• @ManyToMany -> @OneToMany, @ManyToOne