연관관계 매핑시 고려사항 3가지
- 다중성 : @ManyToOne, @OneToMany, @OneToOne, @ManyToMany
- 단방향, 양방향
- 연관계의 주인
어노테이션을 사용하여 관계를 정확히 매핑해주고, 객체(Entity)를 단방향 또는 양방향으로 사용할지 충분히 고려한 후 양방향으로 설정 했다면 연관관계 주인을 설정함으로써 한쪽에서만 등록,수정이 일어날 수 있도록 한다.
1. @ManyToOne 다대일 [N:1]
단방향
가장 많이 사용되는 연관관계로 한쪽(Member)에서만 조회, 등록, 수정 하도록 매핑양방향
양방향으로 설정하게 되면 Member와 Team객체에 서로 참조할 수 있는 필드를 생성하여 각각의 관계를 설정해준다.
이렇게되면 양쪽에서 등록, 수정이 일어날 수 있기 때문에 연관관계의 주인을 정해 mappedBy속성을 사용하여 한쪽에서만 등록,수정이 가능하고 다른쪽에서는 읽기만 가능하도록 설정해준다.
2. @OneToMany 일대다 [1:N]
1인 쪽에서 외래키를 관리하겠다는 뜻이다 ( 이 모델은 추천하지 않는다고 한다 )
- 단방향
DB입장에서는 [ 1 : N ] 관계의 테이블에서 무조건 N쪽에 외래키가 들어가야한다
(하나의 팀은 여러명의 맴버를 갖을 수 있고, 맴버는 하나의 팀만 갖을 수 있다고 했을 때, 당연히 맴버 테이블에 외래키가 있어야한다.)
그렇다면 Team의 List members를 수정했을 때 다른 테이블인 MEMBER테이블의 TEAM_ID(FK)를 변경 해야한다.
그렇기 때문에 다대일 관계에서와 달리 update쿼리가 추가적으로 나가게 된다.
성능상 단점이 될 뿐만 아니라 코드만 봤을 때 team객체를 수정했는데 update쿼리가 member테이블로 나가기 때문에 혼동될 수 있다. ( 권장하지 않는다. )
📌 일대다(1:N) 단방향은 일(1)인 쪽이 연관관계의 주인이다 하지만 테이블은 항상 다(N)쪽에 외래 키가 있으므로 이러한 객체와 테이블의 차이 때문에 반대편 테이블의 외래 키를 관리하는 특이한 구조가 되기때문에 권장하지 않는다.
- 양방향
지원되는 기능은 아니지만 양방향 처럼 사용하기위해 다(N) 쪽을 insert와 update 기능을 차단하고 읽기만 가능하도록 설정하면 등록과 수정을 일(1) 쪽에서만 가능하기 때문에 양방향 매핑과 똑같이 가능하다
( 읽기 전용 필드를 사용해서 양방향 처럼 사용할 수 있지만 권장하지 않는다 )
3. @OneToOne 일대일 [1:1]
외래 키에 데이터베이스 유니크 제약조건이 있어야한다.
-
단방향 - 주 테이블에 외래 키
다대일 단방향 매핑과 유사하다.
-
양방향 - 주 테이블 외래 키
다대일 양방향 매핑 처럼 외래 키가 있는 곳이 연관관계의 주인으로 반대편은 mappedBy적용
-
단방향 - 대상 테이블에 외래 키
Member를 연관관계의 주인으로 하고싶은데 외래 키가 대상 테이블(LOCKER)에 있는 경우를 말하며 이전에 했던 일대다(OneToMany)단방향과 같은 경우이다.
이러한 경우는 JPA에서 지원하지 않는다.
-
양방향 - 대상테이블에 외래 키
일대일 주 테이블의 외래키 양방향과 매핑 방법은 같다.
4. @ManyToMany 다대다 [N:M]
관계형 데이터베이스는 정규화된 테이블 2개로 다대다 관계를 표현할 수 없다, 연결 테이블을 추가해서 일대다, 다대일 관계로 풀어내야 한다.
하지만 객체는 컬렉션을 사용해서 객체 2개로 다대다 관계가 가능하다.
-
다대다 매핑의 한계
편리해 보이지만 실무에서 사용하면 안된다.
연결 테이블이 단순히 연결만 하고 끝나지 않고 주문시간, 수량 같은 데이터가 들어올 수 있다.
-
다대다 매핑의 한계 극복
연결 테이블용 엔티티 추가
위 코드처럼 연결 테이블용 엔티티를 만들어 양쪽 테이블과 연관관계 매핑을 ManyToMany에서 OneToMany, ManyToOne으로 각각 설정해준다.
📚 참고 및 자료 출처 : 자바 ORM 표준 JPA 프로그래밍 - 기본편 (김영한)
