[자바 ORM 표준 JPA 프로그래밍 - 기본편] 4. 엔티티 매핑

jada·2024년 3월 10일
0

Spring 스터디

목록 보기
23/35

📂엔티티 매핑


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

객체와 테이블 매핑


@Entity

  • @Entity가 붙은 클래스는 JPA가 관리, 엔티티라 한다.

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

  • 주의
    • 기본 생성자 필수(파라미터가 없는 public 또는 protected 생성자)
    • final 클래스, enum, interface, inner 클래스는 엔티티로 사용X
    • DB에 저장할 필드에 final 사용 X

@Table

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




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


• DDL을 애플리케이션 실행 시점에 자동 생성

• 테이블 중심 -> 객체 중심

• 데이터베이스 방언을 활용해서 데이터베이스에 맞는 적절한 DDL 생성

• 이렇게 생성된 DDL은 개발 장비에서만 사용

• 생성된 DDL은 운영서버에서는 사용하지 않거나, 적절히 다듬은 후 사용

속성

주의

  • 운영 장비에는 절대 create, create-drop, update 사용하면 안된다.

    • 운영 상태에서는 데이터가 몇 천만 건 있는 상태. alter를 잘못 치거나 하면 시스템이 중단 상태가 될 수 있다. 따라서 애플리케이션 로딩 시점에 시스템이 자동으로 alter를 쳐준다는 게 굉장히 위험함!
  • 개발 초기 단계는 create 또는 update

  • 테스트 서버는 update 또는 validate

  • 스테이징과 운영 서버는 validate 또는 none

DDL 생성 기능

  • 제약조건 추가: 회원 이름은 필수, 10자 초과X
    • @Column(nullable = false, length = 10)

  • 유니크 제약조건 추가
    • @Table(uniqueConstraints = {@UniqueConstraint( name = "NAME_AGE_UNIQUE",
    columnNames = {"NAME", "AGE"} )})

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




필드와 컬럼 매핑


요구사항 추가

  1. 회원은 일반 회원과 관리자로 구분해야 한다.

  2. 회원 가입일과 수정일이 있어야 한다.

  3. 회원을 설명할 수 있는 필드가 있어야 한다. 이 필드는 길이 제한이 없다.

    매핑 애노테이션 정리

  • @Temporal(TemporalType.TIMESTAMP)
    • 데이터베이스는 TemporalType를 세 가지로 구분. (DATE, TIME, TIMESTAMP(날짜와 시간 모두 사용))
  • varchar를 넘어서는 긴 컨텐츠를 DB에 넣고싶으면 @Lob을 사용한다.
  • @enumerated 를 사용한 enum 타입 필드는 데이터베이스 상에서 varchar로 매핑된다.
  • @Transient를 사용한 필드는 데이터베이스에 저장되지 않는다. (메모리에서만 사용하고 싶은 필드일 때 사용)

  • nullabe(DDL) 한 컬럼에 유니크 제약조건 사용
    • Table(uniqueConstraints = ~ ) 이 방식으로 하면 제약 조건의 이름까지 설정할 수 있어서 더 선호된다.

  • ORDINAL을 사용하면, 나중에 enum을 앞쪽에 추가했을 때 DB상에 값이 0인 enum 컬럼이 여러개가 된다.
    • (예. USER, ADMIN 이었던 enum을 VIP, USER, ADMIN 으로 변경하면, VIP와 USER 모두 DB상에서 0으로 매핑됨.)




기본키 매핑


기본키 매핑 어노테이션

  • @Id

  • @GeneratedValue

기본키 매핑 방법

  • 직접 할당: @Id만 사용

  • 자동 생성 (@GeneratedValue)

    • IDENTITY: 데이터베이스에 위임, MYSQL같은 경우는 AutoIncrement
    • SEQUENCE: 데이터베이스 시퀀스 오브젝트 사용, ORACLE에서 많이 사용
      • @SequenceGenerator 필요
    • TABLE: 키 생성용 테이블 사용, 모든 DB에서 사용
      • @TableGenerator 필요
    • AUTO: DB 방언에 따라 자동 지정, 기본값

📝 - IDENTITY 전략 - 특징

  • 기본키 생성을 데이터베이스에 위임
  • 주로 MySQL, PostgreSQL, SQL Server, DB2에서 사용 (예: MySQL의 AUTO_ INCREMENT)
  • JPA는 보통 트랜잭션 커밋 시점에 INSERT SQL 실행
  • AUTO_INCREMENT는 데이터베이스에 INSERT SQL을 실행한 이후에 ID값을 알 수 있음
  • IDENTITY 전략은 트랜잭션 커밋 시점이 아니라, em.persist() 시점에 즉시 INSERT SQL 실행하고 DB에서 식별자를 조회
    • 영속성 컨텍스트 내 1차 캐시에 저장하기 위해서는 PK값을 알아야 하기 때문!!

📝 - SEQUENCE 전략 - 특징

  • 데이터베이스 시퀀스는 유일한 값을 순서대로 생성하는 특별한 데이터베이스 오브젝트 (예. 오라클 시퀀스)

  • 오라클, PostgreSQL, DB2, H2 데이터베이스에서 사용

📝 - TABLE 전략 - 특징

  • 키 생성 전용 테이블을 하나 만들어서 데이터베이스 시퀀스를 흉내내는 전략

  • 장점: 모든 데이터베이스에 적용 가능

  • 단점: 성능

💖 권장하는 식별자 전략

  • 기본키 제약 조건: null 아님, 유일, 변하면 안된다.
  • 미래까지 이 조건을 만족하는 자연키는 찾기 어렵다. 대리키(대체키)를 사용하자.
    • 예를 들어 주민등록번호도 기본 키로 적절하기 않다.
  • 권장: Long형 + 대체키 + 키 생성전략 사용
    • Auto-increment나 Sequence-object 둘 중에 하나 사용 or UUID나 랜덤값 조합한 회사 내 룰에 따른 값을 사용 권장



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


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

도메인 모델 분석

테이블 설계

엔티티 설계와 매핑

데이터 중심 설계(관계형 DB에 맞춘 설계)의 문제점

  • 현재 방식은 객체 설계를 테이블 설계에 맞춘 형식

  • 테이블의 외래키를 객체에 그대로 가져옴

  • 객체 그래프 탐색이 불가능

  • 참조가 없으므로 UML도 잘못됨 !

결론 : 그래서 연관관계 매핑이 필요하다 !

profile
꾸준히 발전하는 개발자가 되자 !

0개의 댓글