> For the complete documentation index, see [llms.txt](https://chloe-codes1.gitbook.io/book-reviews/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://chloe-codes1.gitbook.io/book-reviews/java-orm-standard-jpa-programming/06_-_-_.md). # 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 매핑을 할 수 있다 * 이런 이유로 식별 관계보다는 비식별 관계를 추천한다!