<aside> ❗

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

• 다중성
• 단방향, 양방향
• 연관관계의 주인 </aside>

<aside> ❗

다중성

• 다대일 : @ManyToOne
• 일대다 : @OneToMany
• 일대일 : @OneToOne
• 다대다: @ManyToMany → 실무에서 사용 X → 중간 엔티티로 둬서 분리해야 함 </aside>

<aside> ❗

단방향, 양방향

[테이블]

• 외래 키 하나로 양쪽 조인 가능
• 사실 방향이라는 개념이 없음

[객체]

• 참조용 필드가 있는 쪽으로만 참조 가능
• 한쪽만 참조하면 단방향
• 양쪽이 서로 참조하면 양방향 → 단방향 두 개 </aside>

<aside> ❗

연관관계 주인

• 테이블은 외래 키 하나로 두 테이블이 연관관계를 맺음
• 객체 양방향 관계는 A → B, B → A 처럼 참조가 2군데
• 객체 양방향 관계는 참조가 2군데 있음, 둘 중 테이블의 외래 키를 관리할 곳을 지정해야 함
• 연관관계의 주인 : 외래 키를 관리하는 참조 -> N 쪽이 외래 키를 가지므로 N 쪽인 곳에 참조 필드 추가
• 주인의 반대편 : 외래 키에 영향을 주지 않음, 단순 조회만 가능 - 읽기만 가능 </aside>

<aside> ❗

다대일 [N : 1]

• 가장 많이 사용

• DB 테이블 설계상 Member가 N, Team 1
• N 쪽에 외래키가 간다.
• Member에서 Team으로만 참조할 것이다. → Team 참조 타입 변수를 만들고 매핑을 걸면 된다.

@ManyToOne
@JoinColumn(name = "TEAM_ID") // TEAM_ID는 외래키 이름 
private Team team;

</aside>

<aside> ❗

다대일 양방향

• 1인 쪽에 List<N타입> 참조 변수를 생성하고 매핑을 걸면된다. 이 때, **mappedby로 의존관계 주인의 객체이름으로 설정**한다.
• **** 반대쪽을 추가한다고 해서 테이블에 영향을 주지 않음 (읽기 전용) ****

@OneToMany(mappedBy = "team")
private List<Member> members = new ArrayList<>();

</aside>

<aside> ❗

정리

• @ManyToOne @JoinColumn(name ="")에서 name의 값은 참조하고자 하는 외래키 이름을 등록한다.
• @OneToMany(mappedBy= "") mappedBy의 값은 참조하고자 하는 객체 이름을 등록하면 된다. </aside>

<aside> ❗

일대다

일대다 단방향

• 팀은 멤버를 알아야 하는데, 멤버는 팀을 알기를 원하지 않는 경우
• DB 입장에서는 무조건 다 쪽에 외래키가 들어가야 함
• 다른 Team의 members 값을 바꿨을 때, Member 테이블의 외래키를 업데이트 해줘야 함
• 현재 Team의 members가 연관관계 주인

일대다 단방향

• 일대다 단방향은 일대다에서 일이 연관관계의 주인
• 테이블 일대다 관계는 항상 다 쪽에 외래 키가 있음
• 객체와 테이블의 차이 때문에 반대편 테이블의 외래 키를 관리하는 특이한 구조
• @JoinColumn을 꼭 사용해야 함, 그렇지 않으면 조인 테이블 방식을 사용함 (중간에 테이블을 하나 추가함)

// @JoinColumn은 외래키로 사용할 컬럼명을 명시적으로 지정해주는 것
// 외래키의 컬럼명을 name으로 전달해주는 것 
@OneToMany
@JoinColumn(name = "TEAM_ID")
List<Member> members = new ArrayList<>();

try {
	Member member = new Member();
	member.setUsername("member1");
	
	em.persist(member);
	
	Team team = new Team();
	team.setName("TeamA");
	
	// 팀 테이블에 List를 저장하는 컬럼 없음
	// 그러므로 외래키가 있는 Member 테이블에 업데이트 해준다. 
	// 다대일보다 쿼리가 한 번 더 나감 
	team.getMembers().add(member); 
	
} ...

• 코드만 보면 Team만 건드린 것 같은데 실제 쿼리가 Member를 건드리게 됨
• 실무에서 테이블이 수십개가 얽혀서 돌아가므로 운영이 어려워짐
• 영한님은 이를 잘 사용하지 않음, 다대일을 사용, 필요한 경우 양방향 구현 손해를 보더라도 이것이 더 깔끔함

일대다 단방향 정리

• 일대다 단방향 매핑의 단점
  • 엔티티가 관리하는 외래 키가 다른 테이블에 있음 - 매우 큰 단점
  • 연관관계 관리를 위해 추가로 UPDATE SQL 실행 → 다른 테이블의 값을 업데이트 해줘야하기 때문
• 일대다 단방향 매핑보다는 다대일 양방향 매핑을 사용하자!! → 객체적으로 손해를 보더라도 다대일 양방향 권장 </aside>

<aside> ❗

일대다 양방향 - 그냥 이런게 있구나하고 넘어가라

• 이런 매핑은 공식적으로 존재 X
• @JoinColumn(insertable=false, updatable=false)
• 읽기 전용 필드를 사용해서 양방향처럼 사용하는 방법
• 다대일 양방향을 사용하자

// 연관관계 주인을 정해주기 위해 insertable=false, updatable=false 옵션 추가
// 읽기 전용으로 설정
@ManyToOne
@JoinColumn(name = "TEAM_ID", insertable=false, updatable=false)
private Team team;

</aside>

<aside> ❗

일대일 관계

• 일대일 관계는 그 반대도 일대일
• 주 테이블이나 대상 테이블 중에 외래 키 선택 가능
• 외래 키에 데이터베이스 유니크(UNI) 제약조건 추가

• 다대일 단방향 매핑과 비슷 (어너테이션만 다르다.)

양방향

@Entity
public class Locker {
		@Id @GeneratedValue
		@Column(name = "LOCKER_ID")
		private Long id;
		
		@Column(name = "NAME")
		private String name;
		
		// 양방향 구현 시 
		@OneToOne(mappedBy = "locker")
		Member member;
}

@Entity
public class Member {
		@Id @GeneratedValue
		@Column(name = "MEMBER_ID")
		private Long id;
		
		// 단방향 구현 시 
		@OneToOne
		@JoinColumn(name = "LOCKER_ID")
		Locker locker;
		
		@Column(name = "USERNAME")
		private String name;
}

일대일 - 주 테이블에 외래 키 양방향 정리

• 다대일 양방향 매핑 처럼 외래 키가 있는 곳이 연관관계의 주인
• 반대편은 mappedBy 적용 </aside>