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

상속관계 매핑

---

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

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

 

---

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

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

 

주요 어노테이션

이름	속성	속성 상세	설명
@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 프로그래밍