연관관계를 매핑할 때 고려해야 하는 점이 3가지가 있다.
- 다중성
- 다대일: @ManyToOne
- 실무에서 가장 많이 사용.
- 일대다: @OneToMany
- 일대일: @OneToOne
- 다대다: @ManyToMany
- 실무에서 사용 X.
- 다대일: @ManyToOne
- 단방향, 양방향
- 연관관계의 주인
- N:1의 관계에서 N
연관관계의 주인 (복습)
- 테이블은 외래 키 하나로 두 테이블이 연관관계를 맺는다.
- 객체 양방향 관계를 보면 Member -> Team / Team -> Member 처럼 참조가 2군데이다.
- 따라서 두 테이블 중 외래키를 관리할 곳을 지정해야 한다.
- 연관관계의 주인: 외래키를 관리하는 참조
- 주인의 반대편: 외래키에 영향을 주지 않고, 단순 조회만 가능하도록.
Member, Team 예시에서는 Member.team이 연관관계의 주인이다.
Team(One)에는 여러 Member(Many)가 포함된다.
Team에서는 Member를 조회만 할 수 있도록 해야한다.
다대일 관계 (N:1)
N:1 관계에서 외래 키는 항상 N쪽에 속해야 한다. 그렇지 않으면 설계가 잘못된 것이다.
만약 반대로 team에 member_id를 넣는다고 생각해보면, member가 3명인 team은 3개의 team을 인서트해야 하는 것이다.
- 가장 많이 사용하는 연관관계이다.
- 반대되는 개념은 일대다 이다.
다대일 양방향
다대일 단방향 관계에서 크게 달라지는 것은 없다.
다만 Team에서 Member를 참조해야하는 일이 많아진다면 이런 경우가 되는 것이다.
코드로 보면 아래와 같다.
1
2
3
4
5
6
7
@Entity
public class Team {
//...
@OneToMany(mappedBy = "team") //"team"은 Member class의 Team의 변수 명이다.
private List<Member> members = new ArrayList<>();
}
단순하게 읽기 권한이 부여된 것이다.
일대다 관계 (1:N)
1에 속하는 부분에서 외래 키를 관리하겠다는 것이다. (반드시 필요한 것이 아니라면 권장하지는 않는다.)
우선 DB입장에서는 외래키는 무조건 N쪽에 있어야 한다. 그 반대는 위에 설명했듯 Member 수만큼 Team이 계속 인서트되어야 하기 때문에 문제가 발생한다.
다만 1:N 관계는 Team 객체의 members를 변경했을 때 DB의 Member의 Team_ID(외래키)를 변경시킬 수 있어야 하는 것이다.
(N:1 관계에서는 Member 객체의 Team을 변경했을 때, DB의 Member의 Team_ID(외래키)를 변경시켰었다.)
1
2
3
4
5
6
7
8
9
@Entity
public class Team {
//...
@OneToMany
@JoinColumn(name = "TEAM_ID")
private List<Member> members = new ArrayList<>();
}
코드로 보면 위와 같다.
Team.members를 변경했을 때 DB의 Member의 team_id가 변경되는 것이다.
- 참고로 @JoinColumn을 반드시 사용해야 한다.
- 그렇지 않으면 조인 테이블 방식을 사용해 중간에 테이블을 하나 추가하게 된다.
예시
1
2
3
4
5
6
7
8
9
10
11
Member member = new Member();
member.setUsername("memberA");
em.persist(member);
Team team = new Team();
team.setName("teamA");
team.getMembers().add(member);
em.persist(team);
위 코드를 동작시켜보면 team에 대한 insert 쿼리 이후 update 쿼리가 따로 발생한다.
member 테이블에서 team_id가 업데이트 되어야 하기 때문이다. 이렇게 update 쿼리가 발생하는 과정에서 성능상 약간의 단점이 발생한다.
단점
개발자 입장에서 team 객체에 손을 댔는데, 막상 쿼리가 발생하는 것을 보면 member에 update 쿼리가 발생하는 부분에서 몹시 헷갈릴 수 있다.
team과 member 같이 단순하게 테이블 2개인 구조에서는 상관없을 수 있지만 실제로는 테이블이 수십개가 있을 경우 큰 단점이 될 수 있는 것이다.
- 결론적으로는 일대다 단방향 매핑보다 조금 객체적으로 부자연스러운 부분이 있더라도 다대일 양방향 매핑을 사용하는 것을 권장한다.
일대일 관계 (1:1)
- 일대일 관계는 당연히 그 반대도 일대일이다.
- 주 테이블이나 대상 테이블 중 아무곳에나 외래 키 선택이 가능하다.
- 외래 키에 데이터베이스 유니크(UNI) 제약조건 추가.
위와 반대로 LOCKER 테이블에 MEMBER_ID를 외래 키(UNI)로 가져도 된다는 뜻이다.
양방향으로 만들고 싶다면 Locker 객체에 member를 추가하고, mappedBy를 사용하면 된다.
1
2
3
4
5
6
7
8
9
10
@Entity
public class Locker {
@Id @GeneratedValue
private Long id;
private String name;
@OneToOne(mappedBy = "locker")
private Member member;
}
1
2
3
4
5
6
7
@Entity
public class Member {
//...
@OneToOne
@JoinColumn(name = "LOCKER_ID")
private Locker locker;
- 다대일 양방향 매핑과 같이 외래 키가 있는 곳이 연관관계의 주인이다.
정리
- 주 테이블에 외래 키가 있는 경우
- 주 객체가 대상 객체의 참조를 가지는 것 처럼 주 테이블에 외래 키를 두고 대상 테이블을 찾는다.
- 객체지향 개발자가 선호한다.
- JPA 매핑이 편리하다.
- 장점: 주 테이블만 조회해도 대상 테이블에 데이터가 있는 지 확인 가능
- 단점: 값이 없으면 외래 키에 null 허용
- 대상 테이블에 외래 키가 있는 경우
- 전통적인 데이터베이스 개발자가 선호한다.
- 장점: 주 테이블과 대상 테이블을 일대일에서 일대다 관계로 변경할 때 테이블 구조를 유지할 수 있다.
- 단점: 프록시 기능의 한계로 지연 로딩 설정해도 항상 즉시 로딩된다.
다대다 관계 (N:M)
- 관계형 데이터베이스는 정규화된 테이블 2개로 다대다 관계를 표현할 수 없다.
- 연결 테이블을 추가해 일대다, 다대일 관계로 풀어내야 한다.
하나의 회원이 여러 개의 상품을 선택할 수 있고, 반대로 상품 입장에서도 여러 명의 회원에게 포함될 수 있는 경우이다.
- @ManyToMany를 사용한다.
- @JoinTable로 연결 테이블을 지정한다.
한계
- 편리해보이지만 실무에서 사용하지 않는다.
- 연결 테이블이 단순히 연결만 하고 끝나지 않는다.
- 실제로는 주문을 했을 때, 주문 시간, 주문 수량 같은 추가적인 정보가 더 들어가게 되는데 다대다 관계에 사용되는 중간 테이블(Member_Product)에 이러한 추가 정보를 넣는 것이 불가능하다.
- 따라서 사용이 불가능하다.
한계의 극복
추가 정보를 반영하는 것이 불가능한 연결용 중간 테이블을 엔티티로 승격하는 것이다.
- 연결 테이블용 엔티티를 추가한다. (연결 테이블을 엔티티로 승격)
- @ManyToMany -> @OneToMany, @ManyToOne 관계로 만든다.
Member, Product 입장에서는 @OneToMany(mappedBy)
Order 입장에서는 각각 @ManyToOne (member, product)