Chap.6 다양한 연관관계 매핑

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

- 다중성: @ManyToOne, @OneToMany, @OneToOne, @ManyToMany

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

- 연관관계의 주인: JPA는 두 객체 연관관계 중 하나를 정해서 데이터베이스 외래 키를 관리하는데 이것을 연관관계의 주인이라 한다. 외래 키를 가진 테이블과 매핑한 엔티티가 외래키를 관리하는 게 효율적이므로 보통 이곳을 연관관계의 주인으로 선택한다. 주인이 아닌 방향은 외래 키를 변경할 수 없고 읽기만 가능하다. 연관관계의 주인이 아니면 mappedBy 속성을 사용하고 연관관계의 주인 필드 이름을 값으로 입력해야 한다.

 

다대일

- 객체 양방향 관계에서 연관관계의 주인은 항상 다쪽이다.

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

: 회원은 Member.team으로 팀 엔티티를 참조할 수 있지만 반대로 팀에는 회원을 참조하는 필드가 없다. 따라서 회원과 팀은 단방향 연관관계다. Member.team 필드로 회원 테이블의 TEAM_ID 외래 키를 관리한다.

@ManyToOne

@JoinColumn(name = "TEAM_ID)

pirvate Team team;

- 다대일 양항뱡 [N:1, 1:N]

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

: 양방향 연관관계는 항상 서로를 참조해야 한다. 항상 서로 참조하게 하려면 연관관계 편의 메소드를 작성하는 것이 좋은데 회원의 setTeam(), 팀의 addMmeber() 메소드가 이런 편의 메소드들이다. 편의 메소드는 한 곳에만 작성하거나 양쪽 다 작성할 수 있는데, 양쪽에 다 작성하면 무한루프에 빠지므로 주의해야한다. 예제 코드는 편의 메소드를 양쪽에 다 작성해서 둘 중 하나만 호출하면 된다. 또한 무한루프에 빠지지 않도록 검사하는 로직도 있다.

@Entity
public class Member {
 ....
 
 public void setTeam(Team team) {
  this.team = team;
  
   // 무한루프에 빠지지 않도록 체크
   if(!team.getMembers().contains(this)) {
  	 team.getMembers().add(this);
   }
}


@Entity
public class Team {
 ....
 
 public void addMember(Member member) {
  this.members.add(member);
  
   // 무한루프에 빠지지 않도록 체크
   if(member.getTeam() != this) {
  	 member.setTeam(this);
   }
}

 

일대다

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

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

: 하나의 팀은 여러 회원을 참조할 수 있는데 이런 관계를 일대다 관계라 한다. 그리고 팀은 회원들은 참조하지만 반대로 회원은 팀을 참조하지 않으면 둘의 관계는 단방향이다.

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

@Entity
public class Team {
 ....
 
@OneToMany
@JoinColumn(name = "TEAM_ID") // MEMBER 테이블의 TEAM_ID (FK)
private List<Member> members = new ArrayList<Member>();
}

: 단점

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

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

일대다 단방향 매핑을 사용하면 엔티티를 매핑한 테이블이 아닌 다른 테이블의 외래 키를 관리해야 한다. 이것은 성능 문제도 있지만 관리도 부담스럽다. 문제를 해결하는 좋은 방법은 일대다 단방향 매핑 대신에 다대일 양방향 매핑을 사용하는 것이다. 다대일 양방향 매핑은 관리해야 하는 외래 키가 본인 테이블에 있다.

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

: 일대다 단방향 매핑 반대편에 같은 외래 키를 사용하는 다대일 단방향 배핑을 읽기 전용으로 하나 추가하면 된다.

: 둘 다 같은 키를 관리하므로 문제가 발생할 수 있다. 따라서 반대편인 다대일 쪽은 insertable = false, updatable = false 로 설정해서 읽기만 가능하게 했다.

: 이 방법은 일대다 양방향 매핑이라기보다는 일대다 단방향 매핑 반대편에 대다일 단방향 매핑을 읽기 전용으로 추가해서 일대다 양방향처럼 보이도록 하는 방법이다. 따라서 일대다 단방향 매핑이 가지는 단점을 그대로 가진다. 될 수 있으면 다대일 양방향 매핑을 사용하자.

@Entity
public class Team {
 ....
 
@OneToMany
@JoinColumn(name = "TEAM_ID") // MEMBER 테이블의 TEAM_ID (FK)
private List<Member> members = new ArrayList<Member>();
}

@Entity
public class Member {
 ....
 
@ManyToOne
@JoinColumn(name = "TEAM_ID", insertable = false, updatable = false)
private Team team;

}

 

일대일 [1:1]

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

- 일대일 관계는 그 반대도 일대일 관계다.

- 테이블 관계에서 일대다, 다대일은 항상 다(N)쪽이 외래 키를 가진다. 반면에 일대일 관계는 주 테이블이나 대상 테이블 둘 중 어느 곳이나 외래 키를 가질 수 있다. 따라서 일대일 관계는 주 테이블이나 대상 테이블 중에 누가 외래 키를 가질지 선택해야 한다.

- 주 테이블에 외래 키: 주 객체가 대상 객체를 참조하는 것처럼 주 테이블에 외래 키를 두고 대상 테이블을 참조한다. 외래 키를 객체 참조와 비슷하게 사용할 수 있어서 객체지향 개발자들이 선호한다. 장점은 주 테이블이 외래 키를 가지고 있으므로 주 테이블만 확인해도 대상 테이블과 연관관계가 있는지 알 수 있다.

: 단방향

@OneToOne 사용, 데이터베이스에는 LOCKER_ID 외래 키에 유니크 제약 조건(UNI)을 추가했다. 이 관계는 다대일 단방향(@ManyToOne)가 거의 비슷하다.

: 양방향

양방향이므로 연관관계의 주인을 정해야 한다. MEMBER 테이블이 외래 키를 가지고 있으므로 Member 엔티티에 있는 Member.locker가 연관관계의 주인이다. 따라서 반대 매핑인 사물함의 Locker.member는 mappedBy를 선언해서 연관관계의 주인이 아니라고 설정했다,

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

: 단방향

일대일 관계 중 대상 테이블에 외래 키가 있는 단방향 관계는 JPA에서 지원하지 않는다. 그리고 이런 모양으로 매핑할 수 있는 방법도 없다.

: 양방향

일대일 매핑에서 대상 테이블에 외래 키를 두고 싶으면 양방향으로 매핑한다. 주 엔티티인 Member 엔티티 대신에 대상 엔티티인 Locker를 연관관계의 주인으로 만들어서 LOCKER 테이블의 외래 키를 관리하도록 했다.

 

다대다 [N:N]

- 관계형 데이터베이스는 정규화된 테이블 2개로 다대다 관계를 표현할 수 없다. 그래서 보통 다대다 관계를 일대다, 다대일 관계로 풀어내는 연결 테이블을 사용한다. 그런데 객체는 테이블과 다르게 객체 2개로 다대다 관계를 만들 수 있다. 예를 들어 회원 객체는 컬렉션을 사용해서 상품들을 참조하면 되고 반대로 상품들도 컬렉션을 사용해서 회원들을 참조하면 된다. @ManyToMany를 사용하면 다대다 관계를 편리하게 매핑할 수 있다.

- 다대다: 단방향

@Entity
public class Member {
 ....
 
@ManyToMany
@JoinTable(
name = "MEMBER_PRODUCT", // 연결 테이블 지정
joinColumns = @JoinColumn(name = "MEMBER_ID"), // 현재 방향인 회원과 매핑할 조인 컬럼 정보 지정
inverseJoinColumns = @JoinColumn(NAME = "PRODUCT_ID"))) // 반대 방향인 상품과 매핑할 조인 컬럼 정보 지정
private List<Porduct> products = new ArrayList<Product>();

}

// 저장
public void save() {
Product productA = new Product();
em.persist(productA);

Member member1  = new Member();
member1.getProducts().add(productA); // 연관관계 설정
em.persist(member1);
}

// SQL
INSERT INTO PRODUCT ...
INSERT INTO MEMBER ...
INSERT INTO MEMBER_PRODUCT ...

// member.getProducts() 실행 SQL 결과
SELECT * FROM MEMBER_PRODUCT MP
INNER JOIN PRODUCT P ON MP.PRODUCT_ID = P.PRODUCT_ID
WHERE MP.MEMBER_ID = ?

- 다대다: 양방향

@Entity
public class Product {
 ....
 
@ManyToMany(mappedBy = "products") // 역방향 추가
private List<Member> members;

}

// 다대다의 양방향 연관관계 설정
member.getProducts().add(product);
product.getMembers().add(member);

// 양방향 연관관계는 연관관계 편의 메소드를 추가해서 관리하는 것이 편리함
// 회원 엔티티에 연관관계 편의 메소드 추가
public void addProduct(Product product) {
..
products.add(product);
product.getMembers().add(this);
}

// 양방향 연관관계 설정
member.addProduct(product);

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

: @ManyToMany를 사용하면 연결 테이블을 자동으로 처리해주므로 도메인 모델이 단순해지고 여러 가지로 편리하다. 하지만 이 매핑을 실무에서 사용하기에는 한계가 있다. 예를 들어 회원의 상품을 주문하면 연결 테이블에 단순히 주문한 회원 아이디와 상품 아이디만 담고 끝나지 않는다. 보통은 연결 테이블에 주문 수량 컬럼이나 주문한 날짜 같은 컬럼이 더 필요하다. 결국 연결 테이블을 매핑하는 연결 엔티티를 만들고 이곳에 추가한 컬럼들을 매핑해야 한다.

: 복합 기본 키

별도의 식별자 클래스로 만들어야함

Serializable 을 구현해야 함

equals와 hasCode 메소드를 구현해야 함

기본생성자가 있어야 함

식별자 클래스는 public이어야 함

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

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

@Entity
public class Member {
 ....
 
 // 역방향
@OneToMany(mappedBy = "member")
private List<MemberProduct> memberProducts;

}

@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;
private String product;

// hashCode and equals
@Override
public boolena equals(Object o) {...}

@Override
public boolena hashCode(Object o) {...}
}

// 저장
public void save() {
Member member1  = new Member();
em.persist(member1);

Product productA = new Product();
em.persist(productA);

MemberProduct memberProduct = new MemberProduct();
memberProduct.setMember(member1); // 주문 회원 - 연관관계 설정
memberProduct.setProduct(productA); // 주문 상품 - 연관관계 설정
memberProduct.setOrderAmount(2); // 주문 수량

em.persist(memberProduct);
}

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

: 추천하는 기본 키 생성 전략은 데이터베이스에서 자동으로 생성해주는 대리 키를 Long 값으로 사용하는 것이다. 장점은 간편하고 거의 영구히 쓸 수 있으며 비지니스에 의존하지 않는다. 그리고 ORM 매핑 시 복합 키를 만들지 않아도 되므로 간단히 매핑을 완성할 수 있다.

- 다대다 연관관계 정리

: 식별 관계: 받아온 식별자를 기본 키 + 외래 키로 사용한다.

: 비식별 관계: 받아온 식별자는 외래 키로만 사용하고 새로운 식별자를 추가한다.

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