📋 연관관계 매핑의 3가지 고려사항

• 엔티티의 연관관계를 매핑할 때는 다음의 3가지를 고려해야 한다.
  • 다중성
  • 단방향, 양방향
  • 연관관계의 주인

1. 다중성

- 다대일 @ManyToOne
- 일대다 @oneToMany
- 일대일 @OneToOne
- 다대다 @ManyToMany

• 다중성 판단이 어려울 때는 반대방향을 생각해보며 된다.
  • 일대다의 반대 방향은 항상 다대일
  • 일대일의 반대 방향은 항상 일대일
• 보통 다대일과 일대다 관계를 가장 많이 사용.
• 다대다 관계는 실무에서 거의 사용되지 않는다.

2. 단방향, 양방향

• 테이블: 외래 키 하나로 조인을 사용해 양방향으로 쿼리가 가능
  • 사실상 방향이라는 개념이 없다.
• 객체: 참조용 필드로 연관 객체 조회. (필드를 가진 객체만 참조 가능) 객체의 경우에만 방향성을 가지게 된다.
  • 단방향: 한 쪽의 객체만 참조하는 것.
  • 양방향: 양쪽의 객체가 모두 참조하고 있는 것. (사실상 단방향 2개)

3. 연관관계의 주인

테이블은 외래 키 하나로 양쪽이 모두 관계를 관리할 수 있으므로, 사실상 연관관계 관리 포인트가 외래키 하나이다. 반면 엔티티는 두 객체 모두가 서로를 참조하고 있어 연관관계 관리 포인트가 2곳이 된다. 따라서 엔티티의 경우 두 관리 포인트 중 한 곳을 주인으로 선정하여 외래키를 관리하도록 하고, 나머지 한 곳은 조회만 가능하도록 해야한다. 연관관계의 주인은 mappedBy 속성을 사용하지 않고, 주인이 아니면 mappedBy 속성을 통해 주인의 필드값을 이름으로 입력받는다.

📚 고려 가능한 모든 연관관계 목록

• 다중성은 왼쪽을 연관관계의 주인으로 정했다.

- 다대일: 단방향, 양방향
- 일대다: 단방향, 양방향
- 일대일: 주 테이블 단방향, 양방향
- 일대일: 대상 테이블 단방향, 양방향
- 다대다: 단방향, 양방향

---

1. 다대일

다대일 단방향 [N:1]

Member

@Entity
public class Member {

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

• 회원은 Member.team으로 팀 엔티티를 참조할 수 있지만 반대로 팀에서는 회원을 참조하는 필드가 없다.
  • 따라서 팀에서는 회원을 참조, 조회할 수 없다.
    • 따라서 회원과 팀은 다대일 단방향 연관관계이다.

다대일 양방향 [N:1, 1:N]

• 실선(Member.team)이 연관관계의 주인이고 점선(Team.member)은 연관관계의 주인이 아니다.
• 양방향은 외래키가 있는 쪽이 연관관계의 주인이다.
  • 일대다와 다대일 연관관계는 항상 다(N)에 외래키가 있다. 여기서는 다쪽인 MEMBER 테이블이 외래키를 가지고 있으므로 MEMBER.team이 연관관계의 주인이다.
  • JPA는 외래키를 관리할 때 연관관계의 주인만 사용한다.
  • 주인이 아닌 Team.members는 조회를 위한 JPQL이나 객체 그래프를 탐색하는데 사용된다.
• 양방향 연관관계는 항상 서로를 참조해야 한다.
  • 어느 한쪽만 참조하면 양방향 연관관계가 아니다.
  • 항상 서로를 참조하는 것은 번거롭고 잊기 쉬운 일이기에, 연관관계 편의 메소드를 작성하는 것이 좋다.
    • 편의 메서드는 한 곳에만 작성하거나, 양쪽 다 작성할 수 있는데, 양쪽 다 작성하는 경우 무한루프에 빠지므로 주의해야 한다.
    • 예제 코드에서는 무한 루프에 빠지지 않도록 검사하는 로직을 갖고 있다.

Member

@Entity
public class Member {

	// ...

	@ManyToOne // 연관관계의 주인
    @JoinColumn(name = "TEAM_ID")
    private Team team;
    
    public void setTeam(Team team) {
    	this.team = team;
        
        // 무한 루프에 빠지지 않도록 체크
        if (!team.getMembers().contains(this)) {
        	team.getMembers().add(this);
        }
}

Team

@Entity
public class Team {

	@OneToMany(mappedBy = team)
    private List<Member> members;
    
    public void addMember(Member member) {
    	this.members.add(member);
        if (member.getTeam() != this) { // 무한 루프에 빠지지 않도록 체크
        	member.setTeam(this); 
		}
}        

---

2. 일대다

일대다 관계는 다대일의 반대 방향이다. 일대다 관계는 엔티티를 하나 이상 참조할 수 있으므로 자바 컬렉션인 Collection, List, Set, Map 중 하나를 사용할 수 있다. 실무에서는 거의 사용되지 않는 모델이다.

일대다 단방향 [1:N]

관계도를 보면, Team은 Member를 알고있지만 Member는 Team을 알고있지 않다. 객체를 설계하다 보면 일(1)쪽에서 다(N)를 알고 싶지만, 다(N)쪽에서는 일(1)을 알고 싶지 않은 경우가 있을 수 있다. 이런 경우 일대다 단방향을 사용할 수 있다.(후에 언급되지만 그냥 양방향 매핑을 사용하는 편이 좋다.) 그림에서 Team에는 연관관계인 List members를 가지고 있지만 Member측에서는 Team과 관련된 정보가 없음을 확인할 수 있다.

(그림에서 보듯이) DB상에서는 무조건 외래키는 Member(다, N)쪽에 들어가게 된다. Team에 들어간다는 사실 자체가 말이 안된다. (Member가 추가될때마다 Team 추가 되면서 1이 아니라 다(N)가 되어버린다.)

결과적으로, 테이블에서 Member에 있는 외래키를, 객체의 Team의 변수를 통해 통제해야 한다. 일대다 관계에서 외래키는 항상 다쪽 테이블에 있는데, 다쪽인 Member 엔티티에 외래키를 매핑할 참조 필드가 없어 이런 문제가 발생하게 된다.

Member

@Entity
public class Member {

	@Id @GeneratedValue
    @Column(name = "MEMBER_ID")
    private Long id;
    
    @Column(name = "USERNAME")
    private String username;
    
    ...
}

• Member에는 연관관계 매핑과 관련된 코드를 작성하지 않았다.

Team

@Entity
public class Team {
	
    @Id @GeneratedValue
    @Column(name = "TEAM_ID")
    private Long id;
    private String name;
    
    @OneToMany
    @joinColumn(name = "TEAM_ID")
    private List<Member> members = new ArrayList<>();
}

• Team쪽에만 매핑관련 애노테이션을 추가했다.

주의

일대다 단방향 관계를 매핑할 때는 @JoinColumn을 명시해야 한다. 그렇지 않으면 JPA는 연결 테이블을 중간에 두고 연관관계를 관리하는 조인 테이블 전략을 기본으로 사용해서 매핑한다.

일대다 단방향 매핑의 단점

• 매핑한 객체가 관리하는 외래 키가 다른 테이블에 있다.
  • 본인 테이블에 있는 경우 INSERT SQL 한 번으로 끝낼 수 있지만, 다른 테이블에 외래키가 있으면 연관관계 처리를 위한 UPDATE SQL을 추가로 실행해야 한다.

public void testSave() {

	Member member1 = new Member("member1");
    Member member2 = new Member("member2");
    
    Team team1 = new Team("team1");
    team1.getMembers().add(member1);
    team1.getMembers().add(member2);
    
    em.persist(member1); // INSERT-member1
    em.persist(member2); // INSERT-member2
    em.persist(team1); // INSERT-team1, UPDATE-member1.fk,
    					// UPDATE-member2.fk
	transaction.commit();                        
}

최종적으로 실행되는 SQL문은 다음과 같다.

INSERT INTO MEMBER (MEMBER_ID, username) values (null, ?)
INSERT INTO MEMBER (MEMBER_ID, username) values (null, ?)
INSERT INTO TEAM (TEAM_ID, name) values (null, ?)
UPDATE MEMBER SET TEAM_ID=? WHERE MEMBER_ID=?
UPDATE MEMBER SET TEAM_ID=? WHERE MEMBER_ID=?

• Member 엔티티는 Team 엔티티를 모른다. 연관관계 정보는 Team만 가지고 있다.
  • 따라서 Member 엔티티를 저장할 때는 Member 테이블의 TEAM_ID에 아무값도 저장되지 않는다.
  • 대신 Team 엔티티를 저장할 때 Team.members의 참조값을 확인해 회원 테이블의 외래키를 업데이트 해야한다.

🔨 일대다 단방향 매핑보다는 다대일 양방향 매핑을 사용하자

• 일대다 단방향 매핑: 엔티티를 매핑한 테이블이 아닌 다른 테이블의 외래키를 관리해야 한다.
  • 성능 문제 + 관리의 부담이 발생한다.
• 대신, 다대일 양방향 매핑을 사용하는 편이 좋다.
  • 다대일에서는 관리해야하는 외래키가 본인 테이블에 있다. 따라서, 일대다 단방향 매핑 같은 문제가 발생하지 않는다.
  • 두 매핑의 테이블 모양은 완전히 동일하므로 엔티티만 약간 수정하면 된다.

일대다 양방향 [1:N, N:1]

억지스럽게 설정을 해야 하긴 하지만, 일대다 양방향 매핑도 가능하다. 연관관계의 주인은 Team의 members(List<Member>)로 설정하고, Member에서 Team team으로 조회하는 것도 가능하게 설정할 수 있다. (스펙상 되는게 아니고 야매로 된다.)

양방향 매핑에서 @OneToMany는 연관관계의 주인이 될 수 없다. 관계형 데이터베이스의 특성상 일대다, 다대일 관계는 항상 다쪽에 외래키가 았다. 따라서 @OneToMany, @ManyToOne 둘중에 연관관계의 주인은 항상 다 쪽인 @ManyToOne을 사용한 곳이다. 이런 이유로 @ManyToOne에는 mappedBy 속성이 없다.(즉 주인이 아닐 수 없다.)

(일쪽이 연관관계의 주인이면서) 일대다 양방향을 설정한다는 것은, 굳이 외래키를 갖고 있지 않은 테이블(Team)을 데이터 저장의 주체로 설정하고, 굳이 외래키를 가지고 있는 테이블(Member)쪽을 데이터를 저장할 수 없도록 제한하는 것을 의미한다. 데이터베이스 관점으로 생각했을 때, 직관적이지 않고 이해하기도 힘들다.

그러나 데이터베이스와 개발코드를 연결하는 과정 중 발생하는, RDBMS 패러다임과 객체지향적 개발의 패러다임 사이 간극 조절에 조금 더 객체 중심적으로 생각하는 것이라 보면 편할 것 같다. (근데 너무 복잡해서 실무에서는 그냥 사용 안하는듯)

• 디비와의 연관관계 매핑은 Team.members이다.
• Member.team은 일기전용 필드로 조회만 가능하다.

Member

public class Member {
    @ManyToOne
    @JoinColumn(name ="TEAM_ID", insertable = false, updatable = false)
    private Team team;
}

• @JoinColumn(name ="TEAM_ID", insertable = false, updatable = false)
  • 읽기 전용 필드를 사용해 양방향처럼 사용하고 있다.
  • insertable, updatable 설정을 꺼 조회만 가능하게 변경했다.
    • 만약 이 설정을 넣어주지 않으면 Member.team과 Team.member라는 두개의 연관관계 관리 포인트가 모두 디비와 연결되어 어떤 데이터가 저장될지 예측할 수 없는 곤란한 상황이 될 수 있다.

Team

public class Team {

    @OneToMany
    @JoinColumn(name = "TEAM_ID")
    private List<Member> members = new ArrayList<>();

}

• Team쪽이 연관관계의 주인이 된다.

📌 결론

쓰지마라. 그냥 다대일 양방향 써라.

---

3. 일대일 [1:1]

• 일대일 관계는 양쪽이 서로 하나의 관계만 가진다. 일대일 관계는 다음과 같은 특정이 있다.
  • 외래 키에 데이터베이스 유니크(UNI) 제약조건이 추가된 것을 일대일 관계라 한다.
  • 일대일 관계는 그 반대도 일대일 관계이다.
  • 테이블 관계에서 일대다, 다대일은 항상 다(N)쪽이 외래키를 가진다. 반면에 일대일 관계는 주 테이블이나 대상 테이블 둘 중 어느 곳이나 외래키를 가질 수 있다.
    • 따라서 어느 테이블이 외래키를 가져야 할 지 선택해야 한다.
• 주 테이블에 외래 키
  • 주 객체가 대상 객체를 참조하는 것처럼 주 테이블에 외래키를 두고 대상 테이블을 참조한다.
  • 외래 키를 객체 참조와 비슷하게 사용할 수 있어 객체지향 개발자들이 선호한다.
  • 장점) 주 테이블이 외래키를 가지고 있어 주 테이블만 확인해도 대상 테이블과의 연관관계를 확인할 수 있다.
  • 단점) 값이 없으면 외래 키에 null 허용
• 대상 테이블에 외래 키
  • 전통적인 디비 개발자들을 보통 대상 테이블에 외래키를 두는 것을 선호한다.
  • 장점) 테이블 관계를 일대일에서 일대다로 변경할때 테이블 구조를 그대로 유지할 수 있다.
  • 단점) 프록시 기능의 한계로 지연 로딩으로 설정해도 항상 즉시 로딩됨(프록시는 뒤에서 설명)

주 테이블의 외래 키

단방향

@Entity
public class Member {

	@Id @GeneratedValue
    privae Long id;
    
    private String userame;
    
    @OneToOne
    @JoinColumn(name = "LOCK_ID")
    private Locker locker;
   
}

@Entity
public class Locker {

	@Id @GeneratedValue
    private Long id;
    
    private String name;
}    

• 다대일(@ManyToOne) 단방향 매핑과 유사하다.
• 영한님이 실무에서 가장 선호하시는 사용 방향

양방향

     @OneToOne(mappedBy = "locker")
    private Member member;

• Locker에 연관관계 매핑 코드를 추가한다.
  • 다대일 양방향 매핑 처럼 외래키가 있는 곳이 연관관계의 주인이된다.
  • 반대쪽(주인이 아닌 쪽)은 mappedBy를 적용시켜 준다.

대상 테이블에 외래키

단방향

• JPA에서는 일대일 관계 중 대상 테이블에 외래키가 있는 단방향 관계를 지원하지 않는다.
  • 즉, Member 테이블에서 Locker 테이블에 있는 외래키를 관리하지 못하도록 막아뒀다.
  • 대신 단방향 관계를 Locker에서 Member 방향으로 수정하거나, 양방향 관계로 만들고 Locker를 연관관계의 주인으로 설정해야 한다.

양방향

• Locker 테이블에 외래키를 두고, Locker의 멤버가 외래키를 직접 관리한다.(Member에서는 조회만 가능하다.)
  • 사실상 주 테이블에서 외래키를 가진 양방향을 딱 반대로 뒤집은 형태다.
  • 일대일 관계에서는 엔티티가 가진 외래키를 해당 엔티티가 직접 관리해야 한다.

---

4. 다대다 [N:M]

결론부터 얘기하자면 실무에서는 @ManyToMany를 이용한 다대다 관계를 거의 사용하지 않는다. 대신 연결 테이블을 추가해 일대다, 다대일 관걔로 풀어내는 것이 권장된다.

• 데이터베이스
  • 관계형 데이터베이스는 정규화된 테이블 2개로 다대다 관계를 표현할 수 없다.
  • 대신 다대다 관계를 일대다, 다대일 관계로 풀어내는 연결 테이블을 사용한다.

• 객체의 다대다
  • 객체는 테이블과 다르게 객체 2개로 다대다 관계를 만들 수 있다.
  • 회원 객체는 컬렉션을 사용해 상품들을 참조하면 되고, 반대로 상품들도 컬렉션을 사용해 회원들을 참조하면 된다.
• @ManyToMany를 통한 다대다 관계 설정 시, JPA는 객체와 데이터베이스 사이의 간격을 해결하기 위해 (객체 입장에서는 보이지 않는) 연결테이블을 생성해 제공한다.

단방향

엔티티

Member

@Entity
public class Member {

	@Id @GeneratedValue
    private String id;
    
    private String username;
    
    @ManyToMany
    @JoinTable(name = "MEMBER_PRODUCT",
            joinColumns = @JoinColumn(name = "MEMBER_ID"),
            inverseJoinColumns = @JoinColumn(name = "PRODUCT_ID"))
    private List<Product> products = new ArrayList<>();
	...
    
}	    

• @JoinTable.name: 연결 테이블을 지정한다. 여기서는 MEMBER_PRODUCT 테이블을 선택했다.
• @JoinTable.joinColumns: 현재 방향인 회원과 매핑할 조인 컬럼 정보를 지정한다. MEMBER_ID로 지정했다.
• @JoinTable.inverseJoinColumns: 반대 방향인 상품과 매핑할 조인 컬럼 정보를 지정한다. PRODUCT_ID로 지정했다.

Product

@Entity
public class Product {
	
    @Id @Column(name = "PRODUCT_ID")
    private String id;
    
    private String name;
    ...

}    

• @MantyToMany와 @JoinTable을 사용해 연결 테이블을 바로 매핑했다.
  • 따라서 회원과 상품을 연결하는 회원_상품(MEMBER_PRODUCT) 엔티티 없이 매핑을 완료할 수 있다.

저장

public void save() {
	
    Product productA = new Product();
    productA.setId("productA");
    productB.setName("상품A");
    em.persist(productA);
    
    Member member1 = new Member();
    member1.setId("member1");
    member1.setUsername("회원1");
    member1.getProducts().add(productA) // 연관관계 설정
    em.persist(member1);
   
}

• 회원1과 상품A의 연관관계를 설정했으므로 회원1을 저장할 때 연결테이블에도 값이 저장된다.

INSERT INTO PRODUCT...
INSERT INTO MEMBER...
INSERT INTO MEMBER_PRODUCT...

탐색

public void find() {
	
    Member member = em.find(Member.class, "member1");
    List<Product> products = member.getProducts(); // 객체 그래프 탐색
    for (Product product : products) {
    	System.out.println("product.name = " + product.getName());
	}
}

• member.getProducts()를 통해 상품 이름을 출력하면 아래와 같은 SQL이 실행된다.
  • 연결 테이블인 MEMBER_PRODUCT와 상품 테이블을 조인해 연관된 상품을 조회한다.
  • 복잡한 다대다 관계를 애플리케이션에서는 단순하게 사용할 수 있다.

SELECT * FROM MEMBER_PODUCT MP
INNER JOIN  PRODUCT P ON MP.PRODUCT_ID = P.PRODUCT_ID
WHERE MP.MEMBER_ID = ?

양방향

Product

@Entity
public class Product {

	@Id
    private String id;
    
    @ManyToMany(mappedBy = "products")
    private List<Member> members; // 역방향 추가

}

• 다대다 관계이므로 역방향에서도 @ManyToMany를 사용한다.
• 원하는 곳에 mappedBy를 설정해 연관관계의 주인을 지정한다.

Member: 연관관계 편의 메소드 추가

public void addProduct(Product product) {

	...
    products.add(product);
    product.getMembers().add(this);
}

다대다의 한계: 추가 정보 설정

개발자가 연결 테이블을 따로 설정하지 않아도 JPA에서 직접 설정해주니, 다대다 설정을 통해 개발자는 객체에서 편하게 양쪽을 참조할 수 있다. 그러나 이처럼 편리해보이는 다대다 매핑은 실무에서는 거의 사용하지 않는다. 보통 연결 테이블이 단순히 연결만 하고 끝나지 않기 때문이다.

당장 회원과 상품을 연결하는 이 테이블에서 상품 수량, 상품 날짜등의 데이터가 추가될 수 있다. 그러나 JPA에서 관리해주는 이 중간 테이블은 매핑정보만 삽입 가능하고 그 외 추가 데이터를 삽입할 수 없다.

또 쿼리 측면으로도 어려움이 있다. 멤버와 프로덕트를 조회할 때마다 쿼리가 중간 테이블을 통해 조인이 되어 이루어져야 하는데, 개발자가 생각하지 못한 쿼리가 사용될 수 있다. 중간 테이블이 숨겨져 있어 이러한 어려움이 생긴다.

극복: 연결 엔티티 사용

이처럼 다대다 매핑에는 실무에서 사용하기 어려운 부분이 있어 대신 연결 테이블용 엔티티를 추가하는 것을 권장한다. 즉, 연결 테이블을 엔티티로 승격시키는 것이다.
대신 기존에 @ManyToMany였던 관계가 @OneToMany와 @ManyToOne이 된다.

지금까지는 기본키가 단순해서 기본키를 위한 객체를 사용하는 일이 없었지만 복합 키가 되면 이야기가 달라진다. 복합 키를 사용하는 방법은 복잡하다. 단순히 컬럼 하나만 기본 키로 사용하는 것과 기뵤해서 식별자 클래스도 만드러야 하고 @IdClass 또는 @EmbeddedId도 사용해야 한다. 그리고 식별자 클래스에 equals, hashCode도 구현해야 한다. 대신, 복합키를 사용하지 않고 새로운 기본키를 통해 편하게 구현할 수 있다.

새로운 기본 키 사용

• 추천하는 기본 키 생성 전략은 데이터베이스에서 자동으로 생성해주는 대리 키를 Long 값으로 사용하는 것이다.
  • 간편하고 거의 영구히 쓸 수 있으며 비즈니스에 의존하지 않는다.
  • ORM 매핑 시 복합키를 만들지 않아도 되므로 간단히 매핑을 완성할 수 있다.

Ordrers

package com.study.jpashop.domain;

import jakarta.persistence.*;

import java.time.LocalDateTime;

@Entity
public class Orders {

    @Id @GeneratedValue
    private Long id;

    @ManyToOne
    @JoinColumn(name = "MEMBER_ID")
    private Member member;

    @ManyToOne
    @JoinColumn(name = "PRODUCT_ID")
    private Product product;

    private int count;
    private int price;

    private LocalDateTime orderDateTime;

}

Member

@Entity
public class Member {

	@Id @Column(name = "MEMBER_ID")
    private String id;
    private String username;
    
    @OneToMany(mappedBy = "member")
    private List<Order> orders = new ArrayList<Order>();
	...
}

Product

@Entity
public class Product {

	@Id @Column(name = "PRODUCT_ID")
   	private String id;
    private String name;
    ...
}

저장 코드

public void save() {

	// 회원 저장
    Member member = new Member();
    member1.setId("member1");
    member1.setUsername("회원1");
    em.persist(member1);
    
    // 상품 저장
    Product product = new Product();
    productA.setId("productA");
    productA.setName("상품1");
    em.persist(productA);
    
    // 주문 저장
    Order order = new Order();
    order.setMember(member1);	// 주문 회원 - 연관관계 설정
    order.setProduct(productA); // 주문 상품 - 연관관계 설정
    order.setOrderAmount(2);	// 주문 수량
    em.persist(order);
    
}   

---

5. 실전예제3: 다양한 연관관계 매핑

• 일대일 관게는 외래 키를 양쪽 어디나 둘 수 있음
  • ORDERS에 두면: 성능(바로 확인 가능, 나중에 프록시 등등) + 객체 입장에서 편리함
  • DELIVERY에 두면: 1 -> N으로 확장이 편리함 (DB 컬럼 변경 없이 N으로 변경 가능)
• 다대다 관계 -> 테이블은 중간테이블을 만들고 일대다 다대일 관계로 풀어아 햔다.

배송, 카테고리 추가: 엔티티

• 주문과 배송은 1:1 @OneToOne
• 상품과 카테고리는 N:m @ManyToMany

배송, 카테고리 추가: ERD

배송, 카테고리 추가: 엔티티 상세

N:M 관계는 1:N, N:1로

• 테이블의 N:M 관걔는 중간 테이블을 이용해서 1:N, N:1
• 실전에서는 중간 테이블이 단순하지 않다.
• @ManyToMany는 제약: 필드 추가X, 엔티티 테이블 불일치
• 실전에서는 @ManyToMany 사용 X.

@JoinColumn

• 외래 키를 매핑할 때 사용
  

@ManyToOne

• 다대일 관계 매핑
  

@OneToMany

• 일대다 관계 매핑
  

---

Reference

• [인프런]자바 ORM 표준 JPA 프로그래밍 - 기본편