[자바 ORM 표준 JPA 프로그래밍] 값 타입

값 타입

• JPA의 데이터 타입은 엔티티 타입과 값 타입으로 나눌 수 있으며
  엔티티 타입은 @Entity로 정의하는 객체로 식별자를 통해 지속적으로 추적할 수 있음
  값 타입은 int, Integer, String처럼 단순히 값으로 사용하는 자바 기본 타입이나 객체를 말하며
  식별자가 없고 숫자나 문자같은 속성만 있으므로 추적할 수 없음
  
  
  • 기본값 타입 : 자바가 제공하는 기본 데이터 타입으로 자바 기본 타입(int, double), 래퍼 클래스(Integer), String이 존재 
  • 임베디드 타입 (복합 값 타입) : JPA에서 사용자가 직접 정의한 값 타입 
  • 컬렉션 값 타입 : 하나 이상의 값 타입을 저장할 때 사용

기본값 타입

• 자바가 제공하는 기본 데이터 타입인 기본값 타입

// 기본값 타입
@Entity
public class Member {

    @Id @GeneratedValue
    private Long id; // 식별자 값이며 생명주기를 가짐 
    
    /* 식별자 값도 없고 생명주기도 회원 엔티티에 의존하므로
       회원 엔티티 인스턴스를 제거하면 name, age 값도 제거되므로
       값 타입은 공유하면 안됨 (만약 같은 값을 사용하고 싶다면 복사를 이용 예 : a=b) */
    private String name; // 기본값 타입
    private int age; // 기본값 타입
    ...
}

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

• JPA에서 새로운 값 타입을 직접 정의해서 사용할 수 있는 임베디드 타입은 값 타입임

// 기본 회원 엔티티
// 임베디드 타입 사용 전
@Entity
public class Member {
  
    @Id @GeneratedValue
    private Long id;
    private String name;
    
    // 단순히 정보를 풀어둔 것이므로 근무 시작일과 우편번호는 서로 아무 관련이 없음
  
    // 근무 기간
    @Temporal(TemporalType.DATE)
    Date startDate;
    @Temporal(TemporalType.DATE)
    Date endDate;
  
    // 집 주소 표현
    private String city;
    private String street;
    private String zipcode;
    // ...
}

// 값 타입 적용 회원 엔티티
// 임베디드 타입 사용 후, 회원 엔티티가 더욱 의미 있고 응집력 있게 변함
// 새로 정의한 값 타입들은 재사용할 수 있고 응집도도 아주 높음
@Entity
public class Member {
  
    @Id @GeneratedVAlue
    private Long id;
    private String name;
  
    @Embedded // 값 타입을 사용하는 곳에 표시하는 어노테이션
    private Period workPeriod;	// 근무 기간
  
    @Embedded
    private Address homeAddress;	// 집 주소
}

// 기간 임베디드 타입
@Embeddable // 값 타입을 정의하는 곳에 표시하는 어노테이션
public class Peroid {
  
    @Temporal(TemporalType.DATE)
    Date startDate;
    @Temporal(TemporalType/Date)
    Date endDate;
    // ... 값 타입은 기본 생성자가 필수
  
    public boolean isWork (Date date) {
      // .. 값 타입을 위한 메서드를 정의할 수 있음
      // 해당 값 타입만 사용하는 의미있는 메소드도 만들 수 있음
    }
}

// 주소 임베디드 타입
@Embeddable // 값 타입을 정의하는 곳에 표시하는 어노테이션
public class Address {
  
    @Column(name="city") // 매핑할 컬럼 정의 가능
    private String city;
    private String street;
    private String zipcode;
    // ... 값 타입은 기본 생성자가 필수
}

 

임베디드 타입을 포함한 모든 값 타입은 엔티티의 생명주기에 의존하므로
엔티티와 임베디드 타입의 관계를 UML로 표현하면 컴포지션 관계

회원-컴포지션 관계 UML

• 임베디드 타입과 테이블 매핑
  임베디드 타입은 엔티티의 값일 뿐이므로 값이 속한 엔티티의 테이블에 매핑
  
  

  

• 임베디드 타입과 연관관계
  임베디드 타입은 값 타입을 포함하거나 엔티티를 참조할 수 있음

  

  임베디드 타입과 연관관계

   

// 임베디드 타입과 연관관계
// 값 타입인 Address가 값 타입인 Zipcode를 포함하고,
// 값 타입인 PhoneNumber가 엔티티 타입인 PhoneServiceProvider를 참조
@Entity
public class Member {
  
    @Embedded
    Address address; // 임베디드 타입 포함
    @Embedded
    PhoneNumber phoneNumber; // 임베디드 타입 포함
    // ...
}

@Embeddable
public class Address {
    String street;
    String city;
    String state;
    @Embedded
    Zipcode zipcode; // 임베디드 타입 포함
}

@Embeddable
public class Zipcode {
    String zip;
    String plusFour;
}

@Embeddable
public class PhoneNumber {
    String areaCode;
    String localNumber;
    @ManyToOne
    PhoneServiceProvider provider; // 엔티티 참조
    ...
}

@Entity
public class PhoneServiceProvider {
    @Id  
    String name;
 	...
}

• @AttributeOverride : 속성 재정의
  임베디드 타입에 정의한 매핑정보를 재정의하려면 엔티티에 @AttributeOverride를 사용하면 됨
  예) 회원에게 주소가 하나 더 필요한 경우

// 같은 임베디드 타입을 가지고 있는 회원
@Entity
public class Member {
  
    @Id @GeneratedValue
    private Long id;
    private String name;
  
    // 테이블에 매핑하는 컬럼명이 중복되는 문제가 발생하므로 매핑정보 재정의 필요
    @Embedded
    Address homeAddress; // 집 주소
  
    @Embedded
    Address companyAddress; // 회사 주소
}

// 임베디드 타입 재정의
@Entity
public class Member {
  
    @Id @GeneratedValue
    private Long id;
    private String name;
  
    @Embedded
    Address homeAddress; // 집 주소
  
    @Embedded
    @AttributeOverrides({
        @AttributeOverride(name="city", column=@Column(name="COMPANY_CITY")),
        @AttributeOverride(name="street", column=@Column(name="COMPANY_STREET")),
        @AttributeOverride(name="zipcode", column=@Column(name="COMPANY_ZIPCODE"))
    })
    Address companyAddress; // 회사 주소
}

// 생성된 테이블
// 재정의한대로 변경되어있는 것 확인
CREATE TABLE MEMBER (
    COMPANY_CITY varchar(255),
    COMPANY_STREET varchar(255),
    COMPANY_ZIPCODE varchar(255),
    city varchar(255),
    street varchar(255),
    zipcode varchar(255),
    ...
)

• 임베디드 타입과 null
  임베디드 타입이 null이면 매핑한 컬럼 값은 모두 null 

member.setAddress(null); // null 입력
em.persist(member);
// 회원 테이블의 주소와 관련된 CITY, STREET, ZIPCODE 컬럼 값은 모두 null

값 타입과 불변 객체

• 값 타입 공유 참조
  임베디드 타입 같은 값 타입을 여러 엔티티에 공유하면 위험함
  예) 회원1의 주소는 OldCity, 회원2의 주소는 NewCity로 되길 원할 때

  

  값 타입 공유 참조

   

// 값 타입 공유 참조
// 회원1의 주소는 OldCity, 회원2의 주소는 NewCity로 되길 원할 때
member1.setHomeAddress(new Address("OldCity"));
Address address = member1.getHomeAddress();

address.setCity("NewCity"); // 회원1의 address 값을 공유해서 사용
member2.setHomeAddress(address);

/* 회원2에 새로운 주소를 할당하려고 회원1의 주소를 그대로 참조해서 사용하게 되면
   회원2의 주소만 "NewCity"로 변경되길 기대했지만 
   회원1과 회원2가 같은 address 인스턴스를 참조하므로 
   영속성 컨텍스트는 회원1과 회원2 둘 다 city 속성이 변경된 것으로 판단하므로
   회원1의 주소도 "NewCity"로 변경되어 버림
   그러므로 이러한 부작용을 막으려면 값을 공유 대신, 복사해서 사용하면 됨 */

• 값 타입 복사
  값 타입의 실제 인스턴스인 값을 공유하는 것은 위험하므로 값(인스턴스)을 복사해서 사용
  예) 회원1의 주소는 OldCity, 회원2의 주소는 NewCity로 되길 원할 때

  

  값 타입 복사

   

// 값 타입 복사
member1.setHomeAddress(new Address("OldCity"));
Address address = member1.getHomeAddress();

// 회원 1의 address 값을 복사해서 새로운 newAddress 값을 생성
Address newAddress = address.clone();

newAddress.setCity("NewCity");
member2.setHomeAddress(newAddress);

/* clone() 메소드는 자신을 복사해서 반환하도록 구현된 것이므로 
   회원1의 주소 인스턴스를 복사해서 사용하여 회원 2의 주소만 "NewCity"로 변경되며
   영속성 컨텍스트는 회원2의 주소만 변경된 것으로 판단해서 회원2에 대해서만 UPDATE SQL을 실행 */

// 1) 자바의 기본 타입에 값을 대입하면 값을 복사해서 전달
/* a의 값 10을 복사해서 b에 넘겨주면 
   a, b는 완전히 독립된 값을 가지며 부작용도 없으며
   이 후 b의 값을 바꿔주었으므로
   최종 결과는 a=10, b=4 */
int a = 10;
int b = a; // 기본 타입은 항상 값을 복사
b = 4;

// 2) 자바의 객체 타입에 값을 대입하면 항상 참조 값을 전달 (임베디드 타입처럼 직접 정의한 값 타입은 객체 타입)
/* a가 참조하는 인스턴스의 참조 값을 b에 넘겨주므로
   a와 b는 같은 인스턴스를 공유 참조하므로 
   부작용이 발생해서 b.city 값만 변경하려는 의도와 달리 a.city 값도 변경되므로
   최종 결과는 a=New, b=New */
Address a = new Address("Old");
Address b = a; // 객체 타입은 항상 참조 값을 전달
b.setCity("New");

// 3) 자바의 객체 타입을 대입할 때마다 인스턴스를 복사해서 대입하여 공유 참조를 피하는 방법
// 하지만 복사하지 않고 원본의 참조 값을 직접 넘기는 것을 막을 방법이 없음
Address a = new Address("Old");
Address b = a.clone(); // 항상 복사해서 넘겨야 함
b.setCity("New");

• 객체의 공유 참조는 피할 수 없으므로 근본적인 해결책으로 객체의 값을 수정하지 못하게 막아야 함
  예) setCity() 같은 수정 메소드를 모두 제거하면 공유 참조를 해도 값을 변경하지 못하므로 부작용의 발생을 막을 수 있음
• 불변 객체
  값 타입은 부작용 없이 사용할 수 있어야 하며 부작용이 일어나면 값 타입이라고 할 수 없음
  그러므로 객체를 불변하게 만들면 값을 수정할 수 없으므로 부작용을 원천 차단하기 위해 값 타입은 가능하면 불변 객체로 설계
  불변 객체도 결국 객체이므로 인스턴스의 참조 값 공유를 피할 수는 없지만
  참조 값을 공유해도 인스턴스의 값을 수정할 수 없으므로 부작용이 발생하지 않음

// 주소 불변 객체 
// 생성자로만 값을 설정하고 수정자를 만들지 않는 방법
@Embeddable
public class Address {

    private String city;
    
    protected Address() { // JPA에서 기본 생성자는 필수
    }
    
    // 생성자로 초기 값을 설정
    public Address(String city) {
        this.city = city
    }
    
    // 접근자(Getter)는 노출되므로 조회는 가능
    public String getCity() {
        return city;
    }
    
    // 수정자(Setter)는 만들지 않으므로 수정은 불가능
}

// 불변 객체 사용
// 만약 값을 수정해야 한다면 새로운 객체를 생성해서 사용
Address address = member1.getHomeAddress();
// 회원1의 주소값을 조회해서 새로운 주소값을 생성
Address newAddress = new Address(address.getCity());
member2.setHomeAddress(newAddress);

값 타입의 비교

• 자바가 제공하는 객체 비교는 2가지
  
  
  • 동일성 비교 : 인스턴스의 참조 값을 비교, == 사용
  • 동등성 비교 : 인스턴스의 값을 비교, equals() 사용

// int a의 숫자 10과 int b의 숫자 10은 같다고 표현
int a = 10;
int b = 10;

// Address a와 Address b는 같다고 표현
/* 이 때 a==b로 동일성 비교하면 둘은 서로 다른 인스턴스이므로 결과는 거짓
   이것은 기대하는 결과가 아니며, 값 타입은 인스턴스가 달라도 그 안에 값이 같으면 같은 것을 봐야 함
   따라서 값 타입을 비교할 때는 a.equals(b)를 사용해서 동등성을 비교해야 하므로 
   Address의 equals() 메소드를 재정의해야 하며 재정의할 때는 보통 모든 필드의 값을 비교하도록 구현 
   +) 자바에서 equals()를 재정의하면 hashCode()도 재정의하는 것이 안전 */
Address a = new Address("서울시", "종로구", "1번지");
Address b = new Address("서울시", "종로구", "1번지");

값 타입 컬렉션

• 값 타입을 하나 이상 저장하려면 컬렉션에 보관하고 @ElementCollection, @CollectionTable 어노테이션을 사용

// 값 타입 컬렉션
@Entity
public class Member {

    @Id @GeneratedValue
    private Long id;
    
    @Embedded
    private Address homeAddress;
    
    // 값 타입 컬렉션을 사용하는 favoriteFoods, addressHistory
    /* 기본값 타입인 String을 컬렉션으로 가지는 favoriteFoods :
       관계형 데이터베이스의 테이블은 컬럼 안에 컬렉션을 포함할 수 없으므로 
       별도의 테이블을 추가하고 @CollectionTable을 사용해서 추가한 테이블을 매핑
       favoriteFoods처럼 값으로 사용되는 컬럼이 하나면 @Column을 사용해서 컬럼명을 지정할 수 있음 */
    @ElementCollection
    @CollectionTable(name = "FAVORITE_FOODS", joinColumns = @JoinColumn(name = "MEMBER_ID"))
    @Column(name = "FOOD_NAME")
    private Set<String> favoriteFoods = new HashSet<String>();
    
    /* 임베디드 타입인 Address를 컬렉션으로 가지는 addressHistory
       별도의 테이블을 사용하며 테이블 매핑 정보는 @AttributeOverride를 사용해서 재정의 */
    @ElementCollection
    @CollectionTable(name = "ADDRESS", joinColumns = @JoinColum(name = "MEMBER_ID"))
    private List<Address> addressHistory = new ArrayList<Address>();
    // ...
}

@Embeddable
public class Address {

    @Column
    private String city;
    private String street;
    private String zipcode;
    // ...
}

• 값 타입 컬렉션 사용

// 값 타입 컬렉션 등록
Member member = new Member();

// 임베디드 값 타입
member.setHomeAddress(new Address("통영", "몽동해수욕장", "660-123"));

// 기본값 타입 컬렉션
member.getFavoriteFoods().add("짬뽕");
member.getFavoriteFoods().add("짜장");
member.getFavoriteFoods().add("탕수육");

// 임베디드 값 타입 컬렉션
member.getAddressHistory().add(new Address("서울", "강남", "123-123");)
member.getAddressHistory().add(new Address("서울", "강북", "000-000");)

// 마지막에 member 엔티티만 영속화하면 JPA는 member 엔티티의 값 타입도 함께 저장함
/* 그러므로 em.persist(member) 한 번 호출로 총 6번의 INSERT SQL을 실행
    1. member : INSERT SQL 1번
    2. member.homeAddress : 컬렉션이 아닌 임베디드 값 타입이므로 회원테이블을 저장하는 SQL에 포함
    3. member.favoriteFoods : INSERT SQL 3번
    4. member.addressHistory : INSERT SQL 2번 */
em.persist(member); 

// 실행된 SQL
INSERT INTO MEMBER(ID, CITY, STREET, ZIPCODE) VALUES (1, '통영', '몽돌해수욕장', '660-123')
INSERT INTO FAVORITE_FOODS (MEMBER_ID, FOOD_NAME) VALUES (1, '짬뽕')
INSERT INTO FAVORITE_FOODS (MEMBER_ID, FOOD_NAME) VALUES (1, '짜장')
INSERT INTO FAVORITE_FOODS (MEMBER_ID, FOOD_NAME) VALUES (1, '탕수육')
INSERT INTO ADDRESS(MEMBER_ID, CITY, STREET, ZIPCODE) VALUES (1, '서울', '강남', '123-123')
INSERT INTO ADDRESS(MEMBER_ID, CITY, STREET, ZIPCODE) VALUES (1, '서울', '강북', '000-000')

// 조회
// 값 타입 컬렉션도 조회할 때 패치 전략을 선택할 수 있는데 LAZY가 기본
// 지연 로딩으로 모두 설정했다고 가정하고 조회
// 1.member : SELECT SQL을 1번 호출해 회원만 조회하며, 이때 임베디드 값 타입인 homeAddres도 함께 조회됨
// SQL : SELECT ID, CITY, STREET, ZIPCODE FROM MEMBER WHERE ID 1
Member member = em.find(Member.class, 1L); 

// 2. member.homeAddress : 1번에서 회원을 조회할 때 같이 조회해 둠
Address homeAddress = member.getHomeAddress();

// 3. member.favoriteFoods : LAZY로 설정해서 실제 컬렉션을 사용할 때 SELECT SQL을 1번 호출
Set<String> favoriteFoods = member.getFavoriteFoods(); // LAZY

// SQL : SELECT MEMBER_ID, FOOD_ID FROM FAVORITE_FOODS WHERE MEMBER_ID = 1
for (String favoriteFood : favoriteFoods) {
    System.out.println("favoriteFood = " + favoriteFood);
}

// 4. member.addressHistory : LAZY로 설정해서 실제 컬렉션을 사용할 때 SELCT SQL을 1번 호출
List<Address> addressHistory = member.getAddressHistory(); // LAZY

// SQL : SELECT MEMBER_ID, CITY, STREET, ZIPCODE FROM ADDRESS WHERE MEMBER_ID = 1
addressHisotry.get(0);

// 수정
// 값 타입 컬렉션 수정
Member member = em.find(Member.class, 1L);

/* 1. 임베디드 값 타입 수정 : 
      homeAddress 임베디드 값 타입은 MEMBER 테이블과 매핑했으므로 MEMBER 테이블만 UPDATE 
      (즉, MEMBER 엔티티를 수정하는 것과 같음) */
member.setHomeAddress(new Address("새로운도시", "신도시1", "123456"));

/* 2. 기본값 타입 컬렉션 수정 :
      탕수육을 치킨으로 변경하려면 탕수육을 제거하고 치킨을 추가해야 함
      자바의 String 타입은 수정할 수 없음 */
Set<String> favoriteFoods = member.getFavoriteFoods();
favoriteFoods.remove("탕수육");
favoriteFoods.add("치킨");

/* 3. 임베디드 값 타입 컬렉션 수정 :
      값 타입은 불변해야 하므로 컬렉션에서 기존 주소를 삭제하고 새로운 주소를 등록
      참고로 값 타입은 equals, hashCode를 꼭 구현해야 함 */
List<Address> addressHisotry = member.getAddressHistory();
addressHistory.remove(new Address("서울", "기존 주소", "123-123"));
addressHisotry.add(new Address("새로운도시", "새로운 주소", "123-456"));

• 값 타입 컬렉션의 제약사항
  엔티티는 식별자가 있으므로 엔티티의 값을 변경해도 식별자로 데이터에비스에 저장된 원본 데이터를 쉽게 찾아서 변경 가능
  반면 값 타입은 식별자 개념이 없고 단순한 값들의 모음이므로 값을 변경하면 데이터베이스 저장된 원본 데이터를 찾기 어려움
  
  특정 엔티티 하나에 소속된 값 타입은 값이 변경되어도 자신이 소속된 엔티티를 데이터베이스에서 찾고 값을 변경하면 됨
  값 타입 컬렉션의 경우 값 타입 컬렉션에 보관된 값 타입들은 별도의 테이블에 보관되므로
  여기에 보관된 값 타입의 값이 변경되면 데이터베이스에 있는 원본 데이터를 찾기 어렵다는 문제가 발생
  
  이런 문제로 인해 JPA 구현체들은 값 타입 컬렉션에 변경 사항이 발생하면, 값 타입 컬렉션이 매핑된 테이블의 연관된
  모든 테이터를 삭제하고, 현재 값 타입 컬렉션 객체에 있는 모든 값을 데이터베이스에 다시 저장

// 예) 식별자가 100번인 회원이 관리하는 주소 값 타입 컬렉션을 사용하면
// SQL 같이 테이블에서 회원 100번과 관련된 모든 주소 데이터를 삭제하고
// 현재 값 타입 컬렉션에 있는 값을 다시 저장
// 여기서는 현재 값 타입 컬렉션에 주소가 2건 있어서 2번 INSERT됨
DELETE FROM ADDRESS WHERE MEMBER_ID = 100
INSERT INTO ADDRESS (MEMBER_ID, CITY, STREET, ZIPCODE) VALUES (100, ...)
INSERT INTO ADDRESS (MEMBER_ID, CITY, STREET, ZIPCODE) VALUES (100, ...)

 

• 추가로 값 타입 컬렉션을 매핑하는 모든 테이블은 모든 컬럼을 묶어서 기본 키를 구성해야 함
  따라서 데이터베이스 기본 키 제약 조건으로 인해 컬럼에 null을 입력할 수 없고, 같은 값을 중복해서 저장할 수 없는 제약 존재
  
  그러므로 실무에서는 값 타입 컬렉션이 매핑된 테이블에서 데이터가 많다면 값 타입 컬렉션 대신 일대다 관계를 고려
  또한 여기에 추가로 영속성 전이 + 고아 객체 제거 기능을 적용하면 값 타입 컬렉션처럼 사용할 수 있음

// 값 타입 컬렉션 대신 일대다 관계 사용
@Entity
public class AddressEntity {

    @Id
    @GeneratedValue
    private Long id;
    
    @Embedded 
    Address address;
   
    ...
}

// 설정 코드
@OneToMany(cascade = CascadeType.ALL, orphanRemoval = true)
@JoinColumn(name = "MEMBER_ID")
private List<AddressEntity> addressHistory = new ArrayList<AddressEntity>();

// 예) 식별자가 100번인 회원이 관리하는 주소 값 타입 컬렉션을 사용하면
// SQL 같이 테이블에서 회원 100번과 관련된 모든 주소 데이터를 삭제하고
// 현재 값 타입 컬렉션에 있는 값을 다시 저장
// 여기서는 현재 값 타입 컬렉션에 주소가 2건 있어서 2번 INSERT됨
DELETE FROM ADDRESS WHERE MEMBER_ID = 100
INSERT INTO ADDRESS (MEMBER_ID, CITY, STREET, ZIPCODE) VALUES (100, ...)
INSERT INTO ADDRESS (MEMBER_ID, CITY, STREET, ZIPCODE) VALUES (100, ...)