자바 ORM 표준 JPA 기본편 - 다양한 연관관계 매핑

이번 글은 연관관계에 매핑에 대해 알아보는 시간을 갖겠습니다.

먼저 기본적인 고려사항에 대해 알아보겠습니다.

연관관계 매핑시 고려사항 3가지

• 다중성

• 단방향, 양방향

• 연관관계의 주인

다중성

JPA에서 나오는 어노테이션은 전부 DB랑 매핑하기 위해 있다고 보면 된다.

그래서 데이터베이스의 관점에서의 다중성을 기준으로 고민하면 된다.

애매할 땐 반대쪽을 생각하면 된다.(ex : 회원 - 팀 (대칭성) 1대다 의 반대는 다대1)

대칭성 생각!

• 다대일: @ManyToOne
• 일대다: @OneToMany
• 일대일: @OneToOne
• 다대다: @ManyToMany (실무에서 거의 사용 안함)

단방향, 양방향

• 테이블

• 외래 키 하나로 양쪽 조인 가능
• 사실 방향이라는 개념이 없다

• 객체

• 참조용 필드가 있는 쪽으로만 참조 가능
• 한쪽만 참조하면 단방향
• 양쪽이 서로 참조하면 양방향(객체 입장에선 방향이 하나다)
  멤버 <> 팀, 단방향이 두개가 있는 것인데 알기 쉽게 양방향으로 생각!

연관관계의 주인

• 테이블은 외래 키 하나로 두 테이블이 연관관계를 맺음

• 객체 양방향 관계는 A->B, B->A 처럼 참조가 2군데

• 객체 양방향 관계는 참조가 2군데 있음. 둘중 테이블의 외래 키를 관리할 곳을 지정해야함

• 연관관계의 주인: 외래 키를 관리하는 참조

• 주인의 반대편: 외래 키에 영향을 주지 않음, 단순 조회만 가능

다대일 [N:1]

다대일 단방향

다대일 단방향 정리

• 외래키가 있는 곳에 참조를 걸고 연관관계 매핑을 하면 된다.
• 가장 많이 사용하는 연관관계
• 다대일의 반대는 일대다

다대일 양방향

다대일 양방향 정리

• 외래 키가 있는 쪽이 연관관계의 주인

• 양쪽을 서로 참조하도록 개발해야 한다.

일대다 [1:N]

일대다 단방향 (실무 권장 X)

일대다 단방향 정리

• 일대다 단방향은 일대다(1:N)에서 일(1)이 연관관계의 주인

• 테이블 일대다 관계는 항상 다(N) 쪽에 외래 키가 있음

• 객체와 테이블의 차이 때문에 반대편 테이블의 외래 키를 관리하는 특이한 구조

• @JoinColumn을 꼭 사용해야 함. 그렇지 않으면 조인 테이블 방식을 사용함
  (Default가 JoinTable로 전략->중간에 테이블을 하나 추가함)

일대다 단방향 정리

• 일대다 단방향 매핑의 단점

  • 엔티티가 관리하는 외래 키가 다른 테이블에 있음

  • 연관관계 관리를 위해 추가로 UPDATE SQL 실행

• 일대다 단방향 매핑보다는 다대일 양방향 매핑을 사용하자

일대다 양방향

일대다 양방향 정리

• 이런 매핑은 공식적으로 존재X

• @JoinColumn(insertable=false, updatable=false) 읽기 전용이 된다.

• 읽기 전용 필드를 사용해서 양방향 처럼 사용하는 방법

• 다대일 양방향을 사용하자(권장)

 

일대일 관계

• 일대일 관계는 그 반대도 일대일

• 주 테이블이나 대상 테이블 중에 외래 키 선택 가능

  • 주 테이블에 외래 키

  • 대상 테이블에 외래 키

• 외래 키에 데이터베이스 유니크(UNI) 제약조건 추가

일대일: 주 테이블에 외래 키 단방향

일대일: 주 테이블에 외래 키 단방향 정리

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

일대일: 주 테이블에 외래 키 양방향

일대일: 주 테이블에 외래 키 양방향 정리

• 다대일 양방향 매핑 처럼 외래 키가 있는 곳이 연관관계의 주인

• 반대편은 mappedBy 적용

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

일대일: 대상 테이블에 외래 키 단방향 정리

• 단방향 관계는 JPA 지원X

• 양방향 관계는 지원

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

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

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

일대일 정리

• 주 테이블에 외래 키

• 주 객체가 대상 객체의 참조를 가지는 것처럼 주 테이블에 외래 키를 두고 대상 테이블을 찾음
• 객체지향 개발자 선호

• JPA 매핑 편리

• 장점: 주 테이블만 조회해도 대상 테이블에 데이터가 있는지 확인 가능
• 단점: 값이 없으면 외래 키에 null 허용

• 대상 테이블에 외래 키

• 대상 테이블에 외래 키가 존재
• 전통적인 데이터베이스 개발자 선호
• 장점: 주 테이블과 대상 테이블을 일대일에서 일대다 관계로 변경할 때 테이블 구조 유지
• 단점: 프록시 기능의 한계로 지연 로딩으로 설정해도 항상 즉시 로딩됨(프록시는 뒤에서 설명)

 

다대다 [N:M]

다대다 (실무 사용 X)

• 관계형 데이터베이스는 정규화된 테이블 2개로 다대다 관계를 표현할 수 없음
• 연결(중간) 테이블을 추가해서 일대다, 다대일 관계로 풀어내야함

다대다

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

다대다

• @ManyToMany 사용
• @JoinTable로 연결 테이블 지정
• 다대다 매핑: 단방향, 양방향 가능

다대다 매핑의 한계

• 편리해 보이지만 실무에서 사용X
• 연결 테이블이 단순히 연결만 하고 끝나지 않음
• 주문시간, 수량 같은 데이터가 들어올 수 있음

다대다 한계 극복

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

 

실전 예제 - 3. 다양한 연관관계 매핑

배송, 카테고리 추가 - 엔티티

• 주문과 배송은 1:1(@OneToOne)
• 상품과 카테고리는 N:M(@ManyToMany)

배송, 카테고리 추가 - ERD

배송, 카테고리 추가 - 엔티티 상세

N:M 관계는 1:N, N:1로

• 테이블의 N:M 관계는 중간 테이블을 이용해서 1:N, N:1
• 실전에서는 중간 테이블이 단순하지 않다.
• @ManyToMany는 제약: 필드 추가X, 엔티티 테이블 불일치
• 실전에서는 @ManyToMany 사용X

@JoinColumn

외래 키를 매핑할 때 사용

속성	설명	기본값
name	매핑할 외래 키 이름	필드명 + _ + 참조하는 테이블의 기본 키 컬럼명
referencedColumnName	외래 키가 참조하는 대상 테이블의 컬럼명	참조하는 테이블의 기본 키 컬럼명
foreignKey(DDL)	외래 키 제약조건을 직접 지정할 수 있다. 이 속성은 테이블을 생성할 때만 사용한다
unique nullable insertable updatable columnDefinition table	@Column의 속성과 같다.

@ManyToOne - 주요 속성

다대일 관계 매핑

속성	설명	기본값
optional	false로 설정하면 연관된 엔티티가 항상 있어야 한다.	TRUE
fetch	글로벌 페치 전략을 설정한다.	- @ManyToOne=FetchType.EAGER - @OneToMany=FetchType.LAZY
cascade	영속성 전이 기능을 사용한다.
targetEntity	연관된 엔티티의 타입 정보를 설정한다. 이 기능은 거의 사용하지 않는다. 컬렉션을 사용해도 제네릭으로 타입 정보를 알 수 있다.

@OneToMany - 주요 속성

일대다 관계 매핑

속성	설명	기본값
mappedBy	연관관계의 주인 필드를 선택한다.
fetch	글로벌 페치 전략을 설정한다.	- @ManyToOne=FetchType.EAGER - @OneToMany=FetchType.LAZY
cascade	영속성 전이 기능을 사용한다.
targetEntity	연관된 엔티티의 타입 정보를 설정한다. 이 기능은 거의 사용하지 않는다. 컬렉션을 사용해도 제네릭으로 타입 정보를 알 수 있다.

 

 

김영한님의 팁

1. PK는 의미 없는 값을 쓰는 게 좋다, ID(PK)라는게 종속적으로 걸리면 연결이 조금 힘들다
   -> @GeneratedValue 쓰는 걸 추천한다
   -> JPA 매핑도 심플해지고, 유연성이 증가한다
2. 다대다 쓰지말고 1대다, 다대1로 정리를 해서 쓰자!

마무리

강의를 듣다 보니 과거에 진행했던 ERP 프로젝트 경험이 떠올랐다. 내가 담당했던 채팅 기능의 DB 테이블 설계 과정에서 직원이 참석한 채팅방만을 보여주기 위해 채팅 테이블과 직원 테이블 사이에 중간 테이블을 만들었는데, 당시에는 중간 테이블에 별도의 PK를 지정하지 않고, 채팅 테이블과 직원 테이블의 PK만으로 FK를 줘서 구성했다.
이런 설계 방식은 채팅이나 직원 테이블의 PK 조건이 변경되거나 테이블 구조가 달라질 경우, 중간 테이블을 전체적으로 업데이트해야 하는 상황을 초래할 수 있었다. 프로젝트가 실제 운영되는 애플리케이션이 아니고, 테이블 수도 많지 않아 이러한 상황이 발생해도 비교적 손쉽게 대처할 수 있었겠지만, 실제로 서비스 중인 애플리케이션이라 생각한다면 상당히 막막한 상황이 벌어졌을 거라고 본다...

이처럼 초기 설계 하나하나에 신경을 써서 나중에 유지보수할 때 부담을 줄여주고, 수정이 발생했을 때도 더 적은 노력으로 대응할 수 있게끔 설계에 최대한 힘을 써야 될 거 같다.

나중에 프로젝트 설계할 기회가 온다면 중간 테이블에도 의미 없는 값 하나를 PK로 줘서 진행해보는 것도 고려해봐야겠다.

 

 

참고 문헌 : 자바 ORM 표준 JPA 프로그래밍 / 김영한