07.md

07. 고급 매핑

🍩 이 글은 김영한님의 '자바 ORM 표준 JPA 프로그래밍'을 공부하며 정리한 것임을 알립니다.

7.1 상속 관계 매핑

• 관계형 데이터베이스에는 상속이라는 개념이 없음
  하지만, "슈퍼타입, 서브타입 관계"라는 것이 가장 유사

• 슈퍼타입 서브타입 논리 모델을 실제 테이블로 구현할 때는 3가지 방법이 존재

  1. 각각의 테이블로 변환

     모든 모델을 테이블로 만들고 조인을 사용(조인 전략)

  2. 통합 테이블로 변환

     하나의 테이블만 사용(단일 테이블 전략)

  3. 서브 타입 테이블로 변환

     서브 타입별로 테이블을 사용(구현 클래스마다 테이블 전략)

7.1.1 조인 전략

• 엔티티 각각을 모두 테이블로 만들고 자식 테이블이 부모 테이블의 기본키를 받아 기본키 + 외래키로 사용
  따라서 조회시 조인을 많이 사용
• 테이블에는 타입의 개념이 없기 때문에 이를 구분하는 컬럼을 추가
• @Inheritance(strategy = InheritanceType.JOINED) 를 작성하여 조인 전략을 사용
• @DiscriminatorColumn 을 통해 부모 클래스에서 자식 테이블을 구분하는 컬럼을 지정
  기본값은 DTYPE
• @DiscriminatorValue 를 사용하여 엔티티를 저장할 때, 구분 컬럼에 입력될 값을 지정
• 자식 테이블은 부모 테이블의 ID 컬럼명을 그대로 사용
  만약 이를 바꾸고 싶다면 @PrimaryKeyJoinColumn을 사용
• 장점
  • 테이블의 정규화
  • 외래키 참조 무결성 제약조건을 활용할 수 있음
  • 저장공간을 효율적으로 사용
• 단점
  • 조회시 조인을 많이 사용하므로 성능 저하 발생
  • 조회 쿼리 복잡
  • 데이터 등록시 INSERT SQL이 두번 실행

7.1.2 단일 테이블 전략

• 테이블을 하나만 사용하므로 조인을 사용하지 않고 조회(가장 빠름)
• 구분 컬럼을 사용하여 어떤 자식의 데이터가 저장된지 파악(구분 컬럼 사용 필수)
• 자식 엔티티가 매핑한 컬럼은 모두 null 을 허용해야 함
• @Inheritance(strategy = InheritanceType.SINGLE_TABLE) 을 작성하여 사용
• @DiscriminatorValue를 지정하지 않으면 기본으로 엔티티 이름을 사용
• 장점
  • 조인이 없어 일반적으로 조회 성능이 우수
  • 조회 쿼리가 단순
• 단점
  • 자식 엔티티가 매핑한 컬럼은 모두 null 허용
  • 단일 테이블에 모든 것을 저장하므로 굉장히 커질 수 있으며 상황에 따라 조회 성능에 저하가 올 수 있음

7.1.3 구현 클래스마다 테이블 전략

• 자식 엔티티마다 테이블이 존재하고 각각 필요한 컬럼이 모두 존재
  따라서 구분 컬럼이 존재하지 않음
• @Inheritance(strategy = InheritanceType.TABLE_PER_CLASS)를 작성하여 사용
• 일반적으로 추천하지 않는 전략
• 장점
  • 서브 타입을 구분해서 처리할 때 효과적
  • not null 제약조건 사용 가능
• 단점
  • 여러 자식 테이블과 조인하여 조회할 때 성능 저하
  • 자식 테이블을 통합해서 쿼리하기 어려움

7.2 @MappedSuperclass

• 부모 클래스는 테이블과 매핑하지 않고 상속 받은 자식 클래스에게 매핑 정보만 제공할 때 사용
• 추상 클래스와 비슷(실제 테이블에는 매핑이 안되고 정보만 제공)
• 부모로부터 물려받은 매핑 정보를 재정의 하려면 @AttributeOverrides 혹은 @Attributeoverride를 사용
• 연관관계를 재정의하려면 @AssociationOverrides 혹은 @AsoociationOverride를 사용
• @MappedSuperclass를 지정한 클래스는 엔티티가 아니므로 엔티티매니저를 통한 조회나 JPQL에서 사용 불가
• 추상 클래스로 만들어서 사용하길 권장

7.3 복합 키와 식별 관계 매핑

7.3.1 식별 관계 VS 비식별 관계

• 데이터베이스 테이블 사이에 관계에서 외래 키가 기본 키에 포함되는지에 따라 식별 관계와 비식별 관계로 구분

• 식별 관계

  부모 테이블의 기본 키를 내려받아 자식 테이블의 기본 키 + 외래 키로 사용하는 관계

• 비식별 관계(최근 추세)

  부모 테이블의 기본 키를 받아 자식 테이블의 외래 키로만 사용하는 관계

  외래 키에 NULL을 허용하는지에 따라 필수적 비식별 관계와 선택적 비식별 관계로 나눔

  • 필수적 비식별 관계

    외래 키에 NULL을 허용하지 않음, 연관관계를 필수적으로 맺어야 함

  • 선택적 비식별 관계

    외래 키에 NULL을 허용, 연관관계를 맺을지를 선택 가능

7.3.2 복합 키: 비식별 관계 매핑

• 둘 이상의 컬럼으로 구성된 복합 기본 키는 단순히 @Id 로만 매핑한다면 오류 발생
  이를 JPA에서 사용하기 위해서는 별도의 식별자 클래스를 생성
• 영속성 컨텍스트에 엔티티를 보관할 때 엔티티의 식별자를 키로 사용
  식별자를 구별하기 위해 equals와 hashCode를 사용하여 동등성 비교
  만약 식별자 필드가 2개라면 별도의 식별자 클래스를 만들고 equals와 hashCode를 구현
• 복합 키 지원을 위해 @IdClass와 @EmbeddedId를 제공
• @IdClass를 사용시 식별자 클래스는 다음 조건을 만족(데이터베이스에 맞춤)
  • 식별자 클래스의 속성명과 엔티티에서 사용하는 식별자 속성명이 같아야 함
  • Serailizable 인터페이스 구현
  • equals, hashCode 구현
  • 기본 생성자 존재
  • public
• @EmbeddedId를 사용시 식별자 클래스는 다음 조건을 만족(객체 지향에 맞춤)
  • @Embeddable 어노테이션
  • Serializable 인터페이스 구현
  • equals, hashCode 구현
  • 기본 생성자 존재
  • public

7.3.3 복합 키: 식별 관계 매핑

• @IdClass와 @EmbeddedId를 사용하여 식별자를 매핑
• @IdClass를 사용할 경우, 식별 관계는 기본 키와 외래 키를 같이 매핑하므로 식별자 매핑인 @Id와 연관관계 매핑인 @ManyToOne을 사용
• @EmbeddedId의 경우, @MapsId(외래 키와 매핑한 연관관계를 기본 키에도 매핑)를 사용

7.3.4 비식별 관계로 구현

• 복합 키를 사용하지 않으면 매핑도 쉽고 코드도 단순, 복합 키 클래스를 따로 생성 X

7.3.5 일대일 식별 관계

• 자식 테이블의 기본 키 값으로 부모 테이블의 기본 키 값만 사용
  따라서 부모 테이블의 기본 키가 복합 키가 아니면 자식 테이블의 기본 키는 복합 키로 구성 X

7.3.6 식별, 비식별 관계의 장단점

• 식별 관계는 부모 테이블의 기본 키를 자식 테이블로 전파하면서 자식 테이블의 기본 키 컬럼이 점점 늘어남
  이는 조인시에 SQL이 복잡해지고 기본 키 인덱스가 불필요하게 커질 수 있음
• 식별 관계는 2개 이상의 컬럼을 합해서 복합 기본 키를 만들어야 하는 경우가 많음
• 식별 관계를 사용할 때 기본 키로 비즈니스 의미가 있는 자연 키 컬럼을 조합하는 경우가 많음
  반면 비식별 관계의 기본 키는 비즈니스와 전혀 관계없는 대리 키를 주로 사용
  비즈니스와 관련되면 언젠가는 변하게 되므로 상속이 여러번 있는 경우 변경하기가 힘듬
• 식별 관계는 부모 테이블의 기본 키를 자식 테이블의 기본 키로 사용하므로 비식별 관계보다 테이블 구조가 유연하지 X
• 일대일 관계를 제외하고 식별 관계는 2개 이상의 컬럼을 묶은 복합 기본 키를 사용하므로 별도의 클래스가 필요한데 이에 노력이 더 필요
• 비식별 관계는 주로 대리 키를 사용하는데 간편하게 사용 가능

7.4 조인 테이블

• 데이터베이스 테이블에서 연관관계를 설계하는 방법은 크게 2가지

  • 조인 컬럼 사용(외래 키)

    만약 관계를 맺은 엔티티가 필수가 아닐 때는 null을 허용하는 선택적 비식별 관계가 됨
    따라서 외부 조인을 사용

  • 조인 테이블 사용(테이블 사용)

    조인 테이블은 두 테이블의 외래 키를 가지고 연관관계를 관리
    따라서 각 테이블에는 외래 키 컬럼이 존재하지 않음

    큰 단점은 테이블을 하나 추가하므로 관리할 테이블이 늘고 두 테이블을 조인하려면 조인 테이블까지 추가 조인을 해야 함

• 조인 컬럼의 경우, @JoinColumn으로 매핑, 조인 테이블의 경우, @JoinTable로 매핑

• 조인 테이블은 주로 다대다 관계를 일대다와 다대일로 풀어내기 위해 주로 사용(일대일, 일대다, 다대일에서도 사용)

• 조인 테이블에 컬럼을 추가하면 @JoinTable 전략을 사용할 수 없음
  따라서 새로운 엔티티를 만들어 조인 테이블과 매핑

7.4.1 일대일 조인 테이블

• 조인 테이블의 외래 키 컬럼 각각에 총 2개의 유니크 제약조건을 걸어야 함
• @JoinTable 속성
  • name : 매핑할 조인 테이블 이름
  • joinColumns : 현재 엔티티를 참조하는 왜래 키
  • inverseJoinColumns : 반대 방향 엔티티를 참조하는 외래 키

7.4.2 일대다 조인 테이블

• 조인 테이블의 컬럼중 다쪽과 관련된 컬럼에 유니크 제약 조건을 걸어야 함(다 쪽의 ID를 PK로 사용)

7.4.3 다대일 조인 테이블

• 일대다 조인 테이블과 같음

7.4.4 다대다 조인 테이블

• 조인 테이블의 두 컬럼을 합해 하나의 복합 유니크 제약조건을 걸어야 함

7.5 엔티티 하나에 여러 테이블 매핑

• @SecondaryTable을 사용하면 한 엔티티에 여러 테이블을 매핑
• @SecondaryTable 속성
  • name : 매핑할 다른 테이블의 이름
  • pkJoinColumns : 매핑할 다른 테이블의 기본 키 컬럼 속성
• @SecondaryTable를 사용하여 두 테이블을 하나의 엔티티에 매핑하는 것보다 테이블당 하나의 엔티티에 매핑하는 것을 권장
• 해당 방법은 항상 두 테이블을 조회하므로 최적화 하기가 어려움