[섹션 6, 섹션 7] 헌치 제출합니다

[BETTERFUTURE4]

섹션 6 : 다양한 연관관계 매핑

6-1 연관관계 매핑 시 고려사항

1) 다중성

• 다대다(@ManyToOne)
• 일대다(@OneToMany)
• 일대일(@OneToOne)
• 다대다(@ManyToMany)
• 자세한 내용은 지난 5 챕터 참조

2) 단방향, 양방향

• 테이블 : 외래키를 통해 양방향 조인 가능
• 객체 : 참조 필드가 있는 쪽으로만 참조가능(단방향, 두개의 단방향)

3) 연관관계 주인

• 주인 : 양방향 관계에서 두 참조 중 외래키(FK) 테이블
• 비주인 : 단순 조회만 가능, 주로 PK 테이블

6-2 다대일/일대다

1) 다대일(제일 중요)

가장 많이 사용, 다 쪽이 주인(FK)

• @ManyToOne 사용

양방향

@Entity
public class Member {

    private Long id;

    @ManyToOne
    @JoinColumn(name = "TEAM_ID")
    private Team team;
}

@Entity
public class Team {
    @Id
    @GeneratedValue
    private Long id;

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

• 양방향시 비주인 클래스에서 @MappedBy, @OneToMany

2) 일대다

일 쪽이 주인(FK), 사용 X

• @OneToMany 사용
• @JoinColumn 꼭 사용해야 함
• 양방향 X

6-3 일대일

주 테이블과 대상 테이블 중 FK(주인) 지정

• FK(주인)에 DB 유니크 제약조건 추가해야 함
  • 안 그러면 따로 비즈니스 로직으로 중복처리.. 불편
• 다대일 매핑과 유사
• 단방향 관계는 JPA 지원X

1) 주 테이블에 외래키

• 객체지향 개발자 선호
• 장점: JPA 매핑 편리, 주 테이블만 조회해도 대상 테이블 데이터 여부 확인가능
• 단점: 외래 키에 null 가능

2) 대상 테이블에 외래키

• DB 개발자 선호
• 장점: 일대일 -> 일대다 변경 시 테이블 구조 유지
• 단점: 지연 로딩 설정불가(프록시 기능의 한계)
  • 자세한 건 이후 챕터에서...

6-4 다대다

일대다(@OneToMany) <-> 연결테이블 <-> 다대일(@ManyToOne)

• RDB는 테이블 2개로 다대다 표현 불가

• @ManyToMany는 실무 사용 X

  • 연결테이블 용 엔티티(Orders) 추가 필요
  • Member-Orders-Product

• 단방향, 양방향 가능 시 사용

• @JoinColumn: 외래키 매핑

섹션 7 : 고급 매핑

7-1 상속관계 매핑

• RDB에서는 상속관계 X
  • 대신 모델링 기법(슈퍼타입-서브타입) 사용

1) 어노테이션

@Entity
@Inheritance(strategy = InheritanceType.JOINED)
@DiscriminatorColumn(name = "DTYPE")
public class Item {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    private String name;
    private Integer price;
}

@Entity
@DiscriminatuinValue("A")
public class Album extends Item {
    private String artist;
}

• @Inheritance(strategy=InheritanceType.XXX)
  • 어떤 전략을 사용해 상속관계를 매핑할지 지정
• @DiscriminatorColumn(name=“DTYPE”)
  • 부모 클래스에서, 상속된 자식클래스 종류를 구별하기 위해 지정
• @DiscriminatorValue(“XXX”)
  • 자식 클래스에서, DTYPE 이름을 지정

2) 조인 전략

• @Inheritance(strategy=InheritanceType.JOINED)
• 각각의 클래스를 테이블로 변환
• 부모 테이블 따로, 자식 테이블 따로 -> 나중에 JOIN 으로 연결

a. 장점

• 테이블 정규화
  • 정규화 : RDB 설계에서 중복을 최소화하며 데이터를 구조화하는 프로세스
  • 중복되는 부모 클래스를 슈퍼타입 테이블로 분리 -> 중복 최소화
• 외래키 참조 무결성 제약조건 활용 가능
  • 외래키 참조 무결성 제약조건 : 외래키는 참조할 수 없는 값을 가질 수 없다는 규칙(꼭 참조되는 값이 필요하다)
  • PK-FK 간 무조건 연결되니 조건을 지킬 수 있다?
• 저장공간 효율화

b. 단점

• 조회 시 JOIN이 많이 사용되어 성능 저하
• 조회 쿼리가 복잡함
• 데이터 저장 시 INSERT SQL을 2번 호출
  • 슈퍼타입 테이블에 1번, 서브타입 테이블에 1번?

3) 단일테이블 전략

• @Inheritance(strategy=InheritanceType.SINGLE_TABLE)
• 통합 테이블로 변환
• 모든 자식 칼럼들이 포함된 부모 테이블 1개

a. 장점

• JOIN이 없어 일반적으로 조회 성능이 빠름
• 조회 쿼리가 단순함

b. 단점

• 자식 엔티티가 매핑한 컬럼은 모두 NULL이 허용됨
• 단일 테이블이라 테이블이 커짐!
  • 상황에 따라 오히려 조회 성능이 느릴수도 있음
  • 한 테이블에 많은 정보가 들어가는 형태는 좋지 않다

4) 구현클래스별 테이블 전략

• @Inheritance(strategy=InheritanceType.TABLE_PER_CLASS)
• 서브타입 테이블로 변환(부모 칼럼이 포함된 자식 테이블들)
• 구분칼럼 사용 X
• DBA, ORM 전문가 모두 추천 X

a. 장점

• 서브타입 테이블을 명확히 구분해 처리할 떄 효과적
• not null 제약조건 사용가능

b. 단점

• 여러 서브타입 테이블을 함께 조회시 성능이 느림
  • UNION SQL 필요하고, 모든 서브타입 테이블을 뒤져봐야 함
• 서브타입 테이블들을 통합해 쿼리하기 힘들다

7-2 @MappedSuperclass

@MappedSuperclass
public abstract class BaseEntity {
    private Date createdAt;
    private Date updatedAt;
}

@Entity
@AttributeOverride(name = "createdAt", column = @Column(name = "publishedAt"))
//원하는 매핑정보 재정의
public class Book extends BaseEntity {
    private Long bookId;
    private String bookName;
}

@Entity
public class Movie extends BaseEntity {
    private Long movieId;
    private String movieName;
}

• 여러 엔티티들 사이 공통된 필드를 하나로 묶어 사용하고 싶을 때 사용
• 등록일, 수정일, 등록자, 수정자 등

1) 특징

• 상속관계 매핑과는 다르다!
  • 슈퍼타입-서브타입 관계가 아니다!
• 해당 어노테이션의 클래스(BaseEntity)는 엔티티가 아니며, 테이블과 매핑 되지 않는다
  • 조회, 검색 불가(em.find 불가)
  • 자식 클래스에 매핑 정보만 제공
• 추상 클래스(abstract class) 권장

2) 참고사항

• @Entity클래스는 엔티티나 @MappedSuperclass로 지정한 클래스만 상속 가능