6. 고급 매핑 - 상속관계 매핑, @MappedSuperclass

상속관계 매핑

관계형 데이터베이스는 상속 관계가 없다.
슈퍼타입 서브타입 관계라는 모델링 기법이 객체 상속과 유사
상속관계 매핑: 객체의 상속 구조와 DB의 슈퍼타입 서브타입 관계를 매핑

Album, Movie, Book은 모두id, name, price를 가지고 있다(공통 변수)

슈퍼타입 서브타입 논리 모델을 실제 물리 모델로 구현하는 방법

각각 테이블로 변환 -> 조인 전략
통합 테이블로 변환 -> 단일 테이블 전략
서브타입 테이블로 변환 -> 구현 클래스마다 테이블 전략

주요 어노테이션

이름	속성	속성 상세	설명
@Inheritance	strategy	- JOINED - SINGLE_TABLE - TABLE_PER_CLASS	물리모델 구현 전략 default 전략은 SINGLE_TABLE(단일 테이블 전략)
@DiscriminatorColumn	name		부모 클래스에 선언한다. 하위 클래스를 구분하는 용도의 컬럼이다. 관례는 default = DTYPE
@DiscriminatorValue	value		하위 클래스에 선언한다. 엔티티를 저장할 때 슈퍼타입의 구분 컬럼에 저장할 값을 지정한다. 어노테이션을 선언하지 않을 경우 기본값으로 클래스 이름이 들어간다.

=== Item ===
@Entity
@Inheritance(strategy = InheritanceType.XXX) // 상속 구현 전략 선택
public class Item {

   @Id
   @GeneratedValue(strategy = GenerationType.IDENTITY)
   private Long id;

   private String name;
   private int price;
}

=== Album ===
@Entity
public class Album extends Item {

   private String artist;
}

=== Movie ===
@Entity
public class Movie extends Item {

   private String director;
   private String actor;
}

=== Book ===
@Entity
public class Book extends Item {

   private String author;
   private String isbn;
}

1. 조인전략

Item, Album에 pk,fk가 같아 각각의 테이블에 insert를 수행하고 Item내에 타입(DTYPE)을 구분하는 컬럼을 만들어서 구해온다.
모든 자손 엔티티가 상위 엔티티의 아이디를 PK이자 FK로 지정해줘야 하는데, 컬럼명을 각각의 하위 클래스별로 다르게 만들고 싶다면 @PrimaryKeyJoinColumn 애노테이션을 활용하면 된다.

@Entity
@Inheritance(strategy = InheritanceType.JOINED)
@DiscriminatorColumn // 하위 테이블의 구분 컬럼 생성(default = DTYPE)
public abstract class Item {

   @Id
   @GeneratedValue(strategy = GenerationType.IDENTITY)
   private Long id;

   private String name;
   private int price;
}

Hibernate:
   create table Album (
      artist varchar(255),
      id bigint not null,
      primary key (id)
  )
Hibernate:
   create table Book (
      author varchar(255),
      isbn varchar(255),
      id bigint not null,
      primary key (id)
  )
Hibernate:
   create table Item (
      DTYPE varchar(31) not null,
      id bigint generated by default as identity,
      name varchar(255),
      price integer not null,
      primary key (id)
  )
Hibernate:
   create table Movie (
      actor varchar(255),
      director varchar(255),
      id bigint not null,
      primary key (id)
  )

Movie 객체를 저장하면?

Insert 쿼리가 두개 나간다.
Item 테이블, Movie 테이블 저장.
DTYPE에 클래스 이름이 디폴트로 저장됨.

Movie movie = new Movie();
movie.setDirector("감독A");
movie.setActor("배우B");
movie.setName("분노의질주");
movie.setPrice(35000);

em.persist(movie);

tx.commit();

Hibernate:
   /* insert advancedmapping.Movie
       */ insert
       into
          Item
          (id, name, price, DTYPE)
       values
          (null, ?, ?, 'Movie')
Hibernate:
   /* insert advancedmapping.Movie
       */ insert
       into
          Movie
          (actor, director, id)
       values
          (?, ?, ?)

Movie 객체를 조회하면?

flush(), clear() 해주면, DB에 insert쿼리 날리고, 1차 캐시 지우므로 find에서 SELECT 쿼리가 나간다.
Item과 inner join을 통해서 결과를 조회한다.

Movie movie = new Movie();
movie.setDirector("감독A");
movie.setActor("배우B");
movie.setName("분노의질주");
movie.setPrice(35000);

em.persist(movie);

em.flush();
em.clear();  //DB에 insert쿼리 날리고, 1차 캐시 지우므로 find에서 SELECT 쿼리가 나간다.

em.find(Movie.class, movie.getId());

tx.commit();

Hibernate:
  select
      movie0_.id as id2_2_0_,
      movie0_1_.name as name3_2_0_,
      movie0_1_.price as price4_2_0_,
      movie0_.actor as actor1_3_0_,
      movie0_.director as director2_3_0_
  from
      Movie movie0_
  inner join
      Item movie0_1_
          on movie0_.id=movie0_1_.id
  where
      movie0_.id=?

장점

테이블이 정규화 되어있고, 제약조건을 부모에 걸어 맞출 수 있다.
- ex. Order 테이블에서 특정 아이템(영화)의 가격을 볼때 ITEM 테이블만 봐도 된다.
외래 키 참조 무결성 제약조건 활용 가능
저장공간 효율화

단점

조회시 조인이 많을 경우 성능 저하.
- ※ 조인이 많아도 조건이 잘 걸려있을 경우 성능 하락이 크지 않고 저장공간이 효율적으로 되기에 오히려 더 좋을 수 있다는 점을 고려해야 한다.
조회 쿼리가 복잡함.
데이터 저장시 INSERT SQL 2번 호출 (큰 문제는 아님)

2. 단일 테이블 전략(default)

논리모델을 한 테이블로 합쳐버리는 방법.
한 테이블에 다 넣어 놓고 어떤 테이블인지 구분하는 컬럼(ex:DTYPE)을 통해 구분한다.
테이블은 ITEM 테이블 하나만 관리된다.
성능에서 우위를 가질 수 있다. (select or insert 가 한번에 수행으로 된다.)
@DiscriminatorColumn 이 필수로 들어간다(기입하지 않아도 자동으로 들어감)

@Entity
@DiscriminatorColumn
@Inheritance(strategy = InheritanceType.SINGLE_TABLE)
public class Item {

   @Id
   @GeneratedValue(strategy = GenerationType.IDENTITY)
   private Long id;

   private String name;
   private int price;
}

Hibernate:
   create table Item (
      DTYPE varchar(31) not null,
      id bigint generated by default as identity,
      name varchar(255),
      price integer not null,
      artist varchar(255),
      author varchar(255),
      isbn varchar(255),
      actor varchar(255),
      director varchar(255),
      primary key (id)
  )

조인 전략에서 실습했던 Movie 저장, 조회 예제를 그대로 돌려보면?

Item 테이블을 그냥 조회한다. 조인하지 않고, DTYPE을 검색 조건으로 추가해서 Movie를 조회

Hibernate:
   select
      movie0_.id as id2_0_0_,
      movie0_.name as name3_0_0_,
      movie0_.price as price4_0_0_,
      movie0_.actor as actor8_0_0_,
      movie0_.director as director9_0_0_
   from
      Item movie0_
   where
      movie0_.id=?
       and movie0_.DTYPE='Movie'

장점

조인이 필요 없기에 일반적으로 조회 성능이 빠름
조회 쿼리가 단순함.

단점

자식 엔티티가 매핑한 컬럼은 모두 null 허용 해야 한다. (데이터 무결성 입장에서 애매한 점이 있다.)
단일 테이블에 모든 것을 저장하기에 테이블이 커질 수 있고 상황에 따라서 조회성능이 더 느려질 수 있다.
(임계점을 넘을 정도의 상황은 거의 오지 않는다.)

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

이 전략은 데이터베이스 설계자와 ORM 전문가 둘 다 추천X
- ex. 만약 Item 정산이 요구되는 경우 각각의 테이블을 모두 조회해야 하고 Item이 추가될 때마다 정산 코드를 다시 짜야한다.
각각의 테이블마다 별개로 만들어서 따로 관리
ITEM 테이블을 생성하지 않고 ALBUM, MOVIE, BOOK 테이블에서 각각 id, name, price필드를 가지고 있다.
@DiscriminatorColumn을 사용할 수 없다.(테이블 자체가 다르기 때문에 구분 할 이유가 없다.)
객체 입장에서 부모 타입인 ITEM을 조회하면 ALBUM, MOVIE, BOOK 세개의 테이블을 UNION ALL으로 전부 조회해서 가져온다.(단점) - 너무 복잡한 쿼리가 날라간다.
ex. Item id가 5번인 Item을 찾고 싶을 때 3개 테이블 전체를 select 할수 밖에 없다.

장점

서브 타입을 명확하게 구분해서 처리할 때 효과적
Not null 제약조건 가능

단점

여러 자식 테이블을 함께 조회할 때 성능이 느림(UNION SQL)
자식 테이블을 통합해서 쿼리하기 힘듬.

상속관계 매핑 정리

기본적으로는 조인 전략을 가져가자.
그리고 조인 전략과 단일 테이블 전략의 장단점을 생각해서 trade-off 하자.

그래도 어느 정도 기준을 정하자면

단일 테이블 전략 : 데이터가 단순하거나 확장 가능성이 없을 경우
조인 전략 : 비지니스 적으로 중요하고 복잡한 경우

"구현 클래스마다 테이블 전략"은 거들떠도 보지 말자.

@MappedSuperclass

객체의 입장에서 공통 매핑 정보가 필요할 때 사용한다.
- ex: 모든 테이블 row에 id, name, 생성일, 수정일을 등록해야하는 경우(createdAt, updatedAt)
이렇게 공통 매핑 정보가 필요할 때, 부모 클래스에 선언하고 속성만 상속 받아서 사용하고 싶을 때@MappedSuperclass를 사용한다.
DB 테이블과는 상관없다. 아래에 보면 DB는 매핑 정보 다 따로 쓰고 있다. 객체의 입장이다.

코드로 이해하기

생성자, 생성시간, 수정자, 수정시간을 모든 엔티티에 공통으로 가져가야 하는 상황에서
아래와 같이 BaseEntity를 정의해서 활용할 수 있다.
매핑정보만 상속받는 Superclass라는 의미의 @MappedSuperclass 어노테이션 선언

@MappedSuperclass
public abstract class BaseEntity {

   private String createdBy;

   private LocalDateTime createdDate;

   private String lastModifiedBy;

   private LocalDateTime lastModifiedDate;
}

Member, Team에서 BaseEntity 상속

@Entity
public class Member extends BaseEntity {
  ...
}

@Entity
public class Team extends BaseEntity {
  ...
}

상속광계 매핑이 아니다.
@MappedSuperclass가 선언되어 있는 클래스는 엔티티가 아니다. 당연히 테이블과 매핑도 안된다.
단순히 부모 클래스를 상속 받는 자식 클래스에 매핑 정보만 제공한다.
조회, 검색이 불가하다. 부모 타입으로 조회하는 것이 불가능하다는 이야기.(em.find(BaseEntity) 불가능)
직접 생성해서 사용할 일이 없으므로 추상 클래스로 만드는 것을 권장한다.
테이블과 관계가 없고, 단순히 엔티티가 공통으로 사용하는 매핑 정보를 모으는 역할을 한다.
주로 등록일, 수정일, 등록자, 수정자 같은 전체 엔티티에서 공통으로 적용하는 정보를 모을 때 사용한다.
참고
- JPA에서 @Entity 클래스는 @Entity나 @MappedSuperclass로 지정한 클래스만 상속할 수 있다.

실전예제

도메인

도메인 상세

테이블 설계

참고

자바 ORM 표준 JPA 프로그래밍

상속관계 매핑

슈퍼타입 서브타입 논리 모델을 실제 물리 모델로 구현하는 방법

주요 어노테이션

1. 조인전략

2. 단일 테이블 전략(default)

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

상속관계 매핑 정리

@MappedSuperclass

코드로 이해하기

실전예제

도메인

도메인 상세

테이블 설계

티스토리툴바