treecode

기본적으로 관계형 데이터베이스는 논리적으로 관계가 있는 테이블끼리 연관관계를 설정할 수 있는데 객체 지향 설계에서도 자율적인 객체들간에 협력 관계를 만들기 위해 두 객체 사이에 연관관계를 정의해주어야 한다. 하지만 객체의 연관관계와 테이블 간 연관관계에는 큰 차이가 있다.

테이블은 외래 키로 JOIN을 해서 쉽게 테이블의 연관관계를 만들 수 있지만 객체는 테이블에 맞추어 모델링을 하면 객체 지향적인 협력 관계를 만들어내기가 어렵다. 예를 들면 멤버 객체에서 팀 객체의 PK값인 teamId를 외래 키(FK)로 저장하려면 먼저 팀 객체에서 Id를 조회해서 가져와야하고 나중에 팀 객체에 접근하려면 다시 teamId를 통해 찾아야 하는데 이렇게 식별자로 다시 조회하는 것은 객체 지향적이지 않다. 

반면 객체의 참조를 사용해서 테이블의 외래 키를 매핑하면 멤버 객체는 팀 객체의 참조를 저장하고 객체 그래프 탐색으로 바로 연관관계를 조회할 수 있다. 멤버 객체에서 팀 객체의 참조를 통해 접근하기 때문에 멤버 -> 팀의 단방향 연관관계라고 한다.

JPA에서 외래 키를 매핑할 때는 @JoinColumn을 사용하며 name 기본값은 "필드명_참조 테이블 기본 키 컬럼명", 그 외 unique, nullable, updatable 등이 있다.

양방향 연관관계의 경우 테이블은 외래 키 하나로 JOIN을 하면 두 테이블이 자연스럽게 양방향 관계가 되지만 객체의 양방향 연관관계는 객체가 서로 양쪽을 참조하는 것으로 서로 다른 단방향 연관관계 2개를 만드는 것과 같다.

객체의 양방향 매핑 규칙

- 객체의 두 관계중 하나를 연관관계의 주인으로 지정하여 연관관계의 주인만 외래 키를 등록, 수정할 수 있다.

-  주인이 아닌 쪽은 읽기만 가능하며 mappedBy로 지정을 해줘야 한다.

연관관계의 주인만 외래 키를 등록, 수정 가능하기 때문에  당연히 외래 키가 있는 쪽(N)을 주인으로 정하는 것이 좋다. (반대의 경우에는 외래 키를 수정하려면 반대쪽 객체에 접근해서 수정을 해야 함)

연관관계 주인이 아닌 쪽(mappedBy)는 읽기만 가능하기 때문에 값을 설정 안 해도 되지만 순수 객체 상태를 고려하여 양쪽에 값을 설정하는 것이 좋다. 

기본적으로 단방향 매핑으로 설계를 하며 양방향은 필요할 때 추가하는 것이 좋다. 연관관계 주인이라고 해서 비즈니스 로직을 기준으로 생각하면 안 되고 (멤버가 팀에 속해 있으니 팀이 주인이겠군 -> X), 외래 키를 보유한 쪽을 기준으로 정하며 외래 키는 항상 많은 쪽에 있다.

연관관계를 매핑할 때는 위에서의 단방향, 양방향과 연관관계의 주인, 그리고 마지막으로 다중성에 대해 고려해야 한다.

1. 다대일 (@ManyToOne)

- 글로벌 페치 전략 fetch = FetchType.EAGER(기본값)

- 영속성 전이 기능 cascade

다대일 단방향은 가장 많이 사용하는 연관관계로, 항상 많은 쪽(N)이 참조 필드(외래 키)를 가지고 있기 때문에 외래 키를 가진 쪽에서 참조로 접근을 하는 단방향으로 설계를 한다. 단방향 연관관계는 참조 필드에 @JoinColumns를 붙여서 정의할 수 있다.

2. 일대다 (@OneToMany)

- 양방향 시 mappedBy = "연관관계의 주인 필드"

- 글로벌 페치 전략 fetch = FetchType.LAZY(기본값)

- 영속성 전이 기능 cascade

일대다 단방향은 외래 키가 다른 테이블에 있고 연관관계 관리를 위해 추가 SQL이 실행되기 때문에 사용하지 않는 것이 좋다. (사용하려면 @JoinColumn 필수, 없으면 Join Table 방식으로 중간에 테이블을 하나 생성함)

3. 일대일 (@OneToOne)

일대일 관계는 주 테이블과 대상 테이블 중에 외래 키를 선택할 수 있으며 외래 키에 유니크 제약 조건을 추가한다.

주 테이블에 외래 키를 설정하면 주 테이블에서 참조를 통해 대상 테이블에 접근하기 때문에 객체 지향적이며 JPA 매핑이 편리해지고 주 테이블만 조회하면 대상 테이블에 데이터가 있는지 확인이 가능하다. 단점은 값이 없으면 외래 키에 null 을 허용해야 한다.

대상 테이블에 외래 키는 주 테이블과 대상 테이블의 관계가 일대일에서 일대다로 변경될 때(많은 쪽이 외래 키) 테이블 구조가 유지되기 때문에 데이터베이스 관점에서 좋지만 프록시 적용이 안 되어 지연 로딩이 되지 않고 항상 즉시 로딩만 되는 단점이 있다. (프록시와 지연 로딩은 뒤에서 다룬다.) 대상 테이블에 외래 키의 경우 단방향은 JPA에서 지원하지 않는다.

4. 다대다 (@ManyToMany)

다대다 관계의 경우 @ManyToMany, @JoinTable로 연결 테이블을 지정하고 컬렉션을 사용하면 객체 2개로 연결 테이블을 나타낼 수 있지만 실제로는 연결 테이블이 키값만 있지 않기 때문에 연결 테이블을 엔티티로 만들고 @OneToMany, @ManyToOne으로 연결하는 것이 좋다.

[참고] 인프런 김영한님 강의를 공부한 내용입니다.

@Entity 애노테이션이 붙은 클래스는 JPA가 관리하는 엔티티로 JPA를 사용해서 테이블과 매핑할거면 필수로 입력해야 한다.

파라미터가 없는 public 또는 protected 생성자가 필수이며 final 클래스나 ENUM, 인터페이스, Inner 클래스는 엔티티로 등록할 수가 없다. (저장할 필드에 final 사용 x)

@Table 애노테이션은 Entity와 매핑할 테이블을 지정할 수 있다. (기본값 엔티티명)

ddl-auto 기능을 사용하면 DDL(Database Definition Language)을 애플리케이션 실행 시점에 자동으로 적절하게 생성해주는데 개발 단계에서만 사용하고 운영 서버에서는 사용하지 않는 것이 좋다.

• create : 기존 테이블 삭제 후 재생성 (drop + create)
• create-drop : 종료 시점에 테이블 (drop)
• update : 변경부분만 반영
• validate : 엔티티와 테이블 정상 매핑 확인
• none : 사용 x(default)

개발 초기에는 create, update를 사용하고 테스트 서버는 update, validate, 스테이징과 운영 서버는 validate 또는 none을 주로 사용한다. DDL 생성 기능은 DDL을 자동 생성할 때만 사용되고 JPA의 실행 로직에는 영향을 주지 않는다.

필드 매핑 애노테이션

• @Column : 기본 Column
• @Temporal : 날짜 타입 (LocalDate, LocalDateTime 사용 시 생략 가능)
• @Enumerated : ENUM 타입 (기본 설정인 ORDINAL 대신 STRING 사용)
• @Lob : 데이터베이스 BLOB, CLOB과 매핑, 문자면 CLOB 나머지는 BLOB 매핑
• @Transient : 매핑 무시 (메모리상에 임시로 값 보관할 때 사용)

기본 키 매핑 애노테이션은 @Id(Private Key), @GeneratedValue가 있는데 GeneratedValue는 다음과 같이 설정을 할 수있다.

IDENTITY

• 데이터베이스에 위임 (MySQL의 AUTO_INCREMENT, PostgreSQL ..)
• AUTO_INCREMENT는 INSERT를 한 이후에 ID 값을 알 수 있어서 em.persist() 시점에 즉시 INSERT SQL이 실행된다.

SEQUENCE

데이터베이스 시퀀스는 유일한 값을 순서대로 생성하는 특별한 데이터베이스 오브젝트로 @SequenceGenerator 선언이 추가로 필요하다. (ORACLE, PostgreSQL, H2..) 

@SecuenceGenerator

• name : 식별자 생성기 이름
• sequenceName : 데이터베이스에 등록되어 있는 시퀀스 이름
• initialValue : DDL 생성시에만 사용, 시퀀스 DDL 생성할 때 처음 시작하는 수를 지정 (기본값 1)
• allocationSize : 시퀀스 한번 호출시 증가하는 수, 이 값이 1이면 매번 DB에 접근해서 시퀀스 값을 받아온다. (기본값 50)

기타)

TABLE : 키 생성용 테이블, 모든 DB에서 사용, @TableGenerator 필요 (성능상 잘 쓰진 않음)

AUTO : 데이터베이스에 따라 자동 지정

[참고] 인프런 김영한님 강의를 공부한 내용입니다.

ORM(Object Relatinal Mapping)이란 객체는 객체대로, 관계형 데이터베이스는 관계형 데이터베이스대로 설계를 하고 둘 사이의 관계를 중간에서 매핑시켜 관계형 데이터베이스를 객체지향적으로 사용하게 해주는 기술이다. JPA는 자바 애플리케이션과 JDBC 사이에서 JDBC API를 이용해 DB에 SQL 전달하여 동작하는 자바 ORM 기술 표준 인터페이스로 대표적인 구현체로는 하이버네이트 JPA가 있다.

먼저 JPA를 사용하려면 EntityManagerFactory, EntityManager, 영속성 컨텍스트, 트랜잭션에 대해 알아야 한다.

EntityManagerFactory는 웹서버가 올라오는 시점에 DB당 하나만 생성되어 애플리케이션 전체에서 공유되며 멀티 스레드 환경에서 사용할 수 있으며 createEntityManager()를 통해 EntityManager를 생성할 수 있다.

엔티티 매니저는 트랜잭션을 수행하고 엔티티, SQL을 관리하며 커넥션을 통해 DB에 접근하는 등 핵심 동작을 담당하는 중요한 역할을 하며 트랜잭션에 대해 생각해보면 당연히 스레드 간에 공유는 불가능하며 트랜잭션 수행 후에 반드시 소멸(close) 시켜야한다.

// Persistence에서 하나의 EntityManagerFactory를 생성해서 애플리케이션 전체에서 공유
EntityManagerFactory emf = Persistence.createEntityManagerFactory("hello");

// EntityManagerFactory에서 EntityManager 생성, 쓰레드간에 공유할 수 없고 사용하고 버려야 한다.
EntityManager em = emf.createEntityManager();

// JPA의 모든 데이터 변경은 트랜잭션 안에서 실행
EntityTransaction tx = em.getTransaction();

tx.begin();

try {
	Member member = new Member();
	member.setId(1L);
	member.setName("Kim");
	
	//save
	em.persist(member);
	//read
	Member findMember = em.find(Member.class, 1L);
	//update
	findMember.setName("Lee");
	//delete
	em.remove();

	tx.commit();
} catch (Exception e) {
    // 문제가 생기면 롤백
	tx.rollback();
} finally {
	// 나중에 생성된 순서대로 close
	em.close();	
}
emf.close();

영속성 컨텍스트

영속성 컨텍스트는 자바 애플리케이션과 데이터베이스 사이에서 엔티티를 저장, 관리하는 논리적인 개념으로 엔티티 매니저를 통해 접근할 수 있다.

엔티티의 생명 주기

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

특징

1) 1차 캐시

영속성 컨텍스트는 애플리케이션과 데이터베이스 사이에서 엔티티를 저장, 관리하기 위해서 내부에 1차 캐시 저장소를 가지고 있는데 엔티티를 persist() 하면 1차 캐시에 Key(@Id, PK) Value(Entity), 최초 상태의 엔티티를 복사해둔 스냅샷(변경 감지)을 저장해둔다.

2) 동일성

엔티티 매니저를 통해 조회(em.find)를 하면 먼저 1차 캐시를 확인해서 엔티티 참조값을 반환해주기 때문에 새로운 객체를 생성하지 않고 동일성을 보장한다. 조회하려는 엔티티가 1차 캐시에 없을 경우 DB에서 조회를 해서 1차 캐시에 저장을 하고 반환을 해준다.

3) 쓰기 지연

영속성 컨텍스트는 SQL을 쓰기 지연 저장소에 보관해두었다가 flush()가 호출되는 시점에 SQL을 버퍼처럼 모아서 전송한다.

4) 변경 감지

1차 캐시에 엔티티 스냅샷을 만들어두고 flush() 호출 시, 엔티티와 스냅샷을 비교하여 변경이 있을 경우 쓰기 지연 저장소에 update 쿼리를 추가하고 flush()를 실행한다.

5) 지연 로딩

JPA에서 테이블 간 연관 관계는 객체의 참조를 통해 이루어지는데 이는 하나의 객체를 조회하려다가 해당 객체가 참조하는 N개의 객체를 전부 조회하게 되는(N+1) 등의 문제를 발생시킬 수 있다. 이를 방지하기 위해 엔티티가 실제 사용되기 전까지 DB 조회를 지연하는 지연 로딩(Lazy Loading) 전략을 지원한다.

JPQL

JPQL은 객체 지향 쿼리를 작성하기 위해 JPA가 제공하는 문법으로 SQL을 추상화하여 특정 데이터베이스에 의존하지 않는다.

JPQL은 SQL을 바로 실행하기 때문에 영속 엔티티가 DB 동기화 되지 않아 의도하지 않은 결과가 반환될 수 있어 JPA는 쿼리를 실행할 때 플러시를 자동 호출하는 것을 기본값으로 사용한다. 

em.persist(memberA);
em.persist(memberB);
em.persist(memberC);

// JPQL 실행
query = em.createQuery("select m from Member m", Member.class);

// flush 호출이 안 됐다고 하면 memberA,B,C가 없는 상태인데 의도한 것은 memberA,B,C가 포함된 리스트
List<Member> members= query.getResultList();

플러시 (flush)

플러시는 쓰기 지연 SQL 저장소의 쿼리를 DB에 전송하여 영속성 컨텍스트의 변경 내용을 DB에 동기화 하는데 직접 수동으로 호출하거나 트랜젝션 커밋, JPQL 쿼리 실행에 의해 자동 호출이 된다. (JPA가 JPQL 쿼리 실행시 flush를 자동 호출하는 이유는 JPQL은 우선적으로 데이터베이스에서 조회를 하기 때문에 영속 상태의 엔티티가 조회가 안 되는   )

변경 감지를 통해 1차 캐시 엔티티의 변경 사항(스냅샷을 통해 비교)이 있을 경우 update 쿼리를 flush() 직전에 생성해주기 때문에 사용자는 UPDATE가 필요한 경우 엔티티의 값만 바꿔주면 된다. 영속성 컨텍스트를 비우는 것이 아니며 트랜젝션이라는 작업 단위가 중요하다.

준영속 상태

em.detach(entity) : 특정 엔티티만 준영속 상태로 전환

em.clear() : 영속성 컨텍스트를 완전히 초기화

em.close() : 영속성 컨텍스트를 종료

[참고]