[Spring JPA] 다양한 연관관계 매핑 (N:1, 1:N, 1:1, N:M)

 

목차

• 연관관계 매핑시 고려사항
• 다대일 [N:1]
• 일대다 [1:N]
• 일대일 [1:1]
• 다대다 [N:M]

 

1. 연관관계 매핑시 고려사항

• 다중성 (DB의 관점에서)
  • 다대일: @ManyToOne (가장많이 사용한다)
  • 일대다: @OneToMany
  • 일대일: @OneToOne 
  • 다대다: @ManyToMany (실무에서는 사용하면 안된다)

• 단방향 매핑 or 양방향 매핑
  • 테이블
    • 외래 키 하나로 양쪽 조인 가능
    • 방향이라는 개념이 존재하지 않음
  • 객체
    • 참조용 필드가 있는 쪽으로만 참조가능
    • 한쪽만 참조하면 단방향
    • 양쪽이 서로 참조하면 양방향
• 양방향일때, 연관관계의 주인
  • 테이블
    • 외래 키 하나로 두 테이블이 연관관계를 맺음
  • 객체
    • A와 B 양방향 관계는 A👉B, B👉A 처럼 참조가 2군데임
    • 참조가 2개이니 2개중 테이블의 외래키를 관리하는 곳을 지정해야함
    • 연관관계의 주인: 외래 키를 관리하는 참조
    • 주인의 반대쪽: 외래 키에 영향을 주지 않고, 단순 조회만 가능 (읽기만 가능)

 

2. 다대일 [N:1]

다대일 단방향 매핑

- 외래키가 있는 곳: 다(N)

- 다대일 👈👉 일대다

 

 

다대일 양방향 매핑

- 외래 키가 있는 곳이 연관관계의 주인

- 양쪽을 서로 참조하도록 개발을 진행

 

 

3. 일대다 [1:N]

1이 연관관계의 주인!

 

일대다 단방향 매핑 (실무에서는 권장하지 않음)

- DB입장에서는 외래키를 다쪽에 선언이 되어야한다. 

- 일대다의 경우에는 팀의 리스트 멤버스를 변경했을때, 다른 테이블을 업데이트 해주어야하는 특이한 구조가 된다. 

 

단점

- 엔티티가 관리하는 외래 키가 다른 테이블에 존재한다.

- 연관관계 관리를 위해서 추가적으로 UPDATE SQL을 실행한다. (혼동 + 운영이 힘들어짐)

 

일대다 양방향 매핑

일대다 양방향은 공식적으로는 존재하지 않으니 다대일 양방향을 사용하는 편이 효율적이다.

 

4. 일대일 [1:1]

- 주 테이블 or 대상 테이블 중에 외래 키를 선택할 수 있다.

- 외래 키가 존재하는 DB에 유니크 제약조건이 추가되어야 한다.

- 일대일 단방향 (주 테이블에 외래 키가 존재) 👉 다대일 단방향 매핑과 유사하다.

- 일대일 단방향 (대상 테이블에 외래 키가 존재)은 존재 할 수 없다. (JPA가 지원하지 않음)

- 일대일 양방향 (주 테이블 FK)

- 일대일 양방향 (대상 테이블 FK)

 

주 테이블에 외래키가 존재한다면?

- 객체지향 개발자들이 선호

- JPA 매핑 관리

- 장점: 주 테이블만 조회하면 대상 테이블에 데이터가 존재하는지 확인할 수 있다.

- 단점: 값이 없으면 외래 키에 null이 들어간다.

 

대상 테이블에 외래키가 존재한다면?

- 전통적인 DB 개발자들이 선호

- 장점: 일대일에서 일대다 관계로 변경할 때, 테이블 구조를 유지

- 단점: 프록시 기능의 한계로 인하여 지연 로딩으로 설정을 한다고해도 즉시로딩이 된다. (치명적인 단점)

 

5. 다대다 [N:M]

실무에서는 사용하면 안된다

 

이유?

RDBMS는 정규화된 테이블 2개로 다대다 관계를 사용할 수 없다. 따라서 연결 테이블을 추가하여 일대다, 다대일 관계로 풀어내어야 한다.

예시)

하지만, 객체에서는 컬렉션을 사용하여 객체 2개로 다대다 관계를 설정할 수 있다 (@ManyToMany)

 

한계점?

- 연결 테이블이 단순히 연결만 하고 끝나지 않는다.

- 주문시간, 수량 같은 더미 데이터가 들어올 수 있다.

- 🌟 다대다를 풀어내기위해서 @ManyToMany 👉 @OneToMany, ManyToOne 으로 풀어내야함 🌟