5장. 영속성 클래스 매핑

5.1 엔티티와 값 타입 이해

5.1.1 잘게 세분화된 도메인 모델

• 스프링 데이터 JPA의 주요 목표는 잘게 세분화되고 풍부한 도메인 모델을 지원하는 것이다.
  • 잘게 세분화된다는 것은 단순하게 테이블보다 클래스의 수가 더 많다는 뜻이다.
• JPA는 타입 안정성(type-safety)와 행동(behavior)을 구현할 때, 잘게 세분화된 클래스의 유용성을 강조한다.
• 더 높은 수준의 의미(semantic)와 행위(behavior)가 더해지는 것이다.
• 장점
  • 도메인 모델의 응집성(cohesion) 향상
  • 코드 재사용 용이
  • 유연하지 않은 타입 시스템을 사용하는 SQL보다 더 이해하기가 쉽다.

5.1.2 애플리케이션 개념 정의

• 엔티티 타입
  • 영속성 식별자를 사용해 엔티티 타입의 인스턴스를 조회할 수 있다.
  • 엔티티 인스턴스에는 저마다 고유한 수명주기가 있으며, 다른 엔티티와 독립적으로 존재할 수 있다.
  • 도메인 모델의 일부 선택된 클래스를 엔티티 타입으로 매핑한다.
• 값 타입
  • 영속성 식별자 프로퍼티가 없다.
  • 값 타입 인스턴스는 엔티티에 속하며, 수명은 그것을 소유한 엔티티에 종속된다.
  • JPA에서 값 타입은 기본 프로퍼티 타입(basic property type)이나 임베드 가능한 클래스(embeddable class)로 불린다.

5.2 식별자가 있는 엔티티 매핑

5.2.1 자바 동일성(identity)과 동등성(equality) 이해

• 객체 동일성(==)
  • 자바 가상머신에 의해 정의되는 개념.
  • 두 객체가 JVM에서 같은 메모리 위치를 차지한다면 두 객체는 동일한 것이다.
  • 이것은 a == b 연산자로 확인할 수 있다.
• 객체 동등성
  • 클래스의 equals() 메서드에 의해 정의되는 개념. 때때로 등가성(equivalence)이라 말하기도 한다.
  • 두 객체가 a.equals(Object b) 메서드에 정의된 대로 같은 상태를 가지면 두 객체는 동등한 것이다.
  • equals()를 명시적으로 재정의하지 않는 클래스는 ==로 객체 동일성을 비교하는 java.lang.Object에 정의된 구현을 상속한다.
  • a == b이면, a.equals(b)와 b.equals(a)가 모두 참이어야 한다.
• 데이터베이스 동일성
  • 관계형 데이터베이스에 저장된 객체가 동일한 테이블과 기본키 값을 공유하면 동일한 것이다.
  • 자바 공간에 매핑된 이 개념을 가리켜 데이터베이스 동일성이라고 한다.

5.2.2 엔티티 클래스와 매핑

• @Id
  • 데이터베이스 동일성
  • 기본키 값은 절대 변경되지 않으므로, 식별자 프로퍼티 값을 수정할 수 없게 해야 한다.
  • 엔티티에서 public 세터 메서드를 노출해서는 안 된다.

5.2.3 기본키 선정

• 후보키(candidate key)

  • 테이블의 특정 로우를 식별하는 데 사용할 수 있는 컬럼 또는 컬럼의 집합이다.

  • 기본키가 되려면 후보키가 다음과 같은 조건을 충족해야 한다

    • 후보키의 컬럼이 절대 null이서는 안된다.
    • 후보키 컬럼(또는 여러 개의 컬럼)의 값이 모든 로우에 대해 고유한 값이다.
    • 후보키 컬럼(또는 여러 개의 컬럼)의 값이 절대 변경되지 않고, 불변이다.

    <aside> 👉 JPA에서는 API로 기본키 값을 업데이트하는 것을 지원하지 않는다.(불변성을 가질 것을 기대) 우회하려고 하면, 하이버네이트의 캐싱, 변경 감지 엔진에 문제가 발생할 수 있다.

    </aside>

• 자연키(natural key)

  • 업무적 의미가 있는 키
  • 업무적 의미에 따른 고유한 속성 또는 속성 조합을 의미한다.
    • ex) 주민등록번호, 사회보장번호, 세금파일번호
  • 후보키 속성이 데이터베이스 컨텍스트 외부에서 의미를 갖는다면, 그것이 자동으로 생성되는지 여부와 관계없이 자연키이다.
    • 애플리케이션에 대해 이야기하고, 애플리케이션을 사용할 때 키 속성을 언급한다면 그것은 자연키이다.
  • 자연 기본키는 결국에는 문제를 일으킨다. (자연키를 기본키로 지정하면 안 된다)
    • 좋은 기본키는 고유해야 하고, 변경 불가능해야 하며, 절대 널이 아니어야 한다.

• 대리키(surrogate key) - 대리키를 기본키로 선정하는 것을 적극 권장

  • 대리키(surrogate key)라고 하는 인공 식별자를 추가하는 방식을 적극 권장한다.

  • 대리키는 데이터베이스나 애플리케이션에서 생성된 고유한 값일 뿐 업무적 의미가 없다.

  • 사용자는 이러한 키 값을 보거나 참조하지 않는 것이 바람직한데, 이러한 키 값은 시스템 내부의 일부이기 때문이다.

  • (대리키 컬럼을 도입하는 것은) 후보키가 없는 일반적인 상황에서도 적절하다.

  • 스키마의 거의 모든 테이블에는 전용 대리 기본키 컬럼이 있어야 한다.

5.2.4 키 생성기 구성

5.2.5 식별자 생성기 전략

**엔티티 식별자는 API 등을 통해 비즈니스 로직 외부로 노출하지 말아야 한다.

(외부키(External Key)를 만들어 노출하라)**

• 비즈니스 로직과 관련된 의미가 없고, 영속성하고만 관련이 있기 때문이다.
• 어떤 문제가 발생할 수 있을까?
  1. 확장성 문제(마이그레이션): 시스템이 성장하면서 더 많은 데이터와 복잡한 비즈니스 로직을 다뤄야 할 때, PK에 대한 의존도가 높으면 유연성이 떨어질 수 있습니다. 예를 들어, 분산 시스템에서는 각 데이터 항목에 대해 전역적으로 유일한 식별자를 생성하는 것이 중요한데, 이는 단순한 숫자형 PK로는 해결하기 어려운 문제입니다.
     • 데이터베이스 설계의 유연성: 외부 시스템이나 API가 데이터베이스의 내부 PK에 직접 의존하게 되면, 데이터베이스의 구조를 변경하거나 개선하는 것이 어려워집니다. 예를 들어, 테이블의 분할이나 합병, 또는 식별자의 형태 변경 등을 수행하기 위해서는 외부에 노출된 모든 인터페이스를 수정해야 할 수 있습니다. 이는 시스템의 유지보수 비용을 증가시키고, 민첩한 개발을 방해할 수 있습니다.
     • 시스템의 통합 문제: 서로 다른 시스템이나 서비스 간에 데이터를 통합할 때, 각 시스템의 내부 PK가 충돌할 위험이 있습니다. 이는 데이터 통합 과정을 복잡하게 만들고, 데이터 무결성을 유지하기 어렵게 합니다. 이 문제를 해결하기 위해서는, 시스템 간에 데이터를 교환할 때 내부 PK 대신 도메인에 특화된 식별자나 외부 키를 사용하는 것이 좋습니다.
     • 이기종 데이터베이스 마이그레이션
       • 기술적 차이: 데이터베이스 기술 간에는 식별자를 생성하고 관리하는 방식에 차이가 있을 수 있습니다. 예를 들어, 자동 증가하는 숫자형 ID, UUID, 복합 키 등 다양한 식별자 전략이 있으며, 이런 차이는 마이그레이션을 복잡하게 만들 수 있습니다.
         • 한 데이터베이스에서는 숫자형 PK를 사용하고 다른 데이터베이스에서는 UUID를 사용할 경우, 시스템 간의 일관성 유지가 어려워짐.
       • 데이터베이스 마이그레이션 과정에서의 문제: 식별자의 형태나 구성이 달라질 때, 데이터베이스 간에 데이터를 옮기는 과정에서 데이터의 일관성이나 무결성을 유지하기 어렵게 됩니다. 이는 기존 데이터베이스 시스템에서 새로운 데이터베이스 시스템으로 데이터를 옮길 때, 데이터의 매핑과 변환 작업을 필요로 하며, 이 과정에서 데이터 손실이나 변형의 위험이 있습니다.
       • 시스템 간의 일관성 유지: 서로 다른 식별자 형태를 사용하는 데이터베이스 시스템 간에 일관성을 유지하는 것이 어려워집니다. 이는 특히 대규모 시스템이나 복잡한 데이터 구조를 가진 시스템에서 더욱 문제가 될 수 있습니다.
  2. 도메인 주도 설계(DDD) 관점: DDD에서는 도메인 모델의 식별자가 비즈니스 로직을 반영해야 한다고 강조합니다. 데이터베이스 PK는 기술적인 요구사항에 따른 것이며, 대부분의 경우 비즈니스 로직과 직접적인 연관이 없습니다. 따라서, 도메인 모델을 표현하는데 있어서는 비즈니스 의미를 갖는 식별자를 사용하는 것이 바람직합니다.
     • API 설계와 사용성: API를 설계할 때, PK를 직접 노출하는 것은 사용자가 이해하기 어려운 API를 만들 수 있습니다. 사용자 입장에서는 비즈니스 의미가 있는 식별자(예: 사용자 이름, 제품 코드)가 더 이해하기 쉽고 사용하기 편리합니다.
  3. 보안 문제: PK를 외부에 노출하는 것은 보안상의 위험을 초래할 수 있습니다. 예를 들어, 연속적인 숫자를 사용하는 경우, 공격자가 이를 추측하여 시스템에 무단 접근을 시도할 수 있습니다. 또한, PK를 기반으로 중요한 정보에 접근할 수 있도록 설계된 시스템의 경우, 정보 노출의 위험이 있습니다.
     • 예측 가능함에 따라 인젝션 공격, 사용자 프라이버시 노출 등..

외부키(External Key)

• 외부키란?
• 장점
• 예시

5.3 엔티티 매핑 옵션

5.3.1 이름 제어

• @Table 어노테이션을 사용해 테이블명을 재정의
• 문자열 주위에 따옴표
• 명명 규칙 커스텀

5.3.2 동적 SQL 생성

@DynamicInsert와 @DynamicUpdate 사용할 경우

• 동작:
• 장점:
• 단점:

@DynamicInsert와 @DynamicUpdate 사용하지 않을 경우

• 동작:
• 장점:
• 단점: