※ 본문은 김영한 선생님의 인프런 '자바 ORM 표준 JPA 프로그래밍 - 기본편' 강의를 듣고 정리한 내용임을 알립니다.
▶ Entity Mapping의 종류
- 객체와 테이블 매핑 : @Entity, @Table
- 필드와 컬럼 매핑 : @Column
- 기본 키 매핑 : @Id
- 연관관계 매핑 : @ManyToOne, @JoinColumn
▶ @Entity
- @Entity가 붙은 클래스는 JPA가 관리하는 Entity
- JPA를 사용해서 테이블과 매핑할 클래스는 @Entity 필수
- 주의사항1. 기본 생성자 필수 (파라미터 없는 public 또는 protected 생성자)
- 주의사항2. final 클래스, enum, interface, inner 클래스 사용 불가
- 주의사항3. 저장할 필드에도 final 사용 불가
※ @Table
: Entity와 매핑할 테이블 지정
: name, catalog, schema, uniqueConstraints(DDL) 설정 가능
※ 데이터베이스 스키마 자동 생성
(필드와 컬럼 매핑에 대한 이해를 돕기 위해 중간에 삽입되었음)
hibernate.hbm2ddl.auto
- DDL을 애플리케이션 실행 시점에 자동 생성
- 테이블 중심 → 객체 중심
- DB 방언을 활용해서 DB에 맞는 적절한 DDL 생성
- 이렇게 생성된 DDL은 개발 장비에서만 사용!
- 운영 서버에서는 생성된 DDL을 사용하지 않거나 적절히 다듬은 후 사용
- 데이터베이스 스키마 자동생성의 옵션들
옵션 | 설명 |
---|---|
create | 기존 테이블 삭제 후 다시 생성 (DROP + CREATE) |
create-drop | create와 같으나 애플리케이션 종료 시점에서 테이블 DROP |
update | 변경된 부분만 반영 (운영 DB에서는 사용하지 말 것!) |
validate | Entity와 테이블이 정상 매핑되었는지만 확인 |
none | 사용하지 않음 |
- 운영 장비에는 절대 create, create-drop, update 사용하면 안됨
- 개발 초기 단계는 create 또는 update 사용
- 테스트 서버는 update 또는 validate 사용
- 스테이징과 운영 서버는 validate 사용하거나 빼줌
- DDL 생성 기능은 DDL 자동 생성에만 사용되고 JPA의 실행 로직에는 영향을 주지 않음
▶ 필드와 컬럼 매핑
@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
private String description;
//Getter, Setter...
}
1. @Column
- 제일 중요하고 많이 쓰임
- 칼럼의 속성들
속성 | 설명 | 기본값 |
---|---|---|
name | 필드와 매핑할 테이블의 컬럼 이름 | 객체의 필드 이름 |
insertable, updatable |
등록, 변경 가능 여부 | true |
nullable(DDL) | null값의 허용 여부, false 설정 시 not null 제약 조건이 붙음 |
|
unique(DDL) | @Table의 uniqueConstraints와 같지만, 한 컬럼에 간단하게 유니크 제약조건을 걸 때 사용 |
|
columnDefinition(DDL) | DB 칼럼 정보를 직접 줄 수 있음 ex) varchar(100) default 'EMPTY' |
필드의 자바 타입 or 방언 정보 |
length(DDL) | 문자 길이 제약조건, String 타입에만 사용 가능 |
255 |
precision, scale(DDL) |
BigDecimal 타입이나 BigInteger 타입에서 사용 precision은 소수점을 포함한 전체 자릿수를, scale은 소수의 자릿수를 뜻함 참고로 double, float 타입에는 적용되지 않음 아주 큰 숫자나 정밀한 소수를 다루어야 할 때만 사용 |
precision = 19, scale = 2 |
2. @Enumerated
- 자바 enum 타입을 매핑할 때 사용
- ORDINAL은 웬만하면 사용X (혹시라도 나중에 enum 타입을 추가하게 되면 순서가 뒤엉킴)
속성 | 설명 | 기본값 |
---|---|---|
value | EnumType.ORDINAL : enum 순서를 DB에 저장 EnumType.STRING : enum 이름을 DB에 저장 |
EnumType.ORDINAL |
3. @Temporal
- 날짜 타입(java.util.Date / java.util.Calendar)을 매핑할 때 사용
- ※ LocalDate / LocalDateTime을 사용할 때는 생략 가능
속성 | 설명 | 기본값 |
---|---|---|
value | TemporalType.DATE : 날짜, DB date 타입과 매핑 TemporalType.TIME : 시간, DB time 타입과 매핑 TemporalType.TIMESTAMP : 날짜와 시간, DB timestamp 타입과 매핑 |
4. @Lob
- 데이터베이스 BLOB, CLOB 타입과 매핑
- 지정할 수 있는 속성이 따로 없으며, 매핑하는 필드 타입이 문자면 CLOB 매핑, 나머지는 BLOB 매핑
→ CLOB : String, char[], java.sql.CLOB
→ BLOB : byte[], java.sql.BLOB
5. @Transient
- 필드 매핑 X
- 데이터베이스에 저장 및 조회 X
- 주로 메모리 상에서만 임시로 어떤 값을 보관하고 싶을 때 사용
▶ 기본 키(Primary Key) 매핑
1. 기본 키 매핑 어노테이션
- 활용 예시
@Id @GeneratedValue(strategy = GenerationType.AUTO)
private Long id;
2. 기본 키 매핑 방법
- 직접 할당 : @Id만 사용
- 자동 생성 : @GeneratedValue도 같이 사용
★ @GeneratedValue의 strategy
- IDENTITY
└> 기본 키 생성을 데이터베이스에 위임
└> 주로 MySQL, PostgreSQL, SQL Server, DB2에서 사용
└> ex) MySQL의 AUTO_INCREMENT (DB에 INSERT SQL을 실행한 이후에 ID 값을 알 수 있음)
└> JPA는 보통 트랜잭션 커밋 시점에 INSERT SQL을 실행하지만,
IDENTITY 전략은 em.persist() 시점에 즉시 SQL 실행하고 DB에서 식별자를 조회
- SEQUENCE
└> 데이터베이스 시퀀스는 유일한 값을 순서대로 생성하는 특별한 데이터베이스 오브젝트
└> 오라클, PostgreSQL, DB2, H2 데이터베이스에서 사용
└> @SequenceGenerator 필요
다음은 SEQUENCE 전략 활용의 예시이다.
@Entity
@SequenceGenerator(
name = "MEMBER_SEQ_GENERATOR",
seqenceName = "MEMBER_SEQ",
initialValue = 1, allocationSize = 1)
public class Member {
@Id
@GeneratedValue(strategy = GenerationType.SEQUENCE,
generator = "MEMBER_SEQ_GENERATOR")
private Long id;
}
속성 | 설명 | 기본값 |
---|---|---|
name | 식별자 생성기 이름 | 필수로 지정해야 함 |
sequenceName | DB에 등록되어 있는 시퀀스 이름 | hibernate_sequence |
initialValue | DDL 생성 시에만 사용 시퀀스 DDL을 생성할 때 처음 시작하는 수를 지정 |
1 |
allocationSize | 시퀀스 한번 호출에 증가하는 수 성능 최적화에 사용됨 DB 시퀀스 값이 하나씩 증가하도록 설정되어 있으면 이 값을 반드시 1로 설정해야 함 |
50 |
catalog, schema | DB catalog, schema 이름 |
- TABLE
└> 키 생성 전용 테이블을 하나 만들어서 데이터베이스 시퀀스를 흉내내는 전략
└> 모든 데이터베이스에 적용 가능하지만 성능 최적화의 문제가 있어서 잘 사용되지 않음
└> @TableGenerator 필요
다음은 TABLE 전략 활용의 예시이다.
@Entity
@TableGenerator(
name = "MEMBER_SEQ_GENERATOR",
table = "MY_SEQUENCES",
pkColumnValue = "MEMBER_SEQ",
allocationSize = 1)
public class Member {
@Id
@GeneratedValue(strategy = GenerationType.TABLE,
generator = "MEMBER_SEQ_GENERATOR")
private Long id;
}
속성 | 설명 | 기본값 |
---|---|---|
name | 식별자 생성기 이름 | 필수로 지정해야 함 |
table | 키 생성 테이블명 | hibernate_sequence |
pkColumnName | 시퀀스 컬럼명 | sequence_name |
valueColumnName | 시퀀스 값 컬럼명 | next_val |
pkColumnValue | 키로 사용할 값 이름 | Entity 이름 |
initialValue | 초기값, 마지막으로 생성된 값이 기준 | 0 |
allocationSize | 시퀀스 한번 호출에 증가하는 수 성능 최적화에 사용됨 |
50 |
catalog, schema | DB catalog, schema 이름 | |
uniqueConstraints(DDL) | 유니크 제약조건을 지정 |
- AUTO
└> 방언에 따라 자동 지정 / 기본값 - 권장하는 식별자 전략
└> PK 기본 조건 : null일 수 없으며, 유일하고 변하면 안된다.
└> 몇년 동안 지속될 애플리케이션에서 이 조건을 만족하는 natural key를 찾기 어렵다.
└> 예를 들어 주민등록번호도 기본 키로 적절하지 않다.
└> 권장 : Long형 + 대체키(sequence, UUID 등) + 키 생성전략
▶ 연관관계 매핑
※ 중요한 용어 이해
- 방향(Direction) : 단방향, 양방향
- 다중성(Multiplicity) : 다대일(N:1), 일대다(1:N), 일대일(1:1), 다대다(N:M)
- 연관관계의 주인(Owner) : 객체 양방향 연관관계는 관리 주인이 필요
1. 단방향 연관관계
2. 양방향 연관관계 개념
※ JPA에서 가장 어려운 부분!
→ 객체와 테이블의 차이(참조와 외래 키 join 방식의 차이) 때문!
★ mappedBy는 @ManyToOne이나 @OneToMany, 서로의 반대편 사이드에 있는 변수를 사용한다.
★ 테이블의 연관관계는 방향 자체가 없고, 외래키 하나로 join을 하면 양쪽 다 알 수 있게 되지만, 문제는 객체
→ 객체 입장에서의 양방향 연관관계는 사실, 단방향 연관관계가 2개 있는 것이다.
→ 객체의 양방향 연관관계는 reference가 양쪽에 다 있어야 한다.
=> 여기에서 오는 딜레마 : 한쪽의 값을 바꾸어야 할 때 어느 쪽의 참조 값을 바꾸어야 하는가?
3. 양방향 연관관계의 주인 (Owner)
: 객체의 두 관계 중 하나를 연관관계의 주인으로 지정
- 연관관계의 주인만이 외래 키를 관리(등록 / 수정)하며, 주인이 아닌 쪽은 읽기만 가능
- 주인은 mappedBy를 사용하지 않고, 주인이 아니면 mappedBy 속성으로 주인을 지정
- 가이드라인 : 외래 키(Foreign Key)가 있는 곳을 주인으로 정해라. (Many 쪽을 주인으로)
★ 양방향 매핑에서 가장 많이 하는 실수 : 연관관계의 주인에 값을 입력하지 않았을 경우
- 순수 객체 상태를 고려해서 양쪽에 값을 설정해야 함
- 연관관계 편의 메소드를 생성해서 깜빡하지 않도록 할 것
- 연관관계 편의 메소드는 1에 넣어도 되고 N에 넣어도 되지만 양쪽 다 넣으면 로직이 꼬일 수 있음
★ 양방향 매핑에서 주의사항 : toString(), lombok, JSON 생성 라이브러리로 인한 무한 루프에 조심할 것!
- 양방향 매핑에서 toString()이나 lombok의 toString 기능은 지양할 것
- JSON 생성 라이브러리 문제는 Controller에서 Entity를 반환하지 않도록 할 것
★ 양방향 연관관계 매핑 정리
- JPA에서의 설계 : 단방향 매핑만으로도 이미 연관관계 매핑 완료 (반대 방향으로의 조회 기능만 추가될 뿐)
- JPQL에서 역방향 탐색이 많이 필요하기 때문에 양방향 매핑이 필요하게 됨
=> 단방향 매핑만 잘 해두고 양방향 매핑은 필요할 때 추가해도 됨 (테이블에는 영향을 주지 않기 때문에)
※ 다대일 (N:1)
- 가장 많이 사용하는 연관관계
- 양방향으로 매핑 시, 외래 키가 있는 쪽이 연관관계의 주인
※ 일대다 (1:N) - 1이 연관관계의 주인일 경우
- 표준 스펙에서 지원하지만 권장하지 않음
- @JoinColumn을 꼭 사용해야 하며, 그렇지 않을 경우 테이블을 새로 만들게 됨
- 연관관계 관리를 위해 추가로 UPDATE SQL 실행
- 양방향 매핑은 공식적으로 존재하지 않지만, 읽기 전용 필드를 사용해서 양방향처럼 사용할 수는 있음
※ 일대일 (1:1)
- 외래 키를 어디에 둘지 선택 가능 (주 테이블 / 대상 테이블)
- 외래 키에 데이터베이스 유니크 제약조건을 추가할 것
- 주인과 대상을 정하면 다대일 관계와 상당히 유사하게 볼 수 있음
- 주 테이블은 많이 액세스하는 테이블로 정의하면 편리함
- 주 테이블에 외래 키를 두는 방법이 객체지향의 설계라고 볼 수 있고, JPA 매핑이 편리
※ 다대다(N:M)
- 관계형 데이터베이스는 정규화된 테이블 2개로 다대다 관계를 표현할 수 없음 (연결 테이블이 필요)
- 하지만 객체는 다대다 관계가 가능하기에 딜레마가 옴
- 연결 테이블이 단순히 연결만 하고 끝나지 않기에, 중요한 데이터 노출의 위험이 있으며 쿼리가 복잡해짐
- 연결 테이블 전용 Entity를 만들고 @OneToMany, @ManyToOne으로 연결해주는 방식으로 돌아갈 것
▶ 상속관계 매핑
- 객체는 상속관계가 있지만 관계형 데이터베이스는 상속관계가 없음
- 따라서 슈퍼타입 / 서브타입 관계라는 모델링 기법을 사용
▶ 슈퍼타입 / 서브타입 논리 모델을 실제 물리 모델로 구현하는 3가지 방법
@Inheritance(strategy = InheritanceType.XXX)
1. 각각 테이블로 변환 (join 전략) - InheritanceType.JOINED
- 장점
- 테이블 정규화
- 외래 키 참조 무결성 제약조건 활용 가능
- 저장공간 효율화
- 단점
- 조회 시 join을 많이 사용하므로 조회 쿼리가 복잡하고 성능 저하 이슈가 있음
- 데이터 저장 시 INSERT SQL 2번 호출
★ 정석이라고 보면 됨 / 객체지향 설계에도 맞고 DB 정규화도 되기 때문에
2. 통합 테이블로 변환 (단일 테이블 전략) - InheritanceType.SINGLE_TABLE
- 장점
- join이 필요없으므로 조회 쿼리가 단순하여 조회 성능이 빠름
- 단점
- 자식 Entity가 매핑할 컬럼은 모두 null 허용
- 모든 것을 저장하므로 테이블이 커지게 되기에, 오히려 조회 성능이 느려질 수도 있음
3. 서브타입 테이블로 변환 (구현 클래스마다의 테이블 전략) - InheritanceType.TABLE_PER_CLASS
- 장점
- 서브 타입을 명확하게 구분해서 처리할 때 효과적
- not null 제약조건 사용 가능
- 단점
- 여러 자식 테이블을 함께 조회할 때 성능이 느림 (UNION SQL 필요)
- 자식 테이블을 통합해서 쿼리하기 어려움
★ 이 전략은 DB 설계자와 ORM 전문가 둘 다 추천하지 않음!
※ 주요 어노테이션
- @Inheritance(strategy = InheritanceType.XXX)
- @DiscriminatorColumn(name = "dtype")
- @DiscriminatorValue("타입값") - 기본값은 Entity의 이름
★ @MappedSuperclass
- 공통 매핑 정보가 필요할 때 사용 (id, name)
- 쉽게 말해서, 공통으로 갖는 똑같은 타입을 일일이 적기 귀찮을 때 사용하는 기능
- 상속관계 매핑이 아님
- Entity가 아니므로 테이블과 매핑할 수도 없음
- 부모 클래스를 상속받는 자식 클래스에 매핑 정보만 제공
- 조회 및 검색 불가
- 직접 생성해서 사용할 일이 없으므로 추상 클래스 권장
- 사용 예시 타입 : 등록일 / 수정일 / 등록자 / 수정자
- 따라서 @Entity 클래스는 @Entity나 @MappedSuperclass로 지정한 클래스만 상속 가능하다는 뜻
'JVM > JPA' 카테고리의 다른 글
객체지향 쿼리 언어 (JPQL) (0) | 2021.04.18 |
---|---|
값 타입 (0) | 2021.04.16 |
Proxy와 연관관계 관리 (0) | 2021.04.16 |
영속성 관리 (0) | 2021.04.11 |
JPA란? (0) | 2021.04.10 |