본문 바로가기

Dev Book Review/자바 ORM 표준 JPA 프로그래밍

Chapter6. 다양한 연관관계 매핑

1. 다대일 관계

다대일 관계의 반대 방향은 항상 일대다 관계이고, 일대다 관계의 반대 방향은 항상 다대일 관계이다. 또한 데이터베이스의 외래 키는 항상 다쪽에 있다. 따라서 객체 양방향 관계에서 연관관계의 주인은 항상 다쪽이다.

 

1) 다대일 단방향

 

다대일 단방향

@Entity
public class Member {

  @Id @GeneratedValue
  @Column(name="MEMBER_ID")
  private Long id;

  private String username;

  @ManyToOne
  @JoinColumn(name="TEAM_ID")
  private Team team;
}
@Entity
public class Team {

  @Id @GeneratedValue
  @Column(name="TEAM_ID")
  private Long id;

  private String name;
}

이때 회원은 Member.team을 통해 팀 엔티티를 참조할 수 있지만, 반대로 팀에는 회원을 참조하는 필드가 없다. 따라서 회원과 팀은 다대일 양방향 관계이다.

 

2) 다대일 양방향

다대일 양방향

@Entity
public class Member {

  @Id @GeneratedValue
  @Column(name="MEMBER_ID")
  private Long id;

  private String username;

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

  public void setTeam(Team team) {
    this.team = team;

    if(!team.getMembers().contains(this)) {
    	team.getMembers().add(this);
    }
  }
}
@Entity
public class Team {

  @Id @GeneratedValue
  @Column(name="TEAM_ID")
  private Long id;

  private String name;

  @OneToMany(mappedBy="team")
  private List<Member> members = new ArrayList<Member>();

  public void addMember(Member member) {
    this.members.add(member);
    if (member.getTeam() != this) {
    	member.setTeam(this);
    }
  }
}
  • 양방향은 외래 키가 있는 쪽이 연관관계의 주인이다.
  • 양방향 연관관계는 항상 서로를 참조해야 한다. 그러기 위해서는 연관관계 편의 메소드를 작성하는 게 좋은데 setTeam(), addMember() 메소드와 같다. 연관관계 편의 메소드는 한 곳에만 작성하거나, 양쪽 다 작성할 수 있는데, 양쪽에 다 작성할 경우에는 무한루프에 빠지므로 주의해야 한다. 따라서 위 코드는 무한루프에 빠지지 않도록 검사하는 로직이 있다.

2. 일대다 관계

일대다 관계는 다대일 관계의 반대 방향이다. 일대다 관계에서는 Entity를 하나 이상 참조할 수 있기 때문에 자바 컬렉션(Collection, List, Set, Map) 중에 하나를 사용해야 한다.

 

1) 일대다 단방향

일대다 단방향

@Entity
public class Team {

  @Id @GeneratedValue
  @Column(name="TEAM_ID")
  private Long id;

  private String name;

  @OneToMany
  @JoinColumn(name="TEAM_ID")
  private List<Member> members = new ArrayList<Member>();
}
@Entity
public class Member {

  @Id @GeneratedValue
  @Column(name="MEMBER_ID")
  private Long id;

  private String username;
}

일대다 단방향 관계에서는 팀 엔티티의 Team.members로 회원 테이블의 TEAM_ID 외래 키를 관리한다. 다시 말해서 반대쪽 테이블에 있는 외래 키를 관리하는 특이한 모습이 나타난다. 왜냐하면 일대다 관계에서 외래 키는 항상 다쪽 테이블에 있다. 하지만 다쪽인 Member 엔티티에는 외래 키를 매핑할 수 있는 참조 필드가 없기 때문에 Team 엔티티의 참조 필드인 members를 통해 외래 키를 관리한다.

 

public void testSave() {

  Member member1 = new Member("member1");
  Member member2 = new Member("member2");

  Team team1 = new Team("team1");
  team1.getMembers().add(member1);
  team1.getMembers().add(member2);

  em.persist(member1);
  em.persist(member2);
  em.persist(team1);

  transaction.commit();
}
INSERT INTO Member (MEMBER_ID, username) VALUES (null, ?)
INSERT INTO Member (MEMBER_ID, username) VALUES (null, ?)
INSERT INTO Team (TEAM_ID, name) VALUES (null, ?)
UPDATE Member SET TEAM_ID=? WHERE MEMBER_ID=?
UPDATE Member SET TEAM_ID=? WHERE MEMBER_ID=?

일대다 단방향 매핑의 단점은 매핑한 객체가 관리하는 외래 키가 다른 테이블에 있다는 점이다. 따라서 연관관계를 처리를 위한 UPDATE SQL을 추가로 실행해야 한다. 예를 들어 Member 엔티티는 Team 엔티티의 내용을 알 수 없다. 그리고 연관관계의 주인은 Team.members로 설정했다. 따라서 Member 엔티티를 저장할 때 MEMBER 테이블의 TEAM_ID 외래 키에 아무 값도 저장되지 않는다. 대신 Team 엔티티를 저장할 때가 되어서야 Team.members 참조 값을 확인해서 MEMBER 테이블의 TEAM_ID 외래 키를 업데이트한다.

 

결과적으로 웬만하면 일대다 단방향 매핑보다는 다대일 양방향 매핑을 권장한다.

 

2) 일대다 양방향

일대다 양방향

@Entity
public class Team {

  @Id @GeneratedValue
  @Column(name="TEAM_ID")
  private Long id;

  private String name;

  @OneToMany
  @JoinColumn(name="TEAM_ID")
  private List<Member> members = new ArrayList<Member>();
}
@Entity
public class Member {

  @Id @GeneratedValue
  @Column(name="MEMBER_ID")
  private Long id;

  private String username;

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

일대다 양방향 매핑은 존재하지 않는다. 관계형 데이터베이스에서는 항상 다쪽에 외래 키가 있다. 따라서 양방향 매핑에서 @OneToMany는 연관관계의 주인이 될 수가 없기 때문이다. 억지로 일대다 양방향 매핑을 구현하려고 한다면, 일대다 단방향 매핑 반대편에 같은 외래 키를 사용하는 다대일 단방향 매핑을 읽기 전용으로 하나 추가하면 된다. 하지만 일대다 단방향 매핑이 가지는 단점을 그대로 가지기 때문에 될 수 있으면 다대일 양방향 매핑을 권장한다.

3. 일대일 관계

일대일 관계는 양쪽이 서로 하나의 관계만 가진다. 또한 일대일 관계는 주 테이블이나 대상 테이블 중 어느 곳이나 외래 키를 가질 수 있다. 따라서 누가 외래 키를 가질지 선택해야 한다.

 

1) 주 테이블에 외래 키

 

주 테이블에 외래 키를 두고 대상 테이블을 참조하는 모양이다. 외래 키를 객체 참조와 비슷하게 사용할 수 있기 때문에 객체지향 개발자들이 선호하는 방식이다. 주 테이블이 외래 키를 가지고 있으므로 주 테이블만 확인해도 대상 테이블과 연관관계가 있는지 알 수 있다는 장점이 있다. 또한 JPA도 주 테이블에 외래 키가 있으면 조금 더 편리하게 매핑할 수 있다.

 

<단방향>

주 테이블에 외래 키 (단방향)

@Entity
public class Member {

  @Id @GeneratedValue
  @Column(name="MEMBER_ID")
  private Long id;

  private String username;

  @OneToOne
  @JoinColumn(name="LOCKER_ID")
  private Locker locker;
}
@Entity
public class Locker {

  @Id @GeneratedValue
  @Column(name="LOCKER_ID")
  private Long id;

  private String name;
}

<양방향>

주 테이블에 외래 키 (양방향)

@Entity
public class Member {

  @Id @GeneratedValue
  @Column(name="MEMBER_ID")
  private Long id;

  private String username;

  @OneToOne
  @JoinColumn(name="LOCKER_ID")
  private Locker locker;
}
@Entity
public class Locker {

  @Id @GeneratedValue
  @Column(name="LOCKER_ID")
  private Long id;

  private String name;

  @OneToOne(mappedBy="locker")
  private Member member;
}

양방향 매핑이기 때문에 연관관계의 주인을 선택해야 한다. 따라서 외래 키를 가지고 있는 Member 엔티티의 Member.locker가 연관관계의 주인이다. 또한 반대 매핑인 Locker 엔티티의 Locker.member는 mappedBy를 통해 연관관계의 주인이 아님을 설정했다.

 

2) 대상 테이블에 외래 키

 

전통적인 데이터베이스 개발자들이 선호하는 방식이다. 테이블 관계를 일대일->일대다로 변경할 때 테이블 구조를 그대로 유지할 수 있다는 장점이 있다. 또한 일대일 관계에서 대상 테이블에 외래 키가 있는 단방향 관계는 JPA에서 지원하지 않는다.

 

<양방향>

대상 테이블에 외래 키 (양방향)

@Entity
public class Member {

  @Id @GeneratedValue
  @Column(name="MEMBER_ID")
  private Long id;

  private String username;

  @OneToOne(mappedBy="member")
  private Locker locker;
}
@Entity
public class Locker {

  @Id @GeneratedValue
  @Column(name="LOCKER_ID")
  private Long id;

  private String name;

  @OneToOne
  @JoinColumn(name="MEMBER_ID")
  private Member member;
}

마찬가지로 양방향 매핑이기 때문에 연관관계의 주인을 선택했다. (Locker.member)

4. 다대다 관계

다대다 관계 (테이블-객체)

관계형 데이터베이스는 정규화된 테이블 2개로 다대다 관계를 표현할 수 없다. 그래서 다대다 관계를 일대다/다대일로 풀어내기 위한 연결 테이블을 사용한다. 하지만 객체는 테이블과 달리, 객체 2개로 다대다 관계를 만들 수 있다. (@ManyToMany)

 

1) 다대다 단방향

@Entity
public class Member {

  @Id @Column(name="MEMBER_ID")
  private String id;

  private String username;

  @ManyToMany
  @JoinTable(name="MEMBER_PRODUCT", joinColumns=@JoinColumn(name="MEMBER_ID"),
                                  inverseJoinColumns=@JoinColumn(name="PRODUCT_ID"))
  private List<Product> products = new ArrayList<Product>();
}
@Entity
public class Product {

  @Id @Column(name="PRODUCT_ID")
  private String id;

  private String name;
}

회원 Entity와 상품 Entity를 @ManyToMany를 통하여 매핑했다. 이때 Member_Product와 같은 중간 Entity 없이 @ManyToMany, @JoinTable을 사용해서 매핑을 완료할 수 있다. 따라서 연결 테이블은 신경 쓰지 않고 다대다 관계를 사용할 수 있다.

더보기

1. @JoinTable.name

연결 테이블을 지정한다.

 

2. @JoinTable.joinColumns

현재 방향인 Entity와 매핑할 조인 컬럼 정보를 지정한다.

 

3. @JoinTable.inverseJoinColumns

반대 방향인 Entity와 매핑할 조인 컬럼 정보를 지정한다.

 

2) 다대다 양방향

 

@Entity
public class Product {

  @Id
  private String id;

  @ManyToMany(mappedBy="products")
  private List<Member> members;
}

역방향에서도 @ManyToMany 어노테이션을 사용한다. 또한 양쪽 중 원하는 곳에 mappedBy로 연관관계의 주인을 선택한다.

 

public void addProduct(Product product) {
  products.add(product);
  product.getMembers().add(this);
}

양방향 연관관계는 다음과 같이 연관관계 편의 메소드를 추가해서 관리하는 게 편하다. 따라서 간단한게 양방향 연관관계를 설정한다.

 

3) 다대다 매핑의 한계

 

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

하지만 실제 실무에서는 연결 테이블에 이처럼 단순한 정보만 넣고 끝나지 않는다. 예를 들어 Member_Product 테이블에는 주문 날짜와 같은 컬럼이 추가로 필요하기도 하다. 이런 경우 @ManyToMany를 사용하면 추가한 컬럼들을 매핑할 수 없다는 한계가 있다.

 

연결 엔티티 추가

@Entity
public class Member {

  @Id @Column(name="MEMBER_ID")
  private String id;

  @OneToMany(mappedBy="member")
  private List<MemberProduct> memberProducts;
}
@Entity
public class Product {

  @Id @Column(name="PRODUCT_ID")
  private String id;

  private String name;
}
@Entity
@IdClass(MemberProductId.class)
public class MemberProduct {

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

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

  private int orderAmout;
}

따라서 결국 연결 테이블을 매핑하는 연결 엔티티를 만들고 이곳에 추가한 컬럼들을 매핑해야 한다. 그리고 Entity 간의 관계도 테이블 관계처럼 일대다/다대일 관계로 풀어내야 한다.

 

public class MemberProductId implements Serializable {

  private String member;
  private String product;

  @Override
  public boolean equals(Object o) {...}

  @Override
  public int hashCode() {...}
}

이때 연결 엔티티(MemberProduct)의 기본 키는 동시에 외래 키이다. 따라서 @Id, @JoinColumn을 함께 사용해서 한번에 매핑했다. 그리고 @IdClass를 사용해서 복합 기본 키(이하 복합 키)를 매핑했는데, JPA에서 복합 키를 사용하려면 별도의 식별자 클래스를 만들어야 한다. 그리고 Entity에 @IdClass를 사용하여 식별자 클래스를 지정하면 된다.

더보기

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

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

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

@Entity
public class Order {

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

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

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

  private int orderAmout;
}

하지만 이러한 복합 키 사용 방식 또한 여러모로 귀찮은 점이 많다. 따라서 예시처럼 데이터베이스에서 자동으로 생성해주는 대리 키를 Long 값으로 사용하는 걸 추천한다. 간편하고 거의 영구적으로 사용할 수 있으며 비즈니스에 의존하지 않는다는 장점이 있다.