JPA #4 엔티티 매핑 (객체-테이블 매핑)

JPA는 데이터베이스 테이블과 매핑하기가 정말 쉽다. 애노테이션으로 간단하게 가능하다.

• 객체와 테이블 매핑: @Entity, @Table
• 필드와 컬럼 매핑: @Column
• 기본 키 매핑: @Id
• 연관관계 매핑: @ManyToOne,@JoinColumn

 

📌 @Entity

JPA에서 사용할 엔티티 클래스를 지정한다. 반드시 붙여줘야하며 없다면 객체를 JPA로 다룰 수 없다.

@Entity(name = "이름") 으로 JPA에서 쓸 엔티티 이름을 지정해줄 수 있으며, 생략하면 클래스명을 이름으로 사용한다.

• 단, 리플렉션을 이용하기 때문에 [public 또는 protected 인 기본생성자]가 필수이다.
• 또한 사용하는 필드, 클래스에 final을 사용할 수 없다. 프록시 생성 불가능.
• enum, interface, inner 클래스 또한 지원하지 않는다.

내부적으로 CGLIB등을 사용하지만, 중간에 업데이트되며 리플렉션 기술이 바뀔 수도 있기에 간략하게만 알고 넘어가자.

// JPA 어노테이션은 자바 표준 persistence에 포함되어있다.
import javax.persistence.Entity;
import javax.persistence.Id;

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

 

 

📌@Table

엔티티와 매핑할 테이블을 지정하는 어노테이션이다.

@Table(name= "테이블명" ) 으로 테이블을 지정해줄 수 있으며, 생략하면 Entity 이름을 테이블명으로 사용한다.

@Index로 인덱스를 추가하거나 @UniqueConstraint를 이용해 특정 칼럼에 제약 조건을 추가해줄 수 있다.

특정칼럼 제약조건은 @Column(unique= ... ) 로도 걸 수 있지만, 제약조건 이름설정이 불가능하다는 단점이 있다.

이렇게 제약조건 이름이 UUID로 박혀버린다. @Table을 이용해서 이름을 지정해주자. (ex NAME_IS_UNIQUE)

@Entity
@Table(name="MEMBER", // 테이블명을 MEMBER로 지정
        uniqueConstraints = { // name, age 칼럼에 unique 제약조건 추가
          @UniqueConstraint(name = "NAME_AGE_UNIQUE", columnNames = {"NAME", "AGE"} )
        })
public class Member {
    ...
}

@Table(indexes = {@Index(columnList="mycol1"), @Index(columnList="mycol2")})

 

✔ JPA의 테이블 자동 생성 기능 (ddl.auto)

참고로 JPA를 사용하면 만들어둔 객체를 이용하여 테이블을 자동 생성(=DDL 생성)할 수 있다.

애플리케이션 실행 시점에 @Entity를 읽어 DB에 DDL을 날려서 테이블을 생성한다. 아래 옵션으로 설정할 수 있다.

* 운영서버에서는 절대로 사용해서는 안되는 기능이다. 잘못하다간 운영중인 DB가 삭제되고 다시 생성될 수 있다.

persistence.xml 또는 application.yml에서 해당 옵션을 설정할 수 있다.

 

📌 @Id

테이블에 필수 값인 기본키를 지정한다. (없다면 IntelliJ에서 친절하게 오류를 띄워준다.)

기본타입(int, String)이나 기본 래퍼타입 (Interger)을 기본키로 지정해 줄 수 있다.

객체에는 Null이 들어갈 수 있으므로, 기본 타입보다는 래퍼타입 (Long, Interger)를 사용하는 걸 권장한다.

 

간혹 래퍼타입을 사용하면 boxing/ unboxing 과정 때문에 성능이 나빠지는게 아닌가 걱정하는 사람도 있는데,  이는 DB I/O에 비하면 매우 빠르기 때문에 병목이 생기지 않는다. 오히려 null을 제대로 처리하지 못해 발생할 수 있는 문제가 훨씬 크고, 해결하기 어렵기 때문에 가급적 래퍼타입을 쓰는 걸 권장한다.

 

그 외 Date, BingDecimal 같은 것도 기본키로 사용 가능하지만, 잘 사용하지는 않는다.

기본 키의 제약조건은 null이 되면 안되고, 유일해야하며, 미래에도 변할 일이 없어야 한다.

 

예를 들어 주민등록번호, 학번 같은 것도 먼 미래에는 변해버릴 가능성이 있어 기본키로 적합하지 않다.

변하지 않는다고 하더라도 [비즈니스에 의미있는 데이터]를 키로 사용했다가는, 추후에 법적인 문제나 개인정보 때문에 키를 사용하지 못하게 될 경우 DB를 정말 크게 손봐야할 수도 있다. 

 

그래서 보통 [키 생성전략을 사용한 Long 키] 와 [비즈니스와 상관없는 대체키] 등을 id로 사용하는 걸 권장한다.

 

 

✔ 기본키 생성 전략 @GeneratedValue

기본키는 직접 만들지 않고, DB 자동 생성을 이용할 수 있다. 이는 데이터베이스에 기본키 생성을 의존하는 방법이다.

@Id
@GeneratedValue(strategy = GenerationType.IDENTITY) // 기본값은 AUTO
private Long id;

옵션은 총 4가지가 있다.

• AUTO(기본값) : 아래 3가지중 DB 방언(dialect)에 따라 자동 지정.

• IDENTITY : 데이터베이스에 키 생성을 위임. DB가 알아서 처리해라 (MySQL, PostgreSQL, SQL Server, DB2)
   ➡ JPA 쿼리 : id varchar(255) generated by default as identity
   ➡ MySQL 쿼리 : id varchar(255) not null auto_increment
  * insert를 하지 않으면 id 값이 무엇인지 알 수 없기 때문에 쓰기 지연이 불가능하다. 바로 DB에 flush 된다.
  다만 키 생성시 발생하는 쓰기지연은 실제 서비스에는 성능 차이가 거의 없어서 무시하고 사용해도 큰 상관은 없다.
  * JDBC3부터 추가된 getGeneratedKeys를 사용하기 때문에 [insert SQL+ select key] 두 쿼리를 한 번에 처리한다.
  
• SEQUENCE : 데이터베이스 시퀀스 오브젝트 사용 (Oracle, 단 @SequenceGenerator 로 DB 시퀸스와 연동 필요)
   ➡ id를 시퀸스에서 조회해 영속성 컨텍스트에 저장한다.
   ➡ 시퀀스 오브젝트도 보통 1부터 시작하고, +1 로 증가되긴하지만 개발자가 원한다면 이 값을 변경할 수도 있다. 
  * 시퀀스만 DB에서 가져오면 되기에 쿼리는 쓰기지연이 가능하다.

@Entity
@SequenceGenerator(
    name = "BOARD_SEQ_GENERATOR", // 사용할 sequence 이름
    sequenceName = "BOARD_SEQ", // 실제 데이터베이스 sequence 이름
    initialValue = 1, allocationSize = 1
)
public class Board{
    @Id
    @GeneratedValue(
        strategy = GenerationType.SEQUENCE,
        generator = "BOARD_SEQ_GENERATOR" // 위의 sequence 이름
    )
    private Long id;
}

➡ 아무리 시퀀스를 가져온다고 해도, DB에 매번 시퀀스 값을 요청을 하는게 네트워크 비용이 부담스러울 수 있다.

그래서 allocationSize라는 옵션을 이용해서 DB에 미리 시퀀스 값을 50개를 만들어놓고 한번에 받아와서 사용한다.

allocationSize가 50이면, 1에 DB에서 시퀸스를 가져오고, 마지막 51을 메모리에서 사용할 때 다시 DB에 접근한다.

여러 스레드에서 동시에 사용한다 하더라도, 할당받은 시퀸스가 다르기 떄문에 (1~51, 52~100) 동시성 문제는 없다.

다만 서버가 중간에 죽어버리면 할당받았다가 남은 시퀸스는 영원히 사용하지 못한다. Size를 적당히 설정하자. 

 

• TABLE : 키 생성용 테이블 사용 ( @TableGenerator 필요)
  DB에서 시퀸스 오브젝트를 지원하지 않는 경우, 직접 테이블을 만들어서 시퀸스처럼 사용하는 방법이다.
  Table을 생성하는 것일뿐, DB 시퀸스 오브젝트와 사용법은 동일하다. 다만 성능이 훨씬 구려서 잘 사용하지 않는다.

/* 성능이 구린 대신, 그냥 테이블을 만드는거라 모든 DB에 적용가능 */
@Entity
@TableGenerator(
    name = "MY_BOARD_SEQ_GENERATOR", // 사용할 table sequence 이름
    table = "MY_BOARD_SEQ", // 실제 데이터베이스 table 이름
    pkColumnValue = "BOARD_SEQ", allocationSize = 1
)
public class Board{
    @Id
    @GeneratedValue(
        strategy = GenerationType.TABLE,
        generator = "MY_BOARD_SEQ_GENERATOR" // 위의 sequence 이름
    )
    private Long id;
}

 

 

 

📌 @Column

필드와 칼럼을 매칭할 때 사용한다. @Column을 이용해서 제약조건을 추가할 수 있다.

당연히 JPA 실행 로직에 영향을 주지는 않는다. 테이블을 생성할 때 (=자동 DDL 생성을 사용할 때) 사용된다.

여담이지만 @Table의 인덱스나 @Column을 적어두면 DB를 확인하지 않아도 개발자가 쉽게 정보를 확인할 수 있다.

 

✔ 객체 - 테이블 이름변경 전략 (naming_strategy)

물론 @Column을 생략해도 된다. 알아서 특정 규칙에 따라 테이블과 객체를 매핑되도록 동작한다.

 

보통 객체는 카멜케이스(myHomeTown)을 사용하고, DB는 언더스코어(MY_HOME_TOWN)을 쓰는게 일반적인데. 만약 다르게 변환하고 싶다면 naming_strategy 옵션을 통해 적절하게 변환 가능하다.

• ImprovedNamingStrategy : camelCase를 CAMEL_CASE로 변경
• SpringPhysicalNamingStrategy (스프링용 옵션, 기본값) : camelCase를 CAMEL_CASE로 변경. (위에걸 상속해서만듦)
• PhysicalNamingStrategyStandardImpl (스프링용 옵션) : 변경없이 변수이름을 그대로 사용
• 거의 사용할 일은 없지만 이름 전략 클래스를 커스텀해서 사용할 수도 있다. 궁금하면 검색해보도록 하자.

// resource/META-INFO/persistence.xml
<property name="hibernate.ejb.naming_strategy" value="org.hibernate.cfg.ImprovedNamingStrategy"></property>

// resource/application.yml
jpa:
    hibernate:
    naming:
        physical-strategy: org.hibernate.boot.model.naming.PhysicalNamingStrategyStandardImpl

 

name, nullable, length 정도를 자주 쓴다. unique도 종종 쓰지만, @Table 로 설정하는걸 권장함.

public class Member {
 
    // 기본키 매핑
    @Id
    @Column(name = "ID")
    private String id;
 
    // not null, varchar(10)
    @Column(name = "NAME", nullable = false, length = 10)
    private String username;
}

 

 

📌 [DB 칼럼]과 [객체 필드] 매핑하기

@Column 말고 다양한 매핑 어노테이션을 제공해준다.

Lob은 Large Object의 약자로 이미지, 동영상, 대용량 데이터등을 의미한다. (ex CLOB = Char Lob)

public enum RoleType {
    ADMIN, USER
}

@Entity
public class Member {

    @Id
    private Long id;
    
    @Column(name = "name") // @Column을 이용하여 제약조건을 추가하거나 테이블과 매핑한다.
    private String username;
    
    private Integer age; // DB에 있는 타입은 별다른 옵션이 없어도 알아서 처리.
    
    // DB에는 Enum 타입이란게 없으므로, 따로 지정해주어여한다.
    @Enumerated(EnumType.STRING)
    private RoleType roleType;
    
    // DB는 TIME, DATE, TIMESTAMP(시간+날짜)로 구분지어 사용한다.
    @Temporal(TemporalType.TIMESTAMP)
    private Date createdDate;
    
    @Temporal(TemporalType.TIMESTAMP)
    private Date lastModifiedDate;
    
    @Lob
    private String description;
    
    //Getter, Setter… 
}

 

✔ @Basic

DB 칼럼에 매핑을 할 때에는 @Column이나 @Table (* 이름지정가능)을 사용하면 된다.

만약 JPA Entity에 특정 옵션을 주고싶은 경우 @Basic을 사용한다.

@Lob @Basic(fetch = FetchType.EAGER) // optional = false 등으로 nullable 설정도 가능
private String profileImage;

이는 데이터베이스 칼럼과는 상관없이, 그냥 JPA 상에 추가적인 옵션을 줄 때 사용하는 기능이다.

• @Column 사용시, 데이터베이스에서 null을 허용하면 무조건 null 허용이다. 선택권이 없다.
• @Basic은 데이터베이스 null 여부와 상관없이, JPA Entity 자체에 제약조건을 줄 수 있다.

 

 

✔ 주의사항

만약 DB에 저장하지 않고싶다면, 메모리에만 남겨두는 @Transient를 사용하면 된다. (쿼리가 발생하지 않는다.)

@Transient
private MyCacheMemory Temp

 

* 참고로 Enumeratd는 반드시 STRING으로 사용해야한다.

순서(1,2,3)을 사용하는 ORDINAL는, Enum 객체를 수정할 때마다 DB에 있는 식별자의 의미가 바뀌기에 큰일 날 수있다.

@Enumerated(EnumType.STRING) // ORDINAL ❌ 
private RoleType roleType;

 

@Temporal은 Java8 이후 버전에는 사용할일이 거의 없다.

그냥 LocalDate, LocalDateTime 클래스를 사용하면 알아서 처리되기 때문이다

 

@Lob은 따로 지정하는 옵션이 없고, 타입이 문자면 CLOB, 그 외는 BLOB ( 바이너리 )로 자동 매핑된다.

CLOB = Char Large Object, 말 그대로 문자열 큰 객체..ㅋㅋ

 

📌 @Embedded (컴포넌트)

뭐 차근차근 배워나갈거지만, 이번 글에서 배운 걸 사용한 최종적인 코드는 아래와 비슷하게 만들어 질겁니다.

// 임베디드 타입 사용하지 않았을 때
@Entity
public class Member {
  
  @Id @GeneratedValue
  private Long id;
  
  private String name;
  
  // 근무 기간
  LocalDate startDate;
  LocalDate endDate;
  
  // 집 주소 표현
  private String city;
  private String street;
  private String zipcode;
  // ...
}

회원이 위와 같은 데이터를 가진 이유는 아래와 같이 설계하고자 했기 때문입니다.

"회원 엔티티는 이름, [ 근무 기간 ], [ 집 주소 ]를 가진다."

 

실제 데이터는 '근무기간', '집 주소'라는 하나의 값으로 다루기에는 까다롭습니다. 그래서 이런 Entity가 만들어진거죠.

 

"회원 엔티티는 이름, [근무 시작일, 근무 종료일], [주소 도시, 주소 동호수, 우편 번호]를 가진다."

 

무언가 어색하지 않으신가요? 회원이 '집 주소'가 필요한 경우는 있지만, '서울', '906호' 이런 데이터가 단독으로 필요한 경우가 있을까요?

 

아니 애초에, [ 집 주소 ] 는 하나의 데이터로 봐야할거 같은데, 여기에 포함된 세부 데이터를 회원이 가지고 있는게 객체지향적으로 좋은 설계인지 고민해볼 필요가 있습니다. 이는 응집력을 떨어뜨리고, 사용과 유지보수를 어렵게 만듭니다.

 

 

✨ 이를 해결하기 위해 JPA에서는 @Embedded 타입 (컴포넌트)를 제공해줍니다.

참고로 임베디드 타입을 사용한다고 해서 DB 테이블이 더 생성되지는 않습니다. 기존과 동일하게 매핑해서 사용합니다.

// 임베디드 타입 사용
@Entity
public class Member {
  
  @Id @GeneratedVAlue
  private Long id;
  private String name;
  
  @Embedded
  private Period workPeriod;	// 근무 기간
  
  @Embedded
  private Address homeAddress;	// 집 주소
}

 

임베디드 타입은 아래와 같이 정의 가능합니다.

@Embeddable
public class Address {
  
  @Column(name="city") // 매핑할 컬럼 정의 가능
  private String city;
  
  private String street;
  private String zipcode;
  
  public boolean isMetropolitanCity (City city) {
  // .. 값 타입을 위한 메서드를 정의할 수 있다
  }
}

 

당연히 임베디드 타입 안에서 다른 임베디드 타입을 사용할 수 있습니다.

그래서 잘 설계된 JPA Entity는 보통 DB 테이블보다 더 많은 수의 객체를 가지는게 일반적입니다.

실제 테이블은 Member 하나이다.