[Spring Boot] 5. 상속 관계 매핑

엔코아 플레이데이터(Encore Playdata) Backend 2기 백엔드 개발 부트캠프 (playdata.io)

백엔드 개발 부트캠프

---

1. 상속 관계 매핑

관계형 DB는 상속 관계가 존재하지않는다.
슈퍼타입 - 서브타입 관계라는 모델링 기법이 객체 상속과 유사하긴 하지만, 객체의 상속과는 다르다.
즉, 상속 관계 매핑이란 객체의 상속구조와 DB의 슈퍼타입 - 서브타입 관계를 매핑하는 것을 의미한다.

상속 관계 매핑 예시

1. 상속 관계 매핑 전략
전략 어노테이션은 부모테이블에 붙여서 사용한다.

1. 조인 전략 -> 각각 테이블로 변환
(@Inheritance(strategy = InheritanceType.JOINED)

2. 단일 테이블 전략 -> 통합 테이블로 변환
(@Inheritance(strategy = InheritanceType.SINGLE_TABLE)

3. 구현 클래스마다 테이블 전략 -> 서브타입 테이블로 변환
(@Inheritance(strategy = InheritanceType.TABLE_PER_CLASS)

여기서 JPA 의 장점은, Entity의 변경 없이 전략 이름만 바꾸면, 실제 DB 테이블도 알아서 다 바꿔준다.
이 경우 부모 테이블은 추상 클래스로 만드는 것이 맞다. 일반 클래스로 만들면 단독 엔티티로 취급 되어 Create Table 쿼리가 나가지만, 추상 클래스로 만들면 Create Table 쿼리가 실행되지 않는다.

 

일반적으로 조인 전략을 기본으로 설계하고, 데이터가 많지 않은 경우나 확장 가능성이 높지 않은 경우 단일 테이블 전략 채용한다.

 

2. 상속 관계 매핑 부모테이블 예시

@Entity
@Getter @Setter
@Inheritance(strategy = InheritanceType.JOINED)
@DiscriminatorColumn
public abstract class Item {

    @Id @GeneratedValue
    @Column(name = "ITEM_ID")
    private Long id;

    private String name;
    private int price;
}

3. 상속 관계 매핑 자식 테이블 예시

@Entity
@Getter @Setter
@DiscriminatorValue
public class Album extends Item {

    private String artist;
}

 

이렇게 상속 관계 테이블을 생성하면, 부모 테이블과 자식 테이블의 PK가 동일해지고, 자식 테이블은 PK가 곧 FK가 된다.

때문에 Join을 통해 접근할 수 있게 된다.

이때 부모테이블에는 DTYPE이라는 자식 테이블을 구별할 수 있는 값을 넣어줄 수있다. 

* 부모 테이블
@DiscriminatorColumn(name = "DTYPE") 
기본값이 DTYPE이기 때문에, 생략 가능하다.

* 자식 테이블
@DiscriminatorValue("이름")
이름은 생략할 경우 클래스 이름이 테이블 이름으로 들어간다.

---

2. 조인 전략

조인 전략 구조

1. 표기

* 부모 테이블
@Inheritance(strategy = InheritanceType.JOINED)

2. 장점
1) 데이터가 정규화 되어있고, 제약조건을 부모 테이블에 걸기 때문에 큰 문제가 생기지 않는다. 

예를들어 가격을 정산해야할 때, 부모 테이블에 price 가 있기 때문에, 부모 테이블에 접근해서 부모를 대상으로 쿼리를 날린다면 자식 테이블에도 반영 시킬 수 있다.

* 외래키 참조 무결성 제약조건 활용 가능
부모테이블의 PK가 곧 자식테이블의 FK이기 때문에 부모테이블만 보면 모든 자식 테이블에 접근 가능

 

2) 저장공간이 효율적이다.

3. 단점
1) 조회 시 조인을 많이 사용하기 때문에 성능이 저하된다.

2) 조인이 많이 사용되기 때문에 조회 쿼리가 복잡하다
3) 데이터를 저장 할 때 insert 쿼리가 2번 나간다. (부모 + 자식)

생각보다 큰 단점들은 아니다. 워낙 컴퓨터 스펙이 좋아져서 이정도론 끄떡도 안한다.
단일 테이블 전략에 비해 테이블 구조가 복잡하고, 성능이 안나올 확률이 높다는건 단점이긴하다.
어떤의미에서 저장 공간이 효율적이기 때문에 성능이 좋아지는 면도 존재한다.

---

3. 단일 테이블 전략

단일 테이블 전략의 경우 부모 테이블과 자식 테이블의 모든 컬럼을 한 테이블에 만든다. 

즉, 부모 테이블의 컬럼들과 자식 테이블의 컬럼들이 모두 한 공간에 있기 때문에, 자식 테이블 끼리 서로 구별할 수 있는 DTYPE이 반드시 필요하다.

 

만약 DTYPE이 없으면, 데이터가 어떤 자식의 데이터인지 구별할 수 있는 방법이 없다.

때문에 단일 테이블 전략을 사용 시, @DiscriminatorValue를 붙이지 않아도 알아서 붙어서 DTYPE 이 생성된다.

단일 테이블 전략 구조

1. 표기

@Inheritance(strategy = InheritanceType.SINGLE_TABLE)

2. 장점

1) 모든 데이터가 한 테이블에 모여있기 때문에 조인이 필요 없어서, 조회 성능이 빠르다.
2) 조회 쿼리가 단순하다.

3. 단점
1) 자식 엔티티가 매핑한 컬럼은 모두 NULL을 허용해야한다. 하나라도 NULL이 허용되지 않으면, INSERT 가 제대로 동작하지 않는다.

예를 들어 앨범에 데이터를 넣기 위해 INSERT를 했을 때, 
감독 테이블의 데이터 중 하나가 NULL 이 허용 되지 않은 상태이면, 
현재 모든 데이터가 한 테이블에 있는 상황이기 때문에 해당 부분이 제대로 동작하지 않아 에러가 날 것이기 때문이다.

 

2) 단일 테이블에 모든 것을 저장하므로 테이블이 너무 커질 수 있다.

상황에 따라서 JOIN 테이블 전략과 비교해서 더 느려질 수도 있다.
이를 임계점을 넘는다고 하는데, 보통 그렇게 넘는 경우는 잘 없긴 하다.

---

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

구현 클래스마다 테이블 전략은 사실상 부모 - 자식관계가 아니라 각각의 엔티티를 만드는 것과 같다.

대신, PK는 부모와 자식이 동일하게 가져간다.

 

이 때문에 각 테이블이 중복된 컬럼을 가지고있다. 기존 전략들을 생각해보면 부모 - 자식들이 같은 이름으로 공유하는 컬럼들이 있었는데, 해당 전략은 각각의 엔티티를 만드는 것과 같기 때문에 공유하는 컬럼을 직접 다 써줘야 하기 때문이다.

 

또한, 테이블 자체가 다르기 때문에 Discriminator 어노테이션 들이 필요가 없다. JOIN을 통해 다른 테이블에 접근하는 것과 거의 유사한 구조가 되기 때문이다.

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

 

1. 표기

@Inheritance(strategy = InheritanceType.TABLE_PER_CLASS)

2. 단점

이 전략의 문제는, 부모클래스 타입으로 조회할 시, UNION ALL을 통해 부모 - 자식 테이블을 다 조회해서 데이터를 가져오게된다.

즉, 부모 - 자식이 서로 묶여서 돌아가는게 따로 없기 때문에 검색을 할 때도 모든 테이블을 조회해야하고, 공통 부분을 UPDATE 할 때도 모든 테이블을 UPDATE 해야 한다.
때문에 해당 전략은 사용하지 않는다.

---

5. 40일차 후기

상속 관계 매핑은 수업 중에는 다루지 않았지만 엔티티를 제대로 설계해 활용하기 위해선 반드시 알아야 되는 개념이기 때문에 정리했다.

 

상속 관계 매핑을 사용하지 않으면 모든 엔티티에 대한 Repository 를 만들어야 하기 때문에, 프로젝트의 구조가 너무 복잡해지는 문제가 발생할 수 있기 때문이다.