📖 JPA 연관관계

• 관계 종류: @ManyToOne, @OneToMany, @OneToOne, @ManyToMany
• 방향: 단방향 / 양방향 (mappedBy 사용 시 비주인)
• 연관관계의 주인: 외래키(FK)를 가진 쪽 (@JoinColumn 선언됨)

---

📌 1:N 연관관계 (@OneToMany)

✔️ 단방향

• 한 엔티티가 @OneToMany를 통해 여러 엔티티와 관계를 맺는 경우
• 주인은 1, 비주인의 리스트를 컬렉션으로 보유해야 함
• 실제 FK는 주인 테이블에 있어야 하므로, DB 설계상 부자연스럽고 update 쿼리 추가 발생
• @JoinColumn으로 외래키 컬럼 지정 가능
• 유지보수, 성능 이슈로 실무에서는 잘 사용하지 않음

✔️ 양방향

• 하나의 엔티티가 다른 엔티티와 관계를 맺고 그 반대 방향에서도 서로 참조 가능
• 필요한 경우 insertable = false, updatable = false로 읽기 전용 설정 가능

@ManyToOne
@JoinColumn(name = "company_id", insertable = false, updatable = false)
private Company company;

---

📌 1:1 연관관계 (@OneToOne)

✔️ 단방향 (지원 ❌)

• 외래키 주인 선택 가능
• JPA에서 지원하지 않는다

✔️ 양방향

• 외래 키가 있는 곳이 연관관계의 주인 (UNIQUE 사용 ❌)

  	장점	단점
  주 테이블	주테이블만 조회해도 대상 테이블을 조회할 수 있다	null 허용 (대상 테이블 값이 없을때) 삭제 시 외래 키 값 처리필요
  대상 테이블	연관관계 변경시에도 테이블 구조 유지	지연로딩을 설정해도 즉시 로딩

---

📌 N:M 연관관계 (ManyToMany)

• @ManyToMany로 설정 가능하지만 실무에서는 지양
  • 중간 테이블이 숨겨짐
  • 추가 컬럼(ex. level, license 등) 넣을 수 없음
  • 복잡한 쿼리, 제약 조건 관리 어려움

✔️ 단방향 / 양방향

• @ManyToMany는 단방향도 가능, 필요하면 양방향으로도 설정 가능 (mappedBy 사용)
• 실무에서는 중간 테이블을 별도 Entity로 만들어 @OneToMany - @ManyToOne으로 분리하여 매핑

---

🌟 연관관계 비교하기

연관관계	추천	설명
1:N 단방향	❌ 비추천	FK가 자식에 있는데 부모가 관리하는 구조 → 비효율적
N:1 양방향	✅ 추천	객체-DB 일관성 유지, 가장 자연스러운 구조
1:1	✅ 조건부 추천	상황에 따라 단방향 또는 양방향 선택 (FK 위치 고려)
N:M	❌ 비추천	중간 테이블을 별도 엔티티로 분리하는 방식 추천

---

📖 JPA 테이블 상속 전략

관계형 데이터베이스의 테이블에는 상속관계가 없지만
JPA를 활용해 상속처럼 사용할 수 있다!

✅ 1. SINGLE_TABLE 전략 (default)

▶️ 사용법

• @Inheritance(strategy = InheritanceType.SINGLE_TABLE)
• 부모 클래스 :@DiscriminatorColumn(name = "dtype") ← 생략 가능
• 자식 클래스 : @DiscriminatorValue("원하는구분값")

📌 특징

• 하나의 테이블에 모든 자식 클래스의 정보를 저장 ( 객체 지향적인 개발에 어울림 )
• @DiscriminatorColumn으로 구분 ( 선언하지 않아도 DTYPE으로 컬럼 생성)
• 단순하고 확장가능성이 없는 경우 사용

📌 장단점

장점	단점
쿼리 빠름 (조인 없음)	단일 테이블이므로 컬럼이 많아지고, 자식이 매핑한 컬럼에 NULL 많아짐
관리 용이	DB 정규화 X

▪️ 사용 예시

---

✔️ 엔티티 코드

@Entity
@Inheritance(strategy = InheritanceType.SINGLE_TABLE) ✅
@DiscriminatorColumn(name = "dtype") ✅
public abstract class Item {
    @Id @GeneratedValue
    private Long id;
    private String name;
}

@Entity
@DiscriminatorValue("B") ✅
public class Book extends Item {
    private String author;
}

@Entity
@DiscriminatorValue("M") ✅
public class Movie extends Item {
    private String director;
}

✔️ 실행 코드

Item book = new Book();
book.setName("JPA Book");
((Book) book).setAuthor("수린");

em.persist(book); ✅

✔️ 결과 테이블

item

id	name	author	director	dtype
1	JPA Book	수린	null	B

---

✅ 2. JOINED 전략

▶️ 사용법

• @Inheritance(strategy = InheritanceType.JOINED)
• 부모 클래스 :@DiscriminatorColumn(name = "dtype") ← 생략 불가
• 자식 클래스 : @DiscriminatorValue("원하는구분값")

📌 특징

• 부모, 자식 각각 테이블 생성
• JOIN을 통해 조회
• 비즈니스적으로 복잡한 경우 사용 ( 객체 지향적인 개발에 어울림 )

📌 장단점

장점	단점
정규화 잘됨 (DB 깔끔)	성능 느림 (JOIN 발생)
자식 테이블마다 필요한 컬럼만 가짐	INSERT 시 쿼리 2번 발생

▪️ 사용예시

---

✔️ 엔티티 코드

@Entity
@Inheritance(strategy = InheritanceType.JOINED) ✅
@DiscriminatorColumn(name = "dtype") ✅
public abstract class Item {
    @Id @GeneratedValue
    private Long id;
    private String name;
}

@Entity
@DiscriminatorValue("B") ✅
public class Book extends Item {
    private String author;
}

✔️ 실행 코드

Book book = new Book();
book.setName("JPA Book");
book.setAuthor("수린");

em.persist(book); ✅

✔️ 결과 테이블

item

id	name	dtype
1	JPA Book	B

book

id	author
1	수린

---

✅ 3. TABLE_PER_CLASS 전략 (사용 ❌)

▶️ 사용법

• @Inheritance(strategy = InheritanceType.TABLE_PER_CLASS)

• ❌@DiscriminatorColumn, @DiscriminatorValue 사용 안 함

📌 특징

• 부모 테이블 없이 자식마다 테이블 개별 생성
• 자식끼리도 완전 독립
• 부모 클래스 대신, 추상 클래스 사용해야 함
• ❌GenerationType.IDENTIFY 사용 불가

📌 장단점 (사용하지 않는 것 권장)

장점	단점
자식 테이블 완전 독립, 빠름	쿼리 복잡, UNION 필요(자식 테이블을 전부 합쳐야함)
not null 사용 가능	부모 객체 타입 조회시 자식 전부 조회해야 함

▪️ 사용 예시

---

✔️ 엔티티 코드

@Entity
@Inheritance(strategy = InheritanceType.TABLE_PER_CLASS) ✅
public abstract class Item {
    @Id @GeneratedValue
    private Long id;
    private String name;
}

@Entity
public class Book extends Item {
    private String author;
}

✔️ 실행 코드

Book book = new Book();
book.setName("JPA Book");
book.setAuthor("수린");

em.persist(book); ✅

✔️ 결과 테이블

book

id	name	author
1	JPA Book	수린

💡 item 테이블은 없음! Book, Movie 각각 독립 테이블로 생성됨.

---

🌟 테이블 전략 @Annotation 정리

• @Inheritance(strategy = InheritanceType.${전략})
  1. JOINED : 조인
  2. SINGLE_TABLE : 단일 테이블(Default)
  3. TABLE_PER_CLASS : 구현 클래스마다 테이블

• @DiscriminatorColumn(name = "dtype")
  • dtype 컬럼을 생성함 (관례)
  • 이름 변경 가능
  • 기본 값: DTYPE

• @DiscriminatorValue("${값}")
  • dtype 값 지정
  • 기본 값: 클래스 이름

---

📖 Proxy

em.getReference()는 프록시 객체를 반환

• 지연로딩을 지원하기 위해 대리 객체를 사용
• 실제 엔티티 생성, DB 조회하지 않고도 참조할 수 있음
• target : 실제 객체의 참조값을 보관
  (== 로는 비교 불가, instanceof 사용)

---

📌 em.getReference()

Tutor proxyTutor = em.getReference(Tutor.class, tutor.getId()); ✅ 프록시 객체 생성 (실제 객체의 참조값만 기억)
System.out.println("proxyTutor.getName() = " + proxyTutor.getName()); ✅ 필드 접근 후 조회 SQL 실행 (초기화)

• em.getReference()는 프록시 객체를 생성
• 프록시 객체 생성 후 최초 사용시(엔티티에 접근시)에 한번만 초기화
• 다만, 이미 영속성 컨텍스트에 해당 Entity가 있으면 프록시 생성하지 않고 그 객체 그대로 반환

✔️ 🆚 영속성 컨텍스트

• 영속성 컨텍스트 = JPA가 관리 중인 모든 엔티티의 저장소 (1차 캐시)
• 프록시 = getReference()로 등록된, 아직 초기화되지 않은 객체(껍데기)
• 영속성 컨텍스트는 프록시를 포함하는 상위 개념

✔️ 관련 예외 - LazyInitalizationException

• 프록시 객체를 생성 후, detach했거나, 프록시 객체를 생성하지 않고 객체에 접근하고자 했을때!
• 프록시 객체가 없다 or 영속상태가 아니다!

---

📌 em.find()와 비교

메서드	em.find()	em.getReference()
DB 쿼리 발생 여부	조건부 ✅	❌ ➝ 프록시 객체 반환
설명	1차 캐시 ➝ DB 조회 + 캐시에 추가	실제 DB 조회하지 않고 프록시 객체만 등록

---

🌟 지연로딩, 즉시로딩 정리

지연로딩	즉시로딩
fetch = FetchType.LAZY	fetch = FetchType.EAGER
proxy 객체를 조회	proxy 조회 ❌, 연관된 객체 한번에 조회
연관된 객체를 매번 조회하는게 낭비인 경우	연관된 객체를 매번 함께 조회하는 것이 효율적인 경우

---

📖 영속성 전이

📌 Cascade

    @OneToMany(mappedBy = "category", cascade = CascadeType.ALL) 
    								  🔼 카테고리-프로덕트 리스트 간의 영속성 전이 설정함
    private List<Product> productList = new ArrayList<>();

• 특정 엔티티를 가지고 작업할 때, 연관된 엔티티에도 동일한 작업을 자동으로 하게 설정
• 지연로딩, 즉시로딩과는 무관
• @OneToMany가 선언된 쪽 = 부모 쪽에 선언

📌 CasecadeType별 의미

✔️ CascadeType.ALL	✔️ CascadeType.PERSIST	✔️ CascadeType.REMOVE
PERSIST + REMOVE + MERGE + REFRESH + DETACH ... 등	em.persist(parent) 했을 때 → 자식들도 자동으로 persist()	em.remove(parent) 했을 때 → 자식들도 자동으로 remove()
모든 전이 포함	INSERT 쿼리 같이 발생	DELETE 쿼리 같이 발생

▶️ 고아 객체

• 부모 엔티티와의 관계가 끊긴 자식 엔티티

✔️ orphanRemoval

• 부모-자식 관계가 끊긴 자식 객체를 DB에서 자동으로 삭제할지 설정

• @OneToMany가 선언된 쪽 = 부모에 선언

  false (기본값)	true
  자식은 DB에 그대로 남음 (❗수동 삭제 필요)	자식은 DELETE 쿼리 발생, DB에서도 제거됨

---

▪️ 엔티티 코드

@Entity
@Table(name = "category")
public class Category {

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

    private String name;
	
    @OneToMany(mappedBy = "category", cascade = CascadeType.ALL, orphanRemoval = true) ✅
    private List<Product> productList = new ArrayList<>();

    public Category() {
    }

	...
    
    public void addProduct(Product product) {
        productList.add(product);
        product.setCategory(this); // 연관관계 주인 설정을 메서드로!
    }
}

▪️ 실행 코드

public class OrphanRemovalMain {
    public static void main(String[] args) {

		...

        try {
            // 1. 부모 생성
            Category category = new Category("food");

            // 2. 자식 생성 (아직 연관관계 X)
            Product product1 = new Product("pizza");
            Product product2 = new Product("kimchi");

            // 3. 연관관계 설정 (addProduct가 양방향 연관관계 주입)
            category.addProduct(product1);
            category.addProduct(product2);

            // 4. 부모만 persist했지만, cascade 덕분에 자식도 자동 persist됨
            em.persist(category); // cascade = ALL

            // 5. DB에 반영 + 영속성 컨텍스트 비움
            em.flush(); // INSERT 실행
            em.clear(); // 1차 캐시 초기화

            // 6. 다시 부모 조회
            Category findCategory = em.find(Category.class, category.getId());

            // 7. 자식을 컬렉션에서 제거!
            findCategory.getProductList().remove(0);
            // ✅ orphanRemoval = true 이므로,
            // 여기서 "자식 1개가 부모에서 제거됐네 → 고아 객체!" 라고 판단
            // → 트랜잭션 커밋 시 DELETE 쿼리 날림! 🔥

            transaction.commit(); // ✅ 여기서 자식 1개 DELETE 쿼리 발생

			...
            
    }
}

---

🌟 영속성 삭제 전이 🆚 고아 객체 제거

항목	CascadeType.Remove	orphanRemoval=true
목적	부모 객체 삭제시 자식 객체도 삭제	부모가 없어진 자식 객체는 자동 삭제
작동 시점	부모가 remove 될 때	부모 컬렉션에서 자식을 제거할 때 (관계 끊길 때)
사용 조건	부모-자식 연관관계 + cascade 설정	부모-자식 연관관계만 있어도 가능 (단독 사용 가능 ✅)