JPA 엔티티 양방향 관계에서 연관관계 주인이 필요한 이유

📝 JPA 연관 관계의 주인 1

1. 문제 상황: 양방향 관계에서 외래 키 관리 충돌

예제 설계

• Team과 Member는 양방향 관계로 설계되어 있습니다.
• Team은 여러 Member를 가질 수 있으며, Member는 하나의 Team에 속합니다.
• 데이터베이스에서는 Member 테이블에 TEAM_ID라는 외래 키가 존재합니다.

문제 코드

@Entity
public class Team {
    @Id
    @GeneratedValue
    private Long id;

    @OneToMany
    @JoinColumn(name = "TEAM_ID") // Team도 외래 키를 관리하려고 시도
    private List<Member> members = new ArrayList<>();
}

@Entity
public class Member {
    @Id
    @GeneratedValue
    private Long id;

    @ManyToOne
    @JoinColumn(name = "TEAM_ID") // Member도 외래 키를 관리하려고 시도
    private Team team;
}

2. 실제 동작: 양방향 관계에서 외래 키 변경

1. Team 엔티티에서 멤버 추가

Team team = new Team();
Member member = new Member();

// Team에서 멤버 추가
team.getMembers().add(member);

Team에서 멤버를 추가했지만, 외래 키 TEAM_ID가 어떻게 설정될지 명확하지 않습니다.

2. Member 엔티티에서 팀 설정

member.setTeam(team);

Member에서 팀을 설정했지만, TEAM_ID가 어떻게 변경될지 명확하지 않습니다.

두 엔티티가 모두 외래 키를 관리하려 하면 충돌이 발생할 수 있습니다.

3. JPA의 문제: 외래 키 충돌

JPA는 양방향 관계에서 외래 키를 하나의 주체가 관리해야 합니다.

• 두 엔티티가 동시에 외래 키를 변경하려 하면 충돌이 발생하거나 데이터가 손실될 수 있습니다.
• 주인을 명확히 지정하면 JPA는 주인만 업데이트하고, 비주인은 데이터 일관성을 유지하는 역할만 합니다.

4. 해결: 관계의 주인을 명확히 지정

Member 엔티티를 주인(Owner)으로 지정하고, Team 엔티티를 비주인(Non-Owner)으로 설정합니다.

외래 키를 Member에서만 관리하고, Team에서는 읽기 전용으로 사용합니다.

수정된 설계

@Entity
public class Team {
    @Id
    @GeneratedValue
    private Long id;

    private String name;

    @OneToMany(mappedBy = "team") // 비주인, 외래 키는 Member가 관리
    private List<Member> members = new ArrayList<>();
}

@Entity
public class Member {
    @Id
    @GeneratedValue
    private Long id;

    private String name;

    @ManyToOne
    @JoinColumn(name = "TEAM_ID") // 주인, 외래 키 관리
    private Team team;
}

5. 예시: 주인과 비주인의 차이

Team에서 멤버 추가

Team team = new Team();
Member member = new Member();

// Team에서 멤버 추가
team.getMembers().add(member);

// Member에서 팀 설정 (외래 키 관리)
member.setTeam(team);

em.persist(team);
em.persist(member);

실제 쿼리

INSERT INTO TEAM (id, name) VALUES (?, ?);
INSERT INTO MEMBER (id, name, TEAM_ID) VALUES (?, ?, ?);

6. 왜 외래 키를 주인이 관리해야 하는가?

• 하나의 주체가 관리해야 데이터 일관성이 유지됨:
  • 두 엔티티가 동시에 외래 키를 변경하려 하면 충돌이 발생하거나 데이터가 손실될 수 있습니다.
• JPA의 동작 방식과 일치:
  • JPA는 관계의 주인만이 외래 키를 수정할 수 있도록 설계되어 있습니다.
  • 비주인은 단순히 연관 관계를 읽거나 조회할 수 있습니다.

7. 결론

양방향 관계에서 연관 관계의 주인을 명확히 지정하는 이유는:

• 외래 키 충돌 방지: 하나의 엔티티만 외래 키를 관리하도록 하여 데이터 충돌을 방지합니다.
• JPA의 명확한 역할 분담: 주인은 외래 키를 변경하고, 비주인은 데이터를 읽기만 하도록 설계합니다.

이렇게 주인과 비주인을 명확히 나누면, JPA가 일관된 방식으로 데이터를 관리할 수 있습니다!

 

---

📝 JPA 연관 관계의 주인 2

핵심 개념

"양방향 관계에서 하나의 엔티티만 외래 키(FK)를 관리해야 하며, 그 엔티티는 데이터베이스 테이블에서 실제로 외래 키를 가지고 있는 테이블에 매핑된 엔티티가 연관 관계의 주인이 된다."

왜 이런 규칙이 필요할까?

• 데이터 무결성:
  • 두 엔티티가 동시에 외래 키를 관리하려 하면, JPA가 어떤 엔티티의 상태를 기준으로 외래 키를 변경해야 할지 알 수 없습니다.
  • 한쪽 엔티티를 "주인"으로 지정함으로써, 외래 키 변경에 대한 책임을 명확히 할 수 있습니다.
• JPA 동작 원리:
  • JPA는 연관 관계의 주인만 외래 키를 수정하도록 설계되어 있습니다.
  • 비주인은 단순히 관계를 읽기만 할 수 있습니다. 이를 통해 불필요한 데이터 충돌이나 비일관성을 방지합니다.
• 테이블 구조와 매핑의 일치:
  • 데이터베이스에서 외래 키는 특정 테이블에 존재합니다. 따라서 해당 테이블에 매핑된 엔티티가 외래 키를 관리해야 데이터베이스와 객체 간의 매핑이 일관성 있게 유지됩니다.

주인과 비주인의 역할

• 주인 (Owner):
  • 외래 키를 가지고 있는 엔티티.
  • @JoinColumn을 사용하여 외래 키를 매핑하고, JPA가 외래 키를 관리하도록 설정.
• 비주인 (Non-Owner):
  • 외래 키를 직접 관리하지 않는 엔티티.
  • mappedBy를 사용하여 주인을 지정하고, 연관 관계를 읽기만 가능.

예시

테이블 구조

• TEAM:
  • TEAM_ID (PK)
  • NAME
• MEMBER:
  • MEMBER_ID (PK)
  • NAME
  • TEAM_ID (FK)

엔티티 설계

@Entity
public class Team {
    @Id
    @GeneratedValue
    private Long id;

    private String name;

    @OneToMany(mappedBy = "team") // 비주인
    private List<Member> members = new ArrayList<>();
}

@Entity
public class Member {
    @Id
    @GeneratedValue
    private Long id;

    private String name;

    @ManyToOne
    @JoinColumn(name = "TEAM_ID") // 주인
    private Team team;
}

정리

• 양방향 관계에서는 반드시 하나의 엔티티만 외래 키를 관리해야 합니다.
• 외래 키를 가지고 있는 테이블에 매핑된 엔티티가 연관 관계의 주인이 되는 것이 자연스럽습니다.
• JPA는 연관 관계의 주인만 외래 키를 수정할 수 있고, 비주인은 읽기만 가능합니다.

이 규칙을 따르면 데이터베이스와 객체 간의 매핑이 명확하고 일관성을 유지할 수 있습니다! 😊

---

📙 객체와 테이블의 관계 차이

1. 테이블과 객체의 관계 차이

테이블 세계

• 테이블에서는 하나의 외래 키(FK)만으로 양방향 관계를 표현할 수 있습니다.
• 외래 키는 한쪽 테이블에만 존재하며, 다른 쪽 테이블은 이를 참조하여 관계를 맺습니다.

예: Member 테이블에 TEAM_ID라는 외래 키가 있다면, 이 외래 키만으로 Member가 Team을 참조할 수 있고, 반대로 Team에서 Member를 참조할 수도 있습니다.

객체 세계

• 객체에서는 관계를 양방향으로 표현하려면, 각 객체가 서로를 참조해야 합니다.
• 객체는 외래 키를 직접 가지지 않으며, 대신 참조를 위한 필드를 통해 관계를 표현합니다.
• 따라서 객체 간의 양방향 관계는 단방향 관계 두 개로 이루어져 있습니다:
  • Member 객체가 Team 객체를 참조하는 관계.
  • Team 객체가 Member 객체를 참조하는 관계.

2. 예제

테이블 설계

• TEAM 테이블:

TEAM_ID   NAME
----------------
1         Development
2         Marketing

• MEMBER 테이블:

MEMBER_ID   NAME       TEAM_ID (FK)
------------------------------------
101         Alice      1
102         Bob        1
103         Carol      2

객체 설계

@Entity
public class Team {
    @Id
    @GeneratedValue
    private Long id;

    private String name;

    @OneToMany(mappedBy = "team") // Team에서 Member를 참조
    private List<Member> members = new ArrayList<>();
}

@Entity
public class Member {
    @Id
    @GeneratedValue
    private Long id;

    private String name;

    @ManyToOne
    @JoinColumn(name = "TEAM_ID") // Member에서 Team을 참조
    private Team team;
}

3. 왜 객체는 단방향 참조 두 개로 연결되는가?

• 객체는 외래 키를 직접 가지지 않는다:
  • 객체는 테이블처럼 외래 키를 물리적으로 가지지 않고, 다른 객체를 참조하는 필드를 통해 관계를 표현합니다.
• 객체는 방향성을 가진 참조만 가능하다:
  • 객체는 테이블처럼 양방향으로 데이터를 탐색할 수 있는 구조가 아닙니다.
  • Member가 Team을 참조하려면 Member에 team 필드가 있어야 하고, Team이 Member를 참조하려면 Team에 members 필드가 있어야 합니다.
• 테이블의 FK는 단일 필드로 모든 방향을 해결:
  • 테이블은 JOIN을 사용하여 양방향 탐색이 가능하지만, 객체는 이를 별도로 구현해야 합니다.

4. 객체와 테이블 간의 관계 비교

테이블 관점

TEAM (1) ---- FK (TEAM_ID) ----> MEMBER (N)

객체 관점

Team --> members: List  (단방향)
Member --> team: Team           (단방향)

두 개의 단방향 참조를 합쳐서 양방향 관계처럼 동작하도록 설계합니다.

5. 요약

• 테이블 세계: 외래 키 하나만으로 양방향 관계를 표현할 수 있습니다.
• 객체 세계: 양방향 관계를 표현하려면 각 객체에 상대 객체에 대한 참조를 별도로 추가해야 하므로, 단방향 관계 두 개로 연결됩니다.
• 객체 세계의 양방향 관계는 사실상 단방향 관계 두 개를 합친 것이라고 이해하면 됩니다.

이 개념을 알면 객체 설계와 테이블 설계를 연결하여 더 명확히 이해할 수 있습니다! 😊

---

위와 같은 이유로 연관관계의 주인이 필요하다.

 

📝 연관관계의 주인이 필요한 이유

1. 객체와 테이블의 차이로 인해 발생하는 문제

1. 테이블에서의 양방향 관계

• 테이블에서는 외래 키(FK) 하나로 양방향 관계를 표현할 수 있습니다.
• SQL에서 JOIN을 사용하면 양쪽 방향으로 탐색이 가능합니다:
  • SELECT * FROM MEMBER WHERE TEAM_ID = ? → Member에서 Team으로 탐색
  • SELECT * FROM TEAM T JOIN MEMBER M ON T.TEAM_ID = M.TEAM_ID → Team에서 Member로 탐색

2. 객체에서의 양방향 관계

• 객체에서는 양방향 관계를 구성하려면, 두 객체가 서로를 참조해야 합니다:
  • Member 객체가 Team 객체를 참조 (Member → Team)
  • Team 객체가 Member 객체를 참조 (Team → Member)
• 그러나 JPA는 테이블에 데이터를 저장하거나 외래 키를 관리해야 하는데, 양쪽 모두에서 외래 키를 관리하려고 하면 충돌이 발생합니다.

2. 연관관계의 주인이 필요한 이유

1. 객체의 양방향 관계는 단방향 2개로 구성된다

• 양방향 관계를 구성하기 위해 Member와 Team은 서로를 참조합니다.
• 그러나 하나의 외래 키는 하나의 주체에 의해 관리되어야 데이터 일관성을 유지할 수 있습니다.

2. 외래 키를 관리하는 책임을 하나로 통합해야 한다

• 양방향 관계에서 양쪽이 동시에 외래 키를 관리하면 다음과 같은 문제가 발생합니다:
  • JPA가 어떤 방향에서 외래 키를 업데이트할지 모호합니다.
  • 데이터베이스 일관성이 깨질 수 있습니다.
• 이를 해결하기 위해 연관관계의 주인을 지정하여, 외래 키 관리의 책임을 명확히 합니다.

3. 주인만 외래 키를 관리한다

• JPA에서 연관관계의 주인만 외래 키를 업데이트하거나 저장할 수 있습니다.
• 반면, 비주인은 관계를 읽기만 할 수 있으며, 데이터베이스에는 영향을 주지 않습니다.

3. 예시

잘못된 연관관계 설계

@Entity
public class Team {
    @OneToMany
    @JoinColumn(name = "TEAM_ID") // Team도 외래 키를 관리
    private List<Member> members;
}

@Entity
public class Member {
    @ManyToOne
    @JoinColumn(name = "TEAM_ID") // Member도 외래 키를 관리
    private Team team;
}

올바른 연관관계 설계

@Entity
public class Team {
    @OneToMany(mappedBy = "team") // 비주인
    private List<Member> members;
}

@Entity
public class Member {
    @ManyToOne
    @JoinColumn(name = "TEAM_ID") // 주인
    private Team team;
}

4. 연관관계의 주인이 없으면 발생하는 문제

• 중복 쿼리: JPA가 양쪽에서 외래 키를 관리하려 하면, 동일한 데이터를 두 번 저장하려고 시도할 수 있습니다.
• 데이터 무결성 문제: 두 엔티티가 서로 다른 외래 키 값을 유지할 가능성이 생깁니다.
• JPA 동작 혼란: 어떤 엔티티가 외래 키를 최종적으로 결정할지 알 수 없어, 예외가 발생할 수 있습니다.

5. 결론

객체와 테이블의 관계 표현 차이로 인해 JPA는 연관관계의 주인을 도입합니다.

• 연관관계의 주인은 외래 키를 관리할 책임을 가지며, 데이터베이스에 영향을 줍니다.
• 비주인은 관계를 읽기만 할 수 있어, 데이터 무결성과 JPA의 명확한 동작을 보장합니다.

따라서, "연관관계의 주인은 객체-테이블 간의 관계 차이를 해결하기 위해 도입된 개념이다"라고 이해하면 됩니다. 😊

---

package jpashop.jpaorder.domain;

import javax.persistence.*;

@Entity
public class Member {

  @Id @GeneratedValue
  @Column(name = "MEMBER_ID")
  private Long id;
  private String name;
  private String city;
  private String street;
  private String zipcode;

  @ManyToOne(fetch = FetchType.LAZY)
  @JoinColumn(name = "TEAM_ID")
  private Team team;

  public Long getId() {
    return id;
  }

  public void setId(Long id) {
    this.id = id;
  }

  public String getName() {
    return name;
  }

  public void setName(String name) {
    this.name = name;
  }

  public String getCity() {
    return city;
  }

  public void setCity(String city) {
    this.city = city;
  }

  public String getStreet() {
    return street;
  }

  public void setStreet(String street) {
    this.street = street;
  }

  public String getZipcode() {
    return zipcode;
  }

  public void setZipcode(String zipcode) {
    this.zipcode = zipcode;
  }

  public Team getTeam() {
    return team;
  }

  public void setTeam(Team team) {
    this.team = team;
  }

  /* ==연관관계 편의 메서드== */
  public void changeTeam(Team team) {
    this.team = team;
    team.getMembers().add(this);
  }
}

package jpashop.jpaorder.domain;

import javax.persistence.*;
import java.util.ArrayList;
import java.util.List;

@Entity
public class Team {

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

  @OneToMany(mappedBy = "team")
  private List<Member> members = new ArrayList<>();

  public Long getId() {
    return id;
  }

  public void setId(Long id) {
    this.id = id;
  }

  public String getName() {
    return name;
  }

  public void setName(String name) {
    this.name = name;
  }

  public List<Member> getMembers() {
    return members;
  }

  public void setMembers(List<Member> members) {
    this.members = members;
  }

  /* ==연관관계 편의 메서드== */
  public void addMember(Member member) {
    members.add(member);
    member.setTeam(this);
  }
}

package jpashop.jpaorder;

import jpashop.jpaorder.domain.Member;
import jpashop.jpaorder.domain.Team;

import javax.persistence.EntityManager;
import javax.persistence.EntityManagerFactory;
import javax.persistence.EntityTransaction;
import javax.persistence.Persistence;
import java.util.List;

public class JpaMain {
  public static void main(String[] args) {
    EntityManagerFactory emf = Persistence.createEntityManagerFactory("jpaorder");
    EntityManager em = emf.createEntityManager();
    EntityTransaction tx = em.getTransaction();
    tx.begin();

    try {

      Team team = new Team();
      team.setName("teamA");

      Member member1 = new Member();
      member1.setName("member1");

      Member member2 = new Member();
      member2.setName("member2");

      team.addMember(member1);
      team.addMember(member2);

      em.persist(member1);
      em.persist(member2);
      em.persist(team);

      List<Member> members1 = team.getMembers();
      for (Member member : members1) {
        System.out.println(member.getName());
      }

//      em.flush();
//      em.clear();

//      Team findTeam = em.find(Team.class, team.getId());
//      List<Member> members = findTeam.getMembers();
//      for (Member member : members) {
//        System.out.println("member.getName() = " + member.getName());
//      }

      tx.commit();
    } catch (Exception e) {
      tx.rollback();
    } finally {
      em.close();
      emf.close();
    }
  }
}

 

❓ team에 이미 member1, 2 가 다 add 된 상태로 persist 되잖아 근데 이때 team에는 PK가 없어서 member1,2 의 FK가 세팅이 안되는데 team이 persist 하면 PK가 생기니깐 그때 member1,2 의 FK가 업데이트 되는건가?

네, 정확히 그렇습니다.

team이 persist되어 PK가 생성되면, 그 시점에 JPA가 member1과 member2의 외래 키(FK)를 업데이트합니다.

😁 JPA 연관 관계에서 FK 업데이트 과정

동작 과정

1. team.addMember(member1) 호출
   • 연관관계 편의 메서드를 통해 member1의 team 필드가 team을 참조하도록 설정됩니다.
   • 이 시점에서는 team 객체의 id 값(PK)이 아직 없으므로, 외래 키가 설정되지 않은 상태입니다.
2. em.persist(member1) 호출
   • JPA는 member1을 영속화하고 Member 테이블에 INSERT 쿼리를 생성합니다.
   • 하지만 TEAM_ID 값(PK)이 아직 team에 없으므로, TEAM_ID는 NULL로 삽입됩니다.
3. em.persist(team) 호출
   • team이 영속화되면서 데이터베이스에 저장되고, team.id 값(PK)이 생성됩니다.
4. 플러시(Flush)
   • em.flush() 또는 트랜잭션 커밋 시점에 JPA는 team.id 값을 참조하여 member1과 member2의 TEAM_ID를 업데이트하는 UPDATE 쿼리를 실행합니다.

로그 분석 예시

1. INSERT 쿼리 (Member 테이블)

INSERT INTO Member (name, city, street, zipcode, TEAM_ID) VALUES ('member1', NULL, NULL, NULL, NULL);
INSERT INTO Member (name, city, street, zipcode, TEAM_ID) VALUES ('member2', NULL, NULL, NULL, NULL);

2. INSERT 쿼리 (Team 테이블)

INSERT INTO Team (name) VALUES ('teamA');

3. UPDATE 쿼리 (Member 테이블)

UPDATE Member SET TEAM_ID = 1 WHERE MEMBER_ID = 1;
UPDATE Member SET TEAM_ID = 1 WHERE MEMBER_ID = 2;

왜 이렇게 동작할까?

• IDENTITY 전략의 특성:
  • team.id는 데이터베이스에서 자동 생성되며, persist 시점에만 값을 얻을 수 있습니다.
  • 따라서, team이 먼저 persist되지 않으면 member1과 member2는 올바른 TEAM_ID 값을 설정할 수 없습니다.
• JPA의 플러시 동작:
  • JPA는 영속성 컨텍스트의 변경 내용을 데이터베이스에 동기화할 때, 엔티티 간의 연관관계를 자동으로 처리합니다.
  • team.id가 생성된 이후, JPA는 연관관계의 주인(Member.team)에 설정된 값을 기반으로 외래 키를 업데이트합니다.

코드 개선 방법

1. cascade 옵션 활용

@OneToMany(mappedBy = "team", cascade = CascadeType.PERSIST)
private List<Member> members = new ArrayList<>();

cascade = CascadeType.PERSIST를 설정하면, team.persist 시 member1과 member2도 자동으로 persist됩니다.

2. persist 순서 변경

em.persist(team); // 먼저 team을 저장
em.persist(member1);
em.persist(member2);

team을 먼저 persist한 후, member1과 member2를 persist하면 UPDATE 쿼리를 줄일 수 있습니다.

결론

team이 persist되기 전에는 team.id 값이 없으므로, member1과 member2의 TEAM_ID는 설정되지 않습니다.

team이 persist되어 team.id가 생성된 후, JPA는 member1과 member2의 외래 키를 업데이트합니다.

이를 통해 객체와 데이터베이스 간의 연관관계가 일관되게 유지됩니다. 😊

---

❓ JPA는 영속성 컨텍스트의 변경 내용을 데이터베이스에 동기화할 때, 엔티티 간의 연관관계를 자동으로 처리합니다.

→ 이렇게 할 수 있는 이유는 @JoinedColumn(name = "TEAM_ID") 때문인건가?

 

네 그렇습니다! JPA가 엔티티 간의 연관관계를 자동으로 처리할 수 있는 이유는, @JoinColumn 어노테이션을 통해 **외래 키(FK)**와 데이터베이스 컬럼 간의 매핑 정보를 명확히 전달받았기 때문입니다.

😁 JPA와 @JoinColumn의 역할

@JoinColumn의 역할

1. 외래 키와 데이터베이스 컬럼 매핑
   • @JoinColumn(name = "TEAM_ID")는 Member 엔티티의 team 필드와 데이터베이스의 TEAM_ID 컬럼을 매핑합니다.
   • 이를 통해 JPA는 team 필드에 설정된 Team 엔티티의 식별자(id) 값을 외래 키 컬럼에 저장하거나 갱신할 수 있습니다.
2. 연관관계 관리
   • @ManyToOne과 함께 사용되며, 연관관계의 주인이 되는 필드(Member.team)를 통해 외래 키를 관리합니다.
   • Member.team 필드 값이 변경되면, JPA는 해당 변경 내용을 기반으로 데이터베이스의 외래 키 컬럼(TEAM_ID)을 업데이트합니다.

JPA의 동작 원리

JPA는 영속성 컨텍스트에 관리되는 엔티티의 상태를 추적합니다. @JoinColumn 덕분에 다음과 같은 동작이 가능합니다:

1. 삽입(INSERT) 시 외래 키 설정

• member1.setTeam(team)으로 team 필드를 설정하면, JPA는 team.getId() 값을 읽어 TEAM_ID로 매핑합니다.
• 이 정보를 통해 Member 테이블에 삽입 쿼리를 생성합니다.

INSERT INTO Member (name, TEAM_ID) VALUES ('member1', 1);

2. 업데이트(UPDATE) 시 외래 키 갱신

• member1.setTeam(newTeam)으로 team 필드를 변경하면, JPA는 이전 team.getId() 값과 새 team.getId() 값을 비교합니다.
• 값이 변경되었다면, 데이터베이스의 외래 키 컬럼을 업데이트하는 쿼리를 생성합니다.

UPDATE Member SET TEAM_ID = 2 WHERE MEMBER_ID = 1;

3. 연관관계 탐색(SELECT)

• team.getMembers()를 호출하면 JPA는 TEAM_ID를 기준으로 Member 테이블에서 관련 데이터를 조회합니다.

SELECT * FROM Member WHERE TEAM_ID = 1;

@JoinColumn이 없으면?

• @JoinColumn 없이도 JPA는 기본적으로 필드명을 사용해 외래 키 컬럼을 생성할 수 있습니다.
• 예를 들어:

  @ManyToOne
  private Team team; // @JoinColumn 생략
  

• 이 경우 JPA는 기본 이름 규칙에 따라 team_id라는 외래 키 컬럼을 생성합니다.
• 하지만 기본 이름과 데이터베이스 컬럼 이름이 일치하지 않으면, 외래 키 매핑이 실패하거나 잘못된 쿼리가 생성될 수 있습니다.

결론

JPA가 엔티티 간의 연관관계를 자동으로 처리할 수 있는 이유는:

• @JoinColumn을 통해 외래 키 매핑 정보가 제공되었기 때문입니다.
• JPA는 이를 기반으로 외래 키 값을 생성, 업데이트, 조회하는 SQL을 자동으로 생성하고 실행합니다.

@JoinColumn은 JPA와 데이터베이스 간의 원활한 연동을 위한 핵심적인 구성 요소입니다. 😊

 

 

---

📚 출처 : ChatGPT