[내일배움캠프 TIL] 7일차 - entity 연관관계

오늘은 강의 들으면서 제일 헷깔렸던 부분인

entity 연관관계에 대해 복습 정리해보았습니다.

모든 강의를 다 듣고 다시 복습하니까 이해가 더 잘되고 내 것으로 만들 수 있는 것 같습니다.

1. 오늘의 학습 키워드

 

• Relationship: Foreign Key(외래 키), 단방향/양방향 관계
• Ownership: 연관관계의 주인, mappedBy, @JoinColumn
• Multiplicity: 1:1, N:1, 1:N, N:M
• Life Cycle: 영속성 전이(Cascade), 고아 객체 제거(OrphanRemoval)

 

 

2. 핵심 키워드 상세 정리

🔹 Foreign Key (외래 키)와 연관관계

• 개념: 두 테이블을 연결하는 다리 역할을 합니다.
• DB vs Entity: DB 테이블은 컬럼에 값 하나만 넣을 수 있어 여러 데이터를 담지 못하지만, Entity는 **Collection(List)**을 필드로 가질 수 있어 '1:N' 관계를 유연하게 표현할 수 있습니다.
• 방향성: DB는 외래 키 하나로 양방향 조회가 가능하지만(방향 개념 없음), Entity는 서로를 참조하기 위해 각자 상대 타입을 필드로 가지고 있어야 합니다.

🔹 연관관계의 주인 (Owner)

• 정의: 객체 협력 관계에서 외래 키를 관리(등록, 수정, 삭제)할 수 있는 주체입니다.
• 특징: 주인이 아닌 쪽은 '읽기'만 가능합니다.
• 설정: @JoinColumn은 주인이 사용하며, 주인이 아닌 쪽은 mappedBy를 통해 "나는 저 객체에 의해 매핑되었을 뿐"이라고 선언합니다.

🔹 [심화] 1:N 단방향 관계의 모순 (가장 헷갈렸던 부분!)

일반적으로 외래 키는 '다(N)'가 가지지만, 강제로 '1'을 주인으로 설정할 때 발생하는 문제입니다.

• 상황: Food(1)가 User(N)를 관리하는 주인일 때.
• 문제: 실제 DB의 외래 키는 User 테이블에 있는데, 관리는 Food가 하는 권력과 위치의 불일치가 발생합니다.
• 결과: User 저장 시점에 외래 키를 모르기 때문에, 나중에 Food가 저장될 때 User 테이블을 다시 수정하는 추가 UPDATE 쿼리가 발생하여 성능이 저하됩니다.
• 해결: 성능과 직관성을 위해 가급적 N:1 단방향 혹은 N이 주인인 양방향 설계를 권장합니다.

🔹 연관관계의 종류

• N:1 (ManyToOne): 가장 기본적이고 권장되는 관계입니다. 'N' 쪽이 외래 키의 주인이 됩니다.
• 1:1 (OneToOne): 주인을 직접 지정해야 합니다. 보통 접근이 더 많은 테이블을 주인으로 잡습니다.
• 1:N (OneToMany): 위에서 언급한 이슈로 인해 단독 사용보다는 양방향 관계의 '거울' 역할로 주로 쓰입니다.
• N:M (ManyToMany): 실무에서는 거의 사용하지 않습니다. 중간 테이블이 숨겨져 있어 예상치 못한 쿼리가 나갈 수 있으므로, 연결 테이블용 Entity를 직접 만들어 1:N, N:1로 풀어내는 방식을 사용합니다.

🔹 고아 객체 제거 (OrphanRemoval)

• 개념: 부모 엔티티와 연결이 끊어진 자식 엔티티를 자동으로 삭제하는 기능입니다.
• 차이점: CascadeType.REMOVE는 부모가 삭제될 때만 작동하지만, OrphanRemoval은 리스트에서 제거하는 것만으로도 DB에서 삭제됩니다.
• 주의: 자식 엔티티를 관리하는 부모가 오직 하나일 때(단일 소유)만 사용해야 안전합니다.

 

 

처음엔 "왜 외래 키를 가진 쪽이 주인이어야 하지?"라는 의문이 있었는데, DB의 물리적 구조와 JPA의 관리 방식을 대조해보니 그 이유를 명확히 알 수 있었습니다. 특히 1:N 단방향의 비효율성을 이해한 것이 오늘 공부의 가장 큰 수확인 것 같습니다!