일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
- Java
- 이펙티브자바
- Spring Batch
- Database
- 네트워크
- 자바
- 프로그래머스
- 자율주행
- DeepLearning
- 운영체제
- JPA
- 딥러닝
- 아두이노
- 포인트클라우드
- 논문리뷰
- 자바ORM표준JPA프로그래밍
- 배달로봇
- 장애물인식
- cartograhper
- 파이썬
- 논문
- Hibernate
- MySQL
- 알고리즘
- 자료구조
- Jetson
- 영속성컨텍스트
- Python
- persistance context
- 디자인패턴
- Today
- Total
제리 devlog
[JPA] 일대일, 다다다 매핑 본문
일대일 매핑(1:1)
일대일 관계는 양쪽이 서로 하나의 관계만 가진다. 예를 들어 회원은 하나의 사물함만 사용하고 사물함도 하나의 회원에 의해서만 사용된다. 일대일 관계는 그 반대도 일대일 관계이다. 테이블 관계에서 일대다, 다대일은 항상 다(N)쪽이 외래 키를 가졌다. 반면에 일대일 관계는 주 테이블이나 대상 테이블 둘 중 어느 곳이나 외래 키를 가질 수 있다.
주 테이블에 외래키
주 객체가 대상 객체를 참조하는 것처럼 주 테이블에 외래 키를 설정한다. 외래 키를 객체 참조와 비슷하게 할 수 있어 객체지향 개발자들이 선호한다. 주 테이블이 외래 키를 가지고 있으므로 주 테이블만 확인해도 대상 테이블과 연관 관계를 알 수 있다.
대상 테이블에 외래 키
전통적인 데이터베이스 개발자들은 보통 대상 테이블에 외래 키를 두는 것을 선호한다. 이 방법의 장점은 테이블 관계를 일대일에서 일대다로 변경할 때 테이블 구조를 그대로 유지할 수 있다.
주 테이블에 외래키
@Entity
public class Member {
@Id
@GeneratedValue
@Column(name = "MEMBER_ID")
private Long id;
private String username;
@OneToOne
@JoinColumn(name = "LOCKER_ID")
private Locker locker;
..
}
@Entity
public class Locker {
@Id
@GeneratedValue
@Column(name = "LOCKER_ID")
private Long id;
/*
* 양방향인 경우
*/
@OneToOne(mappedBy = "locker")
private Member member;
private String name;
...
}
주 테이블의 매핑관계는 다대일과 유사하다.
일대일 관계 중 대상 테이블에 외래 키가 있는 단방향 관계는 JPA에서 지원하지 않는다. 그리고 이런 모양으로 매핑할 수 있는 방법도 없다. 이때는 단방향 관계를 LOCKER에서 MEMBER로 수정하거나 양방향 관계로 만들고 LOCKER를 연관관계 주인으로 설정해야한다.
@Entity
public class Member {
@Id
@GeneratedValue
@Column(name = "MEMBER_ID")
private Long id;
private String username;
@OneToOne(mappedBy = "member")
@JoinColumn(name = "LOCKER_ID")
private Locker locker;
..
}
@Entity
public class Locker {
@Id
@GeneratedValue
@Column(name = "LOCKER_ID")
private Long id;
@OneToOne
private Member member;
private String name;
...
}
주 테이블과 대상 테이블에서 코드가 달라진 부분은 mappedby이다. 여기서는 연관관계의 주인이 대상 테이블이 된다.
*프록시를 사용할 때 외래 키를 직접 관리하지 않는 일대일 관계는 지연 로딩으로 설정해도 즉시 로딩된다. Locker.member는 지연 로딩이 가능하지만 Member.locker는 지연 로딩이 불가능하다. 이것은 프록시의 한계때문에 발생하는 문제이고 프록시 대신 bytecode instrumentation을 사용하면 해결할 수 있다고 한다. 프록시에 관한 내용은 나중에 더 알아보겠다.
다대다 매핑(N:N)
관계형 데이터베이스는 정규화된 테이블 2개로 다대다 관계를 표현할 수 없다.
그런 이유로 중간에 연결 테이블을 추가해서 다대다 관계를 일대일, 다대일 관계로 풀어낸다.
그런데, 객체는 컬렉션을 사용하면 2개로 다대다 관계를 만들 수 있다.
다대다 단방향
@Entity
public class Member {
@Id
@Column(name = "MEMBER_ID")
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<Product>();
...
}
@Entity
public class Product {
@Id
@Column(name = "PRODUCT_ID")
private String id;
private String name;
...
}
회원 엔티티와 상품 엔티티를 @ManyToMany로 매핑한다. @ManyToMany와 @JoinTable을 사용해서 연결 테이블을 바로 매핑했다. 따라서 회원과 상품을 연결하는 엔티티 없이 매핑을 완료할 수 있다(연결 테이블 생성)
@JoinTable의 속성
name : 연결 테이블을 지정한다. 여기서는 MEMBER_PRODUCT이다.
joinColumns : 현재 방향인 회원과 매핑할 조인 컬럼 정보를 지정한다. 여기서는 MEMBER_ID이다.
inverseJoinColumns : 반대 방향인 상품과 매핑할 조인 컬럼 정보를 지정한다. PRODUCT_ID로 지정했다.
MEMBER_PRODUCT 테이블은 다대다 관계를 일대다, 다대일 관계로 풀어내기 위해 필요한 연결 테이블이다.
다대다 양방향
다대다 매핑이므로 역방향도 @ManyToMany를 사용한다. 그리고 연관 관계의 주인을 mappedBy 속성을 사용해 정해준다.
@Entity
public class Member {
@Id
@Column(name = "MEMBER_ID")
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<Product>();
...
}
@Entity
public class Product {
@Id
@Column(name = "PRODUCT_ID")
private String id;
private String name;
@ManyToMany(mappedBy = "products")
private List<Member> members;
...
}
다대다 매핑의 한계와 극복, 연결 엔티티 사용
@ManyToMany는 연결 테이블을 자동으로 처리해주기 때문에 편리하지만 실무에서 사용하기는 무리가 있다고 한다.
위와 같은 상황을 보자. 회원이 상품을 주문하면 연결 테이블에 단순히 주문한 회원 아이디와 상품명 뿐만 아니라 주문 수량, 주문 날짜등 추가적인 컬럼이 필요하다. 이렇게되면 @ManyToMany를 사용하여 만든 연결 테이블을 활용할 수 없다. 결국, 연결 테이블을 위한 엔티티를 만들고 추가적인 컬럼을 매핑해야한다.
결국 위와 같은 그림처럼 매핑해야한다.
@Entity
public class Member {
@Id
@Column(name = "MEMBER_ID")
private String id;
@OneToMany(mappedBy = "memeber")
private List<MemberProduct> memberProducts;
...
}
@Entity
public class Product {
@Id
@Column(name = "PRODUCT_ID")
private String id;
private String name;
...
}
@Entity
@IdClass(MemberProductId.class)
public class MemberProduct {
@Id
@ManyToOne
@Column(name = "MEMBER_ID")
private Member member; //MemberProduuctId.member와 연결
@Id
@ManyToOne
@JoinColumn(name = "PRODUCT_ID")
private Product product; //MemberProductId.product와 연결
private int orderAmount;
...
}
public class MemberProductId implements Serializable {
private String member; //MemberProduct.member와 연결
private String product; //MemberProduct.product와 연결
private int orderAmount;
//equals, hashCode메서드 구현
...
}
MemberProduct엔티티는 @Id와 외래 키를 매핑하는 JoinColumn을 사용하여 기본 키 + 외래 키를 한번에 매핑했다. 그리고 @IdClass를 사용해서 복합 기본 키를 매핑했다.
복합 기본 키
회원상품 엔티티는 기본 키가 MEMBER_ID와 PRODUCT_ID로 이루어진 복합 기본키다. JPA에서 복합 키를 사용하려면 별도의 식별자 클래스를 만들어야한다. 그리고 엔티티에 @IdClass를 사용해서 식별자 클래스를 지정하면 된다. 복합 키를 위한 식별자 클래스는 다음과 같은 특징이 있다.
- 복합 키는 별도의 식별자 클래스로 만들어야 한다.
- Serializable을 구현해야 한다.
- equals와 hashCode 메소드를 구현해야 한다.
- 기본 생성자가 있어야 한다.
- 식별자 클래스는 public이어야 한다.
- @IdClass를 사용하는 방법 이외에 @EmbeddedId를 사용하는 방법도 있다.
식별 관계
회원상품은 회원과 상품의 기본 키를 받아서 자신의 기본 키로 사용한다. 이렇게 부모 테이블의 기본 키를 받아 자신의 기본 키 + 외래 키로 사용하는 것을 데이터베이스 용어로 식별 관계라고 한다.
MemberProduct는 회원의 기본 키와 상품의 기본키를 받아서 자신의 기본 키 + 외래 키로 사용한다. 또한, MemberProductId 식별자 클래스로 두 기본 키를 묶어서 복합 기본 키로 사용한다.
저장
public void save() {
//회원 저장
Member member1 = new Member();
member1.setId("member1");
member1.setUsername("회원1");
em.persist(member1);
//상품 저장
Product productA = new Product();
productA.setId("productA");
productA.setName("상품1");
em.persist(productA);
//회원 상품 저장
MemberProduct memberProduct = new MemberProduct();
memberProduct.setMember(member1); //주문 회원 - 연관관계 설정
memberProduct.setProduct(productA); // 주문 상품 - 연관 관계 설정
memberProduct.setOrderAmount(2); // 주문 수량
em.persist(memberProduct);
}
저장의 경우 특별한 부분은 없다.
조회
public void find() {
//기본 키 값 생성
MemberProductId memberProductId = new MemeberProductId();
memberProductId.setMemeber("member1");
memberProductId.setProduct("productA");
MemberProduct memberProduct = em.find(MemberProduct.class, memberProductId);
Member member = memberProduct.getMember();
Product product = memberProduct.getProduct();
}
복합 키의 경우 항상 식별자 클래스를 만들어야한다. em.find를 보면 식별자 클래스로 엔티티를 조회한다. 복합 키를 사용하는 방법은 복잡하고 하나의 기본 키를 사용하는 것과 비교해보면 ORM매핑에서 처리할 일이 많아진다. 복합 키를 사용하기 위한 식별자 클래스도 만들어야 하고 @IdClass 또는 @EmbeddedId도 사용해야한다. 또, 식별자 클래스에 equals, hashCode도 구현해야 한다.
다대다 : 새로운 기본 키 사용
복합 키 대신 데이터베이스에서 자동으로 생성해주는 대리 키를 Long값으로 사용하는 것이다. 이 방법은 간편하고 거의 영구히 쓸 수 있으며 비즈니스에 의존하지 않는다. 그리고 ORM매핑 시 복합 키를 만들지 않아도 되므로 간단히 매핑을 완성할 수 있다.
MemberProduct의 이름은 좀 더 도메인의 맞는 ORDER로 변경했다. 위를 보면 ORDER_ID라는 새로운 기본 키를 하나 만들고 MEMBER_ID와 PRODUCT_ID는 외래 키로 사용한다.
@Entity
public class Order {
@Id
@GenerateValue
@Column(name = "ORDER_ID")
private Long id;
@ManyToOne
@JoinColumn(name = "MEMBER_ID")
private Member member;
@ManyToOne
@JoinColumn(name = "PRODUCT_ID")
private Product product;
private int orderAmount;
...
}
대리 키를 사용하므로써 복합 키보다는 훨씬 매핑이 간단해졌고 이해하기도 쉬워졌다.
@Entity
public class Member {
@Id
@Column(name = "MEMBER_ID")
private String id;
@OneToMany(mappedBy = "memeber")
private List<MemberProduct> memberProducts;
...
}
@Entity
public class Product {
@Id
@Column(name = "PRODUCT_ID")
private String id;
private String name;
...
}
저장
public void save() {
//회원 저장
Member member1 = new Member();
member1.setId("member1");
member1.setUsername("회원1");
em.persist(member1);
//상품 저장
Product productA = 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);
}
조회
public void find() {
Long OrderId = 1L;
Order order = em.find(Order.class, orderId);
Member member = order.getMember();
Product product = order.getProduct();
}
식별자 클래스를 사용하지 않으니 코디가 훨씬 간결해졌다.
데이터베이스 설계에서 부모 테이블의 기본 키를 받아 자식 테이블의 기본 키 + 외래 키로 사용하는 것을 식별 관계라하고, 단순히 외래키로만 사용하는 것을 비식별 관계라고한다. 객체 입장에서는 비식별 관계를 사용하는 것이 복합 키를 위한 식별자 클래스를 만들지 않아도 되므로 단순하고 편리하게 ORM매핑을 할 수 있다.
'JPA' 카테고리의 다른 글
kotlin by 키워드를 사용한 JPA + QueryDsl 통합 Repository 구현 (1) | 2022.03.04 |
---|---|
[JPA] 연관 관계를 가진 엔티티 저장 방식 개선 (불필요한 select문 제거) (7) | 2021.05.30 |
[JPA] 다양한 연관관계 매핑 (1) 다대일, 일대다 (1) | 2020.11.27 |
[JPA] 양방향 연관관계 (0) | 2020.11.21 |
[JPA] 단방향 연관관계 (0) | 2020.11.20 |