연관관계 매핑

객체가 연관관계 없이, 테이블에 맞게 모델링되어 있을 때(참조 대신 FK를 그대로 사용)

 

@Entity
public class Member {
​​​​@Id @GeneratedValue
​​​​private long id;

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

​​​​private int age;

​​​​@Column(name = "TEAM_ID")
​​​​private long teamId;

​​​​@Enumerated(EnumType.STRING)
​​​​private Tier tier;

​​​​// getter and setters...
}

//////////

@Entity
public class Team {

​​​​@Id @GeneratedValue
​​​​private long id;

​​​​private String name;

​​​​// getter and setters...
}

 

이렇게 했을 때...

 

public class Main {
​​​​public static void main(String[] args) {
​​​​​​​​EntityManagerFactory emf = Persistence.createEntityManagerFactory("hello");
​​​​​​​​EntityManager em = emf.createEntityManager();
​​​​​​​​EntityTransaction tx = em.getTransaction();
​​​​​​​​tx.begin();

​​​​​​​​try {
​​​​​​​​​​​​Team team = new Team();
​​​​​​​​​​​​team.setName("teamA");
​​​​​​​​​​​​em.persist(team);

​​​​​​​​​​​​Member member = new Member();
​​​​​​​​​​​​member.setName("member1");
​​​​​​​​​​​​member.setTeamId(team.getId());
​​​​​​​​​​​​em.persist(member);

​​​​​​​​​​​​Member findMember = em.find(Member.class, member.getId());
​​​​​​​​​​​​long teamId = findMember.getTeamId();
​​​​​​​​​​​​Team findTeam = em.find(Team.class, teamId);

​​​​​​​​​​​​tx.commit();
​​​​​​​​} catch (Exception e) {
​​​​​​​​​​​​tx.rollback();
​​​​​​​​} finally {
​​​​​​​​​​​​em.close();
​​​​​​​​}

​​​​​​​​emf.close();
​​​​}
}

 

조회를 하려면? 연관관계가 없기 때문에 조회를 두 번, 따로 해야 한다.

- 테이블은 외래 키로 조인을 사용해서 연관된 테이블을 찾는다.

- 객체는 참조를 사용해서 연관된 객체를 찾는다.

-> 객체를 테이블에 맞추어 데이터 중심으로 모델링하면, 협력 관계를 만들 수 없다.

 

// 팀 조회
Team findTeam = em.find(Team.class, team.getId());

// 멤버 조회
Member findMember = em.find(Member.class, member.getId());

// 멤버의 팀 조회
Member m = em.find(Member.class, member.getId());
Long teamId = m.getTeamId();
Team t = em.find(Team.class, teamId);

 

 

======== 연관관계 매핑 이론 ============ JPA계의 포인터..? ㅋㅋㅋ

 

== 단방향 매핑 ==

Member는 Team을 참조하는데

Team에서는 Member로 갈 수 없다.

 

package com.ddoongi.web.entity;

import javax.persistence.*;

@Entity
public class Member {
​​​​@Id @GeneratedValue
​​​​private long id;

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

​​​​private int age;

//    @Column(name = "TEAM_ID")
//    private long teamId;

​​​​@ManyToOne // 여러 개의 멤버 : 하나의 팀
​​​​@JoinColumn(name = "TEAM_ID") // 객체의 Team team 필드가 → DB의 TEAM_ID(FK)와 '연관관계 매핑'됨
​​​​private Team team;

​​​​@Enumerated(EnumType.STRING)
​​​​private Tier tier;

​​​​// getters and setters...
}

public class Main {
​​​​public static void main(String[] args) {
​​​​​​​​EntityManagerFactory emf = Persistence.createEntityManagerFactory("hello");
​​​​​​​​EntityManager em = emf.createEntityManager();
​​​​​​​​EntityTransaction tx = em.getTransaction();
​​​​​​​​tx.begin();

​​​​​​​​try {
​​​​​​​​​​​​Team team = new Team();
​​​​​​​​​​​​team.setName("teamA");
​​​​​​​​​​​​em.persist(team);

​​​​​​​​​​​​Member member = new Member();
​​​​​​​​​​​​member.setName("member1");
​​​​​​​​​​​​member.setTeam(team);
​​​​​​​​​​​​em.persist(member);

​​​​​​​​​​​​em.flush(); // DB에 쿼리를 다 보낸다.
​​​​​​​​​​​​em.clear(); // 캐시를 비운다.

​​​​​​​​​​​​// member에서 team 검색
​​​​​​​​​​​​Member findMember = em.find(Member.class, member.getId());
​​​​​​​​​​​​Team findTeam = findMember.getTeam();

​​​​​​​​​​​​// team에서 member 검색
​​​​​​​​​​​​List<Member> members = findTeam.getMembers();
​​​​​​​​​​​​for (Member item : members) {
​​​​​​​​​​​​​​​​System.out.println("member = " + item);
​​​​​​​​​​​​}

​​​​​​​​​​​​tx.commit();
​​​​​​​​} catch (Exception e) {
​​​​​​​​​​​​tx.rollback();
​​​​​​​​} finally {
​​​​​​​​​​​​em.close();
​​​​​​​​}

​​​​​​​​emf.close();
​​​​}
}

 

join이 싫고 멤버만 가지고 오고 싶다?

@ManyToOne(fetch = FetchType.LAZY)

 

이렇게 지연로딩을 하면 Team에 대한 조회는 findTeam.getName(); 과 같이,

실제로 사용될 때 시행됨. 대부분 LAZY로 하고, 꼭 필요한 곳에서만 EAGER 쓰는 것을 권장.

속단해서 최적화하지 말자.

 

 

 

======= 양방향 매핑=======

DB는 원래 양방향이라 변화가 없다.

 

 

Member entity는 동일

 

Team entity에 컬렉션 추가

@Entity
public class Team {

​​​​@Id @GeneratedValue
​​​​private long id;

​​​​private String name;

​​​​@OneToMany(mappedBy = "team") // owner가 아님을 나타냄 (컬럼명이 아니라 자바 코드 상의 필드 이름)
​​​​private List<Member> members = new ArrayList<>();

​​​​// getters and setters...
}

 

mappedBy는 왜 필요한가?

왜 JoinColumn은 필요가 없는가?

 

ㅇ객체와 테이블이 관계를 맺는 차이

- 객체 연관관계

-- 회원 -> 팀 연관관계 1개 (단방향)

-- 팀 -> 회원 연관관계 1개 (단방향)

- 테이블 연관관계

-- 회원 <-> 팀 연관관계 1개 (양방향)

 

객체의 양방향 관계는 사실 양방향 관계가 아니라 서로 다른 단방향 관계 2개이다.

객체를 양방향으로 참조하려면 단방향 연관관계를 2개 만들어야 한다. (양방향 참조로 보이는 것 뿐)

 

테이블은 외래 키 하나로 두 테이블의 연관관계를 관리

MEMBER.TEAM_ID 외래 키 하나로 양방향 연관관계 가짐(양쪽으로 조인할 수 있다)

 

 

ㅇ 연관관계의 주인(owner)

#양방향 매핑 규칙

- 객체의 두 관계중 하나를 연관관계의 주인으로 지정

- 연관관계의 주인만이 외래 키를 관리(등록, 수정)

- 주인이 아닌 쪽은 읽기만 가능

- 주인은 mappedBy 속성 사용 x

- 주인이 아니면 mappedBy 속성으로 주인 지정

#그럼 누구를 주인으로 지정하지?

- 외래 키가 있는 곳을 주인으로 정해라

- 여기서는 Member.team이 연관관계의 주인

#양방향 매핑 시 많이 하는 실수: 연관관계의 주인에 값을 입력하지 않음

Team team = new Team();
team.setName("TeamA");
em.persist(team);

Member member = new Member();
member.setName("member1");


// 역방향(주인이 아닌 방향)만 연관관계 설정
// 이렇게 하면 DB에서는...
// ID: 1, USERNAME: member1, TEAM_ID: null
// team.getMembers().add(member);

// 이렇게 해야한다.
// (둘다 하면 역방향은 무시. 그러나 실제로는 둘다 쓰는걸 권장. DB에는 하나만 써도 되지만 객체 관점에서.)
member.setTeam(team);

em.persist(member);

 

#양방향 매핑의 장점

- 단방향 매핑만으로도 이미 연관관계 매핑은 완료

- 양방향 매핑은 반대 방향으로 조회(객체 그래프 탐색) 기능이 추가된 것 뿐

- JPQL에서 역방향으로 탐색할 일이 많음

- 단방향 매핑을 잘 하고 양방향은 필요할 때 추가해도 됨(테이블에 영향을 주지 않음)

 

 

ㅇ 연관관계 매핑 어노테이션

- 다대일(@ManyToOne)

- 일대다(@OneToMany)

- 일대일(@OneToOne)

- 다대다(@ManyToMany) -> 현업에서는 제약조건이 너무많아서 1:다, 다:1로 푼다

- @JoinColumn, @JoinTable

 

ㅇ 상속관계 매핑 어노테이션

- @Inheritance

- @DiscriminatorColumn

- @DiscriminatorValue

- @MappedSuperclass(매핑 속성만 상속)

 

ㅇ 복합 키 어노테이션

- @IdClass

- @EmbeddedId

- @Embeddable

- @Mapsld