- 객체들의 관계를 RDB로 나타낼때 사용된다.
@JoinColumn은 RDB의 외래키컬럼 된다.
객체와 RDB의 개념불일치(임피던스 불일치)
- 객체는 메모리주소를 저장하는 방식으로 연결을 처리한다.
- RDB는 다른 테이블의 키 값을 저장해 연결을 처리한다.
1:N 관계에서 객체는 컬렉션이라는 개념으로 1:N을 처리한다. 하지만 RDB는 정규화를 지원하기 위해 N쪽에 단일값을 가지는 구조가 된다. 이 때문에 메모리에 저장되는 객체와 RDB의 구조가 완전 반대가 된다. 이러한 불일치를 극복하기 위한 방법이 외래키 컬럼을 엔티티에 표시하는 것이고, JPA 에서는@JoinColumn를 사용하는 것이다.
…
이러한 객체를 데이터베이스에 저장하려면 이러한 참조를 저장하는 것이 아주 중요하다. 그러나 개게에 있는 데이터는 실행중인 프로그램의 특정 인스턴스에 한정되므로 원시 데이터 값을 그대로 저장할 수는 없다. 또한 객체가 다른 객체 참조의 컬렉션을 가진 경우에는 문제가 더 어려워진다. 이러한 구조는 관계형 데이터베이스의 제 1정규형을 위반하는 것이다.
엔터프라이즈 애플리케이션 아키텍쳐 패턴 p251 <외래 키 매핑>
…
@ManyToOne 과 같이 사용하는 이유
- 메모리에서 다른 객체와 관계를 맺을때 1:N 이라는 것을 나타내기 위해 사용되고, 이것이
@JoinColumn과 같이 사용되는 이유는 hibernate에서는 RDB에서 다른 객체와의 관계를 위에서 설명한 외래키 매핑 방식으로 나타내도록 되어 있기 때문이다. 그래서@JoinColumn을 쓰지 않으면 자동으로 외래키 컬럼을 추가해서 적용하게 된다.
관계의 주인
JPA를 복습하면서 이 개념이 생소했다. 관계의 주인 이라니.. master/slave의 master를 의역한것일까? 원문을 확인해보니 정말 owner 적혀있었다.
외래키를 기준으로 값을 추적한다.
왜 이런 표현을 하게 됬을까? 몇가지 자료를 찾아보고 나름대로 내린 결론은 다음과 같다.
위에서 설명한 개념불일치 때문에 외래키를 엔티티에 표시해야 했고 엔티티의 정보가 수정됬을 때, 외래키 값을 추적해서 수정하도록 구현되어 있었기 때문에 이 관계를 주인 이라고 표시한것 같다.
관계의 주인 단방향관계, 부가적인 양방향관계
엔티티 양방향 관계, 단방향 관계도 이런 배경을 알고 보면 이해하기 좀더 쉬웠다. 위 내용대로라면 양방향 관계를 구성하는 두개의 관계는 서로 동등한 역할의 관계가 아니다. 주인 관계는 필수지만, 그 역방향 관계는 주인이 아닌쪽에서 데이터가 수정되었을 경우를 위해서 만들어진 관계 이기 때문에 선택해서 만들수 있는 관계이다.
Mybatis와 DDD
이 내용을 정리하면서 이전 프로젝트에서 mybatis를 ORM 처럼 사용하려고 했을때 겪었던 벽이 떠올랐다.
지금 생각해보면 내가 놓치고 있었던 것이 위 개념불일치를 알고 있음에도 이것을 적용한 설계를 하지 못했던게 아닌가 싶다.
이 부분에 대해서는 좀더 정리후에 글로 적어볼 계획이다.
참고자료
java - What is the “owning side” in an ORM mapping? - Stack Overflow
엔터프라이즈 애플리케이션 아키텍처 패턴(재출간판) : 네이버 도서
JSR 338: Java Persistence API, Version2.2
