연관관계 맵핑

연관관계 맵핑 (단방향, 양방향)

테이블

외래키 하나로 양쪽으로 조인 가능
사실 방향이라는 개념이 없다
멤버와 팀 중 하나만 외래키를 두면 됨

객체

참조용 필드가 있는 쪽으로만 참조 가능
한쪽만 참조하면 단방향
양쪽이 서로 참조하면 양방향 (사실 단방향이 두 개)

연관관계의 주인

테이블은 외래 키 하나로 두 테이블이 연관관계를 맺은
객체 양방향 관계는 A->B, B ->A 처럼 참조가 두 개
객체 양방향 관계는 참조가 2군데 있음, 둘 중 테이블의 외래 키를 관리할 곳을 지정해 주어야 함 (연관관계의 주인 설정)
연관관계의 주인: 외래 키를 관리하는 참조
주인의 반대편: 외래 키에 영향을 주지 않음(update X), 단순 조회만

다대일 [N:1] 단방향

다 쪽에 외래키가 있어야
가장 많이 사용

다대일 양방향

( 다쪽 )외래키가 있는 쪽이 연관관계의 주인
양쪽을 서로 참조하도록 개발


@Entity
public class Team {
  @OneToMany(mappedBy = "team")
  private List<Member> members = new ArrayList<>();
}

@Entity
public class Member {
  @MamyToOne
  @JoinColumn(name = "TEAM_ID")
  private Team team;
}

일대다 [1:N] 단방향

(실무에서 추천하지 않는 모델)


Team team = new Team();

Member member = new Member();

team.getMembers().add(member);
// => Member table update 쿼리가 한번더 발생,,,,,

team.setName("myTeam");
// => Member table update 쿼리가 엮여서 발생,,,,,

다대일 단방향을 양방향으로 바꿔 설계

trade off (멤버에서 팀으로 갈일이 없지만, 다대일 설계를 위해) 객체지향적으로 손해가 발생할 지라도,,

일대다 양방향

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

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

주 테이블이나 대상 테이블 중에 외래 키 선택 가능
- 주 테이블에 외래키
- 대상 테이블에 외래키
외래키에 데이터베이스 유니크(UNI) 제약조건 추가

멤버에 락커가 있는 것이 유리한 이유( DBA가 아닌 개발자로서 )

멤버를 조회할 시에 멤버에 속한 락커가 있는 지에 대한 정보를 이미 가지고 있음. 별도의 조인 없이, 디비 쿼리 하나로 멤버의 락커의 값을 가지고 올 수 있다는 성능 상의 이점이 있음. JPA나 객체지향 설계를 위해서는 위의 그림이 실무에서 적용하기는 쉬울 것,

( 단, 멤버 테이블이 커질 수 있다는 단점과, 비즈니스 로직이 변한다면, 수정해야 할 여지가 많다. )

명확한 1대 1 관계일 경우 권장

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


@Entity
public class Member {

	@Id
	@GeneratedValue( strategy = GenerationType.IDENTITY )
	@Column( name = "MEMBER_ID" )
	private Long id;

	@Column( name = "USRNAME" )
	private String username;

	//	@Column( name = "TEAM_ID" )
	//	private Long teamId;

	@ManyToOne // member 입장에서는 many, team 입장에서는 1
	@JoinColumn( name = "TEAM_ID" )
	private Team team;

	@OneToOne
	@JoinColumn( name = "LOCKER_ID" )
	private Locker locker;

}


@Entity
public class Locker {

	@Id
	@GeneratedValue
	private Long id;

	private String name;

	@OneToOne( mappedBy = "locker" )
	private Member member;
}

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

일대일 ( 대상 테이블에 외래 키 단반향 )

- 단방향 관계는 JPA 지원 X

- 양방향 관계는 지원

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

멤버의 락커를 조회할 시에 락커의 값이 실제 존재하는지는 락커 테이블을 조회해야 인정됨. 멤버의 락커의 값이 실제 락커 테이블에도 존재하면 프록시를 넣고, 없으면 null을 넣어주는 처리를 해야 함. 이러한 실제 테이블 상에 존재하는지 확인하기 위한 쿼리가 어차피 나가야하기 때문에 프록시를 넣어줄 필요가 없다.

JPA의 경우, 대상 테이블에 외래키가 있는 경우, lazy loading으로 셋팅을 해도 적용되지 않는다. (즉시 로딩됨)

☝🏻 일대일 정리

주 테이블에 외래 키

주 객체가 대상 객체의 참조를 가지는 것 처럼 
주 테이블에 외래 키를 두고 대상 테이블을 찾음
객체지향 개발자 선호
JPA 매핑 편리
장점: 주 테이블만 조회해도 대상 테이블에 데이터가 있는지 확인 가능
단점: 값이 없으면 외래 키에 null 허용 (DBA 입장에서는 치명적)

대상 테이블에 외래 키

대상 테이블에 외래 키가 존재
전통적인 데이터베이스 개발자 선호
장점: 주 테이블과 대상 테이블을 일대일에서 일대다 관계로 변경할 때 테이블 구조 유지
단점: 프록시 기능의 한계로 지연 로딩으로 설정해도 항상 즉시 로딩됨(위의 인용 글 참고!!)

다대다 [N:M]

관계형 데이터 베이스는 정규화된 테이블 2개로 다대다 관계를 표현할 수 없음
연결 테이블을 추가해서 일대다, 다대일 관계로 풀어내야 함

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

@ManyToMany 사용
@JoinTable로 연결 테이블 지정
다대다 매핑: 단방향, 양방향 가능하긴 함 (절대 실무에서 사용X)

단방향


@Entity
public class Member {

    @ManyToMamy
    @JoinTable(name = "MEMBER_PRODUCT")
    private List<Product> products = new ArrayList<>();
}

@Entity
public class Product {

	@Id
	@GeneratedValue
	private Long id;

	private String name;
}

양방향


@Entity
public class Member {

    @ManyToMamy
    @JoinTable(name = "MEMBER_PRODUCT")
    private List<Product> products = new ArrayList<>();
}

@Entity
public class Product {

	@Id
	@GeneratedValue
	private Long id;

	private String name;

	@ManyToMany( mappedBy = "products" )
	private List<Member> members = new ArrayList<Member>();
}

한계

실무에서 사용 X
연결 테이블이 단순히 연결만 하고 끝나지 않음
주문시간, 수량 같은 데이터가 들어올 수 있음

다대다 한계 극복

연결 테이블용 엔티티 추가 (연결 테이블을 엔티티로 승격)
@MamyToMany -> @OneToMany, @ManyToOne

+ ORDER_ID (모든 테이블에 GeneratedValue)

배송, 카테로기 추가 - 엔티티

주문과 배송은 1:1 (@OneToOne)
상품 카테고리는 N:M (@ManyToMany)

ERD

엔티티 상세

'Spring > JPA & Hibernate' 카테고리의 다른 글

JPA Example (0)	2019.12.18
h2 database 사용하기 (0)	2019.12.17
고급 매핑 (0)	2019.12.17
JPA (0)	2019.10.30
Spring JPA (0)	2019.10.18

준스 개발 이야기

연관관계 맵핑