Jpa기본 06. 다양한 연관관계 매핑(인프런 + 자바 ORM 표준 JPA 프로그래밍)

포스팅 개요

1. 포스팅 개요
2. 본론
       2-1. 다대일
       2-2. 일대다
       2-3. 일대일(1:1)
       2-4. 다대다(N:N)
3. 요약

1. 포스팅 개요

해당 포스팅은 인프런에서 영한님의 JPA기본 강의에서 다양한 연관관계 매핑 파트와 해당 파트에 맞는 책의 챕터를 보고 학습한 내용을 요약 및 정리하는 포스팅입니다.

강의에서는 없는 내용이 있고, 개인적으로 저를 위한 포스팅이니 참고 바랍니다..ㅎㅎ
또한 이전에 있었던 내용과 본문에서 중첩되는 부분은 간단하게 언급만 하고 넘어가는 점도 참고 바라겠습니다.

그리고, 외래 키의 위치는 다중성의 관계에서 왼쪽에 해당하는 부분에 있다고 생각하고 보시면 됩니다.

예를 들어,
일대다 관계라면, 일에 해당하는 곳에 외래 키가 있습니다.
다대일 관계라면, 다에 해당하는 곳에 외래 키가 있습니다.

다대다, 일대일은 알아서 부탁합니다...

그리고 제가 JPA를 처음 학습할 때 굉장히 헷갈렸던 부분이 있었는데, 이번에 단번에 이해했습니다. 여기를 누르시면 확인할 수 있습니다.

2. 본론

이전 내용을 잠시 정리해보겠습니다!
엔티티의 연관관계를 매핑할 때는 고려할 3가지가 있습니다.

• 다중성
  • 먼저 연관관계가 있는 두 엔티티가 일대일 관계인지 일대다 관계인지 다중성을 고려해야 합니다.
  • ex) 다대일, 일대다, 일대일, 다대다
• 단방향, 양방향
  • 두 엔티티 중 한쪽만 참조하는 단방향 관계인지, 서로 참조하는 양방향 관계인지 고려해야 합니다.
  • 테이블은 외래 키 하나로 조인을 사용하여 이미 양방향으로 쿼리가 가능하기때문에 방향이라는 개념이 없습니다.
  • 객체는 참조용 필드를 가지고 있는 객체만 연관된 객체를 조회할 수 있습니다.
• 연관관계의 주인
  • 양방향 관계라면 연관관계의 주인을 정해야 합니다.
  • 데이터베이스는 외래 키 하나로 두 테이블이 연관관계를 맺습니다. 때문에, 테이블의 연관관계를 관리하는 포인트는 외래 키 하나입니다.
  • 객체에서는 엔티티를 양방향으로 매핑하면 서로를 참조합니다.
    때문에, 객체의 연관관계를 관리하는 포인트는 2곳입니다.
    • JPA는 두 객체 연관관계 중 하나를 정해서 데이터베이스 외래 키를 관리하는데, 이를 연관관계의 주인이라고 합니다.
    • 외래 키를 가진 테이블과 매핑한 엔티티가 외래 키를 관리하는 게 효율적이므로 보통 매핑된 엔티티를 연관관계의 주인으로 선택합니다.
      • 참고로 주인이 아닌 방향은 외래 키를 변경할 수 없고 읽기만 가능합니다.

JPA를 처음 공부하면서 헷갈렸던 부분 저는 JPA를 처음공부할 때 다중성을 생각할 때 헷갈렸던 부분이

예를들어서 커피와 주문의 관계를 생각할 때,

하나의 커피는 하나의 주문에 들어갈 수 있습니다.
하나의 주문에는 여러개의 커피가 들어갈 수 있습니다.
커피-주문관계는 일대다 관계인 것이 너무 명확합니다.

이렇게 생각해야했는데, 이런 방법과 또 알려드릴 예가 있는데, 해당 예시 중 어느 것이 맞는지 굉장히 헷갈렸습니다.

커피자체는 여러 개가 주문에 들어갈 수 있습니다.
주문자체는 여러 개의 주문에 커피가 들어올 수 있습니다.
즉, 여러 개의 커피가 여러 개의 주문에 들어갈 수 있습니다.
이렇게 자체를 생각하면, 다대다 관계입니다.

혹시나 헷갈리시는 분이 있다면, 하나의 인스턴스를 기준으로 생각해보시면 될 거 같습니다.
당연한 예시니깐 들어보겠습니다.
한 사람이 하나의 가족에만 해당될 수 있습니다.
(독립해서 결혼을 했네마네, 뭐 가정을 이뤘네마네는 제외하고, 일반적으로 생각합시다..)
그리고, 하나의 가족에는 여러 사람이 해당될 수 있습니다.
따라서 사람과 가족 관계는 다대일입니다.

그런데 사람 자체와 가족 자체를 생각하면, 또 다대다 같은 느낌이겠죠..?
이렇게 클래스를 통해서 생성되는 인스턴스 하나만 생각하면, 편할 거 같습니다.
이번에 완전히 이해되서 한 번 끄적여봅니다.ㅎㅎㅎ

2-1. 다대일

다대일 관계의 반대 방향은 항상 일대다 관계이고, 일대다 관계의 반대 방향은 항상 다대일 관계입니다.

객체 양방향 관계에서 연관관계의 주인은 항상 다쪽입니다!

양방향은 외래 키가 있는 쪽이 연관관계의 주인입니다.

일대다와 다대일 연관관계는 항상 다(N)에 외래 키가 있습니다.
JPA는 외래 키를 관리할 때 연관관계의 주인만 사용합니다.
주인이 아닌 곳에는 조회를 위한 JPQL이나 객체 그래프를 탐색할 때 사용합니다.

양방향 연관관계는 항상 서로를 참조해야 합니다.

양방향 연관관계는 항상 서로 참조해야 합니다.
어느 한 쪽만 참조하면 양방향 연관관계가 성립하지 않습니다.
항상 서로 참조하게 하려면 연관관계 편의 메서드를 작성하는 것이 좋습니다.

2-2. 일대다

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

2-2-1. 일대다 단방향(1:N)

예를 들어, 하나의 팀은 여러 회원을 참조할 수 있는데 이런 관계를 일대다 관계라고 합니다.
(일대다 단방향 관계는 JPA 2.0부터 지원합니다.)

일대다 단방향 관계를 매핑할 때는 @JoinColumn을 반드시 명시해야 합니다.
그렇지 않으면 JPA는 연결 테이블을 중간에 두고, 연관관계를 관리하는 조인 테이블 전략을 기본으로 사용해서 매핑합니다.

무슨 얘기인지 한번 보겠습니다.

위의 그림은 일대다 단방향 관계입니다.
일이 팀이고, 다가 회원인데,
보통은 다가 회원이기 때문에, 회원에 외래 키가 있고, Member 클래스에 외래 키와 조인 되는 필드가 있어야 하는데, 반대편인 팀에 @JoinColumn을 선언한 상태라고 생각하시면 되겠습니다.
그런데 @JoinColumn을 누락시키면 어떻게 되는지 한 번 살펴보겠습니다.

위는 패키지 구조입니다.
원래는 정상적으로 회원-팀이 다대일 관계라면, 아래처럼 될 것 입니다.

회원 클래스의 팀에 해당하는 필드입니다.

팀 클래스의 회원에 해당하는 필드입니다.

그리고, Main메서드를 실행시켜서 생성되는 SQL의 Member와 Team 테이블의 create 문을 보면 다음과 같습니다.

이렇게 되면 정상입니다만,
이제 위의 관계 매핑 그림처럼 회원과 팀을 매핑해보고 @JoinColumn도 누락 시켜보겠습니다.

일단 Member에선 Team team 필드를 삭제하고,
Team에서는 아래처럼 선언했습니다.

그리고, 생성되는 create 문을 보시면 다음과 같습니다.

이번엔 @JoinColumn을 누락시켜보겠습니다.

그리고, 생성되는 테이블에 연결테이블 Team_Member 이 생성되는 것을 볼 수 있습니다.

일대다 단방향 매핑의 단점

일대다 단방향 매핑의 단점은 매핑한 객체가 관리하는 외래 키가 다른 테이블에 있다는 점입니다.
본인 테이블에 외래 키가 있으면 엔티티의 저장과 연관관계 처리를 INSERT SQL 한 번으로 끝낼 수 있지만,
다른 테이블에 외래 키가 있으면 연관관계 처리를 위한 UPDATE SQL을 추가로 실행해야 합니다.
한 번으로 끝낼 수 있는 것을 두 번 처리를 해야하는 것이 단점입니다.

일대다 단방향 매핑보다는 다대일 양방향 매핑을 사용합시다.

일대다 단방향 매핑을 사용하면 엔티티를 매핑한 테이블이 아닌 다른 테이블의 외래 키를 관리해야 합니다.
이는 성능 문제도 있지만, 관리도 부담스럽습니다. 딱 봐도...
이전 내용에서 본거 같지만 객체에선 Team을 업데이트 했는데, Member 테이블에 update 쿼리문이 나가는... 불편한 상황이 야기될 수 있습니다.
따라서 일대다 단방향 매핑 대신에 다대일 양방향 매핑을 사용하여 외래 키를 보다 쉽게 관리하는 방식을 택하는 것을 권장하고 있습니다.

2-2-2. 일대다 양방향

사실 일대다 양방향 매핑은 존재하지 않습니다.
대신 다대일 양방향 매핑을 사용해야 합니다.
더 정확히 말해서 양방향 매핑에서 @OneToMany는 연관관계의 주인이 될 수 없습니다.
왜냐하면, 관계형 데이터베이스의 특성상 일대다, 다대일 관계는 항상 다 쪽에 외래 키가 있습니다.
고로, @OneToMany, @ManyToOne 둘 중에 연관관계의 주인은 항상 다 쪽인 @ManyToOne을 사용한 곳입니다.
그래서 @ManyToOne에는 mappedBy 속성이 없습니다.

그렇다고 하여 일대다 양방향 매핑이 완전히 불가능한 것은 아닙니다.
일대다 단방향 매핑 반대편에 외래 키를 사용하는 다대일 단방향 매핑을 읽기 전용으로 하나 추가하면 됩니다.

Member클래스에 다음과 같은 필드를 추가하면 되는데,,

@ManyToOne
@JoinColumn(name = "TEAM_ID", insertable = false, updatable = false)
private Team team;

insertable 옵션은 생성을 허용하는지에 대한 옵션,
updatable 옵션은 업데이트를 허용하는지에 대한 옵션입니다.

이처럼 일대다 단방향 매핑 반대편에 다대일 단방향 매핑을 추가했습니다.
이 때 일대다 단방향 매핑과 같은 TEAM_ID 외래 키 컬럼을 매핑했습니다.
insertable, updatable 옵션에 둘 다 false를 주어서 읽기 전용으로 매핑하였는데,
이는 일대다 양방향처럼 보이도록 하는 방법입니다.
그리고 이는 일대다 단방향 매핑이 가지는 단점을 그대로 가집니다.
그냥 다대일 양방향 매핑을 사용할 것을 권장합니다.

2-3. 일대일(1:1)

일대일 관계는 양쪽이 서로 하나의 관계만 가집니다.

다음은 일대일 관계의 특징입니다.

• 일대일 관계는 그 반대도 일대일 관계입니다.
• 테이블 관계에서 일대다, 다대일은 항상 다(N) 쪽이 외래 키를 가지는 반면에 일대일 관계는 주 테이블이나 대상 테이블 둘 중 어느 곳이나 외래 키를 가질 수 있습니다.

테이블은 주 테이블이든 대상 테이블이든 외래 키 하나만 있으면 양쪽으로 조회할 수 있습니다.

위에서도 말했다시피 일대일 관계는 그 반대쪽도 일대일 관계입니다. 그렇기 때문에, 일대일 관계는 주 테이블이나 대상 테이블 중에 누가 외래 키를 가질지 선택해야 합니다.

주 테이블에 외래 키를 두는 방식

주 객체가 대상 객체를 참조하는 것처럼 주 테이블에 외래 키를 두고 대상 테이블을 참조합니다.
이 방식은 외래 키를 객체 참조와 비슷하게 사용할 수 있어서 객체지향 개발자들이 선호합니다.
이 방법의 장점은 주 테이블이 외래 키를 가지고 있으므로 주 테이블만 확인해도 대상 테이블과 연관관계가 있는지 알 수 있습니다.
JPA도 주 테이블에 외래 키가 있으면 좀 더 편리하게 매핑할 수 있습니다.

대상 테이블에 외래 키를 두는 방식

전통적인 데이터베이스 개발자들은 보통 대상 테이블에 외래 키를 두는 것을 선호합니다.
이 방법의 장점은 테이블 관계를 일대일에서 일대다로 변경할 때 테이블 구조를 그대로 유지할 수 있습니다.

일대일 관계 중 대상 테이블에 외래 키가 있는 단방향 관계는 JPA에서 지원하지 않습니다. 그리고 다음 모양으로 매핑할 수 있는 방법도 없습니다.
(매핑 그림인데, ㄹㅇ 병맛입니다. 테이블 두개도 이런데, 세 개, 네 개, 다섯 개되면,, 참사일듯 싶습니다.)

참고로 JPA 2.0부터 일대다 단방향 관계에서 대상 테이블에 외래 키가 있는 매핑을 허용했습니다.
하지만, 일대일 단방향은 이런 매핑을 허용하지 않습니다.

만약 일대일 매핑에서 대상 테이블에 외래 키를 두고 싶으면 양방향으로 매핑하면 됩니다.

이 두 방식을 강의에서 얘기하시면서 하신 말씀이..
"잘 하면 DBA와 싸워야 한다."고 하셨습니다. ㅋㅋ 좀 웃기더군요.. 각설하겠습니다..

2-4. 다대다(N:M)

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

위의 그림처럼 중간에 연결테이블을 추가해야 합니다.
그림을 보면, Member_Product 연결 테이블을 추가했음을 볼 수 있습니다.
이 테이블을 사용해서 다대다 관계를 일대다, 다대일 관계로 풀어낼 수 있습니다.

참고로 이 연결 테이블은 회원이 주문한 상품을 나타냅니다.

그러나, 객체는 테이블과 다르게 객체 2개로 다대다 관계를 만들 수 있습니다.

다대다 관계에서 연결테이블을 매핑하는 애너테이션 @JoinTable의 속성을 정리해보면 다음과 같습니다.

• name : 연결 테이블을 지정합니다.
• joinColumns : 현재 방향인 회원과 매핑할 조인 컬럼 정보를 지정합니다.
• inverseJoinColumns : 반대 방향의 필드와 매핑할 조인 컬럼 정보를 지정합니다.

다대다 : 매핑의 한계와 극복, 연결 엔티티 사용

@ManyToMany를 사용하면 연결 테이블을 자동으로 처리해주므로 도메인 모델이 단순해지고 여러가지로 편리합니다.
하지만!
이 매핑을 실무에서 사용하기에는 한계가 있습니다.
(라고 설명되어있지만, 강의에서는 써본 적이 없다고 하셨고, 그냥 쓰지 않는다고 하셨습니다. 단점이 너무 명확하다고 하시면서 말이죠..)

그리고, 보통 연결테이블의 컬럼(필드)이 위의 관계 그림처럼 아이디들만 담고 끝나는 것이 아니라, 보통은 다른 컬럼(필드)들이 더 필요합니다.

이렇게 아이디 외에 컬럼이 더 추가되면 더이상 @ManyToMany를 사용할 수 없습니다.
왜냐하면 왼쪽의 주문 엔티티나 상품 엔티티에는 추가한 컬럼들을 매핑할 수 없기 때문입니다.
(연결 테이블과 매핑되는 클래스가 따로 있어야 하지만, @ManyToMany는 두 개의 클래스로 끝장을 보게되기 때문에 이렇게 기술하신 거 같습니다.)

다음 그림처럼 연결 테이블을 매핑하는 연결 엔티티를 만들고 이곳에 추가한 컬럼들을 매핑해야 합니다.
그리고 엔티티 간의 관계도 테이블 관계처럼 다대다에서 일대다, 다대일 관계로 풀어야 합니다.

2-4-1. 다대다의 식별자 클래스

다음 내용은 강의에서 다루지 않습니다.
책에서 소개되어있기 때문에, 다룹니다.

@IdClass 애너테이션이 붙은 연결테이블입니다.

@Entity
@IdClass(MemberProductId.class)
public class MemberProduct {

    @Id
    @ManyToOne
    @JoinColumn(name = "MEMBER_ID")
    private Member member; // MemberProductId.member와 연결

    @Id
    @ManyToOne
    @JoinColumn(name = "PRODUCT_ID")
    private Product product; // MemberProductId.product와 연결
}

public class MemberProductId implements Serializable {

    private String member;  // MemberProduct.member와 연결
    private String product; // MemberProduct.product와 연결

}

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

그리고 @IdClass를 사용해서 복합 기본 키를 매핑했습니다.

복합 기본 키

회원 상품 엔티티는 기본 키가 MEMBER_ID와 PRODUCT_ID로 이루어진 복합 기본 키(이하 복합 키)입니다.
JPA에서 복합 키를 사용하려면 별도의 식별자 클래스를 만들어야 합니다.
그리고 엔티티에 @IdClass를 사용해서 식별자 클래스를 지정하면 됩니다.

위의 코드에서는 MemberProductId 클래스를 복합 키를 위한 식별자 클래스로 사용합니다.

복합 키를 위한 식별자 클래스의 특징

• 복합 키는 별도의 식별자 클래스로 만들어야 합니다.
• Serializable을 구현해야 합니다.
• equlas와 hashCode 메서드를 구현해야 합니다.
• 기본 생성자가 있어야 합니다.
• 식별자 클래스는 public 이어야 합니다.
• @IdClass를 사용하는 방법 외에 @EmbeddedId를 사용하는 방법도 있습니다.

※식별 관계
위의 클래스들처럼 회원상품은 회원과 상품의 기본 키를 받아서 자신의 기본 키로 사용합니다.
부모 테이블의 기본 키를 받아서 자신의 기본 키 + 외래 키로 사용하는 것을 데이터베이스 용어로 식별 관계(identifying Relationship)라 합니다.

※참고로 복합 키와 식별 관계, @IdClass의 내용은 이후에 또 다룹니다.

다음 관계를 어떻게 저장하는지 봅시다.

public void save() {

    // 회원 저장
    Member member1 = new Member();
    member1.setId("member1");
    member1.setUsername("회원1");
    em.persist(member1);

    // 상품 저장
    Product productA = new Product();
    productA.setId("productA");
    productA.setName("상품1");
    em.persist(productA);

    // 회원상품 저장
    MemberProduct memberProduct = new MemberProduct();
    memberProduct.setMember(member1);   // 주문 회원 - 연관관계 설정
    memberProduct.setProduct(productA); // 주문 상품 - 연관관계 설정
    memberProduct.set...(..);

    em.persist(memberProduct);

}

회원상품 엔티티를 만들면서 연관된 회원 엔티티와 상품 엔티티를 설정했습니다.
회원상품 엔티티는 데이터베이스에 저장될 때 연관된 회원의 식별자와 상품의 식별자를 가져와서 자신의 기본 키 값으로 사용합니다.

이번엔 조회입니다.

public void find() {

    // 기본 키 값 생성
    MemberProductId memberProductId = new MemberProductId();
    memberProductId.setMember("member1");
    memberProductId.setProduct("productA");

    ///
    MemberProduct memberProduct = em.find(MemberProduct.class, memberProductId);
    ///

    Member member = memberProduct.getMember();
    Product product = memberProduct.getProduct();

    System.out.println("member = " + member.getUsername());
    System.out.println("product = " + product.getName());
    System.out.println("orderAmount = " + memberProduct.getOrderAmount());

}

기본 키가 단순해서 기본 키를 위한 객체를 사용하는 일이 없었지만, 복합 키가 되면 이야기가 달라진다고 하시네요.. ㅎㅎ;;
복합 키는 항상 식별자 클래스를 만들어야 합니다.
em.find()를 보면 생성한 식별자 클래스로 엔티티를 조회합니다.

복합 키를 사용하는 방법은 복잡합니다.
단순히 컬럼 하나만 기본 키로 사용하는 것과 비교해서 복합 키를 사용하면 ORM 매핑에서 처리해야 할 일이 상당히 많아집니다..

복합 키를 위한 식별자 클래스도 만들어야 하고요.
@IdClass 또는 @EmbeddedId도 사용해야 합니다.
식별자 클래스에 equals, hashCode도 구현해야 합니다.

---

여기까진 책에 소개되어 있어서 적어봤습니다..
책보다가 처음 알았습니다만, 이제 강의에서도 풀어주시는 부분 보도록 하겠습니다.

---

복합 키를 사용하지 않고, 간단히 다대다 관계를 구성하는 방법입니다.

추천하는 기본 키 생성 전략은 데이터베이스에서 자동으로 생성해주는 대리 키를 Long 값으로 사용하는 것입니다.
이에 대한 장점은 다음과 같습니다.

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

위와 같은 그림에서 ORDER 테이블에 매핑되는 클래스를 작성해보겠습니다.

@Entity
public class Order {

    @Id @GenerateValue
    @Column(name = "ORDER_ID")
    private Long id;

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

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

}

이와 같이 대리 키를 사용함으로써 이전에 보았던 식별 관계에 복합 키를 사용하는 것보다 매핑이 단순하고 이해하기 쉽습니다.

저장은 위의 내용과 비슷하지만,
조회는 간결해졌습니다.

public void find() {

    Long orderId = 1L;
    Order order = em.find(Order.class, orderId);

    Member member = order.getMember();
    Product product = order.getProduct();

    System.out.println("member = " + member.getUsername());
    System.out.println("product = " + product.getName());
    System.out.println("orderAmount = " + order.getOrderAmount());
}

식별자 클래스를 사용하지 않아서 코드가 한결 단순해졌네요^^
이처럼 새로운 기본 키를 사용해서 다대다 관계를 풀어내는 것도 좋은 방법입니다!

다대다 연관관계 정리

다대다 관계를 일대다 다대일 관계로 풀어내기 위해 연결 테이블을 만들 때 식별자를 어떻게 구성할지 선택해야 합니다.

• 식별 관계 : 부모테이블로부터 받아온 식별자를 기본 키 + 외래 키로 사용합니다.
• 비식별 관계 : 부모테이블로부터 받아온 식별자는 외래 키로만 사용하고 새로운 식별자를 추가합니다.

살펴본 것처럼 비식별 관계를 사용하는 것이 복합 키를 위한 식별자 클래스를 만들지 않아도 되기때문에 단순하고 편리하게 ORM 매핑을 할 수 있습니다.

다대다 관계를 정리하자면,
다대다 관계는 연결 테이블을 JPA가 알아서 처리해주므로 편리하지만, 연결 테이블에 필드가 추가되면 더는 사용할 수 없습니다.
따라서 실무에서 활용하기에는 무리가 있습니다.
연결 테이블을 만들어서 일대다, 다대일 관계로 매핑하는 것을 권장합니다.

3. 요약

일대다, 다대일, 일대일, 다대다 관계에 대하여 각각의 상황과 문제점을 살펴보면서 어떻게 풀어나가야 할지를 살펴보았고,

책에서 나오지 않은 @IdClass와 같은 애너테이션을 사용해서 복합 키를 사용하는 방법, 그리고 제가 JPA를 처음 공부하면서 헷갈렸던 부분을 어떻게 풀어나가야할지를 기록해봤습니다.

끝이지만, 추신하자면, 회사다니면서 하느라,
살짝 더디지만, 그래도 저는 끝까지 갈 겁니다.^^

그럼 JPA는 다음 챕터주제로 오겠습니다!