[JPA] 상속관계 매핑과 @MappedSuperclass

📌 상속관계 매핑

왼쪽) DB 슈퍼타입 서브타입, 오른쪽) 객체의 상속

 

상속관계 매핑이 필요한 이유

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

 

데이터베이스의 슈퍼타입 서브타입 논리 모델을 실제 물리 모델로 구현하는 방법

• 슈퍼타입과 서브타입을 각각의 테이블로 변환 → 조인 전략
• 통합 테이블(서브타입에 있는 모든 컬럼을 슈퍼타입에 하나로 통합)로 변환 → 단일 테이블 전략
• 서브타입 테이블로 변환(서브타입 컬럼에 슈퍼타입에 있는 모든 속성을 포함하도록 구성) → 구현 클래스마다 테이블 생성 전략

 

📌 객체 관점 주요 어노테이션

@Inheritance(strategy = InheritanceType.XXX)

• JOINED : 조인 전략
• SINGLE_TABLE : 단일 테이블 전략
• TABLE_PER_CLASS : 구현 클래스마다 테이블 생성 전략

 

@DiscriminatorColumn(name = "DTYPE")

• 구분자 컬럼명 지정
• default 컬럼명이 "DTYPE"임

 

@DiscriminatorValue("BOOK")

• @DiscriminatorColumn에서 설정한 컬럼에 저장될 엔티티 클래스별 값 지정

 

📌 1) 조인 전략

왼쪽) 객체 상속, 오른쪽) DB에서 조인 전략 사용

• 슈퍼타입(객체 관점에서는 부모 클래스)과 서브타입(객체 관점에서는 자식 클래스)이 각각 테이블로 생성된 뒤, 1:1 주식별자 관계로 연결된다.
• 슈퍼타입 테이블이 어느 서브타입 테이블과 연관되는지 구별하기 위해 슈퍼타입 테이블에서 구분자(위의 사진에서 ITEM의 DTYPE)를 가지고 있다.

 

장점

• 슈퍼타입 테이블에 속한 정보만 조회하는 경우 SQL 작성이 편리하다.
• 컬럼의 중복이 없으므로 저장공간이 상대적으로 적다.
• 관계에 의해 발생하는 외래 키 참조 무결성 제약조건 활용이 가능하다.

 

단점

• 슈퍼타입과 서브타입의 정보를 같이 처리하면 항상 조인이 발생해야 하므로 성능 저하를 일으킬 수 있다.
• 전체 테이블(슈퍼타입, 서브타입 모두)을 조회하는 경우에 조인으로 인해 조회 쿼리가 복잡하다.
• 데이터 저장시 INSERT SQL을 2번 호출하게 된다. (이건 그렇게 큰 단점이 아니다..!)

 

📌 2) 단일 테이블 전략

왼쪽) 객체 상속, 오른쪽) DB에서 통합 테이블 전략 사용

• 서브타입에 있는 모든 컬럼을 슈퍼타입에 하나로 통합하여 테이블로 만든다.
• 각각의 서브타입 정보를 구분하기 위한 구분 컬럼(위의 그림에서 ITEM 테이블의 DTYPE)이 필요하다.

 

장점

• 조인이 필요하지 않으므로 일반적으로 조회 성능이 빠르고, 조회 쿼리가 단순하다.
• 서브타입을 구분하지 않고 데이터를 조회하는 경우 처리가 편리하다.

 

단점

• 서브타입의 컬럼들은 모두 null을 허용해야 한다.
  • 예를 들어, 특정 서브타입의 컬럼에는 Not Null이나 기본값을 지정해야 하지만, 다른 서브타입이 해당 컬럼을 사용하지 않는 경우 관련 설정을 할 수 없게 된다.

 

• 테이블의 컬럼이 많아지므로 디스크 저장 공간이 증가할 수 있고, 항상 구분자에 의해 데이터 row를 구분해야 한다.
• 테이블의 인덱스를 사용할 경우 서브타입 개별보다 많은 수의 데이터가 존재하므로 인덱스 크기가 커지고 그에 따라 인덱스의 효율이 떨어질 수 있다.
• 서브타입의 내용을 풀 스캔할 경우 데이터 개수가 더 많기 때문에 성능이 떨어진다.
• 다른 테이블과 서브타입별로 참조 무결성 조약이 복잡한 경우 데이터를 처리하기 복잡하다.

 

📌 3) 구현 클래스마다 테이블 생성 전략

왼쪽) 객체 상속, 오른쪽) DB에서 개별 테이블 생성 전략

• 서브타입 테이블에 슈퍼타입에 있는 모든 속성을 포함하도록 구성한다.
• 서브타입 테이블 각각 PK를 생성하므로, 서로간의 관계는 존재하지 않는다.
• 서브타입 구별을 위한 구분자가 필요하지 않다.
• 객체 관점에서 부모 클래스는 abstract으로 설정해야 해당 테이블이 추가로 생성되지 않는다..!

 

장점

• 서브타입별로 구분하여 조회할 경우 가져와야 할 컬럼을 명확하게 구분하여 처리할 수 있다.
• 테이블 풀 스캔을 할 경우 유리하다.
• 다른 테이블과 복잡한 참조 무결성 관계를 유지할 수 있다.
• 컬럼에 대한 Not Null, 기본값 지정이 가능하다.

 

단점

• 서브타입들을 함께 조회할 때(주로 슈퍼타입의 속성 조회시) UNION SQL을 사용해 성능이 느리다.
• 서브타입을 묶어서 부분 처리 해야하는 경우 복잡하거나 불가능하다.

 

추가

• 서브타입별로 구분하여 처리하는 경우가 많은 경우 이와 같은 설계를 고려해볼 수 있지만, 통합하여 데이터를 처리하는 경우가 많다면 권장하지 않는다.

 

📌 3가지 방식 중 선택 기준

상황에 따라 요구되는 트랜잭션의 성격과 양에 따라 결정해야 한다.

 

트랜잭션의 성격

→ 데이터를 처리할 때 슈퍼타입과 서브타입 전체에 대한 처리가 많은지 or 개별 처리가 많은지

 

트랜잭션의 양

→ 각 엔티티에 존재하는 데이터양이 대용량인지 아닌지

 

📌 번외) @MappedSuperclass

위와 같이 공통 매핑 정보가 존재할 때 사용한다.

 

• 상속관계와 연관 X, 엔티티 X, 다른 테이블과 매핑 X
• 해당 클래스를 상속 받는 자식 클래스에 매핑 정보만 제공
• 조회, 검색 불가(entityManager.find(BaseEntity) 불가)
• 주로 추상 클래스로 선언
• 테이블과 관계 없고, 단순히 엔티티가 공통으로 사용하는 매핑 정보를 가지고 있는 역할
• 주로 등록일, 수정일, 등록자, 수정자 같이 전체 엔티티에서 공통으로 사용되는 정보를 모을 때 사용

 

정리하자면,

• @MappedSuperclass가 선언된 클래스의 용도는 위에서도 언급되었듯이 공통으로 사용되는 필드와 코드의 재사용을 위한 것이다.
• @MappedSuperclass가 선언된 클래스는 엔티티 즉, 하나의 테이블이 아니기 때문에 다른 테이블과의 매핑이 불가능하다.
• @Entity가 선언된 추상 클래스는 이와 달리 엔티티 추상화를 위해 사용되는 실질적인 객체 상속 관계의 엔티티이다.

 

 

🎈참고

인프런 자바 ORM 표준 JPA 프로그래밍 - 기본편

데이터베이스 설계와 구축 책

https://stackoverflow.com/questions/16634048/jpa-hibernate-difference-mappedsuperclass-and-entity-abstract-class