들어가며
오늘은 연관관계에 대해 간략하고 빠르게 알아보자.
연관관계
엔티티들은 다른 엔티티와 관계를 갖는다. 객체는 참조, 주소값을 이용하여 관계를 맺고 테이블은 외래 키를 사용하여 관계를 맺는다. 객체의 참조와 테이블의 외래 키를 매핑하는 것이 바로 연관관계 매핑의 목표이다.
- 방향 : 단방향과 양방향이 있다. 방향은 객체 관계에서 존재하고, 데이터베이스의 테이블 간 관계는 항상 양방향을 갖는다.
- 다중성 : 다대일, 일대다, 일대일, 다대다와 같은 다중성이 있다.
- 연관관계의 주인 : 양방향 연관관계에서 어떤 객체가 연관관계의 주인이 될 것인지를 결정한다.
단방향 연관관계
node와 next 포인터로 이루어 진 연결리스트를 생각나게 하는 연관관계이다. 조금 더 쉬운 예로는 팀과 회원이 있다. 회원 객체는 Member.team 과 같이 팀 객체와 연관관계를 맺는다. -> 회원이 팀을 소유한다.
즉 회원 객체와 팀 객체는 단방향 관계를 갖는다. 회원은 team 필드를 통해서 팀을 알 수 있지만 반대로 팀은 회원을 알 수 없다. 객체에서는 있을 수 있으나 데이터베이스의 테이블에서는 있을 수 없다. 테이블은 항상 양방향이기 때문이다. 그러나 참조를 통한 연관관계는 항상 단방향이다. 만약 객체에서의 양방향 연관관계를 갖기 위해서는 반대 방향에 필드를 추가해서 참조를 보관해야 한다. 이것은 양방향 처럼 보이나 사실은 서로 다른 단방향 관계를 2개 갖는 것이다. ( 양방향이라고 단순히 이해하면 편하다. )
객체는 참조를 통해 연관관계 탐색이 가능하다. 이를 객체 그래프 탐색이라 한다.
양방향 연관관계
이전까지는 회원에서 팀을 추가해야만 했다. 양방향 연관관계에서는? 팀에서 회원을 추가하는 행위를 할 수 있다. ( 굿 )
책에서는 연관관계 마다 객체와 테이블을 분리하여 설명하고 있다. 객체에서는 Team에서는 여러 멤버를 갖기 때문에 Team.members가 되고, list 형태로 보관하게 될 것이다. ( JPA 에서는 List를 포함한 Collections을 사용 가능하다. ) 데이터베이스 테이블은 외래 키 하나로 양방향 조회가 가능하다.
연관관계의 주인
JPA에서는 OneToMany, ManyToOne 과 같은 매핑 어노테이션을 제공한다. 그 안에 mappedBy 속성을 갖고 있다. 해당 속성을 통해 연관관계의 주인을 명시할 수 있다. 테이블에서는 외래 키 하나로 두 테이블의 연관관계를 관리할 수 있다. 그런데 객체에서는 단방향 매핑을 두 개 갖는다고 했기 때문에 연관관계를 관리하는 포인트가 두 개로 증가한다. 엔티티를 양방향 연관관계로 설정하게 되면 객체의 참조와 외래 키 사이의 차이가 발생한다. 외래키와 같이 관리하기 위하여 두 객체 연관관계 중 하나를 정해서 테이블의 외래키를 관리해야 하는데 이것을 연관관계의 주인이라고 한다. ( 위에서 중요했던 3가지 요소 중 하나이다. 외래키를 관리하는 곳! 이라고 생각하면 편하다. )
연관관계의 주인은 데이터베이스 연관관계와 매핑되고, 키를 관리한다. 즉, 등록, 삭제, 수정의 권한이 있다. 반면, 다른 테이블은 단지 읽기만 가능하다. 앞서 말한 mappedBy 속성은 말 그대로 매핑된, 주인의 반대편을 의미한다. 그렇다면 연관관계의 주인인, 외래 키 관리자는 어떤 쪽이 되어야 할까? -> 앞서 말했듯이 키를 가지고 있다면 권한이 발생한다. 반대편은 읽기만 가능하다. 데이터베이스 테이블의 다대일, 일대다 관계에서는 항상 다 쪽이 연관관계의 주인이 된다.
주의사항
양방향 연관관계에서는 외래 키를 갖는, 즉 연관관계의 주인만 권한을 갖는다. 따라서 주인이 아닌 곳에서는 값을 외래 키 값을 변경할 수 없다. 그렇다면 주인이 아닌 곳에는 값을 저장하지 않아도 될까?
객체 관점에서 양쪽 방향 모두 값을 입력해주는 것이 안전하다.
다음과 같이 책에 기재되어 있다. 해당 이유는 객체를 고려하여 프로그래밍하기 때문이다. 데이터베이스 관점에서는 크게 의미가 없으나 객체 관점에서는 양쪽 모두 관계를 맺어주는 편이 옳다고 한다.
