본문 바로가기

JPA

(43)
N:M(다 대 다) 매핑 3: 매핑테이블을 엔티티로 만들기 N:M 관계를 풀어낼 때 두 테이블을 엮기 위해 중간에 매핑테이블을 만들어야 한다. 그런데 이 때 매핑테이블을 @JoinTable과 @ManyToMany 어노테이션을 사용하여 만들면, 개발 도중에 발생하는 상황들에 대해 유연하게 대처하기 힘들어진다. 따라서 돌발상황이 많은 실무에서는 매핑테이블을 엔티티로 승격시키는 것이 좋다. 테이블 구조 Student:Subject는 N:M의 관계를 가지고 있고, 이를 매핑하기 위한 테이블로 StudentSubject를 사용하고 있다. 매핑테이블을 Entity로 사용했을 때의 장점을 살펴보기 위해 StudentSubject에 registrationDate 컬럼을 추가했다. 이번 시간에는 매핑테이블인 StudentSubject를 Entity로 만들어서 사용해볼 것이다! ..
N:M(다 대 다) 매핑 2: @ManyToMany와 @JoinTable 2021.05.20 - [JPA/양방향연관관계] - N:M(다 대 다) 매핑 1: 매핑테이블 N:M(다 대 다) 매핑 1: 매핑테이블 RDB에서는 정규화된 테이블 2개로 N:M 관계를 매핑하는 것이 불가능하다. (정규화란 Table을 아름답게 만드는 과정(?)이다. 정규화에 대해 더 궁금하다면 검색을!!!) 따라서 매핑테이블을 따로 추가 code-mania.tistory.com Entity 설계를 보기 전에 테이블이 어떻게 설계됐는지 여기서 먼저 확인해보자~~~ @ManyToMany와 @JoinTable 이번 글에서는 'N:M(다 대 다) 매핑 1: 매핑테이블'에서 설계했던 테이블을 Entity로 만들어볼 것이다. @ManyToMany와 @JoinTable 어노테이션을 사용해서 N:M 양방향 연관관계를 ..
N:M(다 대 다) 매핑 1: 매핑테이블 RDB에서는 정규화된 테이블 2개로 N:M 관계를 매핑하는 것이 불가능하다. (정규화란 Table을 아름답게 만드는 과정(?)이다. 정규화에 대해 더 궁금하다면 검색을!!!) 따라서 매핑테이블을 따로 추가해서 N:M 관계를 풀어내야 한다. 매핑 테이블 만들어보기 학생이 수강신청을 한다고 해보자. 학생은 여러 과목을 수강신청할 수 있고, 한 과목은 여러 학생에 의해 수강신청될 수도 있다. 여기서 학생은 Student이고 과목은 Subject라고 한다면, Student:Subject = N:M(다 대 다)관계가 성립한다. 하지만 DB에서 테이블 2개로 N:M 관계를 매핑할 수 없다. 그래서 Student, Subject와 더불어 매핑테이블이 추가로 설계된다. 매핑테이블로 StudentSubject이라는 테이..
N:1 양방향 연관관계 매핑하기 길지 않으니 이 글을 먼저 읽어보길 권장한다!!! code-mania.tistory.com/35 DB와 객체의 양방향 연관관계 차이 알아보기 이번 시간에는 양방향 연관관계에 대해 알아보겠다!!!! (좀 빡센 거 같다...) 단방향 연관관계에 대해서 알아볼 때 이런 테이블과 Entity들을 만들었었다. (대충 재활용하겠다는 소리) 객체에서 말 code-mania.tistory.com 전 시간과 같은 테이블과 엔티티를 사용하도록 하겠다!!! 양방향 연관관계 매핑 양방향 연관관계 매핑을 할 때는 주인을 반드시 정해줘야 한다. 주인이란 무엇일까? Student ↔ Club의 양방향 관계 매핑 실습을 해보면서 알아보자!!! 현재 Student → Club은 성립되고 있으므로, Club → Student만 만족시키..
DB와 객체의 양방향 연관관계 차이 알아보기 이번 시간에는 양방향 연관관계에 대해 알아보겠다!!!! (좀 빡센 거 같다...) 단방향 연관관계에 대해서 알아볼 때 이런 테이블과 Entity들을 만들었었다. (대충 재활용하겠다는 소리) 객체에서 말하는 양방향 연관관계는 무엇일까? 먼저 지금 Entity를 살펴보자!!! Student객체에서 Club을 얻어오고 싶으면 'student.getClub();'으로 얻어올 수 있다. 하지만 Club에서 Student를 얻어오고 싶으면 가능할까???? (불가능하다) 즉, Student Entity에서 Club Entity를 참조할 수 있지만, 그 반대는 불가능하다. Student → Club으로 향하는 단방향 연관관계라고 할 수 있다. 그러면 현 상황에서 우리는 Student↔Club이 성립하게 되면 양방향이라..
단방향 연관관계 ORM을 이용하여 테이블을 객체에 매핑할 때 객체와 관계형 DB의 패러다임 차이로 굉장히 불편한 점이 생긴다. 객체는 .을 이용한 참조를 사용하고, DB는 FK를 이용한 참조를 사용한다. 이 차이로 인한 문제점은 무엇인지 알아보고 JPA로 해결해보자~~~~ 예제에 사용할 테이블이다. 이 두 테이블의 관계를 알아보자~~~ 클럽 하나는 여러 명의 학생을 가질 수 있습니까? Yes 학생 한 명은 여러 개의 클럽을 가질 수 있습니까? No 위 테이블의 관계는 Student:Club = N:1이다!!! (만약 둘 다 Yes라고 하면 N:M이 될 것이다) 그러면 이제 위와 같은 테이블을 객체로 바꿔보겠다.(엔티티는 다이어그램 보고 대충 만들어보자~~~) 다른 것보다 club의 Type이 Long이라는 것에 주의하자..
기본키 매핑 기본키를 객체에 매핑할 때는 필드에 @Id를 붙여서 매핑한다. 이 때 @GeneratedValue라는 Annotation이 있으면 insert 쿼리에서 Id 컬럼의 값을 자동할당해준다. 값을 자동할당할 때에 몇 가지 전략이 있는데, 이에 대해 알아보자~~~ IDENTITY package hellojpa; import lombok.Getter; import lombok.Setter; import javax.persistence.*; @Getter @Setter @Entity @Table(name = "MEMBER") public class Member { @Id //PK라는 것을 명시해주는 Annotation; 필수 @GeneratedValue(strategy = GenerationType.IDENTITY..
DB 스키마 자동 생성 JPA는 설정에 따라서 DDL을 애플리케이션 실행 시점에 자동으로 생성해준다. 먼저 Spring Boot의 경우 application.properties나 application.yml에서 적당히 설정해주면 된다. 나의 경우 Spring을 얹지 않은 순수 JPA 프로젝트로 연습해보고 있고, persistence.xml에 다음과 같이 설정해줬다. value 동작 create Entity에 해당하는 기존 table 삭제 후 Entity에 맞게 DDL문을 생성한다. create-drop create와 똑같이 동작하고, 애플리케이션 종료 시점에 Entity에 해당하는 테이블들을 삭제한다. update 변경된 부분만 DB에 반영한다.(drop은 실행하지 않는다.) validate 엔티티와 테이블이 정상 매핑되었는지..