[SPRING]자바 ORM 표준 JPA 프로그래밍 섹션4 (엔티티 매핑)

💡객체와 테이블 매핑

💻 @Entity

'@Entity' 애노테이션은 클래스가 데이터베이스 테이블에 매핑될 엔티티임을 나타낸다.

이 애노테이션을 사용하면 JPA가 해당 클래스를 엔티티로 관리한다.

 

JPA를 사용해서 테이블과 매핑할 클래스는 @Entity가 필수이다.

 

주의사항

• 기본 생성자가 필수이다. (public 또는 protected).
• final 클래스, enum, interface, inner 클래스에는 사용할 수 없다.
• final 필드를 사용할 수 없다.

속성: name

• JPA에서 사용할 엔티티 이름을 지정한다. 
• 기본값은 클래스 이름을 그대로 사용한다.
• 다른 패키지에 동일한 이름의 엔티티 클래스가 있을 때 충돌을 방지하기 위해 사용된다.
• 같은 클래스 이름이 없으면 가급적 기본값을 사용한다.

@Entity(name = "myMember")
public class Member { ... }

 

💻 @Table

'@Table' 애노테이션은 엔티티와 매핑할 데이터베이스 테이블을 지정한다. 

생략하면 엔티티 이름을 테이블 이름으로 사용한다.

 

속성

• name: 매핑할 테이블의 이름을 지정한다.
• catalog: 데이터베이스에서 catalog를 매핑한다.
• schema: 데이터베이스에서 schema 매핑한다.
• uniqueConstraints: 테이블의 유니크 제약조건을 지정한다. 스키마 자동 생성 시에만 적용된다.

@Entity
@Table(name = "t_member", uniqueConstraints = {@UniqueConstraint(columnNames = {"name"})})
public class Member { ... }

 

 

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

1. 테이블 중심에서 객체 중심으로의 전환:
   • 전통적인 데이터베이스 설계 접근 방식은 테이블 중심이었으나, ORM을 사용함으로써 개발자는 객체 중심의 접근 방식을 취할 수 있게 되었다. 이는 객체 지향 프로그래밍과 데이터베이스 설계 사이의 간극을 줄여 준다.
2. DDL 자동 생성:
   • ORM 프레임워크는 엔티티 클래스와 그 관계들을 분석하여 필요한 테이블, 칼럼, 제약조건(예: 외래 키, 유니크 제약조건) 등의 DDL을 자동으로 생성한다. 이는 데이터베이스 방언을 고려하여, Oracle, MySQL, PostgreSQL 등 다양한 데이터베이스 시스템에 맞는 쿼리 형식으로 출력된다.
3. 개발 환경에서의 사용:
   • 스키마 자동 생성 기능은 주로 개발 초기 단계나 개발 환경에서 유용하다. 개발자는 모델의 변경이 빠르게 반영되는 DDL을 통해 데이터베이스와의 연동을 신속하게 테스트할 수 있다.
4. 운영 환경에서의 사용 제한:
   • 운영 서버에서는 자동 생성된 DDL을 직접 사용하는 것을 피해야 한다. 대신, 개발 환경에서 생성된 DDL을 기반으로 성능 최적화, 보안 강화 및 기타 필요한 수정을 거친 후 운영 데이터베이스에 적용하는 것이 권장된다.

속성

스키마 자동 생성은 persistence.xml 또는 application.yml과 같은 애플리케이션의 설정 파일에서 관련 속성을 설정하여 제어할 수 있다.

<property name="hibernate.hbm2ddl.auto" value="create"/>

• create
  기존 테이블을 삭제 후 새로 생성한다. (DROP + CREATE)
• create-drop
  create와 같으나 애플리케이션을 종료시점에 생성한 테이블을 DROP한다. (DROP + CREATE + DROP)
• update
  데이터베이스 테이블과 엔티티 매핑정보를 비교해서 변경 사항만 수정한다.
  (column 삭제는 반영하지 않는다.)  (운영 DB에는 사용하면 안된다.)
• validate
  엔티티와 테이블이 정상 매핑되었는지만 확인한다. 데이터베이스 테이블과 엔티티 매핑정보를 비교해서 차이가 있으면 경고를 남기고 애플리케이션을 실행하지 않는다.
• none
  자동 생성 기능을 사용하지 않는다. (주석 처리를 한 것과 동일)

주의사항

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

 

💻 DDL 생성 기능

제약조건 추가

• 엔티티의 필드에 다양한 제약조건을 추가할 수 있다. 예를 들어, 회원의 이름이 필수이며 최대 10자를 초과할 수 없도록 설정할 수 있다.

@Column(nullable = false, length = 10)
private String name;

 

유니크 제약조건 추가

• 테이블 수준에서 유니크 제약조건을 추가하여 두 개 이상의 컬럼을 조합한 복합 유니크 인덱스를 생성할 수 있다.

@Table(uniqueConstraints = {@UniqueConstraint(name = "NAME_AGE_UNIQUE", columnNames = {"NAME", "AGE"})})

 

JPA 실행 로직에 영향 없음

• DDL 생성 기능은 데이터베이스 스키마를 생성할 때만 사용되며, JPA의 실행 로직에는 직접적인 영향을 주지 않는다. 런타임에는 엔티티 관리와 쿼리 실행 같은 기능들이 중심이 되며, DDL 생성은 애플리케이션 배포나 초기 설정 단계에서만 관련이 있다.

---

💡필드와 컬럼 매핑

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

    public Member() {
    }
}

 

💻 매핑 어노테이션 정리

 

💻 @Column

1. name:
   • 역할: 필드와 매핑할 테이블의 컬럼 이름을 지정한다.
   • 기본값: 객체의 필드 이름이 사용된다.
2. insertable, updatable:
   • 역할: 엔티티를 데이터베이스에 저장하거나 업데이트할 때 해당 컬럼이 포함될지 여부를 결정한다. (등록, 변경 가능 여부)
   • 기본값: 'true' (등록과 변경이 가능하다).
3. nullable (DDL):
   • 역할: 컬럼이 null 값을 허용할지 여부를 설정한다.
   • 기본값: 'true' (null 허용).
   • 'false'로 설정하면, DDL 생성 시 'NOT NULL' 제약조건이 적용된다.
4. unique (DDL):
   • 역할: 단일 컬럼에 대한 유니크 제약조건을 설정한다.
   • 주의: 복잡한 유니크 조건은 '@Table'의 'uniqueConstraints'를 사용하는 것이 좋다.
   • 이 옵션은 컬럼이 유일해야 함을 나타낸다.
5. columnDefinition (DDL):
   • 역할: 컬럼에 대한 SQL 정의를 직접 제공한다. 이를 통해 기본값 설정, 컬럼 타입 지정 등이 가능하다.
   • 예시: 'columnDefinition = "varchar(100) default 'EMPTY'" 는 기본값을 'EMPTY'로 하는 varchar 컬럼을 생성한다.

@Column(name = "name", columnDefinition = "varchar(100) default 'EMPTY'")
    private String name;

 

 

   6. length (DDL):

• 적용 대상: 'String' 타입의 필드에 사용된다.
• 역할: 문자열 길이 제약조건을 설정한다.
• 기본값: 255

   7. precision, scale (DDL):

• 적용 대상: 주로 'BigDecimal' (또는 'BigInteger') 타입에서 사용된다.
• precision: 소수점을 포함한 전체 숫자의 자릿수를 정의한다.
• scale: 소수점 이하의 자릿수를 정의한다.
• 예시: precision = 19, scale = 2는 최대 19자리 숫자 중 소수점 아래 2자리까지를 허용하는 숫자형 필드를 의미한다. 이 설정은 아주 큰 수나 정밀한 계산이 필요한 경우 사용된다.

 

💻 @Enumerated

@Enumerated는 자바 enum 타입을 매핑할 때 사용된다.

 

1. EnumType.ORDINAL:
   • enum 순서를 데이터베이스에 저장한다. (0,1,2 ....)
   • enum 항목의 위치에 따라 정수 값이 데이터베이스에 저장된다.
2. EnumType.STRING: 
   • enum의 이름을 데이터베이스에 저장한다.
   • enum 항목의 이름을 문자열로 데이터베이스에 저장하며, enum 정의의 변경에 더 유연하다.

그렇다면 EnumType.STRING에 비해 EnumType.ORDINAL이 가지는 단점은 무엇일까?

EnumType.ORDINAL 설정은 열거형의 각 상수가 선언된 순서에 따라 데이터베이스에 정수로 저장된다.

예를 들어

public enum Status {
    OPEN, REVIEW, CLOSED
}

import javax.persistence.Entity;
import javax.persistence.EnumType;
import javax.persistence.Enumerated;
import javax.persistence.Id;

@Entity
public class Task {
    @Id
    private Long id;

    @Enumerated(EnumType.ORDINAL)
    private Status status;
}

 

이렇게 Enum 타입과 엔티티를 정의했다면, 'OPEN'은 0, 'REVIEW'는 1, 'CLOSED'는 2로 데이터베이스에 저장된다.

 

단점 1. 순서 의존성

위와 같이 데이터베이스에 저장했다가,

만약 Enum 상수의 순서를 OPEN, CLOSED, REVIEW 순으로 변경하거나, OPEN과 REVIEW 사이에 새로운 상수 'RESERVE'가 추가된다면 기존에 저장된 데이터의 의미가 완전히 달라지게 된다.

 

단점 2. 가독성 저하

데이터베이스에서 값을 조회할 때 정수 값만 보고는 어떤 상태를 의미하는지 직관적으로 이해하기가 어렵다.

 

 

💻 @Temporal

@Temporal 애노테이션은 자바의 java.util.Date와 java.util.Calendar 타입을 데이터베이스의 날짜 및 시간 타입과 매핑할 때 사용된다. 최신 버전의 하이버네이트는 LocalDate와 LocalDateTime을 자동으로 지원하므로, 이 경우 @Temporal 애노테이션은 필요하지 않다.

 

1. TemporalType.DATE:
   • 오직 날짜만을 저장한다. 데이터베이스의 date 타입과 매핑되며, 시간 정보는 저장되지 않는다. (예: 2013-10-11).
2. TemporalType.TIME:
   • 오직 시간만을 저장한다. 데이터베이스의 time 타입과 매핑되며, 날짜 정보는 저장되지 않는다. (예: 11:11:11).
3. TemporalType.TIMESTAMP:
   • 날짜와 시간을 모두 저장한다. 데이터베이스의 timestamp 타입과 매핑되며, 날짜와 시간 정보가 모두 저장된다. (예: 2013-10-11 11:11:11).

 

💻 @Lob

@Lob 애노테이션은 데이터베이스의 BLOB (Binary Large OBject) 또는 CLOB (Character Large OBject) 타입과 매핑될 때 사용된다. 이 애노테이션은 대용량 데이터를 저장하는 데 적합하며, 매핑할 필드의 데이터 타입에 따라 자동으로 CLOB 또는 BLOB으로 매핑된다.

 

• 속성: @Lob에는 설정할 속성이 없다.
• CLOB 매핑: 문자 데이터를 다룰 때 사용한다. String, char[], java.sql.CLOB 타입의 필드에 사용하면 데이터베이스의 CLOB 타입과 매핑된다.
• BLOB 매핑: 이진 데이터를 다룰 때 사용한다. byte[], java.sql.BLOB 타입의 필드에 사용하면 데이터베이스의 BLOB 타입과 매핑된다.

 

💻 @Transient

@Transient 애노테이션은 특정 필드를 데이터베이스 테이블과 매핑하지 않을 때 사용된다.

이 애노테이션을 사용한 필드는 데이터베이스에 저장되거나 조회되지 않으며, 오직 메모리 상에서만 값을 유지한다.

이는 주로 계산된 값이나 임시 데이터를 저장하는 데 사용되며, 엔티티의 일부로 영속화할 필요가 없는 정보를 다룰 때 유용하다.

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

    private String name; // 데이터베이스에 저장될 필드

    @Transient
    private Integer temp; // 데이터베이스에 저장되지 않을 임시 필드

    // 생성자, 게터, 세터 등 기타 메소드
}

• 필드 매핑 제외: @Transient 애노테이션을 적용한 temp 필드는 데이터베이스 테이블의 어떤 컬럼과도 매핑되지 않는다.
• 데이터 저장 및 조회 제외: 이 필드는 데이터베이스에 저장되거나 조회되지 않으며, 오직 Java 애플리케이션 내에서만 사용된다.
• 용도: 이 필드는 데이터 처리 중 임시로 계산된 값이나 상태 정보 등을 저장하는 데 사용할 수 있으며, 엔티티의 영속화 과정에서 제외된다.

---

💡기본 키 매핑

기본 키 매핑은 엔티티의 식별자를 데이터베이스의 기본 키(primary key)와 매핑하는 방법을 정의한다. JPA에서 이를 구현하기 위해 사용되는 주요 애노테이션은 @Id와 @GeneratedValue이다.

 

💻  직접 할당: @Id 만 사용

@Id는 엔티티 클래스의 필드를 테이블의 기본 키로 지정한다. 이 필드의 값은 엔티티의 식별자 역할을 하며, 각 엔티티 인스턴스를 유일하게 구분한다.

💻  자동 생성: @GeneratedValue 애노테이션

@GeneratedValue 애노테이션은 기본 키의 값을 자동으로 생성하기 위한 전략을 지정한다. 이 애노테이션은 strategy 속성을 통해 다양한 키 생성 전략을 지원한다.

1. IDENTITY: 데이터베이스가 자동으로 키 값을 생성하도록 위임한다. 이 전략은 데이터베이스가 지원하는 auto-increment 기능을 사용한다.
2. SEQUENCE: 데이터베이스의 시퀀스를 사용하여 키 값을 생성한다. 이 전략은 시퀀스 생성기를 정의할 필요가 있으며, 시퀀스의 이름, 초기값, 증가 크기 등을 지정할 수 있다.
3. TABLE: 키 생성 전용 테이블을 사용하여 키 값을 생성합니다. 이 방법은 특정 테이블에서 필요한 키 값을 관리하며, 모든 데이터베이스에 적용 가능하다.
4. AUTO: 플랫폼(데이터베이스 방언)에 따라 최적의 전략(IDENTITY, SEQUENCE, TABLE)을 자동으로 선택한다.

 

💻  IDENTITY

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

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

💻  SEQUENCE

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

• 데이터베이스 시퀀스는 유일한 값을 순서대로 생성하는 특별한 데이터베이스 오브젝트이다. 
• Oracle, PostgreSQL, DB2 등에서 사용된다.
• 'allocationSize'를 1로 설정하면, 시퀀스 값이 하나씩 증가한다.

@SequenceGenerator 속성

@SequenceGenerator는 데이터베이스의 시퀀스를 사용하여 식별자를 생성할 때 사용된다.

• name: 식별자 생성기의 이름을 지정한다. 이 이름은 @GeneratedValue에서 generator 속성으로 참조된다.
• sequenceName: 데이터베이스에 등록되어 있는 실제 시퀀스의 이름이다. 기본값은 hibernate_sequence이다.
• initialValue: 시퀀스 DDL을 생성할 때 시퀀스의 시작 숫자를 지정한다. 기본값은 1입니다.
• allocationSize: 시퀀스를 호출할 때마다 증가하는 수를 지정합니다. 이는 성능 최적화에 사용된다. 기본값은 50이지만, 데이터베이스 시퀀스 값이 하나씩 증가하도록 설정되어 있다면 1로 설정해야 한다.
• catalog, schema: 시퀀스가 존재하는 데이터베이스의 카탈로그 또는 스키마를 지정할 수 있다.

💻  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",
    pkColumnName = "sequence_name",
    valueColumnName = "next_val",
    pkColumnValue = "MEMBER_SEQ",
    allocationSize = 1
)
public class Member {
    @Id
    @GeneratedValue(strategy = GenerationType.TABLE, generator = "MEMBER_SEQ_GENERATOR")
    private Long id;
}

• 키 생성 전용 테이블을 하나 만들어서 데이터베이스 시퀀스를 흉내내는 전략이다.
• 모든 데이터베이스에 적용가능하다.
• 다소 성능이 떨어질 수 있다.

@TableGenerator 속성 

@TableGenerator는 키 생성 전용 테이블을 사용하여 식별자를 생성한다.

• name: 식별자 생성기의 이름을 지정한다. 이 이름은 @GeneratedValue에서 generator 속성으로 참조된다.
• table: 키를 생성하기 위해 사용될 테이블의 이름이다. 기본값은 hibernate_sequences이다.
• pkColumnName: 테이블에서 식별자 이름을 저장하는 컬럼의 이름입니다. 기본값은 sequence_name이다.
• valueColumnName: 식별자 값이 저장될 컬럼의 이름입니다. 기본값은 next_val이다.
• pkColumnValue: 특정 엔티티의 키를 생성하기 위한 값의 이름이다. 주로 엔티티 이름을 사용한다.
• initialValue: 식별자의 초기 값으로, 마지막으로 생성된 값이 기준이 된다. 기본값은 0이다.
• allocationSize: 한 번의 호출에 증가하는 식별자의 수이다. 기본값은 50이다.
• catalog, schema: 키 생성 테이블이 위치하는 데이터베이스의 카탈로그 또는 스키마를 지정할 수 있다.
• uniqueConstraints: 유니크 제약 조건을 지정할 수 있다.

 

💻  권장하는 식별자 전략

기본 키를 설계할 때는 몇 가지 중요한 제약 조건을 고려해야 한다.

• 키는 null이 아니어야 하며, 유일해야 하고, 시간이 지나도 변하지 않아야 한다.
• 그러나 이 조건들을 만족하는 자연키를 찾기는 종종 어렵다. 자연키란 엔티티에서 자연스럽게 식별자 역할을 할 수 있는 속성을 의미한다.
• 예를 들어, 주민등록번호와 같은 데이터가 자연키에 해당할 수 있으나, 개인 정보 보호 문제나 키 값의 변동 가능성 때문에 권장되지 않는다.

따라서 !!!! 대리키(대체키)를 사용하는 것이 좋다.

대체키 사용의 장점:

1. 변하지 않음: 대리키는 생성된 후에 변경되지 않으므로 엔티티의 식별자로서의 안정성이 보장된다.
2. 유일성 보장: 시스템이 관리하는 키이므로 중복의 우려가 없다.
3. 개인정보 보호: 비즈니스와 관련된 데이터가 아니므로 개인 정보 보호와 관련된 문제에서 자유롭다.

키 생성 전략:

• Long형 ID 사용: 일반적으로 Long 타입의 숫자를 사용하여 대리키를 구현한다. 이는 대부분의 데이터베이스 시스템에서 효과적으로 처리할 수 있으며, 충분히 큰 범위를 제공하여 확장성 문제를 방지할 수 있다.
• 자동 키 생성: @GeneratedValue 애노테이션을 사용하여 IDENTITY, SEQUENCE 또는 TABLE 전략 중 하나를 선택하여 키를 자동으로 생성할 수 있다. 각 전략은 데이터베이스 시스템과 애플리케이션의 특성에 따라 선택된다.