엔티티 매핑

객체와 테이블 매핑

@Entity

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

@Entity 속성 정리

• name
  • JPA에서 사용할 엔티티 이름을 지정한다.
  • 기본값: 클래스 이름을 그대로 사용(예: Member)
  • 같은 클래스 이름이 없으면 가급적 기본값을 사용한다.
• @Table은 엔티티와 매핑할 테이블 지정

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

• DDL을 애플리케이션 실행 시점에 자동 생성
• 테이블 중심 객체 중심
• 데이터베이스 방언을 활용해서 데이터베이스에 맞는 적절한 DDL 생성 (H2에서는 VARCHAR, Oracle에서는 VARCHAR2)

• 이렇게 생성된 DDL은 개발 장비에서만 사용

• 생성된 DDL은 운영서버에서는 사용하지 않거나, 적절히 다듬은 후 사용

속성

hibernate.hbm2ddl.auto

주의

• 운영 장비에는 절대 create, create-drop, update 사용하면 안 된다.
• 개발 초기 단계는 create 또는 update
• 테스트 서버는 update 또는 validate
• 스테이징과 운영 서버는 validate 또는 none

DDL 생성 기능

• 제약조건 추가: 회원 이름은 필수, 10자 초과X : @Column(nullable = false, length = 10)
• 유니크 제약조건 추가 : @Table(uniqueConstraints = {@UniqueConstraint( name = "NAME_AGE_UNIQUE", columnNames = {"NAME", "AGE"} )})
• DDL 생성 기능은 DDL을 자동 생성할 때만 사용되고 JPA의 실행 로직에는 영향을 주지 않는다.

필드와 컬럼 매핑

요구사항 추가

1. 회원은 일반 회원과 관리자로 구분해야 한다.
2. 회원 가입일과 수정일이 있어야 한다.
3. 회원을 설명할 수 있는 필드가 있어야 한다. 이 필드는 길이 제한이 없다.

@Entity
public class Member {
    
    @Id
    private Long id;
    
    @Column(name = "name")
    private String username;
    
    private Integer age;
    
    @Enumerated(EnumType.STRING)
    private RoleType roleType;
    
    @Temporal(TemporalType.TIMESTAMP)
    private Date createdDate;
    
    @Temporal(TemporalType.TIMESTAMP)
    private Date lastModifiedDate;
    
    @Lob
    private String description;
    //Getter, Setter…
}

매핑 어노테이션 정리

hibernate.hbm2ddl.auto

@Column

@Enumerated

• 자바 enum 타입을 매핑할 때 사용
• 주의! ORDINAL을 사용할 경우 객체가 변경되었을 때 큰 문제가 생길 수 있으므로 사용하지 않는다 ex. 기존 enum {USER, ADMIN} 변경된 enum {GUEST, USER, ADMIN} ORDINAL을 사용하였을 경우 기존에는 0 = USER 였지만 변경 이후에는 0 = GUEST이므로 문제가 생긴다.

@Temporal

• 날짜 타입(java.util.Date, java.util.Calendar)을 매핑할 때 사용
• 참고: LocalDate, LocalDateTime을 사용할 때는 생략 가능 (최신 하이버네이트 지원)

@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;

기본 키 매핑

@Id @GeneratedValue(strategy = GenerationType.AUTO)
private Long id;

기본 키 매핑 방법

• 직접 할당: @Id만 사용
• 자동 생성(@GeneratedValue)
  • IDENTITY: 데이터베이스에 위임, MYSQL
  • SEQUENCE: 데이터베이스 시퀀스 오브젝트 사용, ORACLE
    • @SequenceGenerator 필요
  • TABLE: 키 생성용 테이블 사용, 모든 DB에서 사용
    • @TableGenerator 필요
  • AUTO: 방언에 따라 자동 지정, 기본값

IDENTITY 전략

특징

• 기본 키 생성을 데이터베이스에 위임
• 주로 MySQL, PostgreSQL, SQL Server, DB2에서 사용 (예: MySQL의 AUTO_ INCREMENT)
• JPA는 보통 트랜잭션 커밋 시점에 INSERT SQL 실행
• AUTO_ INCREMENT는 데이터베이스에 INSERT SQL을 실행한 이후에 ID 값을 알 수 있음
• IDENTITY 전략은 em.persist() 시점에 즉시 INSERT SQL 실행하고 DB에서 식별자를 조회

매핑

@Entity
public class Member {
    
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

SEQUENCE 전략

특징

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

매핑

@Entity
@SequenceGenerator(
    name = “MEMBER_SEQ_GENERATOR",
    sequenceName = “MEMBER_SEQ", //매핑할 데이터베이스 시퀀스 이름
    initialValue = 1, allocationSize = 1)
public class Member {
    
    @Id
    @GeneratedValue(strategy = GenerationType.SEQUENCE,
                    generator = "MEMBER_SEQ_GENERATOR")
    private Long id;

@SequenceGenerator

• 주의: allocationSize 기본값 = 50

TABLE 전략

• 키 생성 전용 테이블을 하나 만들어서 데이터베이스 시퀀스를 흉내내는 전략
• 장점: 모든 데이터베이스에 적용 가능
• 단점: 성능

매핑

@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;
}

create table MY_SEQUENCES (
    sequence_name varchar(255) not null,
    next_val bigint,
    primary key ( sequence_name )
)

SELECT * FROM MY_SEQUENCES

@TableGenerator - 속성

권장하는 식별자 전략

• 기본 키 제약 조건: null 아님, 유일, 변하면 안된다.

• 미래까지 이 조건을 만족하는 자연키는 찾기 어렵다. 비즈니스와 연관이 없는 대리키(대체키)를 사용하자.

  • 예를 들어 주민등록번호도 기본 키로 적절하지 않다.
    ex. 회원 테이블의 PK로 주민등록번호를 사용했는데 주민등록번호 사용이 금지된다면?
    회원 테이블과 Join하고 있는 수많은 테이블의 외래키를 변경해야 한다.

• 권장: Long형 + 대체키 + 키 생성전략 사용

  • 엔티티를 처음 new로 생성하는 시점에는 값이 없으므로 null인 상태가 필요하다
    기본형 int는 null 값을 가질 수 없으므로 참조형인 Integer를 사용한다.
    Integer의 크기 제한 때문에 Long을 사용한다.

SEQUENCE 전략과 최적화

• IDENTITY 전략은 데이터베이스에서 INSERT SQL 문을 실행한 이후에야 ID를 알 수 있다.
• 그러나 SEQUENCE 전략은 em.persist()하는 시점에서 데이터베이스에서 ID만 조회해올 수 있다. 하지만 em.persist()를 할 때마다 네트워크를 이용하면 성능 이슈가 발생할 수 있지않을까?
• 이러한 문제점을 해결하기 위하여 하이버네이트는 allocationSize라는 옵션을 지원하여 시퀀스를 한 번에 여러 개 호출할 수 있다. 이 옵션은 동시성 문제도 없다.

실전 예제 - 1. 요구사항 분석과 기본 매핑

요구사항 분석

• 회원은 상품을 주문할 수 있다.
• 주문 시 여러 종류의 상품을 선택할 수 있다.

도메인 모델 분석

• 회원과 주문의 관계: 회원은 여러 번 주문할 수 있다. (일대다)
• 주문과 상품의 관계: 주문할 때 여러 상품을 선택할 수 있다. 반대로 같은 상품도 여러 번 주문될 수 있다. 주문상품 이라는 모델을 만들어서 다대다 관계를 일다대, 다대일 관계로 풀어냄

테이블 설계

• 주문이 ORDERS인 이유 : DB에서 ORDER가 예약어로 걸려 있는 경우가 많아서 테이블명이 ORDER일 경우 오류 발생

엔티티 설계와 매핑

데이터 중심 설계의 문제점

• 현재 방식은 객체 설계를 테이블 설계에 맞춘 방식
• 테이블의 외래키를 객체에 그대로 가져옴
• 객체 그래프 탐색이 불가능
• 참조가 없으므로 UML도 잘못됨
• 특정 주문을 한 회원에 대한 정보를 조회할 경우

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

Member orderedMember = em.find(Member.class, memberId);
// Member orderedMember = order.getMember(); 식으로 사용하는 것이 객체지향적이다.