TIL_221016_자바 ORM 표준 JPA 프로그래밍_05 정리

창고·2022년 10월 16일
JPA
0

7. 다양한 연관관계 매핑

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

  • 다중성 (다대일, 일대다, 일대일, 다대다)
  • 단방향, 양방향
    • 테이블 : 외래 키 하나로 양쪽 조인, 방향 개념이 없음
    • 객체 : 참조용 필드가 있는 쪽으로만 참조 가능, 한쪽만 참조하면 단방향, 양쪽이 서로 참조하면 양방향
  • 연관관계의 주인
    • 테이블은 외래 키 하나로 두 테이블이 연관관계를 맺음
    • 객체 양방향 관계는 참조가 2군데이므로 둘 중 테이블의 외래 키를 관리할 곳을 지정해야 함
    • 연관관계의 주인 : 외래 키를 관리하는 참조
    • 주인의 반대편 : 외래 키에 영향을 주지 않으며 단순 조회만 가능

(2) 다대일 (N:1)

  • JPA에서 가장 많이 사용
  • 다쪽에 외래 키가 가야 함 (연관관계의 주인이 됨)
  • 다대일 단방향
  • 다대일 양방향

(3) 일대다 (1:N)

  • 일쪽에 외래 키가 가는 경우 (연관관계의 주인이 됨)
  • 권장하지는 않음
  • 테이블은 여전히 다쪽에 FK가 있음
  • 일대다 단방향
  • Team 객체가 변경되면 Member 테이블의 Team_id 외래 키가 변경되어야 함
  • 일대다 단방향 정리
    • 객체와 테이블의 차이 떄문에 반대편 테이블의 외래 키를 관리하는 특이한 구조
    • @JoinColumn을 꼭 사용해야 함. 그렇지 않을 경우 조인 테이블 방식을 사용 (중간에 테이블을 하나 추가해야 함, Team과 Member의 경우 Team_Member 테이블이 추가됨)
    • 엔티티가 관리하는 외래 키가 다른 테이블에 있음
    • 연관관계 관리를 위해 추가로 UPDATE SQL 실행
    • 일대다 단방향 매핑보다는 다대일 양방향 매핑이 낫다
  • 일대다 양방향
  • 일대다 양방향 정리
    • 이런 매핑은 공식적으로 존재하지 않음
    • @JoinColumn(insertable=false, updatable=false)
    • 읽기 전용 필드를 사용해서 양방향처럼 사용
    • 다대일 양방향을 쓰자

(4) 일대일 (1:1)

  • 주 테이블이나 대상 테이블 중에 외래 키 선택 가능
  • 외래 키에 데이터베이스 유니크(UNI) 제약조건 추가
  • 주 테이블에 외래 키를 건 상태 (단방향/양방향)-> 다대일 단방향/양방향과 유사
    • 외래 키가 있는 곳이 연관관계의 주인
  • 대상 테이블에 외래 키를 건 상태 -> 단방향 관계는 지원 X, 양방향 관계는 지원

  • 일대일 정리
    • 주 테이블에 외래 키
      • 주 객체가 대상 객체의 참조를 가지는 것처럼 주 테이블에 외래 키를 두고 대상 테이블을 찾음
      • 객체 지향 개발자 선호
      • JPA 매핑 편리
      • 장점 : 주 테이블만 조회해도 대상 테이블에 데이터가 있는지 확인 가능
      • 단점 : 값이 없으면 외래 키에 null 허용
    • 대상 테이블에 외래 키
      • 대상 테이블에 외래 키가 존재
      • 전통적인 DBA 선호
      • 장점 : 주 테이블과 대상 테이블을 일대일에서 일대다 관계로 변경할 때 테이블 구조 유지
      • 단점 : 양방향 관계로 만들어야 하며 프록시 기능의 한계로 지연 로딩으로 설정해도 항상 즉시 로딩됨
  • 장단이 있지만 주 테이블에 외래 키를 건 상태가 좀 더 성능적으로 이점이 있긴 함 (단, DBA와 논의가 필요할 수 있음)

(5) 다대다 (M:N)

  • 실무에서는 어지간해선 사용해서는 안됨
  • 관계형 데이터베이스는 정규화된 테이블 2개로 다대다 관계를 표현할 수 없음
  • 연결 테이블을 추가해서 일대다, 다대일 관계로 풀어내야 함
  • 객체는 그러나 컬렉션을 사용해서 객체 2개로 다대다 관계가 가능함
  • 다대다 매핑의 한계
    • 연결 테이블이 단순히 연결만 하고 끝나지 않음
    • 주문시간, 수량 같은 데이터가 들어올 수 있음
    • 따라서 편리해 보이지만 실무에서 사용하지 않는다
  • 다대다 매핑 한계 극복
    • 연결 테이블용 엔티티 추가 (연결 테이블을 엔티티로 승격)
    • @ManyToMany -> @ManyToOne + @OneToMany로 분리하여 각각 적용
    • 즉, 다대다 -> 다대일, 일대다로 풀어서 사용할 것
  • 가이드 : 실무에서 PK를 특정 값에 종속되게 만들면 추후 유지보수나 확장이 유연해지기 힘드므로 GeneratedValue로 따로 만들어두는 것이 편하긴 함

(6) 실전 예제

  • 엔티티, ERD 수정 (배송, 카테고리 추가)


  • @ManyToOne 주요 속성
    • optional : false로 설정하면 연관된 엔티티가 항상 있어야 함
    • fetch : 글로벌 페치 전략을 설정 (EAGER, LAZY)
    • cascade : 영속성 전이 기능을 사용
    • targetEntity : 연관된 엔티티의 타입 정보를 설정. 이 기능은 거의 사용하지 않음 (컬렉션을 사용해도 제네릭으로 타입 정보를 알 수 있음)
  • @OneToMany 주요 속성
    • mappedBy : 연관관계의 주인 필드를 선택
    • 그 외는 ManyToOne과 동일

8. 고급 매핑

(1) 상속관계 매핑

  • 관계형 데이터베이스는 상속 관계가 없음
  • 슈퍼타입, 서브타입 관계라는 모델링 기법이 객체 상속과 유사
  • 상속관계 매핑 : 객체의 상속과 구조와 DB의 슈퍼타입 서브타입 관계를 매핑
    (왼쪽 : 슈퍼타입, 서브타입 / 오른쪽 : 객체 상속 관계)

(2) 슈퍼타입 서브타입 논리 모델을 실제 물리 모델로 구현

  • 주요 어노테이션
    • @Inheritance(strategy=InheritanceType.XXX)
      • JOINED : 조인 전략
      • SINGLE_TABLE : 단일 테이블 전략
      • TABLE_PER_CLASS : 구현 클래스마다 테이블 전략
    • @DiscriminatorColumn(name="DTYPE")
    • @DiscriminatorValue("XXX")
  • 각각 테이블로 변환 -> 조인 전략 // 보통 많이 선택
    • 장점
      • 테이블 정규화
      • 외래 키 참조 무결성 제약 조건 활용 가능
      • 저장 공간 효율화
    • 단점
      • 조회 시 조회를 많이 사용, 성능 저하 (Inner Join)
      • 조회 쿼리가 복잡함
      • 데이터 저장 시 INSERT SQL 2번 호출 (생각보다 critical하지는 않음)
  @Entity
  @Inheritance(strategy = InheritanceType.JOINED)
  @DiscriminatorColumn(name = "DIS_TYPE") // 기본값은 DTYPE
  public abstract class Item {

  	@Id @GeneratedValue
    private Long id;

    private String name;
    private int price;
  }
  
  @Entity
  @DiscriminatorValue("B") // 기본은 클래스명
  public class Book extends Item {

    private String author;
    private String isbn;
}

  • 통합 테이블로 변환 -> 단일 테이블 전략
    • 장점
      • 조인이 필요없으므로 일반적으로 조회 성능이 빠름
      • 조회 쿼리가 단순함
    • 단점
      • 자식 엔티티가 매핑한 컬럼은 모두 null을 허용해야 함
      • 단일 테이블에 모든 것을 저장하므로 테이블이 커질 수 있음. 상황에 따라 조회 성능이 오히려 느려질 수 있음
  @Entity
  @Inheritance(strategy = InheritanceType.SINGLE_TABLE)
  // @DiscriminatorColumn이 없어도 DTYPE 컬럼 자동 생성
  public abstract class Item {

  	@Id @GeneratedValue
    private Long id;

    private String name;
    private int price;
  }
  
  @Entity
  @DiscriminatorValue("B") // 기본은 클래스명
  public class Book extends Item {

    private String author;
    private String isbn;
}

  • 서브타입 테이블로 변환 -> 구현 클래스마다 테이블 전략 (부모 클래스 테이블 생성 안됨, 아래의 경우는 Table 클래스가 생성되지 않음)
    • 이 전략은 DB, ORM 전문가 둘 다 추천하지 않는다!!
    • 장점
      • 서브 타입을 명확하게 구분해서 처리할 때 효과적
      • NOT NULL 제약 조건 사용 가능
    • 단점
      • 여러 자식 테이블을 함께 조회할 때 성능이 느림 (UNION SQL 필요)
      • 자식 테이블을 통합해서 쿼리하기 어려움
  @Entity
  @Inheritance(strategy = InheritanceType.TABLE_PER_CLASS)
  public abstract class Item {

  	@Id @GeneratedValue
    private Long id;

    private String name;
    private int price;
  }
  
  @Entity
  @DiscriminatorValue("B") // 기본은 클래스명
  public class Book extends Item {

    private String author;
    private String isbn;
}

  • 조인 전략을 보통 생각을 하되, 단일 테이블 전략과의 Trade-off를 염두해두고 DBA와 상의해볼 것 (단순하다면 단일 테이블, 확장 가능성 염두 시 조인 전략)

(2) @MappedSuperclass

  • 공통 매핑 정보가 필요할 때 사용 (id, name, createdAt, createdBy, modifiedAt, modifiedBy...)
  • 상속 관계 매핑이 아님
  • 엔티티 X, 테이블과 매핑되지 않음
  • 부모 클래스를 상속 받는 자식 클래스에 매핑 정보만 제공
  • 조회, 검색 불가 (em.find(BaseEntity) 불가)
  • 직접 생성해서 사용할 일이 없으므로 추상 클래스 권장
  • 테이블과 관계 없고 단순히 엔티티가 공통으로 사용하는 매핑 정보를 모으는 역할
  • 참고 : @Entity 클래스는 엔티티나 @MappedSuperclass로 지정한 클래스만 상속 가능
@MappedSuperclass
public abstract class BaseEntity {

    @Column(name = "CREATED_BY") // 컬럼 이름도 지정 가능
    private String createdBy;
    private LocalDateTime createdAt;
    private String modifiedBy;
    private LocalDateTime modifiedAt;

}

@Entity // (name = ) 없을 경우 기본값으로 클래스 이름과 엔티티 이름을 동일하게 세팅
@Table(name = "MBR") // 매핑할 테이블 이름 지정
public class Member extends BaseEntity {

(3) 실전 예제

  • 요구사항 추가 : 상품의 종류 추가, 확장 예정 / 모든 데이터는 등록일, 수정일 필수


  • 단일 테이블 전략 시 Item 테이블 조회
  • 조인 전략 시 Item, Book 테이블 조회
profile
창고
공부했던 내용들을 모아둔 창고입니다.
이전 포스트

TIL_221014_자바 ORM 표준 JPA 프로그래밍_04 정리

다음 포스트

TIL_221017_자바 ORM 표준 JPA 프로그래밍_06 정리

0개의 댓글