자라선

JPA는 엔티티를 사용하여 데이터들을 관리한다. 하지만 필드값으로 조건을 부여하는 이러한 방법 이외에도 다양한 조건을 통해 데이터를 조회해야하는데 이러면 한계가 있기 때문에 JPA는 JPQL, Native 등 다양한 조회방법을 제공해준다. final Member member = em.find(Member.class, "ID"); 1. JPQL JPQL은 기존의 SQL를 작성하여 SELECT 하는 방식과 동일한데 다른점이라고 한다면 엔티티를 기준으로 SQL를 작성한다. 또한 데이터베이스마다 쿼리의 방언이 다 다르며 사용하는 함수가 다르기 때문에 이를 보완 해준다. @Data @Entity public class Member { @Id @GeneratedValue private long id; @Column..

지금까지는 JAVA에서 제공해주었던 원천 자료형들을 사용하여 엔티티를 구성하였는데 객체 지향 언어인 자바에서는 다양한 객체로 엔티티들을 제공되어야한다. JPA에서는 각 엔티티들을 정의해주는 데이터들의 타입을 크게 엔티티 타입과 값 타입으로 나눌 수 있다. 1. Entity Type 엔티티 타입은 @Entity 로 정의 했던 객체들을 말한다. 이는 embedded type (복합 값 타입) 이라고도 불리며 객체로 사용한다. JAVA에서 클래스를 작성하는 것과 동일하게 각종 원시자료원시나 클래스클을 조합하여 좀 더 객체지향스럽게 엔티티를 구성한다. @Data @Entity public class Member { @Id @GeneratedValue private long id; private String na..

JPA는 엔티티를 관리하기 위해 무조건 영속성 컨텍스트를 통해 관리가 이루어지는데 이는 테이블의 CASCADE와 같은 기능을 사용하여 엔티티도 똑같이 부모 엔티티를 통해 자식 엔티티를 관리할 수 있다. 1. CASCADE - INSERT 영속성 전이라고 부르며 부모 엔티티를 통해 자식 엔티티를 관리할 수 있도록 설정한다. @Data @Entity public class Member {// 자식 엔티티 @Id @GeneratedValue @Column(name = "MEMBER_ID") private long id; private String name; @ManyToOne @JoinColumn(name = "TEAM_ID") private Team team; @OneToMany(mappedBy = "mem..

예를 들어서 Member 엔티티만 사용하고자 한다면 연관되어있는 Team 엔티티까지 DB에서 조회할 필요 있을까? 또 Member 엔티티와 Team 엔티티를 동시에 쓰고자 할때 무조건 한번의 SELECT로 다 가져올 필요가 있을까? JPA는 이러한 이슈를 가지고 성능 향상을 위해 2가지의 엔티티 로딩 방식을 지원한다. 1. EAGER 로딩 (즉시 로딩) 이름 그대로 SELECT 하는 즉시 바로 연관된 모든 엔티티를 DB로부터 데이터를 영속성 컨텍스트에 가져오는 것을 말한다. @Data @Entity public class Member { @Id @GeneratedValue @Column(name = "MEMBER_ID") private long id; private String name; // 즉시 로딩..

DB에서 엔티티를 조회할때 항상 모든 데이터를 조회하는 것은 아니다. JPA는 성능 향상을 위해 필요한 데이터만 DB로 통해 SELECT 를 하게 된다. 하지만 성능 향상을 위하여 관계가 있는 모든 엔티티를 조회하지는 않는다. 이는 지연로딩인 LAZY 와 관련이 있다. 1. 프록시 TEAM 테이블의 데이터만 가져와 매핑된 엔티티로 조회하려고 한다. 하지만 우리는 Team 엔티티만 필요하지 Member 엔티티까지 불러올 필요는 없다. 더군다나 1:N 관계이다보니 Team에 관계돤 모든 Member를 가져올려면 성능이 좋지못할 것이다. 이럴때 JPA는 성능 향상을 위해 Team 엔티티만 조회하게 된다. final Team team = em.find(Team.class, 1l); // Team 엔티티만 조회함..

복합키란 PK가 2개 이상 있는 테이블의 키를 말한다. PARENT 테이블에는 PK가 2개가 있으며 이와 관계를 맺는 CHILD 에서는 2개의 PK를 참조하고 있다. 이럴 경우 JPA는 2가지의 방식으로 매핑 방식을 지원해주고 있다. 1. @IdClass 데이터베이스 관점으로 하여 복합키의 매핑을 사용할때 작성하는 어노테이션 @Data public class ParentId implements Serializable { // 식별클래스는 Serializable 을 필수로 상속해야한다. // 식별클래스의 필드와 복합키 엔티티의 PK 필드 명은 무조건 같아야한다. private long parentId1; private long parentId2; } @Data @IdClass(ParentId.class) ..

데이터베이스에서 PK를 2개 이상가진 테이블의 기본키를 보고는 복합키라고 부른다. 이를 JPA에서는 식별클래스를 사용하여 관리한다. 1. 식별클래스 PARENT 테이블 보면 PK를 2개 갖고있는데 이를 보고 복합키라고 부른다. JPA 는 hashCode와 equals 를 사용하여 영속성 컨텍스트에서 식별자를 구분하게 되는데 PK가 하나만 있다면 문제는 없지만 2개이상 있는 복합키를 가진 엔티티의 경우 별도의 식별 클래스로 구분하게된다. 2. @IdClass 데이터베이스 관점으로 식별자 클래스를 생성하기 위해서는 @IdClass 어노테이션을 사용한다. @Data // implements Serializable 가 필수이다. public class ParentId implements Serializable ..

객체는 extends 예약어를 사용하여 객체간 상속을 사용해 재사용성을 올리거나 다양한 참조가 가능해진다. 상속은 객체지향언어의 장점인데. 문제는 관계형 데이터베이스는 이러한 상속이 불가능하다는 것이다. 아니 정확히 말하자면 아예 테이블간의 상속이라는 개념이 없다보니 패러다임의 불일치가 발생한 것 Item 객체를 Album과 Movie 객체가 상속받고 있다. 이러한 상태의 객체를 테이블과 매핑하려고 한다면 조인전략을 선택해야한다. 1. Join 전략 상위 엔티티와 하위 엔티티를 조인하도록 하여 사용하는 방식이 Join 전략이다. @Entity @Inheritance(strategy = InheritanceType.JOINED) // 전략 선택 JOIN @DiscriminatorColumn(name = "..

DB 테이블은 PK와 FK를 가지고 테이블간 관계를 맺어주는데 엔티티는 기본적으로 단방향 매핑 밖에 안되어 JPA가 별도의 주인을 정하여 양방향 매핑을 가능토록 해준다. 테이블 관계에서 4가지의 유형이 있다 1 : 1 - 서로 1대1로 매핑하는 관계로 테이블 정규화시 보통 이러한 관계로 나타내곤한다. 1 : N - 1 대 N 으로 하나의 ROW가 N개의 ROW와 매핑이 가능한 상태이며 가장 많이 나오는 관계이다. N : 1 - 1 대 N 과 동일하다. N : N - N 대 N 관계로 실제 사용하기에는 복잡하여 보통 정규화를통해 1:N 이나 N:1로 추가한다. 1. 다대일 관계 일반적으로 테이블에서는 관계를 쉽게 표현할 수 있기 때문에 단방향, 양방향이라는 단어를 쓰진않는다. 하지만 엔티티의 경우 객체끼리..

1. 단방향 매핑 테이블은 JOIN 를 사용하여 어떤 테이블이 주 테이블이던 간에 서로간의 테이블의 컬럼 데이터를 조회할 수있다. 하지만 객체는 객체 끼리의 참조가 되어버리기 때문에 테이블과 같이 양방향에서 조회할 수는 없다. @Data @Entity public class Member { @Id @Column(name = "MEMBER_ID") @GeneratedValue private long id; @Column(name = "USER_NAME") private String name; @ManyToOne// N:1 관계를 나타내며 1개의 TEAM 에는 여러 MEMBER가 있을수 있다. @JoinColumn(name = "TEAM_ID")// Team 엔티티의 PK private Team team; ..