연관관계 매핑

- 데이터 중심 설계의 문제점

데이터 중심으로 JPA를 설계하게 된다면,

• 객체 설계를 테이블 설계에 맞춘 방식
• 테이블의 외래키를 객체에 그대로 가져옴
  ex ] private Long memberId;
• 객체 그래프 탐색이 불가능 [끊긴다].
  
  
• 참조가 없으므로 UML도 잘못된다.

따라서 객체를 DB에 맞춰 설계하는 것을 연관관계 매핑을 통해 해결한다.

 

' 객체지향 설계의 목표는 자율적인 객체들의 협력 공동체를 만드는 것이다 '

객체를 테이블에 맞춰 데이터 중심으로 모델링하게 된다면, 객체간의 협력 관계를 만들 수 없다.

• 테이블은 외래 키로 조인을 사용해 연관 테이블을 찾는다.
• 객체는 참조를 사용해서 연관 객체를 찾는다.

 

양방향 연관관계와 연관관계의 주인

• 양방향 매핑 규칙
  - 객체의 두 관계중 하나를 연관관계의 주인으로 지정
  - 연관관계의 주인만이 외래 키를 관리(등록, 수정)
  - 주인이 아닌쪽은 읽기만 가능
  - 주인은 mappedBy 속성 사용 X
  - 주인이 아니면 mappedBy 속성으로 주인 지정
  
  
• 연관관계의 주인
  외래키가 있는 곳을 주인으로 설정하는것이 좋다.
  -> 보통 Many에 속하는 곳이 연관관계의 주인이 된다.

외래키를 제공하는 곳을 주인으로 설정하고 객체에서 속성값을 변경하면 외래키를 제공받는 쪽의 테이블이 변경된다 (?)
-> 무언가 이상함

 

 

양방향 연관관계의 주의

• 값을 변경하려면 연관관계의 주인을 변경해주어야 한다
• 순수 객체 상태를 고려하기 위해 양쪽에 값을 설정하여야 한다
• 따라서 연관관계 편의 메소드를 생성하자

 

 

결론

1. 단방향 매핑으로 설계를 끝 마쳐야 한다
2. 양방향 매핑은 필요할 때 추가해주면 된다 [ 테이블에 영향을 주지 않는다 ]

특정 MemberA의 OrderList를 조회할 때, Order의 FK Member_Id를 통해 주문을 조회해야 하는데
객체구조를 생각하여 양방향 연관관계를 설계하게 되면 MemberA에 OrderList를 생성하여 OnetoMany 매핑을 해준 뒤
연관관계 편의 메소드를 생성하여 OrderList에 주문값을 추가, Order에 주문멤버를 set 해줘야 한다.
따라서 단방향 매핑을 통해 필요한 비지니스는 그 객체에서 끊어줘야 한다.