들어가며..
이번에 다루는 내용이 객체와 관계형 데이터베이스의 패러다임의 차이에서 오는 것 중에서 제일 어려운 내용.
객체가 지향하는 패러다임과 관계형 데이터베이스가 지향하는 패러다임의 차이가 있기 때문에 둘 사이의 차이에 의한 극심한 어려움이 있다.
목표
- 객체와 테이블 연관관계의 차이를 이해
- 객체의 참조와 테이블의 외래 키를 매핑
- 객체의 경우 참조(Reference)를 이용하여 연관된 객체를 쭉 탐색할 수 있다.
- 테이블의 경우 외래키로 조인을 하여 연관된 테이블을 탐색한다.
- 용어 이해
- 방향(Direction) : 단방향, 양방향
- 다중성(Multiplicity) : 다대일(N:1), 일대다(1:N), 일대일(1:1), 다대다(N:M) 이해
- 연관관계 주인(Owner) : 객체 양방향 연관관계는 관리 주인이 필요
연관관계가 필요한 이유
객체지향 설계의 목표는 자율적인 객체들의 협력 공동체를 만드는 것이다.
-조영호(객체지향의 사실과 오해)
👩🏻🤝🧑🏻예제 시나리오
- 회원과 팀이 있다.
- 회원은 하나의 팀에만 소속될 수 있다.
- 회원과 팀은 다대일 관계이다.
객체를 테이블에 맞추어 모델링
연관관계가 없는 객체
▶ 객체에는 연관관계가 없다. 😨
참조 대신에 외래키를 그대로 사용
@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;
...
}
@Entity
public class Team {
@Id @GeneratedValue
private Long id;
private String name;
}▶ 객체는 참조 대신 테이블의 외래키 값을 그대로 가지고 있다.
외래키 식별자를 직접 다룸
//팀저장
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());
//연관관계가 없음
Team findTeam = em.find(Team.class, team.getId());
▶ member를 조회해왔음에도 불구하고, member가 속한 팀을 알기 위해서는 또 member가 가진 team_id(FK)로 테이블을 검색해서 가져와야한다.
▶ 연관관계가 없기 때문, 객체지향스럽지 않은 방식
객체를 테이블에 맞추어 데이터 중심으로 모델링하면, 협력관계를 만들 수 없다
- 테이블은 외래키로 조인을 사용해서 연관된 테이블을 찾는다.
- 객체는 참조를 사용해서 연관된 객체를 찾는다.
테이블과 객체 사이에는 이런 큰 간격이 있다.
데이터 중심(테이블 중심) 설계의 문제점
- 현재 방식은 객체 설계를 테이블 설계에 맞춘 방식
- 테이블의 외래키를 객체에 그대로 가져온다
- 객체 그래프 탐색이 불가능
단방향 연관관계
객체 지향 모델링
객체 연관관계 사용
- Team의 Id가 아닌 Team의 참조값을 그대로 가져온다.
- Member 객체의 Team 레퍼런스와 MEMBER 테이블의 TEAM_ID(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;
@ManyToOne
@JoinColumn(name = "TEAM_ID")
private Team team;
...
}- 연관관계가 무엇인지 (다대일), 이 관계를 정의할 때 조인하는 컬럼은 무엇인지 적어주면 된다.
ORM 매핑
연관관계 저장
//팀 저장
Team team = new Team();
team.setName("TeamA");
em.persist(team);
//회원 저장
Member member = new Member();
member.setName("member1");
member.setTeam(team); //단방향 연관관계 설정, 참조 저장
em.persist(member);- member에 team 참조를 저장하면, JPA가 DB에 엔티티 저장할 때 알아서 team 엔티티에서 PK값을 꺼내서 Member 테이블의 FK컬럼에 저장한다.
참조로 연관관계 조회 - 객체 그래프 탐색
//조회
Member findMember = em.find(Member.class, member.getId());
//참조를 사용해서 연관관계 조회
Team findTeam = findMember.getTeam();연관관계 수정
//새로운 팀 B
Team teamB = new Team();
teamB.setName("TeamB");
em.persist(teamB);
//회원1에 새로운 팀B 설정
member.setTeam(teamB);- 더티 체킹을 이용한 연관관계 수정
양방향 연관관계와 연관관계의 주인
양방향 매핑
- 테이블 연관관계는 그대로이다. 왜냐하면 테이블은 외래키로 조인해서 연관관계를 만들기 때문에 테이블의 연관관계는 외래키하나에 양방향이 다 있는 것이다.
- 하지만 객체는 참조를통해 연관관계 설정하기 때문에, Team에서 member로 가려면 Team에도 member에 대한 참조 넣어줘야한다.
Member 엔티티는 단방향과 동일, Team 엔티티는 컬렉션 추가
@Entity
public class Team {
@Id @GeneratedValue
private Long id;
private String name;
//ArrayList로 초기화해두는 것은 관례 (add할 때 NPE 안뜨니까)
@OneToMany(mappedBy = "team")
List<Member> members = new ArrayList<Member>();
...
}반대 방향으로 객체 그래프 탐색
//조회
Team findTeam = em.find(Team.class, team.getId());
int memberSize = findTeam.getMembers().size(); //역방향 조회연관관계 주인과 mappedBy
객체와 테이블 간에 연관관계를 맺는 차이를 이해해야 한다.
객체와 테이블이 관계를 맺는 차이
- 객체 연관관계 = 2개
- 회원 ➡ 팀 연관관계 1개 (단방향)
- 팀 ➡ 회원 연관관계 1개 (단방향)
- 단방향 연관관계가 2개 있는 것이다. 이것을 우리는 억지로 양방향이라고 부르고 있는 것.
- 객체 세상에서는 양방향 연관관계를 맺으려면, 참조가 양쪽 객체에 있어야한다.
- 테이블 연관관계 = 1개
- 회원 ↔ 팀 연관관계 1개 (양방향, 사실 방향이 없는 것)
- 외래키 값 하나로 테이블을 조인하면 양쪽의 연관관계가 끝이난다.
객체의 양방향 관계
- 객체의 양방향 관계는 사실 양방향 관계가 아니라 서로 다른 단방향 관계 2개이다.
- 객체를 양방향으로 참조하려면 단방향 연관관계 2개를 만들어야한다.
테이블의 양방향 연관관계
- 테이블은 외래키 하나로 두 테이블의 연관관계를 관리
- MEMBER.TEAM_ID 외래키 하나로 양방향 연관관계를 가진다.
(양쪽으로 조인할 수 있다.)
SELECT *
FROM MEMBER M
JOIN TEAM T ON M.TEAM_ID = T.TEAM_ID;
SELECT *
FROM TEAM T
JOIN MEMBER M ON T.TEAM_ID = M.TEAM_ID;둘 중 하나로 외래키를 관리해야 한다.
- 객체에는 두 가지 참조값이 있다.
- Member ➡ Team 참조값
- Team ➡ Member 참조값
- 둘중 어떤 것이랑 테이블의 외래키를 매핑해야하는가?
- Member에 있는 team값이 바뀌었을 때 외래키 값을 업데이트 해야하나.
- Team에 있는 members값이 바뀌었을 때 외래키 값을 업데이트 해야하나.
- 그냥 두 개의 참조값 다 매핑하면 안되나?
- 극단적으로 Member에 있는 team에는 값을 넣고, Team에 있는 members에는 값을 넣지 않는다면?
- 반대로 Member에 있는 team은 값을 넣지 않고, Team에 있는 members에만 값을 넣는다면?
- 아니면 둘 다 값을 넣는다면?
- 무엇을 기준으로 해야하지? 😨
- 따라서 규칙이 생김
- 둘 중 하나로 외래키를 관리해야 한다!!
- 그것이 바로 연관관계의 주인!!
연관관계의 주인(Owner)
🔴 양방향 매핑 규칙
- 객체의 두 관계중 하나를 연관관계의 주인으로 지정
- 연관관계의 주인만이 외래키를 관리(등록, 수정)
- 주인이 아닌쪽은 읽기만 가능
- 주인은 mappedBy 속성 사용 X
- 주인이 아니면 mappedBy 속성으로 주인 지정
🟠 누구를 주인으로?
- 외래키가 있는 곳을 주인으로 정해라!(다대일에서는 다쪽!)
- 여기서는 Member.team이 연관관계의 주인!
왜 외래키가 있는 쪽을 연관관계의 주인으로 정하는 것인가?
- 일단 외래키가 있는 쪽의 테이블에 대응되는 엔티티에 있는 참조를 연관관계의 주인으로 정하는 것이 헷갈리지 않는다.
- 만약 외래키가 있는 곳이 아닌 Team.members를 연관관계의 주인으로 정한다면?
- Team에 있는 members를 수정했는데, update쿼리는 다른 테이블(MEMBER)에 날라간다. ➡ 벌써 헷갈린다! 😵
- 뒤에 나오지만 성능이슈도 있다.
외래키가 있는 쪽을 연관관계의 주인으로 설정하면 많은 것들이 해결된다.
- DB 입장에서는 다대일 관계에서 외래키가 있는 쪽이 다고 외래키가 없는 쪽이 일이다.
- DB의 N쪽이 무조건 연관관계의 주인이 된다.
- 객체에서는 @ManyToOne, @XXXToOne 쪽이 무조건 연관관계의 주인이 된다.
- 연관관계 주인은 비즈니스적으로 큰 의미는 없다. 자동차와 바퀴가 있다고 하면, 비즈니스적으로는 당연히 자동차가 중요하지만, 연관관계의 주인은 바퀴이다. (그정도로 의미 없다는 뜻)
- 다만 설계상 외래키 있는 쪽에 연관관계 주인이 있어야 설계가 깔끔해진다.
- 엔티티랑 테이블이 매핑이 되있는 같은 곳에서 연관관계가 관리가 된다.
- 그래야 내가 Member를 바꿨더니 MEMBER 테이블에 업데이트 쿼리 나가는구나 직관적으로 인식이 됨.
양방향 매핑시 가장 많이하는 실수
🟥 연관관계의 주인에 값을 입력하지 않음
Team team = new Team();
team.setName("TeamA");
em.persist(team);
Member member = new Member();
member.setName("member1");
//역방향(주인이 아닌 방향)만 연관관계 설정
team.getMembers().add(member);
em.persist(member);
- 연관관계의 주인만이 외래키 값을 등록 수정할 수 있다.
- 연관관계의 주인이 아닌쪽은 조회만 가능하다.
- JPA에서 update나 insert할 때는 mappedBy 된 쪽은 아예 안본다.
- mappedBy는 그냥 읽기 전용, 가짜 매핑인 것이다.
🟧 양방향 매핑시 연관관계의 주인에 값을 입력
Team team = new Team();
team.setName("TeamA");
em.persist(team);
Member member = new Member();
member.setName("member1");
team.getMembers().add(member);
//연관관계의 주인에 값 설정
member.setTeam(team);
em.persist(member);
순수한 객체 관계를 고려하면 항상 양쪽 다 값을 입력해야 한다.
- 위의 코드에서 team도 영속성 컨텍스트에 들어가있다.
- 연관관계의 주인에만 값 설정해주면 영속성 컨텍스트에 있는 team 객체의 members 컬렉션은 여전히 비어있는 상태다. (물론 커밋시점에 연관관계의 주인에 의해서 DB에는 업데이트 쿼리 날아간다.)
- 따라서 트랜잭션안에서 영속성 컨텍스트 flush하고 clear 되기 전에 해당 컬렉션 조회한다면 정상적인 결과가 출력되지 않는다.
- 또 하나의 문제점은 나중에 테스트 케이스 작성할 때이다.
- 테스트 케이스 작성시 JPA 없이도 동작하게 순수 자바 코드로도 작성한다.
- 그런 케이스에도 대비하기 위해서는 양쪽 다 입력해주는 것이 맞다.
🟨 결론
- 양방향 연관관계 매핑에서는 순수 객체 상태를 고려해서 항상 양쪽에 값을 설정하자!
- 연관관계 편의 메소드를 생성하자
- 양방향 매핑시에 무한루프를 조심하자
예) toString(), lombok, JSON 생성 라이브러리
🟩 정리
- 단방향 매핑만으로도 이미 연관관계 매핑은 완료
- 양방향 매핑은 반대 방향으로 조회(객체 그래프 탐색) 기능이 추가된 것 뿐이다.
- 생각보다 실무에서는 JPQL에서 역방향으로 탐색할 일이 많음
- 단방향 매핑을 잘 하고 양방향 매핑을 필요할 때 추가해도 된다.
(관계형 DB 테이블에 영향을 주지 않는다.)
연관관계 주인 정하는 기준
- 비즈니스 로직을 기준으로 연관관계 주인을 선택하면 안된다.
- 연관관계의 주인은 외래키의 위치를 기준으로 정해야한다.
해당 게시글은 인프런 김영한님의 <자바 ORM 표준 JPA 프로그래밍 - 기본편>을 듣고 정리한 내용입니다.
백엔드 꿈나무 🐥