자바 ORM 표준 JPA 프로그래밍 - 기본편

이 글은 김영한님의 Inflearn 강의를 학습한 내용을 정리하였습니다.
글에 포함된 그림의 출처는 자바 ORM 표준 JPA 프로그래밍 - 기본편 강의와 자바 ORM 표준 JPA 프로그래밍입니다.

목표

연관관계 매핑시 고려사항과 4가지 연관관계 매핑에 대해서 알아본다.

• 다대일 [N:1]
• 일대다 [1:N]
• 일대일 [1:1]
• 다대다 [N:M]

연관관계 매핑시 고려사항

엔티티의 연관관계를 매핑할 때는 아래 3가지를 고려해야 한다.

• 다중성
• 단방향, 양방향
• 연관관계의 주인

먼저 두 엔티티의 관계가 일대일인지 일대다인지 다중성을 고려해야 한다. 그리고 두 엔티티 중 한쪽만 참조하는 단방향 관계인지 서로 참조하는 양방향 관계인지 고려해야 한다. 마지막으로 양방향 관계면 연관관계의 주인을 정해야 한다.

다중성

연관관계는 4가지 종류가 있다.

• 다대일 (@ManyToOne)
• 일대다 (@OneToMany)
• 일대일 (@OneToOne)
• 다대다 (@ManyToMany)

실무에서 @ManyToMany을 통한 다대다 매핑은 권장하지 않는다.
@ManyToMany을 통한 다대다는 고유한 필드를 갖지 못하기 때문이다.

단방향, 양방향

테이블은 외래 키 하나로 조인을 사용해서 양방향으로 쿼리가 가능하다. 그렇기에 방향이라는 개념이 없다.
하지만 객체는 참조용 필드를 가지고 있는 객체만 연관된 객체를 조회할 수 있다. 객체 관계에서 한 쪽만 참조하는 것을 단방향 관계라 하고, 양쪽이 서로 참조하는 것을 양방향 관계라 한다.

연관관계의 주인

외래 키를 관리하는 대상을 연관관계 주인이라 한다. JPA는 양방향 관계에서 연관관계 주인을 정하는데 mappedBy 속성을 사용한다. (mappedBy를 사용하지 않으면 연관관계의 주인이고, 사용하면 연관관계의 주인이 아니다.)

외래 키를 관리는 데이터베이스에서 외래 키를 등록, 수정, 삭제할 수 있다는 의미이다.

이제 4가지 연관관계와 단방향, 양방향을 조합해 가능한 모든 연관관계를 알아보자.

• 다대일 : 단방향, 양방향
• 일대다 : 단방향, 양방향
• 일대일 : 주 테이블 단방향, 양방향
• 일대일 : 대상 테이블 단방향, 양방향
• 다대다 : 단방향, 양방향

다대일 (@ManyToOne)

데이터베이스 테이블의 일대다 관계에서 외래 키는 항상 다쪽에 있다. 따라서 객체 양방향 관계에서 연관관계의 주인은 항상 다쪽이다. 예를 들어 한 회원이 하나의 팀에 가입할 수 있고, 하나의 팀은 여러 회원을 갖을 수 있으면 회원 쪽이 연관관계의 주인이다.

다대일 단방향 (N:1)

우선 단방향 연관관계를 알아보자

Member에서 Team 호출이 가능하다. 하지만 Team에서 Member로 객체 참조가 없어 호출이 불가능하다. 따라서 회원과 팀은 다대일 단방향 연관관계이다.

@ManyToOne
@JoinColumn(name = "team_id")
private Team team;

@JoinColumn(name = "team_id")를 사용해서 Member.team 필드를 TEAM_ID 외래 키와 매핑했다. 따라서 Member.team 필드로 회원 테이블의 team_id 외래 키를 관리한다.

다대일 양방향 (N:1, 1:N)

다대일 양방향의 객체 연관관계에서 실선이 연관관계의 주인이고 점선은 연관관계의 주인이 아니다.

양방향은 외래 키가 있는 쪽이 연관관계의 주인이다. 일대다와 다대일 관계가 있다면 항상 다에 외래 키가 있다. JPA는 외래 키를 관리할 때 연관관계의 주인만 사용한다. 주인이 아닌 Team.member는 조회를 위한 JPQL이나 객체 그래프를 탐색할 때 사용한다.

양방향 연관관계는 항상 서로를 참조해야 한다. 어느 한 쪽만 참조하면 양방향 연관관계가 성립하지 않는다. 항상 서로를 참조하도록 연관관계 편의 메소드 작성을 권장한다. (예제에 Member의 joinTeam(), Team의 addMember()가 연관관계 편의 메소드이다.)

주의!
연관관계 편의 메소드는 한 곳에만 작성하거나 양쪽에 작성할 수 있다.
만약 양쪽에 작성한다면 무한루프에 빠지지 않도록 주의해야 한다.
예제는 무한루프에 빠지지 않도록 검사가하는 로직을 작성했다.

일대다 (@OneToMany)

일대다 관계는 엔티티를 하나 이상 참조할 수 있으므로 자바 컬렉션인 Collection, List, Set, Map 중에 하나를 사용해야 한다.

일대다 단방향 (1:N)

뭔가 복잡하다. (권장하지 않는 방법이다.) 뭐가 복잡한지 알아보자.

보통은 자신이 매핑한 테이블의 외래 키를 관리한다. 하지만 이 방식은 반대쪽 테이블에 있는 외래 키를 관리한다.
이런 상황은 일대다 관계에서 외래 키는 항상 다쪽 테이블에 있어서 발생한다.

일대다 단방향으로 매핑한 팀 엔티티와 회원 엔티티를 보자.

@JoinColumn 사용 이유
@JoinColumn을 사용하지 않으면 JPA는 연결 테이블을 중간에 두고 연관관계를 관리하는 조인 테이블을 통해 매핑한다. (조인 테이블을 이후에 알아보자.)

단점

이 방식은 매핑한 객체가 관리하는 외래 키가 다른 테이블에 있는 단점이 있다.

본인 테이블에 외래 키가 있으면 엔티티의 저장과 연관관계 처리를 INSERT SQL 한 번으로 끝낼 수 있지만, 다른 테이블에 외래 키가 있다면 연관관계 처리를 위한 UPDATE SQL을 추가로 실행해야 한다.

SQL 확인을 위한 코드이다.

실행 결과 수행된 SQL은 아래와 같다.

위와 같이 UPDATE 쿼리가 수행되는 이유는 Member 엔티티는 Team 엔티티를 모르기 때문이다. 그리고 연관관계에 대한 정보는 Team 엔티티의 members가 관리한다. 따라서 Member 엔티티를 저장할 때는 Member 테이블의 team_id 외래 키에 아무 값도 저장되지 않다가 Team 엔티티를 저장할 때 Team.members의 참조 값을 확인해서 회원 테이블에 있는 team_id 외래 키를 업데이트한다.

결론!
일대다 보다는 다대일을 통한 외래 키 관리 방식을 권장한다. (그렇다고 무조건 다대일로 해야되는 것은 아니다.)

일대다 양방향 (1:N, N:1)

일대다 양방향 매핑은 존재하지 않는다. 대신 다대일 양방향 매핑을 사용해야 한다.

양방향 매핑에서 @OneToMany는 연관관계의 주인이 될 수 없다.
관계형 데이터베이스의 특성상 일대다, 다대일 관계는 항상 다 쪽에 외래 키가 있다.
따라서 @OneToMany, @ManyToOne 둘 중에 연관관계의 주인은 항상 다 쪽인 @ManyToOne을 사용한 곳이다. (이런 이유로 @ManyToOne에는 mappedBy 속성이 없다.

그렇다고 일대다 양방향이 불가능한 것은 아니다. (다대일 단방향 매핑을 읽기 전용으로 설정하면 된다.)
예제를 통해 알아보자.

(복잡하다...)

Member 엔티티는 @ManyToOne으로 Team 엔티티를 참조한다.
@ManyToOne은 외래 키를 관리하는 연관관계의 주인이 되므로 양쪽에서 키를 관리하면 문제가 발생할 수 있다. (mappedBy 속성을 추가할 수 없다.) 따라서 insertable = false, updatable = false로 설정해서 읽기만 가능하게 한다.

일대일 (@OneToOne)

일대일 관계는 양쪽이 서로 하나의 관계만 가진다. 따라서 일대일 관계는 그 반대도 일대일 관계다.
그리고 외래 키는 주 테이블이나 대상 테이블 둘 중 어느 곳이나 외래 키를 가질 수 있다. (다대일은 항상 다쪽이 외래 키를 갖는다.)

외래 키의 위치는 아래 2가지 경우로 나뉜다.

• 주 테이블에 외래 키
• 대상 테이블에 외래 키

이번 예제는 Member가 하나의 Locker를 갖고, Locker도 하나의 Member를 갖는다.

주 테이블에 외래 키

주 객체가 대상 객체를 참조하는 거처럼 주 테이블에 외래 키를 두고 대상 테이블을 참조한다. 이 방법의 장점은 주 테이블이 외래 키를 가지고 있으므로 주 테이블만 확인해도 대상 테이블과 연관관계가 있는지 알 수 있다.

단방향 (1:1)

연관관계 그림과 이를 구현한 코드는 아래와 같다.

양방향 (1:1)

대상 테이블에 반대 방향을 추가하면 된다.

Member 코드는 단방향 때 사용한 코드와 같다. Locker 코드는 Member 참조를 추가해준다. (물론 연관관계 주인이 아니라는 mappedBy 속성 추가도 잊지말자.)

대상 테이블에 외래 키

이 방법의 장점은 테이블 관계를 일대일에서 일대다로 변경할 때 테이블 구조를 그대로 유지할 수 있다.

JPA에서 일대일 관계 중 대상 테이블에 외래 키가 있는 단방향은 지원하지 않는다.

따라서 아래와 같은 일대일 양방향으로 사용해야한다.

다대다 (N:M)

관계형 데이터베이스는 정규화된 테이블 2개로 다대다 관계를 표현할 수 없다. 그래서 보통 다대다 관계를 일대다, 다대일 관계로 풀어내는 연결 테이블을 사용한다.

데이터베이스와 달리 객체는 연결 객체 없이 다대다 관계를 만들 수 있다. 예를 들어 회원 객체는 컬렉션을 사용해서 상품들을 참조하면 되고 반대로 상품들도 컬렉션을 사용해서 회원들을 참조하면 된다.

단방향

우선 다대다 단방향 관계인 회원과 상품 예제를 보자.

회원 엔티티와 상품 엔티티를 @ManyToMany로 매핑했다. 여기서 중요한 점은 @ManyToMany와 @JoinTable을 사용해서 연결 테이블을 바로 매핑한 것이다. (따라서 회원_상품 엔티티 없이 다대다 매핑이 가능하다.)

@JoinTable 속성 정리

• name : 연결 테이블을 지정한다.
• joinColumns : 현재 방향인 회원과 매핑할 조인 컬럼 정보를 지정한다.
• inversionJoinColumns : 반대 방향인 상품과 매핑할 조인 컬럼 정보를 지정한다.

member_product 테이블
이 테이블은 다대다 관계를 일대다, 다대일 관계로 풀어내기 위해 필요한 연결 테이블일 뿐이다. @ManyToMany로 매핑한 덕분에 다대다 관계를 사용할 때는 이 연결 테이블을 따로 생성하지 않아도 된다.

양방향

다대다 매핑은 역방향도 @ManyToMany를 사용한다. 그리고 어느 한 쪽에 mappedBy로 연관관계의 주인을 지정한다.

이 예제에서는 회원(Member) 엔티티가 연관관계의 주인이고, 상품(Product) 엔티티에 mappedBy 속성을 추가했다.

다대다 연결 엔티티 사용

@ManyToMany를 사용하면 연결 테이블을 자동으로 처리해주므로 도메인 모델이 단순해지고 여러 가지로 편리하다. 하지만 이 어노테이션을 이용한 다대다 처리 방식은 한계가 있다. 아래의 ERD를 보면서 알아보자.

@ManyToMany를 이용한 방식은 연결 테이블에 칼럼을 추가할 방법이 없다. 따라서 주문 수량(orderAmount)과 주문일자(orderDate)를 추가하지 못한다.

연결 테이블에 칼럼 추가가 필요한 경우 연결 테이블 엔티티를 만들고 일대다, 다대일 관계로 풀어야한다. 아래에 ERD와 객체 관계를 그림으로 표현했다.

이를 코드로 작성해보자.

회원코드

상품코드

회원상품 엔티티 코드

회원상품 식별자 클래스

복합 기본 키 사용 (@IdClass)

회원상품(MemberProduct) 엔티티를 보면 기본 키를 매핑하는 @Id와 외래 키를 매핑하는 @JoinColumn을 동시에 사용해서 기본 키 + 외래 키를 한번에 매핑했다. 그리고 @IdClass를 사용해서 복합 기본 키를 매핑했다.

복합 기본 키

JPA에서 복합 키를 사용하려면 별도의 식별자 클래스를 만들어야 한다. 그리고 엔티티에 @IdClass를 사용해서 식별자 클래스를 지정하면 된다.
복합 키를 위한 식별자 클래스는 다음과 같은 특징이 있다.

• 복합 키는 별도의 식별자 클래스로 만들어야 한다.
• Serializable을 구현해야 한다.
• equals와 hashCode 메소드를 구현해야 한다.
• 기본 생성자가 있어야 한다.
• 식별자 클래스는 public이어야 한다.
• 방법은 @IdClass 또는 @EmbeddedId가 있다.

식별 관계
부모 테이블의 기본 키를 자신의 기본 키 + 외래 키로 사용하는 것을 데이터베이스 용어로 식별 관계(Identifying Relationship)라 한다.

대리 키 사용

연결 테이블의 기본 키는 데이터베이스에서 자동으로 생성해주는 대리 키 방식 사용을 권장한다. 대리 키 방식의 이점은 아래와 같다.

• 비즈니스에 의존하지 않으므로 거의 영구히 사용할 수 있다.
• ORM 매핑 시에 복합 키를 만들지 않아도 되므로 간단히 매핑을 완성할 수 있다.

대리 키 방식을 적용한 주문 코드는 아래와 같다.

복합 키 방식과 달리 @IdClass 또는 @EmbeddedId 클래스를 생성하고 적용하는 수고가 줄었다.

정리

이번에는 다대일, 일대다, 일대일, 다대다 연관관계를 단방향, 양방향으로 매핑하는 방법에 대해 알아보았다. 다대다의 경우 일대다, 다대일 관계로 풀어보았다.(다대다의 경우 @ManyToMany 방식보단 @OneToMany, @ManyToOne 방식을 권장한다.)