JPA #5 데이터 중심 설계의 문제점, 연관 관계 매핑

📌 테이블간의 관계를 객체로 구현하는 방법

기존의 JDBC를 이용하던 방식은 객체 설계를 테이블에 맞춰야한다는 단점이 있었다. 객체가 아닌 데이터 중심의 설계.

public class Order{
    private Long id;
    private Long memberId; // 연관 관계는 단순히 id로 표현
    
    // ... 이하 생략 ... //
}

private Member member // 이렇게 참조를 가지고 있을 수 없다.
member.getAddress().getCity() // 이런건 당연히 불가능

객체 그래프 탐색이 불가능하고, 단순한 id 값만 가지고 있을 뿐 객체끼리 어떠한 관계도 연결되어있지 않다.

 

DB에는 연관관계가 연결되어있지만, 객체에는 단순 id 값만 가지고 있을 뿐 어떠한 안전장치도 없다.

 

JPA로 코드를 옮기면, 아래와 같이 만들 수 있겠다.

@Entity
public class Member {

    @Id
    @GeneratedValue
    private Long id;
    
    @Column(name = "USERNAME")
    private String name;
    
    @Column(name = "TEAM_ID")
    private Long teamId; //만약 Team 객체가 존재하지 않는다면?
…
}

@Entity
public class Team {

    @Id
    @GeneratedValue
    private Long id;
    private String name; 
…
}

 

아무리 JPA를 사용한다고 한들, 이렇게 지정해버리면 식별자(id)를 이용해서 한번 더 조회해야한다.

이렇게 객체지향을 포기하고 테이블에 맞춰 모델링하는게 맞는 방법일까?

//회원 저장
 Member member = new Member();
 member.setName("member1");
 member.setTeamId(team.getId()); // 그냥 id값을 저장
 em.persist(member);

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

//연관관계가 없음. 그냥 id 값으로 조회하는 것일 뿐임
 Team findTeam = em.find(Team.class, team.getId());

• DB 테이블은 외래 키와 조인을 이용해서 연관된 테이블을 찾는다.
• 객체에서는 외래 키라는 개념이 없다. 참조를 통해서 연관된 객체를 찾는다.

객체지향은 어떠한 문제를 각 객체들이 협력하고 책임을 나눠 해결한다.

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

 

 

 

📌 단방향 연관관계 매핑

@ManyToOne으로 단방향 매핑을 설정하고

@JoinColumn으로 조인할 칼럼을 지정해주면 된다. 애노테이션 으로 매핑이 끝난다.

@Entity
public class Member {

    @Id
    @GeneratedValue
    private Long id;
    
    @ManyToOne
    @JoinColumn(name = "TEAM_ID")
    private Team team;
	
}

 

이렇게하면 놀랍게도 사용할 때 그냥 객체를 사용하듯이 사용하면 된다.

심지어 한 트랜잭션에서 둘 다 생성하면 1차 캐시를 이용하기 때문에, 커밋 전에는 DB 쿼리를 날리지도 않는다.

Member와 Team은 [ N:1, Many ➡ One ] 관계이다.

 //팀 저장
 Team team = new Team();
 em.persist(team);
 
 //회원 저장
 Member member = new Member();
 member.setTeam(team); //단방향 연관관계 설정, 참조 저장
 em.persist(member)

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

//참조를 사용해서 연관관계 조회
Team findTeam = findMember.getTeam();

만약 다른 Team으로 교체할 때도, 그냥 Member.setTeam(~)으로 변경하면 DB 외래키 값이 업데이트된다.

 

 

📌 양방향 연관관계 매핑

잘 생각해보면, DB 테이블에는 '단방향 연관관계'라는 개념 자체가 존재하지 않는다.

애초에 외래 키로 관계를 맺었다면, 양쪽에서 참조가 가능하기 때문이다.

 

객체는 그렇지 않다. 참조 값이 없으면 접근이 불가능하다. 그래서 단방향 참조 2개를 만들어 양방향으로 만들어야한다.

다만 외래키로 관계가 맺어졌다면 단방향, 양방향의 여부와 상관없이 DB 테이블은 똑같다는 걸 인지하자.

DB는 외래키가 있으면 양쪽에서 참조 가능하다. 객체는 그렇지 않다.

우선 Member에서 다른점은 없다. 단방향 매핑과 동일하다.

@Entity
public class Member {

    @Id
    @GeneratedValue
    private Long id;
    
    @ManyToOne
    @JoinColumn(name = "TEAM_ID")
    private Team team;
	
}

Team에서는 @OneToMany를 사용해야한다. 여러 Member를 가지고 있기 때문에 컬렉션을 이용해야한다.

* 단, mappedBy를 제대로 이해하고 있지 않으면 DB에 제대로 반영되지 않는데, 이는 아래에서 알아보자.

@Entity
public class Team {

    @Id
    @GeneratedValue
    private Long id;
    
    @OneToMany(mappedBy = "team") // Member.team 이 주인임.
    List<Member> members = new ArrayList<Member>();

}

 

이제 Team에서 Member를 조회할 수 있게 되었다.

//조회
 Team findTeam = em.find(Team.class, team.getId()); 
 int memberSize = findTeam.getMembers().size(); //역방향 조회

 

 

✔ 연관관계의 주인과 (mappedBy="~")

mappedBy는 연관 관계의 주인(=외래키를 수정할 수 있는 쪽)을 설정할 때 사용된다.

@OneToOne, @OneToMany, @ManyToMany 에서 사용할 수 있는 옵션이며, mappedBy가 없다면 JPA에서는 양방향 관계로 설정하지 않은 상태로 테이블을 매핑한다.

// List<players>가 관계의 주인임을 나타내기위해, mappedBy = "team" 을 적어준다.
@OneToMany(mappedBy = "team") // Member.team
private List<Player> players = new ArrayList<Player>();

 

그런데 @OneToMany를 사용할 때, 반드시 mappedBy로 연관관계의 주인을 지정해줘야한다. 왜 그럴까?

@OneToMany // ?? 그냥 이렇게 사용해도 별 문제없는거 아닌가?
List<Member> members = new ArrayList<Member>();

 

그 이유는 객체는 참조를 2개를 가지지만, DB는 외래키 1개로 양방향 참조가 가능하기 때문이다.

• DB에서는 1개의 외래키로 테이블을 서로 참조할 수 있다.
• 객체에서는 단방향 참조가 2개가 만들어진다. 즉 외래키 역할을 하는 참조가 2개가 생성된다.

DB에 한 관계에 외래키를 2개를 넣는 기능은 존재하지 않는다. 그렇게 할 이유도 없고

별로 안중요해보여도, 이는 매우 중요하다. 외래키를 변경하는건 '한 객체만' 가능해야 하기 때문이다.

• DB는 외래키가 1개지만, 객체에는 양쪽 두 가지 참조값이 있다.
    Member ➡ Team 참조값
    Team ➡ Member 참조값
  
  
• 그냥 두 개의 참조값 다 매핑하면 안되나?
    극단적으로 Member.team에는 값을 넣고, Team.members에는 값을 넣지 않는다면?
    반대로 Member.team은 값을 넣지 않고, Team.members에만 값을 넣는다면?
    아니면 둘 다 다른 값을 동시에 넣는다면?
    같은 참조인데 양쪽의 값이 다르다면 JPA는 무엇을 기준으로 변경하지?
  
  
• 따라서 규칙이 생김
    둘 중 하나로 외래키를 관리해야 한다 ➡ 연관관계(외래키)의 주인
    (주인이 Member) Member에 있는 team값이 바뀌었을 때 외래키 값을 업데이트 해야하나.
    (주인이 Team) Team에 있는 members값이 바뀌었을 때 외래키 값을 업데이트 해야하나.

그래서 JPA에서는 외래키를 다룰 연관관계의 주인을 정하고, 주인이 아닌 쪽은 읽기만 가능하도록 설계되어있다.

 

즉 연관관계의 ✨주인이 아닌 쪽에서는, 참조값을 통해 값을 수정할 수 없다. 수정해도 DB에 반영되지 않는다.

또 아무 생각없이 주인을 정해버리면 객체처럼 사용하기 어려워지고, 전혀 상관없는 테이블에 DB 쿼리가 발생하게 된다.

 

 

✔ 누구를 연관관계의 주인으로 정해야하는가?

해당 외래 키가 있는 곳을 주인으로 정해야한다.

비즈니스마다 Team이 주인이 될 수도, Member가 주인이 될 수도 있다. 그러나 보통은 다대일 방향으로, Many가 주인이 되는게 좋다. 위의 예제에서는 ManyToOne 관계에서 Many쪽, Member.team이 연관관계의 주인이다.

물론 Team을 주인으로 정할 수 도 있다. 왜 그렇게 하면 안될까?

• 하나의 팀은 여러 Member를 가진다. 만약 Team을 수정하게되면 모든 members에게 DB 쿼리가 발생하게 된다.
• Member에서 외래키를 가지고 있지 않기때문에, Member가 스스로 Team을 변경할 수 없게 되버린다.

 

별로 어렵지않지만 실제 코드에서 정말 정말 많이 실수하는 부분이다. JPA를 이해하고 있지않으면 찾기도 어렵다.

아래 코드를 실행했을 때 DB 외래키에는 null이 들어가있다.

// 해당 JPA코드는 Member와 Team이 연결되지 않는다. DB 외래키에는 null이 들어가있다.
// 무엇이 문제인지 보이는가?
 Team team = new Team();
 team.setName("TeamA");
 
 em.persist(team);
 
 Member member = new Member();
 member.setName("member1");
 team.getMembers().add(member);
 
 em.persist(member)

 

아래와 같이 외래키를 가진 연관관계의 주인 (Member)에서 등록해주어야 된다.

member.setTeam(team);  //연관관계의 주인에 값 설정

 

주인쪽인 member에서 단방향 매핑만 해주더라도, 양방향 연관관계를 사용할 수 있다.

// Team에는 연관 관계 설정을 하지 않았음.
 Team team = new Team();
 team.setName("TeamA");
 em.persist(team);
 
// Member에서는 team과 관계 설정을 하였음.
 Member member = new Member();
 member.setName("member1");
 member.setTeam(team);
 em.persist(member)
 
// 확실하게 DB에서 가져오기 위해 영속성 컨텍스트를 완전히 제거
  em.flush();
  em.clear();

// Team에서 연관관계를 지정하지 않았음에도, 아래와 같이 사용해도 member가 정상 참조됨.
Team findTeam = em.find(Team.class, team.getId());
findTeam.getMembers();

JPA 동작시 Team 엔티티를 참고해서, 쿼리가 나갈 때 연관된 member를 가지고 오기 때문이 그렇다.

 

 

✔ 양방향 연관관계는 양쪽에서 맺어주는게 좋다.

위에서 말한대로 주인쪽 (Member)에서만 연관관계를 맺어도, 양방향으로 사용이 가능하긴하다.

하지만 실제 사용은 아래와 같이 관계를 붙여서 양쪽에서 다 맺어주는게 맞다.

member.setTeam(team);
team.getMembers().add(member); // 엥? 이건 DB에 반영이 안된다면서요? 귀찮게 왜 굳이

더 확실한 방법은, 그냥 원자적으로 동작하게 Member에 관계를 설정하는 순간 바로 양방향 관계를 맺어버리는 것이다.

Team에서 아래와 같이 설정해줘도 상관은 없다. 다만 양쪽 다 하면 무한루프 & 버그의 위험이 있으므로 하나만 하자.

@Entity
public class Member {

    @Id
    @GeneratedValue
    private Long id;
    
    @ManyToOne
    @JoinColumn(name = "TEAM_ID")
    private Team team;
	
    public void setTeam(Team team){
    	this.team=team;
        team.getMembers().add(this); // 바로 양쪽 연관관계를 설정.
    }
}

 

굳이 이렇게 하는건 Java를 사용할 때 객체지향적으로 자연스러워서 그런 것도있지만, 내부동작에도 차이가 있다.

• 한 트랜잭션 내에서 제대로 조회가 되지 않을 수 있다.

DB에 반영이 되는 시점에는 상관없지만, 아래와 같이 한 트랜잭션에서는 사용 불가능하다. 당연히 커밋 되기전 순수한 Team 객체에는 아직 값이 들어가지 않았으니까.

// Team에는 연관 관계 설정을 하지 않았음.
 Team team = new Team();
 team.setName("TeamA");
 em.persist(team);
 
// Member에서는 team과 관계 설정을 하였음.
 Member member = new Member();
 member.setName("member1");
 member.setTeam(team);
 em.persist(member)

// 조회하면 null이 나온다.
// 당연한거다. 커밋되지 않았으면 순수한 자바 객체니까. 값을 넣은적이 없잖아?
 Team findTeam = em.find(Team.class, team.getId());
 findTeam.getMembers();

 

Team에서 아래와 같이 설정해줘도 상관은 없다. 다만 양쪽 다 하면 무한루프 & 버그의 위험이 있으므로 하나만 하자.

양쪽으로 설정하지 말라는 이유와 같게 toString(), lombok, JSON 등을 사용할 때 양방향 매핑을 잘못사용하면 무한루프가 생길 수 있다. 이를 조심해서 사용하도록 하자.

 

제일 좋은 방법은 lombok에서 team.toString() 같은 걸 아예 쓰지말고, 스프링 컨트롤러에서 Entity 대신 DTO를 반환하는 것이다. 이것만 주의해도 큰 문제가 안생긴다.

// 이렇게 양쪽으로 무한 참조를 하면서 앱이 죽어버릴 수 있다.
public toString(){
	return "member=" + name + "team" + team; // team.toString() 호출
}

public toString(){
	return "team members" + members; // member.toString() 호출
}

 

📌  결론: 양방향 매핑을 되도록이면 사용하지 마세요.

DB 테이블을 처음 설계할 때, 단방향 매핑만으로 설계를 완료하는 게 좋다.

어차피 ManyToOne 관계가 나오면 조회하는 방향을 쉽게 알 수 있기 때문이다.

 

위에서 배웠겠지만 객체입장에서 양방향 매핑을 사용하는건 정말 머리 아픈 일이다. 최초 설계에는 단방향만 사용하자.

 

그리고 나서 양방향 매핑이 꼭 필요할 때 (ex JPQL을 이용해서 역방향으로 탐색할 때) 사용하는게 좋다.

어차피 양방향, 단방향은 객체에만 있는 개념이고 DB 테이블에는 아무런 영향이 없어서 필요할 때 쉽게 변경 가능하다.