Spring/JPA

[JPA] 엔티티 매핑

lumana 2024. 11. 8. 23:11

엔티티 매핑

#Spring/DB/JPA/기본

엔티티 매핑에 사용하는 대표적인 애노테이션은 다음과 같다.

객체와 테이블 매핑 : @Entity, @Table
필드와 칼럼 매핑 : @Column
PK 매핑 : @Id
연관관계 매핑 : @ManyToOne, @JoinColumn

객체와 테이블 매핑

@Entity

@Entity가 붙은 클래스는 JPA가 관리, 엔티티라 한다.
JPA를 사용해서 테이블과 매핑할 클래스는 @Entity 필수
주의
- 기본 생성자 필수(파라미터가 없는 public 또는 protected 생성자)
  - JPA에서 reflection, proxy 등의 기술을 사용하기 때문에 기본 생성자가 필요하다.
- final 클래스, enum, interface, inner 클래스 사용X
- 저장할 필드에 final 사용 X

@Entity 속성

name

JPA에서 사용할 엔티티 이름을 지정한다
기본값: 클래스 이름을 그대로 사용
가급적 기본값을 사용한다. 만약 같은 이름의 클래스가 다른 패키지에 있다면 이 때는 지정해줘야 한다.

@Table

엔티티와 매핑할 테이블을 지정한다.

속성	기능	기본값
name	매핑할 테이블 이름	엔티티 이름을 사용
catalog	데이터베이스 catalog 매핑
schema	데이터베이스 schema 매핑
uniqueConstraints (DDL)	DDL 생성 시에 유니크 제약 조건 생성

만약 클래스 이름이 DB의 예약어와 겹치는 경우(Ex. Order) name 속성을 통해 매핑할 테이블 이름을 정해줘야 한다.

데이터베이스 스키마 자동 생성

JPA는 DDL을 애플리케이션 실행 시점에 자동 생성
테이블 중심 객체 중심
데이터베이스 방언을 활용해서 데이터베이스에 맞는 적절한 DDL 생성해준다.
이렇게 생성된 DDL은 개발 장비에서만 사용
생성된 DDL은 운영서버에서는 사용하지 않거나, 적절히 다듬은 후 사용
- 로그에 DDL 스크립트가 나오는데, 이걸 그대로 사용하지 말라는 말이다. 다듬고 사용하자.

데이터베이스 스키마 자동 생성 - 속성

hibernate.hbm2ddl.auto=

옵션	설명
create	기존 테이블 삭제 후 다시 생성 (DROP + CREATE)
create-drop	create와 같으나 종료 시점에 테이블 DROP
update	변경분만 반영 (운영 DB에는 사용하면 안됨)
validate	엔티티와 테이블이 정상 매핑되었는지만 확인
none	사용하지 않음

update 옵션의 경우 테이블 칼럼을 추가하는 것만 가능하다. 특정 필드를 지워도 칼럼이 사라지지 않는다.

데이터베이스 스키마 자동 생성 - 주의

운영 장비에는 절대 create, create-drop, update 사용하면 안된다.
- 이 옵션 쓰면 DB 데이터가 다 날라가버릴 수 있다.
개발 초기 단계는 create 또는 update
테스트 서버는 update 또는 validate
- 그냥 테스트 서버여도 update를 쓰지 말자. 왠만하면 테스트 서버나 스테이징, 운영서버 모두 아무 옵션도 안쓰는게 좋다.
스테이징과 운영 서버는 validate 또는 none

update 쿼리를 쓰면 alter가 나가서 락이 걸려버림. 서비스 중단이 생겨버린다 스테이징, 운영은
절대 쓰면 안 된다.

DDL 생성 기능

제약조건 추가: 회원 이름은 필수, 10자 초과X
- @Column(nullable = false, length = 10)
유니크 제약조건 추가
- @Table(uniqueConstraints = {@UniqueConstraint( name = "NAME_AGE_UNIQUE", columnNames = {"NAME", "AGE"} )})
- @Column(unique = true, length = 10)
  - 유니크 제약조건을 JPA 단에서 속성으로 사실 잘 안쓴다. 이름에 임의의 값을 만들어주는데, 알아먹을 수가 없다.
  - @Table에서 유니크 제약 조건을 설정해주면, 컬럼 이름까지 지정해줄 수 있다.
DDL 생성 기능은 DDL을 자동 생성할 때만 사용되고 JPA의 실행 로직에는 영향을 주지 않는다.
- Application 에는 영향이 없다. DDL 생성만 도와준다.

필드와 컬럼 매핑

예제: 요구사항

일반 회원과 관리자 구분
회원 가입일과 수정일 필요
회원을 설명할 수 있는 필드가 있어야 함. 길이제한 X

package hellojpa;

import jakarta.persistence.Column;
import jakarta.persistence.Entity;
import jakarta.persistence.EnumType;
import jakarta.persistence.Enumerated;
import jakarta.persistence.Id;
import jakarta.persistence.Lob;
import jakarta.persistence.Table;
import jakarta.persistence.Temporal;
import jakarta.persistence.TemporalType;
import java.util.Date;

@Entity
public class Member {
    @Id
    private Long id;
    @Column(name = "name")
    private String username;
    private Integer age; // DB에는 Integer와 가장 적절한 타입으로 매핑됨
    @Enumerated(EnumType.STRING)
    private RoleType roleType;
    @Temporal(TemporalType.TIMESTAMP)
    private Date createdDate; // DB에는 보통 날짜, 시간, 날짜시간 3가지만 있따.
    @Temporal(TemporalType.TIMESTAMP)
    private Date lastModifiedDate;
    @Lob
    private String description; // DB에 varchar 가 넘는 큰 컨텐츠를 넣고싶을 때 @Lob을 사용한다.
}

어노테이션	설명
@Column	컬럼 매핑
@Temporal	날짜 타입 매핑
@Enumerated	enum 타입 매핑
@Lob	BLOB, CLOB 매핑
@Transient	특정 필드를 컬럼에 매핑하지 않음 (매핑 무시)

@Column

속성	설명	기본값
name	필드와 매핑할 테이블의 컬럼 이름	객체의 필드 이름
insertable, updatable	등록, 변경 가능 여부	TRUE
nullable(DDL)	null 값의 허용 여부를 설정한다. false로 설정하면 DDL 생성 시에 not null 제약조건이 붙는다.
unique(DDL)	@Table의 uniqueConstraints와 같지만 한 컬럼에 간단히 유니크 제약조건을 걸 때 사용한다.
columnDefinition (DDL)	데이터베이스 컬럼 정보를 직접 줄 수 있다. ex) varchar(100) default 'EMPTY'	필드의 자바 타입과 방언 정보를 사용해 설정 (특정 DB에 종속적인 옵션을 넣을 수도 있다.)
length(DDL)	문자 길이 제약조건, String 타입에만 사용한다.	255
precision, scale(DDL)	BigDecimal 타입에서 사용한다 (BigInteger도 사용할 수 있다). precision은 소수점을 포함한 전체 자릿수, scale은 소수의 자릿수를 의미한다. 참고로 double, float 타입에는 적용되지 않는다. 아주 큰 숫자나 정밀한 소수를 다루어야 할 때만 사용한다.	precision=19, scale=2

@Enumerated

자바 enum 타입을 매핑할 때 사용한다.

속성	설명	기본값
value	- EnumType.ORDINAL: enum 순서를 데이터베이스에 저장 - EnumType.STRING: enum 이름을 데이터베이스에 저장	EnumType.ORDINAL

절대로 ORDINAL을 사용하면 안 된다.
ORDINAL이면 0, 1, 2, 3,... 요런 식으로 저장된다. 만약 새로운 ROLE이 추가되서 순서가 밀리면
1 이 USER였다가 갑자기 ADMIN이 되버리는 상황이 나올 수 있음

기본값이 ORDINAL이기 때문에 무조건 EnumType.STRING으로 지정해줘야 한다.
STRING으로 하면 varchar로 들어간다 ex) GUEST, USER, ADMIN

@Temporal

날짜 타입(java.util.Date, java.util.Calendar)을 매핑할 때 사용하는데, Java 8부터 LocalDate, LocalDateTime에 매핑하면 애노테이션을 붙이지 않아도 된다.

사실 지금은 거의 사용하지 않는 애노테이션이라고 보면 된다.

속성	설명	기본값
value	- TemporalType.DATE: 날짜, 데이터베이스 date 타입과 매핑 (예: 2013-10-11) - TemporalType.TIME: 시간, 데이터베이스 time 타입과 매핑 (예: 11:11:11) - TemporalType.TIMESTAMP: 날짜와 시간, 데이터베이스 timestamp 타입과 매핑 (예: 2013-10-11 11:11:11)

@Lob

데이터베이스 BLOB, CLOB 타입과 매핑한다

@Lob에는 지정할 수 있는 속성이 없다.
매핑하는 필드 타입이 문자면 CLOB 매핑, 나머지는 BLOB 매핑
- CLOB: String, char, java.sql.CLOB
- BLOB: byte, java.sql.BLOB

@Transient

필드 매핑X
데이터베이스에 저장X, 조회X
주로 메모리상에서만 임시로 어떤 값을 보관하고 싶을 때 사용

@Transient private Integer temp;

PK 매핑

PK 매핑 어노테이션

@Id
@GeneratedValue

PK 매핑 방법

직접 할당 : @Id만 사용하면 된다.
자동 생성(@GeneratedValue)

IDENTITY: 데이터베이스에 위임, MYSQL
SEQUENCE: 데이터베이스 시퀀스 오브젝트 사용, ORACLE
- @SequenceGenerator 필요
TABLE: 키 생성용 테이블 사용, 모든 DB에서 사용
- @TableGenerator 필요
AUTO: 방언에 따라 자동 지정, 기본값
- ORACLE이면 시퀀스로, Mysql이면 IDENTITY로….

Id의 필드에 String이나 정수형을 넣는데, 정수를 쓰면 Long을 쓰자. 10억이 넘어갈 때 타입 바꾸는게 더 힘들다

IDENTITY 전략 특징

PK 생성을 데이터베이스에 위임
주로 MySQL, PostgreSQL, SQL Server, DB2에서 사용
(예: MySQL의 AUTO_ INCREMENT)
JPA는 보통 트랜잭션 커밋 시점에 INSERT SQL 실행
AUTO_ INCREMENT는 데이터베이스에 INSERT SQL을 실행 한 이후에 ID 값을 알 수 있음
IDENTITY 전략은 em.persist() 시점에 즉시 INSERT SQL 실행하고 DB에서 식별자를 조회
- IDENTITY 전략에서만 이렇게 동작하는 것임.
- 성능 저하가 있을 것 같지만, 큰 영향은 없다고 하네요
- INSERT하고 SELECT 쿼리를 날려서 PK를 가져오는게 아님. JDBC 드라이버에서 insert 시점에 PK를 알 수 있게 구현이 되어있다.

package hellojpa;

import jakarta.persistence.*;

public class JpaMain {

    public static void main(String[] args) {

        EntityManagerFactory emf = Persistence.createEntityManagerFactory("hello");
        // persistence 의 unit name 을 넘겨서 EntityManagerFactory 를 만든다.
        EntityManager em = emf.createEntityManager(); // 쉽게 생각하면 DB 커넥션을 얻었다고 생각하면 된다.
        EntityTransaction tx = em.getTransaction();
        tx.begin(); // 트랜잭션 시작

        // 정석 code
        try {
            Member member = new Member();
            member.setUsername("UserB");
            System.out.println("===================");
            em.persist(member); // 여기서 insert 쿼리가 나간다.
            System.out.println("member.getId() = " + member.getId());
            System.out.println("===================");
            tx.commit();
        } catch (Exception e) {
            tx.rollback();
        } finally {
            em.close(); // 반드시 닫아주자
        }
        emf.close();
    }
}

실제로 확인해보자.

SEQUENCE 전략 특징

데이터베이스 시퀀스는 유일한 값을 순서대로 생성하는 특별한 데이터베이스 오브젝트(예: 오라클 시퀀스)
오라클, PostgreSQL, DB2, H2 데이터베이스에서 사용

시퀀스 generator가 시퀀스를 만들어주고, 이에 맞춰서 PK가 지정되는 방식이다.

속성	설명	기본값
name	식별자 생성기 이름	필수
sequenceName	데이터베이스에 등록되어 있는 시퀀스 이름	hibernate_sequence
initialValue	DDL 생성 시에만 사용됨, 시퀀스 DDL을 생성할 때 처음 1 시작하는 수를 지정한다.	1
allocationSize	시퀀스 한 번 호출에 증가하는 수 (성능 최적화에 사용됨). 데이터베이스 시퀀스 값이 하나씩 증가하도록 설정되어 있으면 이 값을 반드시 1로 설정해야 한다.	50!!!!!!
catalog, schema	데이터베이스 catalog, schema 이름

주의: allocationSize의 기본값 = 50

필자가 최근 진행한 해커톤에서 PostgreSQL로 DB를 갈아끼우면서 allocationSize를 1로 설정하지 않아 배포 단계에서 고생을 겪었던 경험이 있다.

예시: allocationSize를 1로 설정한 경우

package hellojpa;

import jakarta.persistence.*;

public class JpaMain {

    public static void main(String[] args) {

        EntityManagerFactory emf = Persistence.createEntityManagerFactory("hello");
        // persistence 의 unit name 을 넘겨서 EntityManagerFactory 를 만든다.
        EntityManager em = emf.createEntityManager(); // 쉽게 생각하면 DB 커넥션을 얻었다고 생각하면 된다.
        EntityTransaction tx = em.getTransaction();
        tx.begin(); // 트랜잭션 시작

        // 정석 code
        try {
            Member member = new Member();
            member.setUsername("UserB");
            System.out.println("===================");
            em.persist(member);
            System.out.println("member.getId() = " + member.getId());
            System.out.println("===================");


            tx.commit();
        } catch (Exception e) {
            tx.rollback();
        } finally {
            em.close(); // 반드시 닫아주자
        }
        emf.close();
    }
}

작동 순서
member_seq 오브젝트가 생긴다.
start with 1 increment by 1
1부터 시작 1씩 증가

멤버 객체를 생성하고 ID값은 아직 비어 있다.
ID값을 알려면 DB의 시퀀스 오브젝트에서 값을 가져와야 한다.
em.persist 영속성 컨텍스트에 넣는다는 건데, PK 값을 알아야 넣을 수 있다.
그래서 sequence에서 먼저 PK를 가져와야 한다.

======================== 출력
이후에 call next value for MEMBER_SEQ 쿼리가 나가서 다음 PK 값을 가져온다.
이 값으로 em.persist할때 member에 이 PK 값을 넣어준다.
그래서 이 때는 insert 쿼리가 안나간다.
========================= 출력

트랜잭션 커밋할 때 insert 쿼리가 나간다.

왜 allocationSize의 기본값이 50일까?
멤버 객체 3개를 저장한다고 해보자.
저장할 때 마다 시퀀스 오브젝트에서 pk 값을 가져오는 과정에서 네트워크를 타야한다. 비효율적이다.

성능 최적화를 위해 미리 50개를 땡겨놓고(DB에는 이제 51) 메모리에서 1씩 늘리면서 쓰다가
다쓰면 call next로 또 50개 땡겨놓는다 .(DB에는 이제 101)

만약 em.perist(member1)하면 call next value가 두 번 호출된다.
처음 호출할 때 시퀀스 1이 되야 하고, 두 번째 호출될 때 시퀀스가 51이 되야 한다.

서버에서는 50개씩 써야하는데 처음 호출했을 때 DB의 시퀀스 값이 1이네? 한 번더 호출한다 DB에는 51

1 | 1
51 | 2
51 | 3

첫 persist에서 두 번 호출되서 1, 51로 맞춰지고
그 뒤로는 51번까지 메모리에서 돌아간다. 51번까지 next call은 없다.

숫자를 너무 크게 잡으면 DB에 구멍이 생겨버린다. 50이나 100이 적당

TABLE 전략

키 생성 전용 테이블을 하나 만들어서 데이터베이스 시퀀스를 흉내내는 전략이다

장점: 모든 데이터베이스에 적용 가능
단점: 성능

실제 운영에서 table 전략을 거의 쓰지 않는다.

CREATE TABLE MY_SEQUENCES (
    sequence_name VARCHAR(255) NOT NULL,
    next_val BIGINT,
    PRIMARY KEY (sequence_name)
);

@Entity
@TableGenerator(
    name = "MEMBER_SEQ_GENERATOR",
    table = "MY_SEQUENCES",
    pkColumnValue = "MEMBER_SEQ",
    allocationSize = 1
)
public class Member {
    @Id
    @GeneratedValue(strategy = GenerationType.TABLE, generator = "MEMBER_SEQ_GENERATOR")
    private Long id;
}

my_sequences라는 테이블이 생기고,
여기에는 sequence_name이라는 칼럼과 next_Val이라는 칼럼이 들어 있다.
여기에는 각각 member_seq과 value 값이 들어있다

@TableGenerator 속성

속성	설명	기본값
name	식별자 생성기 이름	필수
table	키 생성 테이블명	hibernate_sequences
pkColumnName	시퀀스 컬럼명	sequence_name
valueColumnName	시퀀스 값 컬럼명	next_val
pkColumnValue	키로 사용할 값 이름	엔티티 이름
initialValue	초기 값, 마지막으로 생성된 값이 기준이다.	0
allocationSize	시퀀스 한 번 호출에 증가하는 수 (성능 최적화에 사용됨)	50
catalog, schema	데이터베이스 catalog, schema 이름
uniqueConstraints(DDL)	유니크 제약 조건을 지정할 수 있다.

권장하는 식별자 전략

기본 키 제약 조건: null 아님, 유일, 변하면 안된다.
미래까지 이 조건을 만족하는 자연키는 찾기 어렵다. 대리키(대체키)를 사용하자.
- 자연키 : 주민번호, 전화번호처럼 비즈니스적으로 의미 있는 것. 내추럴 키라고도 함
예를 들어 주민등록번호도 기본 키로 적절하기 않다.
- 나라에서 갑자기 주민번호를 저장하지 말라고 함. 만약 주민번호를 PK로 쓰면 회원을 갖다 쓴 나머지 FK에서 다 난리가 나버린다
권장: Long형 + 대체키 + 키 생성전략 사용
- 시퀀스나 UUID + 키 생성전략
- AutoIncrement나 sequence object를 쓰자. 비즈니스를 절대 키로 끌고오면 안 됨

비즈니스를 키로 끌고오면, 비즈니스적으로 뭔가 바뀌면 이 키를 참조하는 모든 테이블의 필드에 영향이 너무 크다.

예제: 상품 주문 및 회원

package jpabook.jpabasicshop.domain;

import jakarta.persistence.Column;
import jakarta.persistence.Entity;
import jakarta.persistence.EnumType;
import jakarta.persistence.Enumerated;
import jakarta.persistence.GeneratedValue;
import jakarta.persistence.Id;
import jakarta.persistence.Table;
import java.time.LocalDateTime;

@Entity
@Table(name = "ORDERS")
public class Order {

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

    @Column(name = "MEMBER_ID")
    private Long memberId; // 객체지향스럽지 않다.
    // Member member 이렇게 있으면 좋을 것 같은데?

    private LocalDateTime orderDate;

    @Enumerated(EnumType.STRING)
    private OrderStatus status;

    public Long getId() {
        return id;
    }

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

    public Long getMemberId() {
        return memberId;
    }

    public void setMemberId(Long memberId) {
        this.memberId = memberId;
    }

    public LocalDateTime getOrderDate() {
        return orderDate;
    }

    public void setOrderDate(LocalDateTime orderDate) {
        this.orderDate = orderDate;
    }

    public OrderStatus getStatus() {
        return status;
    }

    public void setStatus(OrderStatus status) {
        this.status = status;
    }
}

package jpabook.jpabasicshop;

import jakarta.persistence.EntityManager;
import jakarta.persistence.EntityManagerFactory;
import jakarta.persistence.EntityTransaction;
import jakarta.persistence.Persistence;
import jpabook.jpabasicshop.domain.Member;
import jpabook.jpabasicshop.domain.Order;

public class JpaMain {
    public static void main(String[] args) {

        EntityManagerFactory emf = Persistence.createEntityManagerFactory("hello");
        // persistence 의 unit name 을 넘겨서 EntityManagerFactory 를 만든다.
        EntityManager em = emf.createEntityManager(); // 쉽게 생각하면 DB 커넥션을 얻었다고 생각하면 된다.
        EntityTransaction tx = em.getTransaction();
        tx.begin(); // 트랜잭션 시작

        // 정석 code
        try {
            Order order = em.find(Order.class, "1L");
            Long memberId = order.getMemberId();

            Member member = em.find(Member.class, memberId);
            // 위 방법 대신
            // Member findMebmer = order.getMember();
            // 이런 방법으로 찾고 싶다.

            tx.commit();
        } catch (Exception e) {
            tx.rollback();
        } finally {
            em.close(); // 반드시 닫아주자
        }
        emf.close();
    }
}

여기서 주의해서 봐야할 것은

@Column(name = "MEMBER_ID")
private Long memberId; // 객체지향스럽지 않다.

현재 Order 엔티티에 memberId 키를 필드에 가지고 있다.

Order order = em.find(Order.class, "1L");
Long memberId = order.getMemberId();
Member member = em.find(Member.class, memberId);

데이터 중심으로 설계했기 때문에 이런 식으로 번거롭게 영속성 컨텍스트에서 조회하는 작업을 추가로 더 해야 한다.

데이터 중심 설계의 문제점

현재 방식은 객체 설계를 테이블 설계에 맞춘 방식
테이블의 외래키를 객체에 그대로 가져옴
객체 그래프 탐색이 불가능
참조가 없으므로 UML도 잘못됨

만약 private Member member 로 선언이 되어 있다면,
Member findMebmer = order.getMember();로 찾을 수 있지 않을까?

다음 챕터에서

Ref) 김영한 자바 ORM 표준 JPA 프로그래밍 - 기본편

'Spring > JPA' 카테고리의 다른 글

[JPA] 영속성 관리 (0)	2024.11.06
[JPA] About JPA (0)	2024.11.06
[JPA] 웹 계층 개발 (0)	2024.10.09
[JPA] 도메인 개발 (0)	2024.10.04
[JPA] Cascade 적용 기준 (0)	2024.09.29

현재글[JPA] 엔티티 매핑

Brute force Study

배움을 나누는 공간 https://github.com/DawnGlow

Today :
Yesterday :

일	월	화	수	목	금	토
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	31

Brute force Study

[JPA] 엔티티 매핑

엔티티 매핑

객체와 테이블 매핑

@Entity

@Entity 속성

@Table

데이터베이스 스키마 자동 생성

데이터베이스 스키마 자동 생성 - 속성

데이터베이스 스키마 자동 생성 - 주의

DDL 생성 기능

필드와 컬럼 매핑

@Column

@Enumerated

@Temporal

@Lob

@Transient

PK 매핑

PK 매핑 어노테이션

PK 매핑 방법

IDENTITY 전략 특징

SEQUENCE 전략 특징

TABLE 전략

@TableGenerator 속성

권장하는 식별자 전략

예제: 상품 주문 및 회원

데이터 중심 설계의 문제점

'Spring > JPA' 카테고리의 다른 글

'Spring/JPA'의 다른글

티스토리툴바

[JPA] 엔티티 매핑

엔티티 매핑

객체와 테이블 매핑

@Entity

@Entity 속성

@Table

데이터베이스 스키마 자동 생성

데이터베이스 스키마 자동 생성 - 속성

데이터베이스 스키마 자동 생성 - 주의

DDL 생성 기능

필드와 컬럼 매핑

@Column

@Enumerated

@Temporal

@Lob

@Transient

PK 매핑

PK 매핑 어노테이션

PK 매핑 방법

IDENTITY 전략 특징

SEQUENCE 전략 특징

TABLE 전략

@TableGenerator 속성

권장하는 식별자 전략

예제: 상품 주문 및 회원

데이터 중심 설계의 문제점

'Spring > JPA' 카테고리의 다른 글

'Spring/JPA'의 다른글

관련글

티스토리툴바