상속 관계 매핑 정리

기존 RDB 설계 방식의 문제

관계형 DB에서는 상속 개념이 없기 때문에, 공통된 속성이 있어도 테이블마다 반복해서 작성해야 한다.

기존 테이블 예시

책

상품번호(PK)	이름	가격	저자	출판사

옷

상품번호(PK)	이름	가격	사이즈	색상	브랜드

운동기구

상품번호(PK)	이름	가격	무게	사이즈	브랜드

→ 공통 필드(상품번호, 이름, 가격)가 반복됨

---

슈퍼·서브 타입 모델링(ER 모델)

공통 속성을 부모(슈퍼) 테이블로 올리고 자식(서브)이 상속받는 구조

상품(슈퍼테이블)

상품번호(PK)	이름	가격	상품타입
책 / 옷 / 운동기구를 구분

서브 테이블

• 서브 테이블의 PK는 부모 테이블의 PK를 그대로 사용 → PK이자 FK

책

상품번호(PK, FK)	저자	출판사

옷

상품번호(PK, FK)	사이즈	색상	브랜드

운동기구

상품번호(PK, FK)	무게	사이즈	브랜드

※ 이 구조는 논리적 모델이며, 실제 물리 구현은 전략에 따라 달라짐

---

JPA 상속 매핑 전략 3가지

1) 조인 전략(Joined)

• 부모·자식 각각 테이블 생성
• 자식 테이블은 부모 테이블의 PK를 받아 FK + PK로 사용
• 조회 시 조인 연산이 자주 발생
• 테이블 구조가 명확하여 정규화 관점에서 유리

2) 단일 테이블 전략(Single Table)

• 하나의 테이블에 모든 엔티티 데이터를 저장
• 공통 속성 외의 필드는 NULL 허용

상품(단일 테이블)

상품번호	이름	가격	저자	출판사	사이즈	색상	브랜드	무게	상품타입
책/옷/운동기구 구분 칼럼 포함

• 쿼리가 단순하지만, 불필요한 NULL 필드가 증가하여 공간 낭비

3) 구현 클래스마다 테이블 전략(Table Per Class)

• 엔티티마다 테이블 생성
• 일반적인 RDB 설계와 유사하지만
  중복 데이터가 많고 쿼리 비용이 높아 비추천

---

JPA 기본 Fetch 전략

연관관계	기본 로딩 방식
@ManyToOne, @OneToOne	즉시 로딩(EAGER)
@OneToMany, @ManyToMany	지연 로딩(LAZY)

→ 특별히 항상 함께 조회되는 관계가 아니면 지연 로딩 권장

---

JPA 데이터 타입 종류

1. 엔터티 타입

   • 식별자(PK)를 가지며 독립적으로 존재

2. 임베디드 타입(복합 값 타입)

   • 개발자가 직접 정의한 타입
   • 예) 주소 정보

class Address {
    private String address;
    private String addressDetail;
    private String zipcode;
}

→ 엔터티에서 아래처럼 통합 표현 가능

private Address address;

3. 컬렉션 값 타입
   • 값 타입을 컬렉션 형태로 보관하는 구조

---

핵심 정리

• 기존 RDB는 상속 개념이 없어 중복된 설계를 피하기 어려움
• JPA는 상속 매핑 전략을 통해 객체 모델과 DB 간 패러다임 차이를 해소
• 사용 목적에 따라 상속 전략을 선택하면 설계 품질과 유지보수성이 향상됨

JPA 상속 매핑 = 객체지향 설계 + DB 물리 모델링 간 격차 해소