Chapter 6: 다양한 연관관계 매핑

Intro

엔티티의 연관관계를 매핑할 때 고려해야할 것

1. 다중성

   • 연관관계에는 아래와 같은 다중성이 있다

     • 다대일 (@ManyToOne)

     • 일대다 (@OneToMany )

     • 일대일 (@OneToOne )

     • 다대다 (@ManyToMany )

   • 다중성을 판단하기 어려울 때는 반대방향을 생각해보면 된다

   • 보통 다대일과 일대다 관계를 가장 많이 사용하고, 다대다 관계는 실무에서 거의 사용하지 않는다

2. 단방향 / 양방향

   • 테이블은 외래 키 하나로 조인을 사용해서 양방향으로 쿼리가 가능하므로, 사실상 방향이라는 개념이 없다

   • 반면, 객체는 참조용 필드 를 가지고 있는 객체만 연관된 객체를 조회할 수 있다

   • 객체 관계에서 한 쪽만 참조하는 것을 단방향 관계 라 하고, 양쪽이 서로 참조하는 것을 양방향 관계 라 한다

3. 연관관계의 주인

   • 데이터베이스는 외래 키 하나로 두 테이블이 연관관계를 맺는다

     • 따라서 테이블의 연관관계를 관리하는 포인트는 외래 키 하나다

   • 반면 엔티티를 양방향으로 매핑하면 A → B, B → A 2곳에서 서로를 참조한다

     • 따라서 객체의 연관관계를 관리하는 포인트는 2곳이다

   • JPA는 두 객체의 연관관계 중 하나를 정해서 데이터베이스 외래 키를 관리하는데, 이것을 연관관계의 주인 이라고 한다

     • 외래 키를 가진 테이블과 매핑한 엔티티가 외래 키를 관리하는 게 효율적이므로, 이곳을 연관관계의 주인으로 선택한다

       • 주인이 아닌 방향은 외래 키를 변경할 수 없고, 읽기만 가능하다

   • 연관관계의 주인은 mappedBy 속성을 사용하지 않는다

     • 연관관계의 주인이 아니면 mappedBy 속성을 사용하고, 연관관계의 주인 필드 이름을 갑승로 입력해야 한다

1. 다대일

• 다대일 관계의 반대 방향은 항상 일대다 관계고, 일대다 관계의 반대 방향은 항상 대다일 관계다

  • 데이터베이스 테이블의 일(1), 다(N) 관계에서 외래 키는 항상 다 쪽에 있다

  • 따라서 객체 양방향 관계에서 연관관계의 주인은 항상 다 쪽이다

    • ex) 회원(N)과 팀(1)이 있으면 회원 쪽이 연관관계의 주인!

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

  • 일대다 다대일 연관관계는 항상 다(N)에 외래 키가 있다

  • JPA는 외래 키를 관리할 때 연관관계의 주인만 사용한다

    • 주인이 아닌 쪽(ex. Team.members)은 조회를 위한 JPQL 이나 객체 그래프를 탐색할 때 사용한다

• 양방향 연관관계는 항상 서로를 참조해야 한다

  • 양방향 연관관계는 항상 서로를 참조해야 한다

    • 어느 한 쪽만 참조하면 양방향 연관관계가 성립하지 않는다

  • 항상 서로 참조하게 하려면 연관관계 편의 method 를 작성하는 것이 좋다

    • ex) 회원의 setTeam(), 팀의 addMember()

  • 편의 method는 한 곳에만 작성하거나, 양쪽 다 작성할 수 있는데, 양쪽에 다 작성하면 무한루프에 빠지므로 주의해야 한다

    • 무한루프에 빠지지 않도록 검사하는 로직도 필요하다!

2. 일대다

• 일대다 관계는 다대일 관계의 반대 방향이다

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

2-1. 일대다 단방향 [1:N]

• 하나의 팀은 여러 회원을 참조할 수 있는데 이런 관계를 일대다 관계라 한다

  • 그리고 팀은 회원들을 참조하지만, 반대로 회원은 팀을 참조하지 않으면 둘의 관계는 단 방향이다

• 일대다 관계에서 외래 키는 항상 다쪽 테이블에 있다

  • 그래서 반대편 테이블(N)의 외래키를 1 쪽에서 관리하는 모습이 나타난다

• 일대다 단방향 관계를 매핑할 때는 @JoinColumn 을 명시해야 한다

  • 그렇지 않으면 JPA는 연결 테이블을 중간에 두고, 연관관계를 관리하는 JoinTable 전략을 기본으로 사용해서 매핑한다

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

  • 일대다 단방향 매핑의 단점은 매핑한 객체가 관리하는 외래 키가 다른 테이블에 있다는 점이다

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

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

  • 일대다 단방향 매핑을 사용하면 엔티티를 매핑한 테이블이 아닌 다른 테이블의 외래 키를 관리해야 한다

    • 이것은 성능 문제 도 있지만, 관리도 부담스럽다

  • 일대다 단방향 매핑 대신 다대일 양방향 매핑을 사용하면, 다대일 양방향 매핑은 관리해야 하는 키가 본인 테이블에 있으므로 일대다 단방향 매핑같은 문제가 발생하지 않는다

    • 두 매핑의 테이블 모양은 완전히 같으므로 엔티티만 약간 수정하면 된다!

2-2. 일대다 양방향 [1:N, N:1]

• 일대다 양방향 매핑은 존재하지 않는다

  • 대신 다대일 양방향 매핑을 사용해야 한다

• 더 정확히 말하면 양방향 매핑에서 @OneToMany 는 연관관계의 주인이 될 수 없다

  • 왜냐하면 관계형 데이터베이스의 특성상 일대다, 다대일 관계는 항상 다 쪽에 외래 키가 있다

    • 따라서 @OneToMany , @ManyToOne 둘 중에 연관관계의 주인은 항상 다 쪽인 @ManyToOne 을 사용하는 곳이다!

      • 이런 이유로 @ManyToOne 에는 mappedBy 속성이 없다

• 일대다 양방향 매핑이 완전히 불가능 한 것은 아닌데, 일대다 단방향 매핑 반대편에 같은 외래키를 사용하는 다대일 단방향 매핑을 읽기 전용으로 하나 추가하면 된다

  • 이 방법은 일대다 양방향 매핑이라기 보다는, 일대다 단방향 매핑 반대편에 다대일 단방향 매핑을 읽기 전용 으로 추가해서 일대다 양방향처럼 보이도록 하는 방법이다

    • 그래서 일대다 단방향 매핑이 가지는 단점을 그대로 가진다

• 될 수 있으면 다대일 양방향 매핑을 사용하자!

3. 일대일 [1:1]

• 일대일 관계는 양쪽이 서로 하나의 관계만 가진다

• 특징

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

  • 테이블 관계에서 일대다, 다대일은 항상 다(N) 쪽이 외래 키를 가진다

    • 반면에 일대일 관계는 주 테이블이나 대상 테이블 중 어느 곳이나 외래 키를 가질 수 있다

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

    • 주 테이블이나 대상 테이블 중에 누가 외래 키를 가질지 선택해야 한다

3-1. 주 테이블에 외래 키

• 주 객체가 대상 객체를 참조하는 것처럼, 주 테이블에 외래 키를 두고 대상 테이블을 참조한다

  • 외래 키를 참조 객체 와 비슷하게 사용할 수 있어 객체지향 개발자들이 선호!

• 장점

  • 주 테이블이 외래 키를 가지고 있으므로, 주 테이블만 확인해도 대상 테이블과 연관관계까 있는지 알 수 있다

3-2. 대상 테이블에 외래 키

• 전통적인 데이터베이스 개발잗르은 대상 테이블에 외래 키를 두는 것을 선호한다

• 장점

  • 테이블 관계를 1:1에서 N:N으로 변경할 때, 테이블 구조를 그대로 유지할 수 있다

4. 다대다 [N:N]

• 관계형 데이터베이스는 정규화된 테이블 2개로 다대다 관계를 표현할 수 없다

  • 그래서 보통 다대다 관계를 일대다, 다대일 관계로 풀어내는 연결 테이블 을 사용한다

• @ManyToMany

  • @ManyToMany 를 사용하면 다대다 관계를 편리하게 매핑할 수 있다

    • @ManyToMany 를 사용하면 연결 테이블을 자동으로 처리해주므로, 도메인 모델이 단순해지고 여러 가지로 편리하다

  • but, 이 매핑을 실무에서 사용하기에는 한계가 있다

    • ex)

      • 회원이 상품을 주문하면 연결 테이블에 단순히 주문한 회원 아이디와 상품 아이디만 담고 끝아지 않는다

      • 보통은 연결 테이블에 주문 수량 컬럼이나, 주문한 날짜 같은 칼럼이 더 필요하다

      • but, 이렇게 칼럼을 추가하면 더는 @ManyToMany 를 사용할 수 없다

        • why? 주문 엔티티나 상품 엔티티에는 추가한 컬럼들을 매핑할 수 없기 때문!

      • 그래서 결국 연결 테이블을 매핑하는 연결 엔티티를 만들고, 해당 엔티티에 추가한 컬럼들을 매핑해야 한다

4-1. 다대다: 단방향

• 두 엔티티를 매핑할 때, @ManyToMany 와 @JoinTable 을 사용해서 연결 테이블 을 바로 매핑할 수 있다

• 연결 테이블을 매핑하는 @JoinTable 의 속성

  • @JoinTable.name

    • 연결 테이블을 지정한다

  • @JoinTable.joinColumns

    • 현재 방향인 엔티티와 매핑할 JOIN 컬럼 정보를 지정한다

  • @JoinTable.inverseJoinColumns

    • 반대 방향 엔티티와 매핑할 JOIN 컬럼 정보를 지정한다

4-2. 다대다: 양방향

• 다대다 매핑이므로 역방향도 @ManyToMany 를 사용한다

• 그리고 양쪽 중 원하는 곳에 mappedBy 로 연관관계의 주인 을 지정한다

  • mappedBy가 없는 곳이 연관관계의 주인!

• 양방향 연관관계는 연관관계 편의 method를 추가해서 관리하는 것이 편리하다

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

• @ManyToMany 를 사용하면 연결 테이블 을 자동으로 처리해주므로 도메인 모델이 단순해진다

• but, 이 매핑을 실무에서 사용하기에는 한계가 있다

• 복합 기본 키

  • JPA에서 복합 키를 사용하려면 별도의 식별자 클래스를 만들어야 한다

  • 그리고 엔티티에 @IdClass 를 사용해서 식별자 클래스 를 지정하면 된다

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

    • 복합 키는 별도의 식별자 클래스로 만들어야 한다

    • Serializable을 구현해야 한다

    • 기본 생성자가 있어야 한다

    • 식별자 클래스는 public 이어야 한다

    • @IdClass 를 사용하는 방법 외에 @EmbeddedId 를 사용하는 방법도 있다

• 식별 관계

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

• 복합 키를 사용하는 방법은 복잡하다

  • 단순히 컬럼 하나만 기본 키로 사용하는 것과 비교해서 복합 키를 사용하면 ORM 매핑에서 처리할 일이 상당히 많아진다

    • 복합 키를 위한 식별자 클래스도 만들어야 하고, @IdClass 또는 @EmbeddedId 도 사용해야 한다

    • 식별자 클래스에 equals, hashCode도 구현해야 한다

  • 복합 키를 사용하지 않고 간단히 다대다 관계를 구성하는 방법을 4-4에서 알아보자!

4-4. 다대다: 새로운 기본 키 사용

• 추천하는 기본 키 생성 전략은 데이터베이스에서 자동으로 생성 해주는 대리 키를 Long 값 으로 사용하는 것이다

  • 이것의 장점은 간편하고, 거의 영구히 쓸 수 있으며, 비즈니스에 의존하지 않는다

  • 그리고 ORM 매핑 시에 복합키를 만들지 않아도 되므로 간단히 매핑을 완성할 수 있다!

• 새로운 기본 키를 사용해서 다대다 관계를 풀어내면, 식별 관계에 복합 키를 사용하는 것 (4-3) 보다 매핑이 단순하고 이해하기 쉽다!

4-5. 다대다 연관관계 정리

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

  • 식별 관계

    • 받아온 식별자를 기본 키 + 외래 키로 사용한다

  • 비식별 관계

    • 받아온 식별자는 외래 키로만 사용하고, 새로운 식별자를 추가한다

• 객체 입자에서 비식별 관계를 사용하는 것이 복합 키를 위한 식별자 클래스를 만들지 않아도 되므로, 단순하고 편리하게 ORM 매핑을 할 수 있다

  • 이런 이유로 식별 관계보다는 비식별 관계를 추천한다!