다양한 연관관계 맵핑

• 1. 연관관계 맵핑시 고려사항 3가지
• 2. 다대일[N:1]
• 3. 일대다[1:N]
• 4. 일대일[1:1]
• 5. 다대다[N:M]

1. 연관관계 맵핑시 고려사항 3가지

1. 다중성

@ManyToOne, @OneToMany, @OneToOne, @ManyToMany

2. 단방향, 양방향

1. 테이블

• 외래 키 하나로 양쪽 조인 가능
• 사실 방향이라는 개념이 없음

2. 객체

• 참조용 필드가 있는 쪽으로만 참조 가능
• 한쪽만 참조하면 단방향
• 양쪽이 서로 참조하면 양방향

3. 연관관계의 주인

• 테이블은 외래 키 하나로 두 테이블이 연관관계를 맺음
• 객체 양방향 관계는 참조가 2군데 있음. 둘 중에 테이블의 외래 키를 관리할 곳을 지정해야 함.
• 연관관계의 주인 = 외래 키를 관리하는 참조
• 주인의 반대편 = 외래 키에 영향을 주지 않음. 단순 조회만 가능

2. 다대일[N:1]

• 가장 많이 사용하는 연관관계

3. 일대다[1:N]

• 권장하지 않음(실무에서 거의 안 쓰신다고 함...)
• 일대다 단방향 맵핑보다는 다대일 양방향 맵핑을 사용하자

4. 일대일[1:1]

• 주 테이블이나 대상 테이블 중에 외래 키 선택 가능
• 외래 키에 데이터베이스 유니크(UNI) 제약조건 추가
• 외래 키 관련 예시(외래키를 MEMBER에 두기 vs LOCKER에 두기)
  1. DBA 입장
     (1) 시간이 지나서 비지니스 룰이 '하나의 회원이 여러 개의 라커를 가지게 한다.'로 바뀌면, LOCKER쪽에 외래키가 있는게 더 바꾸기 쉬움
     (만약에 MEMBER에 외래키가 있으면, 변경 포인트가 많음)
     (2) '하나의 라커를 여러명이 공유하도록 한다.' 면 반대가 맞음
  2. 개발자 입장
     (1) 멤버에 라커가 있는게 여러가지로 유리
     $\to$ 멤버를 조회할 때, 라커에 대한 값이 있는지 없는지 쉽게 나옴

5. 다대다[N:M]

• 실무에서 쓰면 안됨
  추가데이터가 들어오면 쓸 수가 없음(중간테이블에 맵핑 정보만 들어가고, 추가 정보를 더 넣는게 불가능 하다는 것)
  쿼리가 직관적이지 않게 날라감(중간테이블 때문에 생각한것과 다르게 쿼리가 나감)
• 한계 극복
  $\to$ @OneToMany, @ManyToOne으로 변경

이 글은 김영한님의 '자바 ORM 표준 JPA 프로그래밍 - 기본편'을 수강하고 정리한 내용입니다.