앞선 포스팅들을 통해 JPA 의 내부구조와 동작흐름에 대해 알아보았다.
그럼 이제, JPA 를 사용해서 실제 RDB와는 어떤식으로 매핑되는지에 대해 알아보도록 하자.

엔티티와 테이블

@Entity

JPA를 통해 관리할 객체에 붙이는 어노테이션이다.
기본생성자가 필수적인데, 사용하게 되는 JPA 구현체에서 엔티티 객체를 조작할때 리플렉션을 활용해 프록시 객체를 만드는데, 이 때 기본생성자가 필요하기 때문이다.

속성

name : JPA 에서 사용할 엔티티 이름, 기본값은 클래스와 동일

@Table

엔티티와 매핑할 테이블에 대한 정보가 담기는 어노테이션

속성

name : 매핑할 테이블 이름, 기본값은 엔티티 이름과 동일
catalog : catalog 기능이 있는 데이터베이스에서 catalog 매핑
schema : schema 기능이 있는 데이터베이스에서 schema 매핑
uniqueConstraints(DDL) : DDL 생성 시에 유니크 제약조건을 만든다. (2개 이상의 복합 유니크 제약조건도 가능) 스키마 자동 생성 기능을 사용해서 DDL를 만들 때만 사용

엔티티의 필드와 테이블의 컬럼

Entity 객체가 RDB의 테이블과 매핑된다면 Entity 객체의 필드들은 테이블의 컬럼과 매핑된다. 필드는 기본적으로 컬럼으로 매핑이되며 별도의 설정이 필요하지 않다면 @Column 어노테이션은 생략해도 된다.

@Column

객체의 필드에는 기본자료형 뿐만아니라 참조자료형들이 올 수 있다. 기본자료형들은 직관적으로 어떻게 매핑될지 감이 오지만 참조자료형들은 어떤식으로 매핑이 되는지 궁금할 것이다. 바로 이러한 부분에서 패러다임의 불일치가 발생한 것이라고 생각하면 된다. 여하튼, 차근차근 알아보도록 하자. 이번 포스팅에서 뿐만 아니라 이어질 포스팅에서 모두 설명하도록 하겠다.

@Enumerated

enum 을 매핑할때 사용하는 어노테이션이다.

@Enumerated 의 value 속성 기본값이 ORDINAL 인데, 아쉬운 부분중 하나다. enum 의 값들에 변경이 일어날 경우 ORDINAL 은 안정적이지 못하다. 예를들어
ADMIN, USER 라는 값이 있었는데 추후에 ADMIN, BESTUSER, USER 이런식으로 변경이 일어난다면 ORDINAL 은 이러한 변경사항을 처리할 수 없다. ( 무조건 뒤로 추가할 수 있긴 하겠지만...)

@Transient

Entity 객체의 필드 중 테이블에 매핑시키고 싶지 않은 필드가 있을 경우 사용하는 어노테이션이다.

@Temporal

java.util.Date 를 사용할 때 사용하던 어노테이션으로 날짜 타입 매핑에 이용되었지만 하이버네이트 버전이 올라가면서 LocalDate, LocalDateTime 을 지원함으로 LocalDate, LocalDateTime 을 사용하는 경우 별도로 매핑해주지 않아도 된다.

@Lob

데이터베이스의 BLOB과 CLOB 타입 매핑해주는 어노테이션이다.

기본키 (PK) 매핑

기본키 매핑에 사용되는 어노테이션은 @Id, @GeneratedValue 가 있다.

@Id

PK에 해당할 필드를 지정해 주는 어노테이션이다.

@GeneratedValue

데이터베이스를 사용할때 PK 값을 직접 할당하는 경우보단, DB가 자동생성 해주는 방법을 사용하는 경우가 많다. 그와 관련된 설정을 할때 사용하는 어노테이션이다.
DB가 자동생성 해주는 방법의 경우 DB마다 그 방법이 조금씩 다르고, JPA는 이를 모두 지원하는데 JPA가 제공하는 방법을 살펴보자면 다음과 같다.

• IDENTITY
  데이터 베이스에 위임하는 방식으로, MySQL 의 AutoIncrement 를 생각하면 된다.
• SEQUENCE
  데이터 베이스의 시퀀스 오브젝트를 사용하는 방식으로, Oracle 의 시퀀 스를 생각하면된다. 테이블 마다 시퀀스를 별도로 설정해주고 싶은 경우 @SequenceGenerator 을 사용해 시퀀스를 만들 수 있다.
  시퀀스전랴을 사용할 경우 성능 최적화를 위해 데이터베이스로부터 한 번에 50~100 정도의 값을 한번에 받아와 사용한다. 해당 값의 크기는 allocationsize 속성을 통해 설정한다.
• TABLE
  키 생성용 테이블 사용, 모든 DB에서 사용할 수 있는 방식이지만 이건 쫌.. 성능이 떨어질 수 밖에 없다.
• AUTO
  Dialect(방언) 에 따라 JPA 가 알아서 IDENTIY 전략을 사용하지
  SEQUENCE 아니면 TABLE 을 사용할지 결정해 준다.

권장되는 기본키(식별자)

이 부분은 JPA 와 관련된 부분은 아닙니다.
식별자는 Null 일 수 없고, 유일해야하며 변하지 않아야 한다. 이런 조건을 만족하는 자연키는 찾기 힘들다. 따라서 대체키를 사용하는 방법을 고려해보아야 한다.

• 기본키 ( Primary Key ) : 테이블에서 레코드를 유일하게 식별하는 데 가 장 적합한 후보키(Candidate Key)
• 자연키 ( Natural Key ) : 테이블을 이루는 컬럼들 가운데 의미를 담고 있는 후보키
• 대체키 ( Surrogate Key ) : 테이블을 이루는 컬럼들 가운데 유일하게 식별하기에 적합한 단일 후보키가 존재하지 않을 때, 임의의 식별번호로 이 루어진 후보키를 추가할 수 있는데 이를 대체키라고 한다.

기본키, 자연키, 대체키에 대한 설명은 https://bunhere.tistory.com/45 의 글을 참조 하였습니다.

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

JPA 는 어플리케이션 로딩시점에 DB테이블을 생성하는 기능을 제공한다
해당 기능은 개발시점에 많은 편의성을 제공하지만, 실제 운영시점에는 직접 스키마를 작성하는 것이 BEST PRACTICE 이다. 데이터베이스는 보수적으로 운영되어야 한다는 점을 잊지말자! DDL 자동생성 기능을 사용하다 운영중인 DB인의 데이터가 날라간다던가, 락이 걸리는 대형사고가 발생할 수 있음을 경계해야한다.

• create : 기존테이블 삭제 후, 다시생성

• create-drop : create와 동일하나 종료시점에 테이블 drop

• update : (기존테이블 삭제 x) 추가된 필드를 ALTER 를 통해 추가 (엔- 티티에서 삭제한 필드를 없애지는 않는다. DB의 데이터는 매우 보수적이어야 한다.

• validate : 엔티티와 테이블이 정상 매핑되었는지만 확인

해당 포스팅은 김영한님의 '자바 ORM 표준 JPA 프로그래밍' 강의를 참고하여 작성된 내용입니다.