Home JPA 데이터 타입 - 값 타입
Post
Cancel

JPA 데이터 타입 - 값 타입

Posted Jan 7, 2024 Updated Feb 13, 2024
By
16 min read

JPA의 데이터 타입 분류

  • 엔티티 타입
    • @Entity로 정의하는 객체
    • 데이터가 변해도 식별자로 지속해서 추적 가능하다.
      • ex) Member 엔티티의 나이 같은 값을 변경해도 식별자로 인식 가능
  • 값 타입
    • int, Integer, String과 같이 단순히 값으로 사용하는 자바 기본 타입이나 객체
    • 식별자가 없고 값만 존재하므로 값이 변경됐을 시 추적 불가.
      • ex) 숫자 100을 200으로 변경했을 시 완전히 다른 값으로 대체된다.

값 타입의 분류

  • 기본 값 타입
    • 자바 기본 타입(int, double …)
    • 래퍼 클래스(Integer, Long …)
    • String
  • 임베디드 타입(embedded type, 복합 값 타입)
    • ex) (x,y) 좌표 값을 사용하는 Point 클래스 (구현 클래스)
  • 컬렉션 값 타입(collection value type)

기본 값 타입

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

자바의 기본 타입은 절대 공유되지 않는다.

  • int, double 같은 기본 타입은 절대 공유되지 않는다.
  • 기본 타입은 항상 값을 복사한다.
    • a=b를 해도 값을 복사해 서로 다른 저장공간을 가지고 있는 것.
  • Integer 같은 래퍼 클래스나 String 같은 특수한 클래스는 공유 가능한 객체이지만 변경이 안되기 때문에 부작용이 없다.
1
2

Integer a = 10;
Integer b = a;

이 과정에서는 값을 복사하는 것이 아닌 참조값이 넘어간다. 하지만 a의 값을 변경할 방법이 없기 때문에 부작용이 없는 것이다.

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

  • ex) Point p
  • int, String과 같은 값 타입이다.

startDate와 endDate로 workPeriod로 묶을 수 있고 city, street, zipcode를 homeAddress 묶을 수 있다. 이런 경우의 workPeriod, homeAddress 타입을 임베디드 타입이라고 부른다.

사용 방법

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

@Entity
public class Member {

	@Id @GeneratedValue
	@Column(name = "MEMEBER_ID")
	private Long id;

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

	private LocalDateTime startDate;
	private LocalDateTime endDate;

	private String city;
	private String street;
	private String zipcode;
}

위와 같이 되어 있던 코드를 아래와 같이 수정하는 것이다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

@Entity
public class Member {

	@Id @GeneratedValue
	@Column(name = "MEMEBER_ID")
	private Long id;

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

	@Embedded
	private Period period;

	@Embedded
	private Address address;
}

1
2
3
4
5

@Embeddable
public class Period {
	private LocalDateTime startDate;
	private LocalDateTime endDate;
}

이렇게 하면 DB에서 테이블 자체의 속성은 startDate, endDate, city 등이 유지되지만 코드를 객체지향적으로 사용할 수 있다.

정리

  • 장점
    • 재사용이 가능하다.
    • 높은 응집도
    • Period.isWork() 처럼 해당 값 타입만 사용하는 의미있는 메서드를 만들 수 있다.
    • 임베디드 타입을 포함한 모든 값 타입은 값 타입을 소유한 엔티티에 생명주기를 의존한다.
  • 정리
    • 임베디드 타입은 엔티티의 값일 뿐이다.
    • 임베디드 타입을 사용하기 전과 후의 매핑하는 테이블에는 차이가 없다.
    • 객체와 테이블을 아주 세밀하게 매핑하는 것이 가능하다.
    • 따라서 잘 설계된 ORM 애플리케이션은 매핑한 테이블의 수보다 클래스의 수가 더 많다.

  • Member 엔티티는 Address와 PhoneNumber라는 임베디드 타입을 갖고 있다.
  • Address 임베디드 타입은 Zipcode 임베디드 타입을 가질 수 있다.
  • PhoneNumber 임베디드 타입은 PhoneEntity 엔티티 타입을 가질 수 있다.
    • PhoneNumber가 PhoneEntity FK 값을 들고 있는 것이다.

주의

1
2
3
4
5

@Embedded
private Address homeAddress;

@Embedeed
private Address workAddress;

이렇게 하나의 엔티티에서 같은 값 타입을 사용한다면 컬럼 명이 중복되어 오류가 발생한다.

이런 경우 @AttributeOverrides, @AttributeOverride를 사용해 컬럼 명 속성을 재정의 한다.

1
2
3
4
5
6
7
8
9
10

@Embedded
@AttributeOverrides({
		@AttributeOverride(name="city",
				column=@Column("WORK_CITY")),
		@AttributeOverride(name="street",
				column=@Column("WORK_STREET")),
		@AttributeOverride(name="zipcode",
				column=@Column("WORK_ZIPCODE"))
})
private Address workAddress;
  • 추가로 임베디드 타입의 값이 null이면 매핑한 컬럼 값은 모두 null이다.

값 타입과 불변 객체

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

값 타입 공유 참조

  • 임베디드 타입 같은 값 타입을 여러 엔티티에서 공유하면 위험하다. 부작용이 발생한다.

1
2
3
4
5
6
7
8
9
10
11
12

Address address = new Address("OldCity", "street", "10000");

Member member1 = new Member();
member1.setHomeAddress(address);
em.persist(member1);

Member member2 = new Member();
member.setHomeAddress(address);
em.persist(member2);

member1.getHomeAddress().setCity("newCity");
//member1의 주소를 가져와 city를 변경했다.

개발자의 의도는 member1의 city만 바꾸고 싶었던 것인데, 실행해보면 update 쿼리가 두 번 발생해 member1, member2 둘 다 city가 변경된다.

따라서 임베디드 타입 같은 값 타입을 여러 엔티티에서 공유하면 위험하다.

보완 방법: 값 타입의 복사

  • 값 타입의 실제 인스턴스를 공유하는 것은 위험하다.
  • 대신 값을 복사해서 사용한다.
1
2
3
4
5

Address address = new Address("OldCity", "street", "10000");
member1.setHomeAddress(address);

Address copyAddress = new Address(address.getCity(), address.getStreet(), address.getZipcode());
member2.setHomeAddress(copyAddress);

이렇게 하면 member1의 address를 수정해도 member2의 address는 값만 복사해 사용한 것이기 때문에 영향을 끼치지 않는다.

(그러나) 객체 타입의 한계

  • 임베디드 타입처럼 직접 정의한 값 타입은 자바의 기본 타입이 아니라 객체 타입이다.
    • 자바의 기본 타입에 값을 대입하면 값을 복사한다.
    • 하지만 객체 타입은 참조 값을 직접 대입하는 것을 막을 수 있는 방법이 없다.
      • 위의 예시에서도 참조 값을 직접 대입하는 것을 막을 수 없다.
      • Address copyAddress = address;
    • 객체의 공유 참조를 피할 수 없는 것이다.

컴파일러 단에서 이러한 부분을 발견하고 막을 수 있는 방법이 없다. 따라서 문제가 발생하면 찾기 힘들다.

따라서 불변 객체로 설계해야 한다.

불변 객체

  • 객체 타입을 수정할 수 없게 만들면 부작용을 원천 차단할 수 있다.
  • 따라서 값 타입은 불변 객체로 설계해야 한다.
    • 생성 시점 이후 절대 값을 변경할 수 없도록.
  • 생성자로만 값을 설정하고 수정자(Setter)를 만들지 않으면 된다.
  • 참고: Integer, String은 자바가 제공하는 대표적인 불변 객체이다.

불변에 대한 내용(방법, 컬렉션 등)은 더 알아보아야 한다.

값 타입의 비교

  • 인스턴스가 달라도 그 안의 값이 같으면 같은 것으로 보아야 한다.

int 값에 ==을 사용하면 값이 같을 때 true를 반환한다. 하지만 Address같은 객체에 값을 같게 두 번 생성하여 비교해보면 false가 나오게 된다. 참조 값을 비교하기 때문이다.

즉 기본적으로는 값이 같아도 같은 것으로 보지 않는다는 뜻이다.

  • 동일성(identity) 비교: 인스턴스의 참조 값을 비교, == 사용
  • 동등성(equivalence) 비교: 인스턴스의 값을 비교, equals() 사용
  • 값 타입은 address1.equals(address2)와 같이 equals()를 사용하는 동등성 비교를 해야한다.
  • 값 타입의 equals() 메서드를 적절하게 재정의해서 동등성 비교를 해준다.
    • 주로 모든 필드를 전부 재정의 해주어야 한다.

값 타입 컬렉션

말 그대로 어떠한 값 타입을 컬렉션에 넣어 사용하는 경우를 뜻한다.

1
2

List<Address> ...
Set<String> ...

이러한 부분을 DB 테이블로 구현할 때 문제가 발생한다.

  • 데이터베이스는 컬렉션을 같은 테이블에 저장할 수 없다.
  • 컬렉션을 저장하기 위한 별도의 테이블이 필요하다.
    • @ElementCollection, @CollectionTable 사용
    • 값 타입을 하나 이상 저장할 때 사용한다.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

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

	//...

	@Embedded
	private Address homeAddress;

	@ElementCollection
	@CollectionTable(name = "FAVORITE_FOOD", joinColumns = 
		@JoinColumn(name = "MEMBER_ID")
	)
	private Set<String> favoriteFoods = new HashSet<>();

	@ElementCollection
	@CollectionTable(name = "ADDRESS", joinColumn = 
		@JoinColumn(name = "MEMBER_ID")
	)
	private List<Address> addressHistory = new ArrayList<>();

	//...
}

1
2
3
4
5
6
7
8
9
10
11

Member member = new Member();
member.setUsername("member1");
member.setHomeAddress(new Address("city1", "street", "10000");

member.getFavoriteFoods().add("치킨");
member.getFavoriteFoods().add("피자");

member.getAddressHistory().add(new Address(~));
member.getAddressHistory().add(new Address(~));

em.persist(member);

이러한 결과를 볼 수 있다.

기본적으로 값 타입 컬렉션도 지연 로딩 전략이 사용된다.

값 타입 컬렉션의 한계

  • 값 타입은 엔티티와 다르게 식별자 개념이 없다. 값이 변경되면 추적이 어렵다.
  • 값 타입 컬렉션에 변경 사항이 발생하면, 주인 엔티티와 연관된 모든 데이터를 삭제하고 값 타입 컬렉션에 있는 현재 값을 모두 다시 저장한다.
    • 기본적으로 불변이기 때문에 remove() 후 새로 추가하는 방식으로 update를 한다는 뜻.
  • 값 타입 컬렉션을 매핑하는 테이블은 모든 컬럼을 묶어 기본 키를 구성해야 한다.
    • 따라서 null 입력 X, 중복 저장 X
1
2
3
4
5
6

create table ADDRESS {
	MEMBER_ID bigint not null,
	city varchar(255),
	street varchar(255),
	zipcode varchar(255)
}

이런식의 쿼리가 생성되는데 현재 PK가 없는 것을 볼 수 있다. PK로 사용하려면 저 4개의 값을 묶어서 PK값으로 지정해야 된다.

매우 복잡하다.

값 타입 컬렉션 대안

  • 실무에서는 상황에 따라 값 타입 컬렉션 대신 일대다 관계를 고려한다.
    • 영속성 전이 + 고아 객체 제거를 사용해 값 타입 컬렉션 처럼 사용한다.
  • 값 타입 컬렉션을 사용하는 경우는 정말 단순한 경우이다.
    • 선호 음식을 입력받을 때 체크박스로 여러 개 받는 경우. 이렇게 추적할 필요도 없고 값이 바뀌어도 update할 필요가 없는 단순한 경우.
1
2
3
4
5
6
7

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

	private Address address; //값 타입
}

1
2
3
4
5
6
7
8

@Entity
public class Member {
	//...
	
	@OneToMany(cascade = CascadeType.ALL, orphanRemoval = true)
	@JoinColumn(name = "MEMBER_ID")
	private List<AddressEntity> addressHistory = new ArrayList<>();
}

위와 엔티티를 이용해 일대다 관계로 같이 바꿀 수 있다.

정리

  • 엔티티 타입의 특징
    • 식별자가 존재
    • 생명 주기 관리
    • 공유
  • 값 타입의 특징
    • 식별자가 없다
    • 생명 주기를 엔티티에 의존한다.
    • 공유하지 않는 것이 안전하다.
    • 불변 객체로 만드는 것이 안전하다.

값 타입은 정말 값 타입이라고 판단될 때만 사용한다. 엔티티와 값 타입을 혼동해 사용하면 안된다.

식별자가 필요하고 지속해서 값을 추적하고 변경해야 한다면 그것은 값 타입이 아닌 엔티티이다.

Spring, JPA 기본
java Spring SpringBoot
This post is licensed under CC BY 4.0 by the author.
Recently Updated
Contents