김영한님의 자바 ORM 표준 JPA 프로그래밍 - 기본편 강의를 듣고 정리한 내용입니다.
https://www.inflearn.com/course/ORM-JPA-Basic
연관관계 매핑
연관관계 매핑시 주의사항
- 방향 - 단방향, 양방향
- 다중성 - 다대일(N:1) , 일대다 (1:N), 일대일(1:1), 다대다(N:N)
- 연관관계의 주인 : 객체 양방향 연관관계는 관리주인이 필요하다.
객체지향 설계의 목표는 자율적인 객체들의 협력 공동체를 만드는 것이다.
객체를 테이블에 맞추어 데이터 중심으로 모델링하면, 협력관계를 만들 수 없다.
테이블과 객체의 차이
- 테이블은 외래 키로 조인을 사용해서 연관된 테이블을 찾는다.
- 객체는 참조를 사용해서 연관된 객체를 찾는다.
단방향 연관관계
객체지향 모델링 (ORM 매핑)
양방향 연관관계 & 연관관계의 주인
테이블에서는 FK를 통해 양방향으로 값을 사용할 수 있지만, 객체에서는 Member → Team은 Team이 있기때문에 가능하지만, Team → Member는 불가능하여 List를 추가해주고, @OneToMany(mappedBy = "team")로 반대편에 매핑된 필드도 지정해준다.
❗️객체와 테이블간에 연관관계를 맺는 차이를 이해해야 한다.
객체 연관관계 : 2개 ( 회원 → 팀 , 팀 → 회원)
객체의 양방향 관계는 사실 양방향 관계가 아니라 서로 다른 단뱡향 관계 2개다.
객체를 양방향으로 참조하려면 단방향 연관관계를 2개 만들어야 한다.
테이블 연관관계 : 1개 ( 회원 ↔ 팀 (FK사용))
테이블은 외래키 하나로 두 테이블의 연관관계를 관리한다.
→ Member의 team과 Team의 Members리스트 둘중하나로 외래키를 관리해야한다. (연관관계 주인)
⭐️ 연관관계 주인 ⭐️
객체의 두 관계중 하나를 연관관계의 주인으로 지정한다.
연관관계의 주인만이 외래키를 관리(등록, 수정) 할 수 있고, 주인이 아닌쪽은 읽기만 가능하다.
@JoinColumn으로 주인임을 나타내고, mappedBy 속성으로 주인이 아님을 나타낸다.
→ 외래키가 있는곳을 주인으로 정하자!!
Member 엔티티가 Member테이블을 매핑했기때문에 FK가 Member에 있다.
따라서, Member의 team을 연관관계의 주인으로 지정하고, Team의 members리스트는 mappedBy로 주인의 반대편으로 가짜매핑한다. 이렇게되면 members는 등록,수정이 불가하고 값을 조회만 할 수 있다.
* Team의 members리스트를 연관관계의 주인으로 정한다고 하더라도, 등록,수정시에 쿼리가 매핑되지않은 다른 테이블(Member)에서 나가기때문에 어지러워진다.
DB입장에서 보면 외래키가 있는곳이 무조건 ‘다'에 속한다. 따라서 DB의 N쪽이 무조건 연관관계의 주인이 된다. → @ManyTo… 쪽이 연관관계의 주인이 된다.
❗️ 주의
양방향 매핑시 연관관계의 주인에 값을 입력해야 한다. (순수한 객체 관계를 고려하면 항상 양쪽다 값을 입력해야 한다)
한쪽(member)에만 값을 넣어놓고 영속성 컨텍스트를 flush하지않으면, 최초에 team에 세팅해놓은 값이 1차캐시에 그대로 있고, 값을 조회할때 1차캐시의 값을 가져와 없는 값을 가져올수도있다!
→ 따라서, 순수한 객체 관계를 고려하면 항상 양쪽다 값을 입력해야 한다!
- 연관관계 편의 메소드를 생성하는것도 방법이다. ( 한쪽 엔티티에서 세팅할때 해당메서드 내에서 다른쪽도 같이 세팅해준다.)
- 양방향 매핑시에 무한 루프를 조심하자 (toString, lombok, JSON)
정리
- 단방향 매핑만으로도 이미 연관관계 매핑은 완료한 것이다.
- 양방향 매핑은 반대 방향으로 조회(객체 그래프 탐색) 기능이 추가된 것 뿐이다.
- JPQL에서 역방향으로 탐색할 일이 많아서 양방향 매핑을 고민해야한다.
- 단방향 매핑을 잘 하고, 양방향은 필요할 때 추가해도 됨 (테이블에 영향을 주지 않음!)
- 객체입장에서 양방향 매핑이 크게 이득은 아니다
연관관계의 주인을 정하는 기준 → 연관관계의 주인은 외래 키의 위치를 기준으로 정해야함
