목차

  • 기본값 타입
  • 임베디드 타입(복합 값 타입)
  • 값 타입과 불변 객체
  • 값 타입의 비교
  • 값 타입 컬렉션
  • 실전 예제 - 6. 값 타입 매핑

 

 

기본값 타입


JPA의 데이터 타입 분류

  • 엔티티 타입
    • @Entity로 정의하는 객체
    • 데이터가 변해도 식별자로 지속해서 추적 가능
    • 예) 회원 엔티티의 키나 나이 값을 변경해도 식별자로 인식 가능
  • 값 타입
    • int, Integer, String처럼 단순히 값으로 사용하는 자바 기본 타입이나 객체
    • 식별자가 없고 값만 있으므로 변경시 추적 불가
    • 예) 숫자 100을 200으로 변경하면 완전히 다른 값으로 대체

 

값 타입 분류

  • 기본값 타입
    • 자바 기본 타입 (int, double)
    • 래퍼 클래스 (Integer, Long)
    • String
  • 임베디드 타입(embedded type, 복합 값 타입)
    • x,y 좌표 같은 경우
  • 컬렉션 값 타입(collection value type)

 

기본값 타입

  • 예) int age, String name
  • 생명 주기를 엔티티의 의존
    • 예) 회원을 삭제하면 이름, 나이 필드도 함께 삭제
  • 값 타입은 공유하면 X
    • 예) 회원 이름 변경시 다른 회원의 이름도 함꼐 변경되면 안됨

 

참고 : 자바의 기본 타입은 절대 공유 X

  • int, double 같은 기본 타입(primitive type)은 절대 공유 X
  • 기본 타입은 항상 값을 복사함
  • Integer같은 래퍼 클래스나 String 같은 특수한 클래스는 공유 가능한 객체이지만 변경 X

 

 

임베디드 타입 (복합 값 타입)


임베디드 타입

  • 새로운 값 타입을 직접 정의할 수 있음
  • JPA는 임베디드 타입(embedded type)이라 함
  • 주로 기본 값 타입을 모아서 만들어서 복합 값 타입이라고도 함
  • int, String과 같은 값 타입

 

임베디드 타입

  • 회원 엔티티는 이름, 근무 시작일, 근무 종료일, 주소 도시, 주소 번지, 주소 우편번호를 가진다.

  • 회원 엔티티는 이름, 근무 기간, 주소를 가진다.

 

임베디드 타입 사용법

  • @Embeddeable : 값 타입을 정의하는 곳에 표시
  • @Embedded : 값 타입을 사용하는 곳에 표시
  • 기본 생성자 필수

 

임베디드 타입의 장점

  • 재사용
  • 높은 응집도
  • Perioid.isWork() 처럼 해당 값 타입만 사용하는 의미있는 메소드를 만들 수 있음
  • 임베디드 타입을 포함한 모든 값 타입은 값 타입을 소유한 엔티티에 생명주기를 의존함

 

임베디드 타입과 테이블 매핑

 

임베디드 타입과 테이블 매핑

  • 임베디드 타입은 엔티티의 값일 뿐이다.
  • 임베디드 타입을 사용하기 전과 후에 매핑하는 테이블은 같다.
  • 객체와 테이블을 아주 세밀하게(find-grained) 매핑하는 것이 가능
  • 잘 설계한 ORM 애플리케이션은 매핑한 테이블의 수 보다 클래스의 수가 더 많음

 

임베디드 타입과 연관관계

 

@AttributeOverride : 속성 재정의

  • 한 엔티티에서 같은 값 타입을 사용하면?
  • 컬럼 명이 중복 됨
  • @AttributeOverrides, @AttributeOverride를 사용해서 컬럼 명 속성을 재정의

@AttributeOverrides, @AttributeOverride 예시

 

 

 

값 타입과 불변 객체


값 타입은 복잡한 객체 세상을 조금이라도 단순화하려고 만든 개념이다. 따라서 값 타입은 단순하고 안전하게 다룰 수 있어야 한다.

 

값 타입 공유 참조

  • 임베디드 타입 같은 값 타입을 여러 엔티티에서 공유하면 위험함
  • 부작용 (side effect) 발생

  • 예시

member1의 city만 바꾸고싶었지만, member2도 변경되기 때문에 update쿼리문이 두번 나가는 것을 볼 수 있다.

  • 해결 방법
    • 이렇게 값을 공유하고 싶을 때는 임베디드가 아닌 엔티티로 해주어야 합니다. 

 

값 타입 복사

  • 값 타입의 실제 인스턴스인 값을 공유하는 것은 위험
  • 대신 값(인스턴스)를 복사해서 사용

값을 복사해서 사용하는 경우, update 쿼리문이 한번만 나가 의도치 않은 업데이트 쿼리문이 나가지 않습니다.

 

객체 타입의 한계

  • 항상 값을 복사해서 사용하면 공유 참조로 인해 발생하는 부작용을 피할 수 있다.
  • 문제는 임베디드 타입처럼 직접 정의한 값 타입은 자바의 기본 타입이 아니라 객체 타입이다.
  • 자바 기본 타입에 값을 대입하면 값을 복사한.
  • 객체 타입은 참조 값을 직접 대입하는 것을 막을 방법이 없다.
  • 객체의 공유 참조는 피할 수 없다.

기본 타입은 타입의 값을 복사해서 넘기지만, 객체 타입은 참조 값을 전달하기 때문에 값 변경시 a와 b모두 변경이 됩니다. 

 

 

불변 객체

  • 객체 타입을 수정할 수 없게 만들면 부작용을 원천 차단
  • 값 타입은 불변 객체(immutable object)로 설계해야한다.
  • 불변 객체 : 생성 시점 이후 절대 값을 변경할 수 없는 객체
  • 생성자로만 값을 설정하고 수정자(Setter)를 만들지 않으면 됨 (또는 setter를 public이 아닌 private로 선언)
  • 참고 : Integer, String은 자바가 제공하는 대표적인 불변 객체 

불변이라는 작은 제약으로 부작용이라는 큰 재앙을 막을 수 있다.

 

 

 

값 타입의 비교


값 타입의 비교

  • 값 타입 : 인스턴스가 달라도 그 안에 값이 같으면 같은 것으로 봐야 함

 

값 타입의 비교

  • 동일성(identity) 비교 : 인스턴스의 참조 값을 비교, == 사용
  • 동등성(equivalence) 비교 : 인스턴스의 값을 비교, equals()
  • 값 타입은 a.equals(b)를 사용해서 동등성 비교를 해야 함
  • 값 타입의 equals() 메소드를 적절하게 재정의(주로 모든 필드 사용)

 

 

값 타입 컬렉션


값 타입 컬렉션

위의 Member 엔티티의 경우 1: N의 개념이기 때문에 별도의 테이블을 만들어주어야 관리가 가능합니다.

 

값 타입 사용 법

 

값 타입 컬렉션

  • 타입을 하나 이상 저장할 때 사용
  • @ElementCollection, @CollectionTable 사용
  • 데이터베이스는 컬렉션을 같은 테이블에 저장할 수 없다. (정석적으로 불가능)
  • 컬렉션을 저장하기 위한 별도의 테이블이 필요함

 

값 타입 컬렉션 사용

  • 값 타입 조회 예제
    • 값 타입 컬렉션도 지연 로딩 전략 사용 (해당 컬럼에 접근할 때 select 쿼리문이 나간다.)
  • 참고 : 값 타입 컬렉션은 영속성 전에(Cascade) + 고아 객체 제거 기능을 필수로 가진다고 볼 수 있다.

 

값 타입 컬렉션의 제약사항

  • 값 타입은 엔티티와 다르게 식별자 개념이 없다.
  • 값은 변경하면 추적이 어렵다.
  • 값 타입 컬렉션에 변경 사항이 발생하면, 주인 엔티티와 연관된 모든 데이터를 삭제하고, 값 타입 컬렉션에 있는 현재 값을 모두 다시 저장한다. (매우 비효율적인데...) - 역시나 쓰면 안된다고 한다.
  • 값 타입 컬렉션을 매핑하는 테이블은 모든 컬럼을 묶어서 기본키를 구성해야 함 : Null 입력 X, 중복 저장 X

 

값 타입 컬렉션 대안

  • 실무에서는 상황에 따라 값 타입 컬렉션 대신에 일대다 관계를 고려
  • 일대다 관계를 위한 엔티티를 만들고, 여기에서 값 타입을 사용
  • 영속성 전이(Cascade) + 고아 객체 제거를 사용해서 값 타입 컬렉션 처럼 사용
  • EX) AddressEntity

 

 

 

 

실전 예제 6 - 값 타입 매핑


 

Address 임베디드를 추가해서 변경

 

 

 

 

 

 

출처

 

자바 ORM 표준 JPA 프로그래밍 - 기본편 - 인프런 | 강의

JPA를 처음 접하거나, 실무에서 JPA를 사용하지만 기본 이론이 부족하신 분들이 JPA의 기본 이론을 탄탄하게 학습해서 초보자도 실무에서 자신있게 JPA를 사용할 수 있습니다., - 강의 소개 | 인프런

www.inflearn.com

 

 

목차

  • 프록시
  • 즉시 로딩과 지연 로딩
  • 지연 로딩 활용
  • 연속성 전이 : CASECADE
  • 고아 객체
  • 연속성 전이 + 고아 객체, 생명주기
  • 실전 예제 - 5. 연관관계 관리

 

 

프록시


Member를 조회할 때 Team도 함께 조회해야 할까?

결론적으로 비즈니스 로직에 따라 다를 것이다. 멤버를 가져왔을 때 팀을 100% 사용한다고 할 때는 함께 조회하는 게 이득일 수 있지만, 팀을 20% 사용한다고 할 때는 필요할 때 팀 데이터를 가져오는게 이득일 수 있다.

 

JPA에서는 위의 문제점을 지연로딩과 프록시로 기가막히게 처리한다고 한다.

 

 

프록시 기초

  • em.find() vs em.getReference()
  • em.find() : 데이터베이스를 통해서 실제 엔티티 객체 조회
  • em.getReference() : 데이터베이스 조회를 미루는 가짜(프록시) 엔티티 객체 조회
    • DB 쿼리가 나가지 않는데 조회가 되는 것
    • 실제로 해보니 getReference 시점에 쿼리가 나가지 않고 해당 객체를 사용할 때 쿼리가 나감.

getReference로 가져온 객체는 .getClass()로 네이밍 조회 시에 Hibernate에서 제공해주는 프록시 객체인 것을 알 수 있습니다.

 

 

프록시 특징

  • 실제 클래스를 상속 받아서 만들어짐 (hibernate가 내부적으로 프록시 라이브러리를 통해 만들어 냄)
  • 실제 클래스와 겉 모양이 같다.
  • 사용하는 입장에서는 진짜 객체인지 프록시 객체인지 구분하지 않고 사용하면 됨. (이론상)

  • 프록시 객체는 실제 객체의 참조(targer)을 보관
  • 프록시 객체를 호출하면 프록시 객체는 실제 객체의 메소드 호출 (여기서 DB에 쿼리가 나감)

 

프록시 객체의 초기화

Member member = em.getReference(Member.class, "id1");
member.getName();

getName시 프록시 객체가 하는 작업

 

 

프록시의 특징

  • 프록시 객체는 처음 사용할 때 한 번만 초기화
  • 프록시 객체를 초기화 할 때, 프록시 객체가 실제 엔티티로 바뀌는 것은 아님, 초기화되면 프록시 객체를 통해서 실제 엔티티에 접근 가능
  • 프록시 객체는 원본 엔티티를 상속 받음, 따라서 타입 체크시 주의해야함 (== 비교 실패, 대신 instance of 사용)
    • instanceof 사용법 : 객체 instanceof 클래스명 
  • 영속성 컨텍스트에 찾는 엔티티가 이미 있으면 em.getReference()를 호출해도 실제 엔티티 반환
    • getReference 전 find로 같은 객체를 찾아놓았다면 실제 엔티티 반환
    • getReference 전 getReference로 같은 객체를 찾아놓았다면 프록시 객체 반환
    • getReference -> find가 같은 데이터일 때 find에서도 프록시 반환
      • -->> 이렇게까지 하는 이유는 JPA에서는 어떻게든 ==비교 시에 같도록 나오게하려고 함.
  • 영속성 컨텍스트의 도움을 받을 수 없는 준영속 상태일 때, 프록시를 초기화하면 문제 발생 (하이버네이트는 org.hibernate.LazuInitializationException 예외를 터트림) - 영속성 컨텍스트에 없기 때문에 초기화할 수 없다는 뜻
    • em.detach(객체) or em.close()

 

프록시 확인

  • 프록시 인스턴스의 초기화 여부 확인
    • emf.getPersistenceUnitUtil().isLoaded(Object entity)
  • 프록시 클래스 확인 방법
    • entity.getClass().getName() 출력
  • 프록시 강제 초기화
    • org.hibernate.hibernate.initialize(entity)
  • 참고 : JPA 표준은 강제 초기화 없음
    • 강제 호출 : member.getName()

 

 

 

즉시 로딩과 지연 로딩


Member를 조회할 때 Team도 함께 조회해야 할까?

이것은 비즈니스 로직에 따라 다르지만, 단순히 member 정보만 조회하는 비즈니스 로직에서는 Team에 대한 쿼리문을 날릴 필요가 없다.

 

지연 로딩 LAZY를 사용해서 프록시로 조회

fetch = FetchType.LAZY로 조회하는 경우 Member를 조회할 때, Team에 대한 쿼리가 나가지 않는 것을 볼 수 있습니다.

 

findMember.getTeam을 해서 Team 객체를 가져오면 쿼리문을 보내지 않고, 프록시 객체를 가져오는 것을 볼 수 있습니다. 후에 프록시 객체의 접근해 데이터를 가져올 때 프록시 객체가 진짜 객체를 필요로 하기 때문에 쿼리문을 보내고, 데이터를 가져오는 것을 볼 수 있습니다.

 

지연 로딩

지연 로딩으로 했을 때

 

지연 로딩 LAZY를 사용해서 프록시로 조회

Team team = member.getTeam(); // 쿼리가 나가지 않음 (프록시 객체 할당)

team.getName(); // 실제 team을 사용하는 시점에 초기화 (쿼리가 나감)

 

 

즉시 로딩

Member를 가져올 때 Team을 자주 함께 사용할 때 사용하면 쿼리 한번으로 조회가 되기때문에 좋은 방법입니다.

EAGER

LAZY 테스트 할 때와 같은 코드로 EAGER일 때 실행해 보았습니다. 출력된 쿼리문으로 Member와 Team 객체를 한 번의 쿼리로 조회하는 것을 볼 수 있습니다. LAZY는 Member->Team의 플로우에서 두번 쿼리문을 날리는 것에 비해 효율적으로 보입니다. 가져온 Team의 객체는 프록시 객체가 아닌 진짜 객체를 가져온 것을 볼 수 있습니다.

 

즉시 로딩

Member 객체를 가져올 때 진짜 Team 객체를 가져옴

 

즉시 로딩(EAGER), Member조회 시 항상 Team도 조회

JPA 구현체는 가능하면 조인을 사용해서 SQL 한 번에 함께 조회

 

 

프록시와 즉시로딩 주의

  • 가급적 지연 로딩만 사용 (특히 실무에서)
  • 즉시 로딩을 적용하면 예상하지 못한 SQL이 발생하기 때문 (2개일 땐 별다른 차이가 없지만, 5개 아니 더 많은 구조들에서 문제가 생깁니다.)
  • 즉시 로딩은 JPQL에서 N+1 문제를 일으킨다. (N+1문제란, 처음 쿼리 1개를 날렸는데 추가 쿼리가 N개가 나간다.)
  • @ManyToOne, @OneToOne은 기본이 즉시 로딩
    -> LAZY로 설정
  • @OneToMany, @ManyToMany는 기본이 지연 로딩

EAGER의 경우 Member를 조회할 때, Member마다 Team 쿼리를 또 날린다.
LAZY의 경우 JPQL으로 요청한 쿼리만 나간다.

 

지연 로딩 활용

  • Member와 Team은 자주 함께 사용 -> 즉시 로딩
  • Member와 Order는 가끔 사용 -> 지연 로딩
  • Order와 Product는 자주 함께 사용 -> 즉시 로딩
  • 위의 설명은 이론적인 것, 실무에서는 모두 지연 로딩으로 해야함.

 

지연 로딩 활용 - 실무

  • 모든 연관관계에 지연 로딩을 사용해라!
  • 실무에서 즉시 로딩을 사용하지 마라!
  • JPQL fetch 조인이나, 엔티티 그래프 기능을 사용해라! (뒤에서 설명)
  • 즉시 로딩은 상상하지 못한 쿼리가 나간다.

 

 

영속성 전이 : CASCADE와 고아 객체


영속성 전이 : CASCADE

  • 특정 엔티티를 영속 상태로 만들 때 연관된 엔티티도 함께 영속 상태로 만들고 싶을 때
  • 예 : 부모 엔티티를 저장할 때 자식 엔티티도 함께 저장

 

영속성 전이 : 저장

연관관계의 주인을 저장할 때, 연관된 객체를 모두 저장하는 것을 cascade라고 한다.

 

cascade가 없을 땐 연관관계의 주인을 저장할 때, 연관관계의 주인만 DB에 insert 쿼리문이 나가며 저장된다. 아래는 위의 코드로 실행했을 때의 출력되는 쿼리문.

 

하지만 cascade를 all로 설정하면 연관관계의 주인을 저장할 때에는 연관관계의 주인 뿐만이 아닌 하위 객체들 모두 DB에 insert 쿼리문이 나가며 저장된다. 아래는 위의 코드로 실행했을 때의 출력되는 쿼리문.

 

영속성 전이 : CASCADE - 주의!

  • 영속성 전이는 연관관계를 매핑하는 것과 아무 관련이 없음
  • 엔티티를 영속화할 때 연관된 엔티티도 함께 영속화하는 편리함을 제공할 뿐 
  • 위의 경우처럼 parent -> child일 때, child와 다른 객체가 연관관계가 없다면 cascade를 사용해도 되지만 child에 또 다른 객체가 연관관계가 있다면 사용하면 안된다고 합니다. (이유는 알게되면 정리)

 

CASCADE의 종류

  • ALL : 모두 적용
  • PERSIST : 영속
  • REMOVE : 삭제
  • MERGE : 병합
  • REFRESH : REFRESH
  • DETACH : DETACH

 

 

고아 객체

  • 고아 객체 제거 : 부모 엔티티와 연관관계가 끊어진 자식 엔티티를 자동으로 삭제
  • orphanRemoval = true
  • Parent parent1 = em.find(Parent.class, id);
    parent1.getChildren().remove(0);
    // 자식 엔티티를 컬렉션에서 제거
  • DELETE FROM CHILD WHERE ID = ?

 

고아 객체 - 주의

  • 참조가 제거된 엔티티는 다른 곳에서 참조하지 않는 고아 객체로 보고 삭제하는 기능
  • 참조하는 곳이 하나일 때 사용해야 함!
  • 특정 엔티티가 개인 소유할 때 사용
  • @OneToOne, @OneToMany만 가능
  • 참고 : 개념적으로 부모를 제거하면 자식은 고아가 된다. 따라서, 고아 객체 제거 기능을 활성화 하면, 부모를 제거할 때 자식도 함께 제거된다. 이것은 CascaseType.REMOVE처럼 동작한다.

 

영속성 전이 + 고아 객체, 생명주기

  • CascadeType.ALL + orphanRemoval=true
  • 스스로 생명주기를 관리하는 엔티티는 em.persist()로 영속화, em.remove()로 제거
  • 두 옵션을 모두 활성화 하면 부모 엔티티를 통해서 자식의 생명 주기를 관리할 수 있음
  • 도메인 주도 설계(DDD)의 Aggregate Root개념을 구현할 때 유용 (나중에 찾아 보자)
 

DDD, Aggregate Root 란?

이번에 알아볼 것은, DDD란? Domain이란? Domain Model이란? DDD가 필요한 이유 DDD와 Aggregate Root DDD의 특징과 이유 간단히 영속성 전이, 고아 객체와의 연관 DDD(Domain Driven Design)란? 도메인 중심으로..

eocoding.tistory.com

 

 

실전 예제 5 - 연관관계 관리


글로벌 패치 전략 설정

  • 모든 연관관계를 지연 로딩으로
  • @ManyToOne, @OneToOne은 기본이 즉시 로딩이므로 지연 로딩으로 변경

 

영속성 전이 설정

  • Order -> Delivery를 영속성 전이 ALL 설정
    • 주문을 생성할 때 배송정보도 함께 저장하겠다는 뜻
  • Order -> OrderItem을 영속성 전이 ALL 설정
    • 주문을 생성할 때 주문아이템도 함께 저장하겠다는 뜻

 

 

 

 

 

 

출처

 

자바 ORM 표준 JPA 프로그래밍 - 기본편 - 인프런 | 강의

JPA를 처음 접하거나, 실무에서 JPA를 사용하지만 기본 이론이 부족하신 분들이 JPA의 기본 이론을 탄탄하게 학습해서 초보자도 실무에서 자신있게 JPA를 사용할 수 있습니다., - 강의 소개 | 인프런

www.inflearn.com

 

목차

  • 상속관계 매핑
  • @MappedSuperclass
  • 실전 예제

 

상속관계 매핑


상속관계 매핑

  • 관계형 데이터베이스는 상속 관계 X
  • 슈퍼타입 서브타입 관계라는 모델링 기법이 객체 상속과 유사
  • 상속관계 매핑 : 객체의 상속과 구조와 DB의 슈퍼타입 서브타입 관계를 매핑
  • 슈퍼타입 서브타입 논리 모델을 실제 물리 모델로 구현하는 방법
    • 각각 테이블로 변환 -> 조인 전략
    • 통합 테이블로 변환 -> 단일 테이블 전략
    • 서브타입 테이블로 변환 -> 구현 클래스마다 테이블 전략

 

 

주요 어노테이션

  • Inheritance(strategy = InheritanceType.XXX)
    • JOINED : 조인 전략
    • SINGLE_TABLE : 단일 테이블 전략
    • TABLE_PER_CLASS : 구현 클래스마다 테이블 전략
  • @DiscriminatorColumn(name = "DTYPE")
    • 해당 컬럼에 DTYPE이 생기게 되고, value는 상속된 객체의 엔티티 명이 들어갑니다.
  • @DiscriminatorValue("XXX")
    • 엔티티 명을 바꿀 수 있음, 자식 객체에 부여함

 

조인 전략

  • 장점
    • 테이블 정규화
    • 외래 키 참조 무결성 제약조건 활용가능
    • 저장공간 효율화
  • 단점
    • 조회시 조인을 많이 사용, 성능 저하
    • 조회 쿼리가 복잡함
    • 데이터 저장시 INSERT SQL 2번 호출

 

단일 테이블 전략

  • 장점
    • 조인이 필요 없으므로 일반적으로 조회 성능이 빠름
    • 조회 쿼리가 단순함
  • 단점
    • 자식 엔티티가 매핑한 컬럼은 모두 null 허용
    • 단일 테이블에 모든 것을 저장하므로 테이블이 커질 수 있다. 상황에 따라서 조회 성능이 오히려 느려질 수 있다.

 

구현 클래스마다 테이블 전략

  • 이 전략은 데이터베이스 설계자와 ORM 전문가 둘 다 추천 X
  • 장점
    • 서브 타입을 명확하게 구분해서 처리할 때 효과적
    • not null 제약조건 사용 가능
  • 단점
    • 여러 자식 테이블을 함께 조회할 때 성능이 느림(UNION SQL 필요)
    • 자식 테이블을 통합해서 쿼리하기 어려움

 

 

@MappedSuperclass


@MappedSuperclass

  • 공통 매핑 정보가 필요할 때 사용(id, name)

  • 상속관계 매핑 X
  • 엔티티 X, 테이블과 매핑 X
  • 부모 클래스를 상속 받는 자식 클래스에 매핑 정보만 제공
  • 조회, 검색 불가(em.find(BaseEntity)) 불가)
  • 직접 생성해서 사용할 일이 없으므로 추상 클래스 권장
  • 테이블과 관계 없고, 단순히 엔티티가 공통으로 사용하는 매핑 정보를 모으는 역할
  • 주로 등록일, 수정일, 등록자, 수정자 같은 전체 엔티티에서 공통으로 적용하는 정보를 모을 때 사용
  • 참고 : Entity 클래스는 엔티티나 @MappedSuperclass로 지정한 클래스만 상속가능

 

 

 

실전 예제


요구사항 추가

  • 상품의 종류는 음반, 도서, 영화가 있고 이후 더 확장될 수 있다.
  • 모든 데이터는 등록일과 수정일이 필수다.

 

 

모데인 모델

 

 

 

 

테이블 설계를 보면 ITEM이라는 테이블에 DTYPE으로 하위 테이블에 대한걸 명시해줍니다. 이처럼 설계하기 위해서는

1.

@Inheritance(strategy = InheritanceType.SINGLE_TABLE)

SINGLE_TALBE로 해주면 ITEM 테이블에 모든 하위 테이블에 대한 정보가 저장됩니다.

 

2.

@DiscriminatorColumn

DIscriminatorColumn을 추가해주면 해당 컬럼 데이터가 어떤 하위 테이블의 데이터인지 DTYPE으로 명시해줍니다.

 

 

 

 

 

 

 

출처

 

자바 ORM 표준 JPA 프로그래밍 - 기본편 - 인프런 | 강의

JPA를 처음 접하거나, 실무에서 JPA를 사용하지만 기본 이론이 부족하신 분들이 JPA의 기본 이론을 탄탄하게 학습해서 초보자도 실무에서 자신있게 JPA를 사용할 수 있습니다., - 강의 소개 | 인프런

www.inflearn.com

 

목차

  • 연관관계 매핑시 고려사항 3가지
  • 다대일 [N:1]
  • 일대다 [1:N]
  • 일대일 [1:1]
  • 다대다 [N:N]
  • 실전 예제

 

연관관계 매핑시 고려사항 3가지

  • 다중성
  • 단방향, 양방향
  • 연관관계의 주인

 

다중성

  • 다대일 : @ManyToOne
  • 일대다 : @OneToMany
  • 일대일 : @OneToOne
  • 다대다 : @ManyToMany

 

단방향, 양방향

  • 테이블
    • 외래 키 하나로 양쪽 조인 가능
    • 사실 방향이라는 개념이 없음
  • 객체
    • 참조용 필드가 있는 쪽으로만 참조 가능
    • 한쪽만 참조하면 단방향
    • 양쪽이 서로 참조하면 양방향

 

연관관계의 주인

  • 테이블은 외래 키 하나로 두 테이블이 연관관계를 맺는다.
  • 객체 양방향 관계는 A -> B, B -> A 처럼 참조가 2곳. 둘 중 테이블의 외래 키를 관리할 곳을 지정해햐 함.
  • 연관관계의 주인 : 외래 키를 관리하는 참조
  • 주인의 반대편 : 외래 키에 영향을 주지 않음, 단순 조회기능

 

 

다대일 [N:1]


다대일 단방향

DB 설계 상 1:N의 경우 N 쪽에 외래키가 있어야 합니다. 

 

 

다대일 양방향

기존에 했던 것과 다를 것 없이 양방향의 경우 TEAM 객체에 조회하하는 list만 추가하면 됩니다. 

 

 

 

일대다 [1:N]


일대다 단방향

권장하지 않는 모델링 방법 (무조건 N 쪽에 외래 키가 있기 때문)

 

 

일대다 단방향 정리

  • 일대다 단방향은 일대다(1:N)에서 일(1)이 연관관계의 주인
  • 테이블 일대다 관계는 항상 다(N) 쪽에 외래 키가 있음
  • 객체와 테이블의 차이 때문에 반대편 테이블의 외래 키를 관리하는 특이 구조
  • @JoinColumn을 꼭 사용해야 함. 그렇지 않으면 조인 테이블 방식을 사용함 (중간에 테이블을 하나 추가함)

 

일대다 

JoinColumn은 꼭 해주어야함!! JoinColumn을 하지 않게되면 두 테이블을 연결시킬 새로운 테이블을 JPA에서 자동으로 만든다.

JoinColumn을 하지 않으면 생기는 테이블

 

일대다 단방향 단점

  • 엔티티가 관리하는 외래 키가 다른 테이블에 있음
  • 연관관계 관리를 위해 추가로 UPDATE SQL 실행

그렇기때문에 일대다 단방향 매핑보다는 다대일 양방향 매핑을 사용하자. (다(N)쪽에 외래 키가 있도록)

 

 

일대다 양방향

 

insertable = false, updatable = false를 하게되면 읽기만 가능하게 해줍니다. 

 

 

일대다 양방향 정리

  • 일대다 양방향 매핑은 공식적으로 존재 X
  • @JoinColumn(insertable = false, updatable = false)
  • 읽기 전용 필드를 사용해서 양방향처럼 사용하는 방법
  • 다대일 양방향을 사용하자

 

 

일대일 [1:1]


일대일 관계

  • 일대일 관계는 그 반대도 일대일
  • 주 테이블이나 대상 테이블 중에 외래 키 선택 가능
    • 주 테이블에 외래 키
    • 대상 테이블에 외래 키
  • 외래 키에 데이터베이스 유니크(UNI) 제약조건 추가

 

일대일 : 주 테이블에 외래 키 단방향

외래 키는 Member, Locker 어디에 넣어도 상관없다. 위의 예시에서는 Member에 외래 키를 넣었습니다. 다대일(@ManyToOne) 단방향 매핑과 유사

 

 

일대일 : 주 테이블에 외래 키 양방향

양방향으로 하고 싶다면 Member, Member 모두 필드를 추가해주면 됩니다. 

 

 

일대일 : 주 테이블에 외래 키 양방향 정리

  • 다대일 양방향 매핑처럼 외래 키가 있는 곳이 연관관계의 주인
  • 반대편은 mappedBy 적용

 

일대일 : 대상 테이블에 외래 키 단방향

일대일의 경우 대상 테이블에 외래 키가 있으면 작동하지 않습니다.

 

일대일 : 대상 테이블에 외래 키 단방향 정리

  • 단방향 관계는 JPA 지원 X
  • 양방향 관계는 지원

 

일대일 : 대상 테이블에 외래 키 양방향

일대일 주 테이블에 외래 키 양방향과 매핑 방법은 같음

 

 

일대일 정리

  • 주 테이블에 외래 키
    • 주 객체가 대상 객체의 참조를 가지는 것 처럼
      주 테이블에 외래 키를 두고 대상 테이블을 찾음
    • 객체지향 개발자 선호
    • JPA 매핑 관리
    • 장점
      • 주 테이블만 조회해도 대상 테이블에 데이터가 있는지 확인 가능
    • 단점
      • 값이 없으면 외래 키에 null 허용
  • 대상 테이블에 외래 키
    • 대상 테이블에 외래 키가 존재
    • 전통적인 데이터베이스 개발자 선호
    • 장점
      • 주 테이블과 대상 테이블을 일대일에서 일대다 관계로 변경할 때 테이블 구조 유지
    • 단점
      • 프록시 기능의 한계로 지연 로딩으로 설정해도 항상 즉시 로딩 됨 (프록시는 뒤에서 설명)

 

 

 

다대다 [N:M]


실무에서 다대다 관계는 쓰면 안된다.

  • 관계형 데이터베이스는 정규화된 테이블 2개로 다대다 관계를 표현할 수 없음.
  • 연결 테이블을 추가해서 일대다, 다대일 관계로 풀어내야 함.

 

 

다대다

  • @ManyToMany 사용
  • @JoinTable로 연결 테이블 지정
  • 다대다 매핑 : 단방향, 양방향 가능

 

다대다 매핑의 한계

  • 편리해 보이지만 실무에서 사용 X
  • 연결 테이블이 단순히 연결만 하고 끝나지 않음
  • 주문 시간, 수량 같은 데이터가 들어올 수 있음

 

다대다 한계 극복

  • 연결 테이블용 엔티티 추가 (연결 테이블을 엔티티로 승격)
  • @ManyToMany -> @OneToMany, @ManyToOne

 

 

실전 예제


배송, 카테고리 추가 - 엔티티

  • 주문과 배송은 1:1 (@OneToOne)
  • 상품과 카테고리는 N:M (@ManyToMany)

 

배송, 카테고리 추가 - ERD

 

배송, 카테고리 추가 - 엔티티 상세

 

N:M 관계는 1:N, N:1로

  • 테이블의 N:M 관계는 중간 테이블을 이용해서 1:N, N:1
  • 실전에서는 중간 테이블이 단순하지 않다.
  • @ManyToMany는 제약 : 필드 추가 X, 엔티티 테이블 불일치
  • 실전에서는 @ManyToMany 사용 XX

 

@JoinColumn

  • 외래 키를 매핑할 때 사용

 

@ManyToOne

  • 다대일 관계 매핑

 

@OneToMany

  • 다대일 관계 매핑

 

 

 

 

 

 

 

 

 

 

 

출처

 

자바 ORM 표준 JPA 프로그래밍 - 기본편 - 인프런 | 강의

JPA를 처음 접하거나, 실무에서 JPA를 사용하지만 기본 이론이 부족하신 분들이 JPA의 기본 이론을 탄탄하게 학습해서 초보자도 실무에서 자신있게 JPA를 사용할 수 있습니다., - 강의 소개 | 인프런

www.inflearn.com

 

목표

  • 객체와 테이블 연관관계의 차이를 이해
  • 객체의 참조와 테이블의 외래 키를 매핑
  • 용어 이해
    • 방향 (Direction) : 단방향, 양방향
    • 다중성 (Multiplicity) : 다대일(N:1), 일대다(1:N), 일대일(1:1), 다대다(N:N) 이해
    • 연관관계의 주인 (Owner) : 객체 양방향 연관관계는 관리 주인이 필요

 

예제 시나리오

  • 회원과 팀이 있다.
  • 회원은 하나의 팀에만 소속될 수 있다.
  • 회원과 팀은 다대일 관계다.

 

객체를 테이블에 맞추어 모델링 (연관관계가 없는 객체)

 

객체를 테이블에 맞추어 모델링 (참조 대신에 외래 키를 그대로 사용)

@Entity
public class Member {
    @Id @GeneratedValue
    private Long id;

    @Column(name = "USERNAME")
    private String name;

    @Column(name = "TEAM_ID")
    private Long teamId;
    ...
    }
    
@Entity
public class Team {
    @Id
    @GeneratedValue
    private Long id;

    private String name;
    ...
    }

 

test code

            //팀 저장
            Team team = new Team();
            team.setName("TeamA");
            em.persist(team);

            //회원 저장
            Member member = new Member();
            member.setName("member1");
            member.setTeamId(team.getId());
            em.persist(member);

 

결과

테이블에 잘 저장되고 Join도 잘 동작하는 것을 볼 수 있습니다.

 

 

객체를 테이블에 맞추어 모델링 (식별자로 다시 조회, 객체 지향적인 방법이 아니다.)

이전에 보았던 것처럼 DB를 통해서 계속해서 끄집어 내야한다.

 

객체를 테이블에 맞추어 데이터 중심으로 모델링하면, 협력 관계를 만들 수 없다.

  • 테이블은 외래키로 조인을 사용해서 연관된 테이블을 찾는다.
  • 객체는 참조를 사용해서 연관된 객체를 찾는다.
  • 테이블과 객체 사이에는 이러한 간격이 존재한다.

 

 

단방향 연관관계


객체 지향 모델링 (객체 연관관계 사용)

 

변경된 코드

    //@Column(name = "TEAM_ID")
    //private Long teamId;

    @ManyToOne
    @JoinColumn(name = "TEAM_ID")
    private Team team;
  • @ManyToOne
    • Member N : Team 1 이기 때문에 Member 객체에선 Team과 연관되는 컬럼에는 본인이 Many 팀이 One이라는 어노테이션을 추가해주어야 합니다. (연관관계 사용할 때 이러한 일대일, 다대일, 일대다, 다대다 관계의 어노테이션을 추가해야함)
  • @JoinColumn
    • 조인해야하는 컬럼이 어떤 컬럼인지 명시해주는 어노테이션입니다. DB에 실제 존재하는 값을 찾아서 매핑합니다.

이렇게 관계와 join 컬럼만 추가해주면 끝입니다.

 

 

객체 지향 모델링

 

조회

            //조회
            Member findMember = em.find(Member.class, member.getId());
            //참조를 사용해서 연관관계 조회
            Team findTeam = findMember.getTeam();

Member 객체를 가져온 뒤, getTeam() 메소드만 호출하면 원하는 연관된 Team 객체를 받아올 수 있습니다. (다시 DB를 조회할 필요가 없음)

 

 

 

양방향 연관관계와 연관관계의 주인


양방향 매핑

이전엔 멤버 -> 팀 으로만 가능했다면 양방향 연관관계는 멤버 <-> 팀 으로 이동이 가능하게 매핑하는 것 입니다.

 

코드

    @OneToMany(mappedBy = "team")
    private List<Member> members = new ArrayList<>();

Team 객체에 해당 컬럼만 추가해주면 됩니다.

OneToMany는 일대다 관계라는 것을 프로그램에게 알려 주는 것이고, mappedBy는 Member객체에 있는 team이라는 변수와 매핑이 된다는 것을 나타내는 것 입니다.

 

테스트

            //조회
            Team findTeam = em.find(Team.class, team.getId());
            int memberSize = findTeam.getMembers().size(); //역방향 조회

위의 테스트를 해보았는데 문제가 발생했다.

기존 데이터를 em.flush()를 통해 DB에 저장한 뒤, 탐색하면 정상적으로 데이터를 가져올 수 있을 거라고 생각했지만 그렇지 못했습니다.

em.flush후 em.clear까지 해줘야지 정상적으로 데이터를 갖고올 수 있었습니다. 

 

em.flush후 em.clear를 해야하는 이유는? em.flush를 하면 DB에 데이터가 저장이 됩니다. 그렇기 때문에 DB에 데이터를 가져올 것이라고 생각했지만, 영속성 컨텍스트에 가져오려는 데이터가 있기때문에 DB에 저장된 데이터가 아닌 영속성 컨텍스트에 있는 데이터를 가져옵니다. 여기서 문제점은 영속성 컨텍스트에 있는 Team 테이블에 members 컬럼에는 아무것도 없습니다. DB에서 조회를 하여 가져올 때는 @OneToMany를 통해 DB에서 연관된 테이블을 같이 가져오지만, 영속성 컨텍스트에 있는 Team 테이블은 그렇지 않기 때문입니다. 그렇기 때문에 em.clear를 통해 영속성 컨텍스트를 초기화 시켜준 뒤, 원하는 객체를 DB로부터 받아올 수 있도록 해줘야합니다.

 

 

연관관계의 주인과 mappedBy

  • mappedBy = JPA의 멘탈붕괴 난이도
  • mappedBy는 처음에 이해하기 어렵다.
  • 객체와 테이블간에 연관관계를 맺는 차이를 이해해야 한다.

 

객체와 테이블이 관계를 맺는 차이

  • 객체 연관관계 = 2개
    • 회원 -> 팀 연관관계 단방향 1개
    • 팀 -> 회원 연관관계 단방향 1개
  • 테이블 연관관계 = 1개
    • 회원 <-> 팀 연관관계 양방향 1개

테이블의 경우 fk 값 하나로 테이블의 연관관계가 끝이 납니다. 하지만 객체의 경우 참조가 객체마다 있어야합니다.

 

사실상 객체의 양방향 관계서로 다른 단방향 관계 2개입니다.

 

한명의 멤버가 팀을 바꾸려고 할 때 테이블에서는 fk 값만 바꿔주면 끝이납니다. 하지만, 객체의 경우 Member에 있는 team을 바꿔야할 지, Team에 있는 members를 바꿔야할지 딜레마에 빠지기 때문입니다. 

그렇기때문에 객체를 매핑할 때 테이블이 fk 값하나로 연관관계를 맺는 것처럼 객체의 참조도 하나일 필요가 있습니다.

 

그래서 결론은 "객체도 둘 중 하나로 외래 키를 관리해야 한다"로 됩니다. 이 개념이 바로 연관관계의 주인입니다.

 

 

연관관계의 주인

  • 객체의 두 관계 중 하나를 연관관계의 주인으로 지정
  • 연관관계의 주인만이 외래 키를 관리 (등록, 수정)
  • 주인이 아닌 쪽은 읽기만 가능
  • 주인은 mappedBy 속성 사용 X
  • 주인이 아니면 mappedBy 속성으로 주인 지정

이전에 짰던 코드를 비유하면 연관관계의 주인은 Member의 team입니다.

 

 

누구를 주인으로?

  • 외래 키가 있는 곳을 주인으로 정해라
  • 여기서는 Member.team이 연관관계의 주인

외래 키가 있는 곳을 주인으로 정하는 이유는 아래와 같다.

  • 예를들어, Team.members를 외래키로 정했다고 가정해보자. members의 값을 변경하게되면 연관된 다른 테이블의 업데이트 쿼리도 나가게되는데 이렇게되면 헷갈리게 된다.
  • 성능 이슈

 

 

양방향 연관관계와 연관관계의 주인 - 주의점, 정리


양방향 매핑시 가장 많이 하는 실수 (연관관계의 주인에 값을 입력하지 않음)

실제 코드만 보면 아무런 문제가 없어보이는 코드입니다. member 객체를 만들었고, team에 member를 추가해주었습니다. 한번 더 기억을 더듬어 보자면 저희는 이전에 mappedBy로 연관관계의 주인을 Member로 설정했습니다. 또 등록, 수정이 member를 통해서만 이루어진다고 말했었습니다. 하지만, 해당 코드에서 등록을 연관관계의 주인이 아닌 역방향으로 했습니다. 결과는 어떨까요??

위를 보다시피 매핑이 정상적으로 이루어지지 않은 모습을 볼 수 있습니다. 

다시 한번 기억합시다! 연관관계 주인에 설정을 해야합니다.

 

그렇다면 연관관계의 주인에만 설정을 하는 것이 맞는 걸까요?? 이것도 무언가 객체지향스럽지 못합니다. 이유는 데이터를 넣지도 않았는데 이미 데이터는 들어가있기 때문입니다. 이것은 아래와 같은 두가지에서 문제가 생깁니다.

  • em.clear()를 하지 않은 경우 (위에 해당의 문제는 설명한 바 있습니다. 간단하게 설명하자면 영속성 컨텍스트에서 데이터를 가져오기 때문입니다. 이해되지 않는 분들은 em.clear를 하고 안하고의 차이를 주석처리해보며 직접 느껴보시길 추천합니다.)
  • 테스트케이스를 작성할 때, member.getTeam은 되지만 team.getMembers는 동작하지 않음.

위의 이유로 "양쪽 다 데이터를 세팅하는 것이 맞는 방법이다"라고합니다.

 

 

양방향 연관관계 주의 - 실습

  • 순수 객체 상태를 고려해서 항상 양쪽에 값을 설정하자
  • 연관관계 편의 메소드를 생성하자
  • 양방향 매핑시에 무한 루프를 조심하자
    • 예) toString(). lombok, JSON 생성 라이브러리 

 

연관관계 편의 메소드

연관관계 편의 메소드

연관관계 편의 메소드를 생성해 한번의 메소드로 양쪽에 값을 설정해줍니다. 위 코드는 setTeam -> changeTeam을 통해 양쪽의 연관관계를 설정해주는 코드입니다. 양쪽 연관관계를 맺는 방법은 다양한 방법이 있으니 편한 방법대로 해주시면됩니다. 

 

 

양방향 매핑시 무한 루프

Member, Team toString 메소드
toString 사용
StackOverFlow

양방향 연관관계에서 두 객체 모두 toString을 생성한 뒤, 한쪽 객체의 toString을 사용하는 경우 member <-> team을 계속해서 부르기 때문에 stackoverflow가 발생하게 됩니다. (toString하는 경우 한쪽 방향만 이용하던가, 양방향 연관하는 컬럼의 경우 제외해주어야 합니다.) 특히, lombok으로 toString 쓰는 경우 보이지 않기때문에 조심해야합니다.

 

 

양방향 매핑 정리

  • 단방향 매핑만으로도 이미 연관관계 매핑은 완료
  • 양방향 매핑은 반대 방향으로 조회(객체 그래프 탐색) 기능이 추가된 것 뿐
  • JPQL에서 역방향으로 탐색할 일이 많음
  • 단방향 매핑을 잘 하고 양방향은 필요할 때 추가해도 됨 (테이블에 영향을 주지 않음)

김영한님의 추천으로 단방향 매핑으로 설계를 완료하고 필요에 의해서 탐색하는 경우에만 조회용으로만 양방향으로 사용하는 것을 권장한다고 합니다.

 

 

 

연관관계 매핑 시작


테이블 구조

 

객체 구조

 

 

 

 

 

 

 

 

 

 

 

 

 

출처

 

자바 ORM 표준 JPA 프로그래밍 - 기본편 - 인프런 | 강의

JPA를 처음 접하거나, 실무에서 JPA를 사용하지만 기본 이론이 부족하신 분들이 JPA의 기본 이론을 탄탄하게 학습해서 초보자도 실무에서 자신있게 JPA를 사용할 수 있습니다., - 강의 소개 | 인프런

www.inflearn.com

 

 

11286번: 절댓값 힙

첫째 줄에 연산의 개수 N(1≤N≤100,000)이 주어진다. 다음 N개의 줄에는 연산에 대한 정보를 나타내는 정수 x가 주어진다. 만약 x가 0이 아니라면 배열에 x라는 값을 넣는(추가하는) 연산이고, x가 0

www.acmicpc.net

 

 

 

  • 풀이

 

Comparable 인터페이스를 이용해 클래스 데이터 문제의 조건에 맞게 정렬하면서 넣어준 뒤, 빼는 식의 풀이를 사용했습니다.

 

 

 

  • 코드

 

import java.io.*;
import java.util.*;

public class Main {
	static StringBuilder sb;

	public static void main(String[] args) throws Exception {
		SetData();
		System.out.println(sb);
	}

	private static void SetData() throws Exception {
		InputReader in = new InputReader(System.in);

		int N = in.nextInt();
		sb = new StringBuilder();
		PriorityQueue<Node> pq = new PriorityQueue<>();

		while(N-->0) {
			int input = in.nextInt();
			if(input == 0) {
				if(pq.size() == 0) {
					// 큐가 비어있다면 0 출력
					sb.append("0").append("\n");
				} else {
					// 큐가 비어있지 않다면 큐에 저장한 값 중 가장 작은 값 출력
					sb.append(pq.poll().value).append("\n");
				}
				continue;
			}

			// 입력이 0이 아니라면 큐에 입력값과 절댓값 추가
			int absoluteInput = Math.abs(input);
			pq.add(new Node(input, absoluteInput));
		}
	}
}

class Node implements Comparable<Node> {
	int value;
	int absoluteValue;

	public Node(int value, int absoluteValue) {
		this.value = value;
		this.absoluteValue = absoluteValue;
	}

	@Override
	public int compareTo(Node o) {
		// TODO Auto-generated method stub
		// 절댓값 값이 같다면 입력값이 가장 작은 값
		if(this.absoluteValue == o.absoluteValue) {
			return this.value - o.value;
		} else {
			// 절댓값이 다르다면 절댓값으로 오름차순 정렬
			return this.absoluteValue - o.absoluteValue;
		}
	}
}

class InputReader {
	private final InputStream stream;
	private final byte[] buf = new byte[8192];
	private int curChar, snumChars;

	public InputReader(InputStream st) {
		this.stream = st;
	}

	public int read() {
		if (snumChars == -1)
			throw new InputMismatchException();
		if (curChar >= snumChars) {
			curChar = 0;
			try {
				snumChars = stream.read(buf);
			} catch (IOException e) {
				throw new InputMismatchException();
			}
			if (snumChars <= 0)
				return -1;
		}
		return buf[curChar++];
	}

	public int nextInt() {
		int c = read();
		while (isSpaceChar(c)) {
			c = read();
		}
		int sgn = 1;
		if (c == '-') {
			sgn = -1;
			c = read();
		}
		int res = 0;
		do {
			res *= 10;
			res += c - '0';
			c = read();
		} while (!isSpaceChar(c));
		return res * sgn;
	}

	public long nextLong() {
		int c = read();
		while (isSpaceChar(c)) {
			c = read();
		}
		int sgn = 1;
		if (c == '-') {
			sgn = -1;
			c = read();
		}
		long res = 0;
		do {
			res *= 10;
			res += c - '0';
			c = read();
		} while (!isSpaceChar(c));
		return res * sgn;
	}

	public int[] nextIntArray(int n) {
		int a[] = new int[n];
		for (int i = 0; i < n; i++) {
			a[i] = nextInt();
		}
		return a;
	}

	public String nextLine() {
		int c = read();
		while (isSpaceChar(c))
			c = read();
		StringBuilder res = new StringBuilder();
		do {
			res.appendCodePoint(c);
			c = read();
		} while (!isEndOfLine(c));
		return res.toString();
	}

	public boolean isSpaceChar(int c) {
		return c == ' ' || c == '\n' || c == '\r' || c == '\t' || c == -1;
	}

	private boolean isEndOfLine(int c) {
		return c == '\n' || c == '\r' || c == -1;
	}
}

객체와 테이블 매핑


엔티티 매핑 소개

  • 객체와 테이블 매핑
    • @Entity, @Table(name = "테이블 명")
  • 필드와 컬럼 매핑
    • @Column(name = "컬럼 명")
  • 기본 키 매핑
    • @Id
  • 연관관계 매핑
    • @ManyToOne, @OneToMany, @ManyToMany, @OneToOne, @JoinColumn

 

 

@Entity

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

 

@Table

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

 

 

 

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


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

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

 

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

hibernate.hbm2ddl.auto

 

 

데이터베이스 스키마 자동 생성 - 주의

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

운영 같은 경우 몇천만건 있는 상태에서 alter를 잘못치면 시스템이 중단상태가 될 수 있다. 애플리케이션 로딩시점에 시스템에서 자동으로 alter 친다는 것은 매우 위험하다. 

 

 

DDL 생성 기능

  • 제약조건 추가 : 회원 이름은 필수, 10자 초과X
    • @Column(nullable = false, length = 10)
  • 유니크 제약조건 추가
    • @Table(uniqueConstraints = {@uniqueConstraint( name = "NAME_AGE_UNIQUE",
      columnNames = {"NAME", "AGE"})})
  • DDL 생성 기능은 DDL을 자동 생성할 때만 사용되고 JPA의 실행 로직에는 영향을 주지 않는다.

 

 

 

필드와 컬럼 매핑


요구사항 추가

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

 

Member 클래스 수정

@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                    // 데이터베이스에 varchar를 능가하는 큰 문자열을 넣을 때 Lob 사용
    private String description;

    public Member(){}
}

테이블이 create된 출력

  • description이 clob인 이유는 String으로 선언했기 때문
  • enum은 varchar로 매핑

 

매핑 어노테이션 정리

 

@Column

 

@Enumerated

자바 enum 타입을 매핑할 때 사용

주의! ORDINAL 사용 X (순서로 하게되면 1,2,3 이런식으로 저장되는데 문제는 Enum의 데이터를 추가할 경우 기존의 데이터가 바뀌지 않아 문제가 생긴다.)

 

@Temporal

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

참고 : LocalDate, LocalDateTime을 사용할 때는 생략 가능(최신 하이버네이트 지원)

 

@Lob

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

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

 

@Transient

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

 

 

기본 키 매핑


기본 키 매핑 방법

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

 

Identity 전략 - 특징

  • 기본 키 생성을 데이터베이스에 위임
  • 주로 MySQL, PostgreSQL, SQL Server, DB2에서 사용 (예, MySQL의 AUTO_INCREMENT)
  • JPA는 보통 트랜잭션 머킷 시점에 INSERT SQL 실행
  • AUTO_INCREMENT는 데이터베이스에 INSERT SQL을 실행한 이후에 ID 값을 알 수 있음
  • IDENTITY 전략은 em.persist() 시점에 즉시 INSERT SQL 실행하고 DB에서 식별자를 조회
  • JDBC 드라이브에 insert 쿼리를 날릴 때 return을 받는 것이 내부적으로 되어있기 때문에 select 쿼리문을 날리지 않고 insert 만으로 기본 키를 넣을 수 있음
  • persist 시점에 insert SQL을 실행하기 때문에 버퍼링을 이용한 성능 최적화를 할 수 없다.

 

Sequence 전략 - 특징

  • 데이터베이스 시퀀스는 유일한 값을 순서대로 생성하는 특별한 데이터베이스 오브젝트 (예 : 오라클 시퀀스)
  • 오라클, PostgreSQL, DB2, H2 데이터베이스에서 사용
  • em.persist() 일 때 DB에서 Sequence만 갖고와서 영속성 컨텍스트에 저장하면서, insert 쿼리문도 함께 SQL저장소에 저장한 뒤, 트랜잭션 commit 시점에 insert 쿼리문을 DB에 전송
  • 따라서, 버퍼링 기능을 사용 가능
  • 하지만, persist에서 SEQ 값을 갖고 오기위해 네트워크를 이용하는 것 때문에 성능에 문제가 생길 수 있습니다. SEQ값을 갖고오는 것보다 Insert 쿼리문을 날리는게 성능에 더 좋아진다고 생각할 것 입니다.
  • 이를 해결하기 위해, allocationSize를 이용하면됩니다. allocationSize에 할당한 수만큼 데이터가 모일 때 SEQ 값을 증가시키는 아래와 같은 쿼리문을 보냅니다.

Sequence 전략 - 매핑

Sequence - @SequenceGenerator

 

Table 전략

  • 키 생성 전용 테이블을 하나 만들어서 데이터베이스 시퀀스를 흉내내는 전략
  • 장점 : 모든 데이터베이스에 적용 가능
  • 단점 : 성능
    • 최적화가 되어있지 않기 때문에 성능이 떨어진다.

Table 전략 - 매핑

알아서 테이블과 컬럼이 생성되고, select와 update문을 날리면서 동작

테이블을 하나 만들어서 관리하는게 있어보이지만, 성능상 좋지 않기 때문에 잘 사용하지는 않는다고 합니다.

 

 

권장하는 식별자 전략

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

 

 

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


요구사항 분석

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

 

기능 목록

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

 

도메인 모델 분석

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

 

테이블 설계

 

엔티티 설계와 매핑

엔티티 설계를 보며, 프로젝트에 Entity로 추가합니다. (Order 클래스에 status는 enum 타입입니다.)

 

 

참고

    <dependency>
            <groupId>javax.xml.bind</groupId>
            <artifactId>jaxb-api</artifactId>
            <version>2.3.1</version>
    </dependency>

자바 11이상 버전을 이용하면 위의 라이브러리를 pom.xml에 추가해주어야합니다. java 11부터는 Java ee 모듈이 제거되어 jaxb 라이브러리를 꼭 추가해줘야 된다고 합니다.

 

 

엔티티를 추가한 뒤, 코드를 돌렸을 때 create table 로그가 출력되고 콘솔에 테이블이 만들어지면 잘 작동된 것 입니다.

 

근데 자세히보면 Member와 Order의 관계를 만들어주는 Order엔티티에 memberId의 자료형은 Long입니다. 조금 더 객체지향적으로 설계하기 위해선 자료형을 Member로 선언해야 할 것입니다. 그렇다면 객체지향적으로 설계된 엔티티와 그렇지 않은 엔티티의 차이점은 어떨까요? 

 

자료형을 Long, 클래스로 하는 것의 차이점은 아래의 예시를 들어 확인해보도록 하겠습니다.

자료형을 Member로 하면 order.getMember()를 통해 한번의 작업으로 원하는 Member 엔티티를 얻어올 수 있습니다. 하지만, 객체지향적으로 설계하지 않은 Long의 자료형order.getMemberId()를 통해 memberid를 받아오고 해당 memberid를 통해 다시 또 엔티티를 찾아주는 작업을 해야합니다. 즉, Long 자료형의 경우 두번의 작업을 해야합니다. 

 

위의 같은경우는 Order -> Member 한번의 이동의 차이점을 본 것인데요. 이러한 엔티티간의 이동이 많은 경우 객체지향적으로 설계한 것이 더 편리하다는 것을 느낄 수 있을 것 입니다.

 

 

데이터 중심 설계의 문제점

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

 

 

 

 

 

 

출처

 

자바 ORM 표준 JPA 프로그래밍 - 기본편 - 인프런 | 강의

JPA를 처음 접하거나, 실무에서 JPA를 사용하지만 기본 이론이 부족하신 분들이 JPA의 기본 이론을 탄탄하게 학습해서 초보자도 실무에서 자신있게 JPA를 사용할 수 있습니다., - 강의 소개 | 인프런

www.inflearn.com

 

영속성 컨텍스트


JPA에서 가장 중요한 2가지

  1. 객체와 관계형 데이터베이스 매핑하기 (Object Relational Mapping)
    • DB를 어떻게 설계하고, 객체를 어떻게 설계해서 중간에서 JPA를 어떻게 사용해서 mapping 할 것 인지
  2. 영속성 컨텍스트
    • 실제 JPA가 내부에서 어떻게 동작하는지 
    • 영속성 컨텍스트를 이해하면 JPA가 내부적으로 어떻게 돌아가는지 이해할 수 있을 것

 

 

Entity Manager Factory와 Entity Manager

예를들어 웹 어플리케이션을 개발할 때 사용자의 요청에 따라서 EMF를 통해 EM을 생성합니다. EM은 내부적으로 DB 커넥션을 통해 DB를 사용합니다.

 

그렇다면 영속성 컨텍스트는 무엇일까??

영속성 컨텍스트

  • JPA를 이해하는데 가장 중요한 용어
  • "엔티티를 영구 저장하는 환경"이라는 뜻
  • EntityManager.persist(entity);
    • 해당 코드의 의미는 DB에 저장되지만 DB에 저장한다는 의미가 아닌 영속성 컨텍스트에 저장한다는 의미입니다. (아직 어떤 느낌인지 모르겠습니다... ?!?!?!?)   => 실제 확인해보니 em.persist할 때 쿼리문이 나가지 않고 쓰기 지연 SQL 저장소에 쿼리가 저장되고 commit이나 flush를 할 경우 DB에 쿼리문을 보내어 DB를 동기화 시켜줌


EM? 영속성 컨텍스트?

  • 영속성 컨텍스트는 논리적인 개념
  • 눈에 보이지 않기때문에 이해하기 쉽지 않다.
  • EM을 통해 영속성 컨텍스트에 접근

 

  • EM과 영속성 컨텍스트는 J2SE 환경에서 1:1로 매핑됩니다.
  • 스프링 프레임워크같은 환경에선 N:1로 매핑되는데 해당 부분은 다음에 이해하는 것을 권장

 

Entity의 생명주기

  • 비영속 (new/transient)
    • 영속성 컨텍스트와 전혀 관계가 없는 새로운 상태
  • 영속 (managed)
    • 영속성 컨텍스트에 관리되는 상태
  • 준영속 (detached)
    • 영속성 컨텍스트에 저장되었다가 분리된 상태
  • 삭제 (removed)
    • 삭제된 상태

 

비영속

객체만 생성하고 em에 persist하지 않은 상태

 

 

영속

객체를 EM에 저장한 상태 (트랜잭션에 commit하지 않았기때문에 DB에는 올라가지 않는다.)

 

 

준영속, 삭제

 

 

영속성 컨텍스트의 이점

  • 1차 캐시
  • 동일성(Identity) 보장
  • 트랜잭션을 지원하는 쓰기 지연 (transactional write-behind)
  • 변경 감지(Dirty Checking)
  • 지연 로딩(Lazy Loading)

애플리케이션과 DB 사이에 중간 계층이 있음으로서 위와같은 이점을 얻을 수 있다. 영속성 컨텍스트 뿐만 아니라 중간에 하나를 더 두면서 얻는 이점은 버퍼링, 캐시 등과 같은 이점을 얻을 수 있다.

 

 

엔티티 조회, 1차 캐시

이렇게 @Id로 member1이 있고, Entity로 객체가 있음으로서 얻는 이점은 1차 캐시에서 조회할 때 있습니다.

 

1차 캐시에서 조회

em.persist로 1차 캐시에 저장이 되었다고 가정한뒤, 조회한다고 합시다. 조회를 할 경우 DB를 먼저 조회하는 것이 아닌 1차 캐시에서 먼저 조회를 하게 됩니다. 그때 1차 캐시에서 원하는 객체가 있는 경우 DB를 조회하지 않고 바로 객체를 반환 받을 수 있습니다.

 

데이터베이스에서 조회

조회할 때, 1차 캐시에 없는 경우 DB를 조회하게 됩니다. 이때, DB에 원하는 객체가 있는 경우 1차 캐시에 저장한 뒤, 1차 캐시에 있는 객체를 반환하게 됩니다.

 

EM을 사용함으로서 위와같은 1차캐시의 이점을 얻을 수 있지만, 현업자분의 말로는 큰 이점은 없다고 합니다. 이유는 EM은 DB 트랜잭션 단위로 만들고 트랜잭션 종료시 종료됩니다. 이 말은 고객의 요청에 따라 비즈니스가 끝나게 될 경우 영속성 컨텍스트를 지운다는 뜻 입니다. 이렇듯 굉장히 찰나에 순간에만 이점을 얻을 수 있기 때문에 사실상 큰 이점은 없다고 합니다.

 

 

영속 엔티티의 동일성 보장

영속성 컨텍스트에서 같은 객체를 불러와 비교해보면 자바 컬렉션에서 똑같은 레퍼런스 두개를 가져와 비교할 때 같다고 나오는 것 처럼 같다고 나옵니다.

 

 

엔티티 등록

트랜잭션을 지원하는 쓰기 지연

트랜잭션 commit을 하기전까진 1차 캐시에 변경된 내용은 쓰기 지연 SQL 저장소에 쿼리문이 차곡차곡 쌓이게 됩니다. Queue와 비슷한 형식인 것 같습니다. 후에 트랜잭션 commit을 한 경우 쌓인 쿼리문은 flush가 되며 DB에 저장하게 됩니다.

 

 

 

엔티티 수정

변경 감지

데이터를 수정할 때 객체를 가져와 수정 후 update나 persist를 다시 해줘야하는 것 아닌가라는 의문이 생길 수 있습니다. (저도 그랬습니다) 하지만, JPA를 사용하는 목적은 자바에서 컬렉션을 사용하는 것처럼 사용하기 위함 입니다.  컬렉션을 수정할 때, 수정 후 다시 데이터를 집어넣는 작업을 해야하는가를 생각해보면 그렇지 않습니다. 그렇기때문에 JPA에서도 데이터를 수정 후 집어넣는 작업을 하지 않아도 됩니다. 이것이 가능한 이유는 JPA에서 Dirty Checking을 하기 때문입니다. 

 

 

변경 감지 (Dirty Checking)

JPA는 DB 트랜잭션 커밋하는 시점에 내부적으로 flush()가 호출됩니다. 후 엔티티와 스냅샷을 비교합니다. 1차 캐시 안에는 사실 PK값, 객체 뿐만아니라 스냅샷도 있습니다. 스냅샷은 값을 읽는 최초 시점을 저장한 객체입니다. 그렇기 때문에 flush()가 호출 되어 엔티티와 스냅샷을 비교할 때 최초 시점에 객체와 commit된 객체의 값을 비교 후 변경된 데이터에 대한 update 쿼리문을 자동으로 생성하여 쓰기지연 SQL 저장소에 생성하여 저장합니다. 이러한 내부적인 로직때문에 수정할 때 persist나 update를 안해줘도 됩니다.

 

 

엔티티 삭제

위의 메커니즘과 같이 remove(객체)를 하여 삭제할 수 있습니다. 

 

 

플러시 


위 내용을 보다보면 flush라는 단어를 보았을 것 입니다. 

 

flush

영속성 컨텍스트의 변경 내용을 데이터베이스에 반영

 

 

플러시 발생

  • 변경 감지 (Dirty Checking)
  • 수정된 엔티티 쓰기 지연 SQL 저장소에 등록
  • 쓰기 지연 SQL 저장소의 쿼리를 데이터베이스에 전송 (등록, 수정, 삭제 쿼리)

 

 

영속성 컨텍스트를 플러시하는 방법

  • 직접 호출
    • em.flush()
  • 플러시 자동 호출
    • 트랜잭션 커밋
    • JPQL 쿼리 실행

 

플러시 정리

  • 영속성 컨텍스트를 비우지 않음
  • 영속성 컨텍스트의 변경 내용을 데이터베이스에 동기화
  • 트랜잭션이라는 작업 단위가 중요 -> 커밋 직전에만 동기화하면 됨

 

 

 

준영속 상태


준영속 상태

  • 영속 -> 준영속
  • 영속 상태의 엔티티가 영속성 컨텍스트에서 분리 (detached)
  • 영속성 컨텍스트가 제공하는 기능을 사용 못함

 

준영속 상태로 만드는 방법

  • em.detach(entity)
    • 특정 엔티티만 준영속 상태로 전환
  • em.clear()
    • 영속성 컨텍스트를 완전히 초기화
  • em.close()
    • 영속성 컨텍스트를 종료

 

 

 

 

 

 

 

 

 

 

 

 

 

출처

 

자바 ORM 표준 JPA 프로그래밍 - 기본편 - 인프런 | 강의

JPA를 처음 접하거나, 실무에서 JPA를 사용하지만 기본 이론이 부족하신 분들이 JPA의 기본 이론을 탄탄하게 학습해서 초보자도 실무에서 자신있게 JPA를 사용할 수 있습니다., - 강의 소개 | 인프런

www.inflearn.com

 

+ Recent posts