카테고리 없음

JAVA JPA - Entity Mapping

jonghyeon6084 2024. 2. 2. 20:43
728x90

객체와 테이블 매핑

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

@Entity

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

@Entity 속성 정리

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

@Table 속성 정리

  • @Table은 entity와 매핑할 테이블 지정

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

  • DDL을 애플리케이션 실행 시점에 자동 생성
  • 테이블 중심 -> 객체 중심
  • 데이터베이스 방언을 활용해서 데이터베이스에 맞는 적절한 DDL 생성
  • 이렇게 생성된 DDL은 개발 장비에서만 사용
  • 생성된 DDL은 운영서버에는 사용하지 않거나, 적절히 다듬은 후 사용

속성(hidernate.hbm2ddl.auto)

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

DDL 생성 기능

  • DDL 생성 기능은 DDL을 자동 생성할 때만 사용되고, JPA의 실행 로직에는 영향을 주지 않는다.

필드와 컬럼 매핑

만들 예제의 조건

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

매핑 어노테이션 정리

hibernate.hbm2ddl.auto

@Column

@Enumerated

자바 enum 타입을 매핑할 때 사용, ORDINAL 사용 안 하는 게 좋음!!

@Temporal

날짜 타입(java.util.Data, java.util.Calendar)을 매핑할 때 사용

참고 : LocalDatae, LocalDataTime을 사용할 때는 생략 가능

@Lob

데이터베이스 BLOB, CLOB 타입과 매핑

  • @Lob에는 지정할 수 있는 속성이 없다.
  • 매핑하는 필드 타입이 문자면 CLOB, 나머지는 BLOB 매핑
    • CLOB : String, char[], java.sql.CLOB
    • BLOB : byte[], java.sql.BLOB

@Transient

  • 필드 매핑 x
  • 데이터베이스에 저장 x, 조회 x
  • 주로 메모리상에서만 임시로 어떤 값을 보관하고 싶을 때 사용
  • @Transent / private Integer temp;

기본 키 매핑

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

기본 키 매핑 방법

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

직접 할당

  • @Id 사용

IDENTITY 전략 - 특징

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

IDENTITY 전략 - 매핑

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

IDENTITY 전략 - 특징

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

SEQUECE전략 - 매핑

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

SEQUECE전략 - @SequenceGenerator

  • 주의 : allocationSize 기본값 = 50

TABLE 전략

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

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

@TableGenerator - 속성

권장하는 식별자 전략

  • 기본 키 제약 조건 : null 아님, 유일, 변하면 안 된다.
  • 미래까지 이 조건을 만족하는 자연키는 찾기 어렵다. 대리키(대체키)를 사용하자.
  • 예를 들어 주민등록번호도 기본 키로 적절하지 않다.
  • 권장 : Long형 + 대체키 + 키 생성전략 사용

 

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

요구사항 분석

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

기능 목록

  • 회원 기능
    • 회원 등록
    • 회원 조회
  • 상품 기능
    • 상품 등록
    • 상품 수정
    • 상품 조회
  • 주문 기능
    • 상품 주문
    • 주문 내역 조회
    • 주문 취소

도메인 모델 분석

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

테이블 설계

엔티티 설계와 매핑

 

@Entity
@Table(name = "ORDERS")
public class Order {
    @Id
    @GeneratedValue
    @Column(name = "ORDER_ID")
    private Long id;
    @Column(name = "MEMBER_ID")
    private Long memberId;
    //객체지향적이기 위해 바로 위 코드를 아래와 같이 쓸 수 있음.
    private Member member;
    private LocalDateTime orderDate;
    @Enumerated(EnumType.STRING)
    private OrderStatus status;
     ---getter, setter---
 }

이 상황에서 한 가지 예시를 들자면

 Order order = em.find(Order.class, 1L);
Long memberId = order.getMemberId();
// 객체지향적이지 못한 코드
Member member = em.find(Member.class, memberId);
// 객체지향적인 코드
Member findMember = order.getMember();

 

사실 위 Order 클래스를 보면 객체 지향적 코드가 아니라 데이터 중심적인 코드이다.

 

데이터 중심 설계의 문제점

  • 현재 방식은 객체 설계를 테이블 설계에 맞춘 방식
  • 테이블의 외래키를 객체에 그대로 가져옴
  • 객체 그래프 탐색이 불가능
  • 참조가 없으므로 UML도 잘못됨

다음 쓸 블로깅에 개선할 방법을 배워보자.