TIL_221012_자바 ORM 표준 JPA 프로그래밍_03 정리

5. 엔티티 매핑

(1) 객체와 테이블 매핑

• @Entity
  • @Entity가 붙은 클래스는 JPA가 관리, 엔티티라 함
  • 기본 생성자 필수 (파라미터가 없는 public 혹은 protected 생성자)
  • final 클래스, enum, interface, inner 클래스 사용 x
  • 저장할 필드에 final 사용 x
• @Table
  • 엔티티와 매핑할 테이블 지정
  • name : 매핑할 테이블 이름
  • catalog : 데이터베이스 catalog 매핑
  • schema : 데이터베이스 schema 매핑
  • uniqueConstraints(DDL) : DDL 생성 시에 유니크 제약 조건 생성

(2) 데이터베이스 스키마 자동 생성

• DDL을 애플리케이션 실행 시점에 자동 생성
• 테이블 중심 -> 객체 중심
• 데이터베이스 방언을 활용, 데이터베이스에 맞는 적절한 DDL을 생성
• 이렇게 생성된 DDL은 개발 장비에서만 사용
• 생성된 DDL은 운영 서버에서는 사용하지 않거나, 적절히 다듬은 후 사용
• 데이터베이스 스키마 자동 생성 - 속성 (hibernate.hbm2ddl.auto)
  (gradle application.yml 에서는 hibernate.ddl-auto:)
  • create : 기존 테이블 삭제 후 다시 생성 (DROP + CREATE)
  • create-drop : create와 같으나 종료 시점에 테이블 DROP
  • update : 변경(추가)분만 반영 (ALTER TABLE, 운영 DB에는 사용하면 안됨)
  • validate : 엔티티와 테이블이 정상 매핑되었는지만 확인
  • none : 사용하지 않음
• 주의사항 (중요)
  • 운영 장비에는 절대 create, create-drop, update를 사용하면 안됨
  • 개발 초기 단계는 create 또는 update
  • 테스트 서버는 update 또는 validate
  • 스테이징과 운영 서버는 validate 또는 none
• DDL 생성 기능
  • 제약조건 추가 / 유니크 제약조건 추가
  • DDL 생성 기능은 DDL을 자동 생성할 때만 사용되고 JPA의 실행 로직에는 영향을 주지 않음

(3) 필드와 컬럼 매핑

• 매핑 어노테이션 정리
  • @Column : 컬럼 매핑
  • @Temporal : 날짜 타입 매핑
  • @Enumerated : enum 타입 매핑
  • @Lob : BLOB, CLOB 매핑
  • @Transient : 특정 필드를 컬럼에서 제외
• @Column
  • name : 필드와 매핑할 테이블의 컬럼 이름 (기본값 : 객체의 필드 이름)
  • insertable, updatable : 등록, 변경 가능 여부 (기본값 : TRUE)
  • nullable(DDL) : null값의 허용 여부 설정
  • unique(DDL) : 한 컬럼에 간단히 유니크 제약 조건을 걸 때 사용 (@Table의 uniqueConstraints와 같음)
  • columnDefinition(DDL) : 데이터베이스 컬럼 정보를 직접 줄 수 있음 (필드의 자바 타입, 방언 정보 활용)
  • length(DDL) : 문자 길이 제약 조건, String 타입에만 사용 (기본값 : 255)
  • precision, scale(DDL) : BigDecimal 타입에서 사용 (BigInteger에서도 사용 가능)
    precision은 소숫점을 포함한 전체 자릿수를, scale은 소숫의 자릿수. double, float 타입에는 사용 x, 정밀한 소수 다룰 때에만 사용
• @Enumerated : 자바의 enum 타입을 매핑할 때 사용, ORDINAL 사용하지 말 것!
  • EnumType.ORDINAL : enum 순서를 DB에 저장 (기본값)
  • EnumType.STRING : enum 이름을 DB에 저장
• @Temporal : LocalDate, LocalDateTime을 사용할 때엔 생략 가능
• @Lob : 지정할 수 있는 속성이 없음, 매핑 필드 타입이 문자면 CLOB, 나머지는 BLOB 매핑

(4) 기본 키 매핑

• 직접 할당 : @Id만 사용
• 자동 생성 : @GeneratedValue
  • IDENTITY : 데이터베이스에 위임, MySQL
  • SEQUENCE : 데이터베이스 시퀀스 오브젝트 사용, ORACLE (@SequenceGenerator 필요)
  • TABLE : 키 생성용 테이블 사용, 모든 DB에서 사용 (@TableGenerator 필요)
  • AUTO : 방언에 따라 자동 지정, 기본값
• IDENTITY : 기본 키 생성을 데이터베이스에 위임 (MySQL, PostgreSQL, SQL Server 등)
  • MySQL의 AUTO_INCREMENT이 대표적
  • JPA는 보통 트랜잭션 커밋 시점에 INSERT SQL 실행
  • AUTO_INCREMENT는 데이터베이스에 INSERT SQL 실행 한 후에 ID 값을 알 수 있음
    -> 즉 트랜잭션 처리가 되지 않으면 INSERT SQL이 실행되지 않아 ID 값을 알 수 없게 됨
  • 따라서 IDENTITY 전략은 커밋 시점이 아닌, em.persist() 시점에 즉시 INSERT SQL 실행하고 DB에서 식별자 조회

@Entity
public class Member {

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

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

@Entity
@SequenceGenerator(
		name = “MEMBER_SEQ_GENERATOR",
        sequenceName = “MEMBER_SEQ", //매핑할 데이터베이스 시퀀스 이름
        initialValue = 1, allocationSize = 1)
        // 시퀀스 생성 시 초기값, 시퀀스 1회 호출 시 증가값
public class Member {

	@Id
    @GeneratedValue(strategy = GenerationType.SEQUENCE,
    		generator = "MEMBER_SEQ_GENERATOR")
    private Long id; 

• TABLE : 키 생성 전용 테이블을 만들어서 데이터베이스 시퀀스를 흉내냄
  • 장점 : 모든 데이터베이스에 적용 가능
  • 단점 : 성능 (그래서 잘 안 씀)
• 권장하는 식별자 전략
  • 기본 키 제약 조건 : NULL 아님, 유일, 변하면 안됨
  • 미래까지 이 조건을 만족하는 자연키는 찾기 어려움, 대리키를 사용
  • 권장 : Long형 + 대체키 + 키 생성전략 사용 (비즈니스와 관련된 것, 예를 들어 주민등록번호 등...을 기본 키로 가져오지 말 것)

(5) 실전 예제

• 회원은 상품을 주문할 수 있음
• 주문 시 여러 종류의 상품을 선택할 수 있음
• 기능
  • 회원 기능 (회원 등록, 조회)
  • 상품 기능 (상품 등록, 수정, 조회)
  • 주문 기능 (상품 주문, 주문 내역 조회, 주문 취소)
• 도메인 모델 분석
  • 회원과 주문의 관계 : 회원은 여러번 주문할 수 있음 (일대다)
  • 주문과 상품의 관계 : 주문할 때 여러 상품 선택 가능, 반대로 같은 상품도 여러 번 주문 될 수 있음 -> 주문상품이라는 모델을 만들어 다대다 관계를 일다대, 다대일 관계로 풀어냄
    
    
    
• 데이터 중심 설계의 문제점
  • 현재 방식은 객체 설계를 테이블 설계에 맞춘 방식
  • 테이블의 외래키를 객체에 그대로 가져옴
  • 객체 그래프 탐색이 불가능
  • 참조가 없으므로 UML도 잘못됨