#JPA-11 다양한 연관관계 매핑

[출처] 인프런 김영한 강사님 -자바 ORM 표준 JPA 프로그래밍 기본

연관관계 매핑시 고려사항 3가지

• 다중성

• 단방향, 양방향

• 연관관계의 주인

 

단방향, 양방향

• 테이블

    • 외래 키 하나로 양쪽 조인 가능

    • 사실 방향이라는 개념이 없음

• 객체

    • 참조용 필드가 있는 쪽으로만 참조 가능

    • 한쪽만 참조하면 단방향

    • 양쪽이 서로 참조하면 양방향(사실은 단방향이 두개 있는 것)

 

연관관계의 주인

• 테이블은 외래 키 하나로 두 테이블이 연관관계를 맺음

• 객체 양방향 관계는 A->B, B->A 처럼 참조가 2군데

• 객체 양방향 관계는 참조가 2군데 있음. 둘중 테이블의 외래 키 를 관리할 곳을 지정해야함

• 연관관계의 주인: 외래 키를 관리하는 참조

• 주인의 반대편: 외래 키에 영향을 주지 않음, 단순 조회만 가능

 

<여기서부터 '대' 의 왼쪽이 연관관계의 주인을 뜻함.>

1. 다대일 [N:1] @ManyToOne(제일 많이 쓰는 것)

다대일 단방향

• 가장 많이 사용하는 연관관계

• 다대일의 반대는 일대다

 

다대일 양방향

• 외래 키가 있는 쪽이 연관관계의 주인

• 양쪽을 서로 참조하도록 개발

 

 

 

2. 일대다 [1:N] @OneToMany(그 다음으로 많이 쓰는 것)

실무에서 거의 이모델은 지향하지 않는다.

일대다 단방향(팀은 멤버를 알고싶은데 멤버는 팀을 알고싶지 않은 상황)

일대다 Team class 설정

일대다 JpaMain class 설정

실제로 날라가는 쿼리 (쿼리가 한번 더 나간다. Team에 없기 때문에)

• 일대다 단방향은 일대다(1:N)에서 일(1)이 연관관계의 주인

• 테이블 일대다 관계는 항상 다(N) 쪽에 외래 키가 있음

• 객체와 테이블의 차이 때문에 반대편 테이블의 외래 키를 관리하 는 특이한 구조

• @JoinColumn을 꼭 사용해야 함. 그렇지 않으면 조인 테이블 방식을 사용함(중간에 테이블을 하나 추가함)

 

일대다 단방향 매핑의 단점

• 내용을 잘모르는 사람은 난 Team에 손을 댓는데 왜 MEMBER TABLE에 UPDATE가 날라가지 하고 오해를 할 수 있다.

• 실무에서는 TABLE이 한 두개가 아니기 때문!

• 엔티티가 관리하는 외래 키가 다른 테이블에 있음

• 연관관계 관리를 위해 추가로 UPDATE SQL 실행

• 일대다 단방향 매핑보다는 다대일 양방향 매핑을 사용하자

   (객체적으로 손해를 보더라도<Member에서 Team 에 갈일이 없는데 만들지라도> 양방향으로 매핑을 사용한다.)

 

일대다 양방향

• JPA 스팩상 이런 매핑은 공식적으로 존재X

• @JoinColumn(insertable=false, updatable=false)

 

         insertable updateble을 넣음으로써 읽기전용이 되버린다(양뱡향 매핑이랑 똑같은 상태가 된다.)

• 읽기 전용 필드를 사용해서 양방향 처럼 사용하는 방법 (실무에서 복잡하게 하다 보면 사용하게 될 수도 있다.)

• 다대일 양방향을 사용하자 (일대다 양방향 고통스럽게 사용하지말고 다대일 양방향을 사용하자)

 

 

3. 일대일 [1:1] @OneToOne(가끔 나온다)

일대일 관계

• 일대일 관계는 그 반대도 일대일

•  주 테이블이나 대상 테이블 중에 외래 키 선택 가능(외래키 아무때나 가능 1:1관계이기 때문에 대칭적이기 때문에)

    • 주 테이블에 외래 키

    • 대상 테이블에 외래 키

• 외래 키에 데이터베이스 유니크(UNI) 제약조건 추가가 되야지 1:1이된다.

(유니크 제약조건을 안넣고도 쓸수는 있지만 이렇게되면 Application에서 관리를 잘해야한다.)

 

일대일: 주 테이블에 외래 키 단방향

• 다대일(@ManyToOne) 단방향 매핑과 유사

Member class

Locker class

일대일: 주 테이블에 외래 키 양방향

• 다대일 양방향 매핑 처럼 외래 키가 있는 곳이 연관관계의 주인

• 반대편은 mappedBy 적용

Member class

Locker class

 

일대일: 대상 테이블에 외래 키 단방향

• 단방향 관계는 JPA 지원X

• 양방향 관계는 지원

 

일대일: 대상 테이블에 외래 키 양방향

• 사실 일대일 주 테이블에 외래 키 양방향과 매핑 방법은 같음

일대일 정리

• 주 테이블에 외래 키

    • 주 객체가 대상 객체의 참조를 가지는 것 처럼 주 테이블에 외래 키를 두고 대상 테이블을 찾음

    • 객체지향 개발자 선호

    • JPA 매핑 편리

    • 장점: 주 테이블만 조회해도 대상 테이블에 데이터가 있는지 확인 가능

    • 단점: 값이 없으면 외래 키에 null 허용

• 대상 테이블에 외래 키

    • 대상 테이블에 외래 키가 존재

    • 전통적인 데이터베이스 개발자 선호

    • 장점: 주 테이블과 대상 테이블을 일대일에서 일대다 관계로 변경할 때 테이블 구조 유지

    • 단점: 프록시 기능의 한계로 지연 로딩으로 설정해도 항상 즉시 로딩됨(프록시는 뒤에서 설명)

4. 다대다 [N:M] @ManyToMany (실무에서 쓰면 안되는 것)

• 관계형 데이터베이스는 정규화된 테이블 2개로 다대다 관계를 표현할 수 없음

• 연결 테이블을 추가해서 일대다, 다대일 관계로 풀어내야함

 

 

• 객체는 컬렉션을 사용해서 객체 2개로 다대다 관계 가능

단방향 Product class

양방향 products

Member class

다대다

• @ManyToMany 사용

• @JoinTable로 연결 테이블 지정

• 다대다 매핑: 단방향, 양방향 가능

 

다대다 매핑의 한계

• 편리해 보이지만 실무에서 사용X

• 연결 테이블이 단순히 연결만 하고 끝나지 않음(실무에서는 단순연결? 말도안돼! 언제변경했는지 추가 정보까지 더들어가기때문! query도 이상하게 나간다 중간테이블이 숨겨져있기 때문에)

• 주문시간, 수량 같은 데이터가 들어올 수 있음

 

다대다 한계 극복

• 연결 테이블용 엔티티 추가(연결 테이블을 엔티티로 승격)

• @ManyToMany -> @OneToMany, @ManyToOne

 

Member class

MemberProduct class

Product class