[ORM 표준 JPA] 8.다양한 연관관계 매핑

DB 테이블

DB 테이블에는 외래 키 하나로 양쪽에 조인이 가능하다. 

저번 글에서 언급했듯이, 방향이라는 개념이 없다. 

 

객체

참조용 필드가 있는 쪽으로만 참조가 가능하다.

사실, 양방향이라는 개념이 있는 것이 아니라 단방향이 2개 있는 것이다. 

사람들이 이해하기 쉽게 양방향으로 설명을 하는 것이지, 객체 입장에선 방향이 1개이다.

 

연관관계 주인

테이블은 외래 키 하나로 두 테이블이 연관관계를 맺는다.

객체 양방향 관계는 참조가 2군데이다.

객체 양방향 관계는 참조가 2군데이며 둘 중 테이블의 외래 키를 관리할 곳을 지정해줘야한다.

연관관계의 주인: 외래 키를 관리하는 참조

주인의 반대편: 외래 키에 영향을 주지 않음, 단순 조회만 가능함

 

다대일 [N:1]

 

DB 입장

관계형 DB에는 다(N) 쪽에 외래키를 두는 것이 기본이다.

 

객체에서 참조를 Member에서 Team으로만 간단히 참조한다는 단순한 가정이 있을 때, 

TEAM_ID를 갖고 와서 Member에 매핑을 걸어주면 된다. 

 

가장 많이 사용하는 관계이며, 다대일[N:1] 의 반대는 일대다[1:N]이다.

 

단방향

Member

public class Member {

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

    @Column(name = "USERNAME")
    private String username;

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

 

Team

public class Team {
    @Id @GeneratedValue
    @Column(name = "TEAM_ID")
    private Long id;
    private String name;
    // ...
}

Member에서만 Team을 참조하는 값을 가지는 이 형식이 단방향이다.

 

양방향

위 코드에서 반대쪽을 추가해주면 된다. 

 

Member

기존 코드 유지

 

Team

public class Team {
    @Id @GeneratedValue
    @Column(name = "TEAM_ID")
    private Long id;
    private String name;

    @OneToMany(mappedBy = "team")
    // 여기서 team은 Member객체에서 Team을 참조하는 변수 명
    private List<Member> members = new ArrayList<>();
}

기존 코드에서 참조하는 것을 추가해주면 된다. 

mapperBy로 'team에 의해 mapping이 되어짐' 을 나타냈기 때문에, team이 연관관계 주인이다.

연관관계 주인을 Member에 있는 team으로 설정했기 때문에, 추가한다고 해서 테이블에 전혀 영향을 주지 않으며, 조회 기능이 추가된 것이다. 

 

외래 키가 있는 쪽이 연관관계 주인이다!

 

일대다 단방향 [1:N]

 

DB에는 당연히 외래키를 다 (N) 쪽에 갖고 있다.

위 모델에서는 Member 즉 외래키를 갖고 있지 않은 쪽에다가 연관관계 주인으로 둔다.

 

실무에서는 사용하지 않지만, JPA가 지원하는 표준 스펙이기에 이론적으로 알아만 본다.

 

위 상황에서는 Member객체는 Team을 알고 싶지 않은데, Team은 Member객체가 알고 싶은 상황이라 가정한다.

 

team.getMembers.add(member) 

이런식으로 team에 연관관계 주인을 두고, 추가하면 Member 테이블에 업데이트 쿼리가 추가적으로 나간다.

Member는 어떠한 team인지 모르기 때문이다. 

 

이를 실무에서 사용하지 않는 이유는

1. 엔티티가 관리하는 외래 키가 다른 테이블에 있다.

1. 업데이트 쿼리가 추가적으로 나가기 때문에 성능 이슈가 있다. (미비하지만 굳이 손해 볼 필요가 없다)

2. 운영이 힘들어진다. team을 세팅했는데 쿼리는 member 테이블로 나가기 때문이다. 실무에서 수십 수백개의 엔티티가 돌아갈 때, 어떠한 테이블에서 쿼리가 나갔는지 알 수 없다. 

 

@JoinColumn(Team_Id)

이 애노테이션을 사용하지 않으면 조인 테이블이 추가적으로 하나 생긴다. (중간에 테이블을 하나 추가한다.)

 

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

 

일대일 [1:1]

 

주 테이블이나 대상 테이블 중에 외래 키 선택 가능하다.

 

외래 키에 DB 유니크 제약 조건이 추가되어야한다.

 

다대일(ManyToOne) 단방향 매핑과 유사하다.

 

주 테이블에 외래 키

주 객체가 대상 객체가 참조랄 가지는 것처럼 주 테이블에 외래 키를 두고 대상 테이블을 찾는다.

객체지향 개발자들이 선호한다.

JPA 매핑이 편리하다.

장점: 주 테이블만 조회해도 대상 테이블에 데이터가 존재하는지 확인할 수 있다.

단점: 값이 없으면 외래 키에 null을 허용한다.

 

대상 테이블에 외래 키

대상 테이블에 외래 키가 존재하는 것

전통적인 DB 개발자들이 선호한다.

장점: 주 테이블과 대상 테이블을 일대일에서 일대다로 관계로 변경할 때 테이블 구조를 유지하여 수정해야할 부분이 적다.

단점: 프록시 기능의 한계로 지연 로딩으로 설정해도 항상 즉시 로딩된다.

 

만약에 대상 테이블에 외래 키가 존재한다면, Member를 조회한다고 대상 테이블에 값이 존재하는지 확인할 수 없으니, 즉시 로딩해야한다.

 

실주에서는 주 테이블에 외래 키를 두는 것이 일반적이지만, DBA와 협의를 해야함!

 

다대다 [N:M]

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

연결 테이블을 추가해서 일대다, 다대일 관계로 풀어내야한다. 

실무에서 사용하지 않으므로 마찬가지로 이론으로만 적어본다.

 

객체는 컬렉션을 사용해서 객체 2개로 다대다 관계가 가능하다.

 

다대다를 사용할 수 없는 이유

실무에서는 연결 테이블이 단순히 연결만 하고 끝나지 않는다. (언제 데이터가 변경되었는지, 추가되었는지, 주문시간, 수량 같은 데이터가 들어올 수 있다.)

 

예)

이를 해결하기 위한 방법

연결 테이블용 엔티티 추가(연결 테이블을 엔티티로 승격)

@ManyToMany -> @ManyToOne, @OneToMany

MemberProduct에 Member와 매핑하고, MemberProduct에 Product와 매핑하면 된다.

이렇게 엔티티로 승격했으므로 추가적인 값을 넣을 수 있다.

 

왠만하면 pk는 GenerateValue와 같은 의미 없는 값을 사용하는 것이 좋다.