엔티티 매핑
엔티티 매핑
| 객체와 테이블 매핑 | @Entity, @Table |
| 필드와 컬럼 매핑 | @Column |
| 기본 키 매핑 | @Id |
| 연관관계 매핑 | @ManyToOne, @JoinColumn |
@Entity
- Entity가 붙은 클래스는 JPA가 관리, 엔티티라 함
- JPA를 사용해서 테이블과 매필할 클래스는 @Entity 필수
- 기본 생성자 필수
- final 클래스, enum, interface, inner클래스 사용 x
데이터베이스 스키마 자동 생성
- DDL을 애플리케이션 실행 시점에 자동 생성
- 테이블중심 -> 객체 중심
- 데이터베이스 방언을 활용해서 데이터베이스에 맞는 적절한 DDL 생성
- 생성된 DDL은 개발 장비에서만 사용
- 생성된 DDL은 운영서버에서는 사용 X, 다듬어서 사용
기본 키 매핑 방법
직접 할당: @Id만 사용
자동 생성(@GeneratedValue)
- IDENTITY: 데이터베이스에 위임, MYSQL
- SEQUENCE: 데이터베이스 시퀀스 오브젝트 사용, ORACLE @SequenceGenerator필요
- TABLE: 키 생성용 테이블 사용, 모든 DB에서 사용 @TableGenerator필요
- AUTO: 방언에 따라 자동 지정, 기본값
권장하는 식별자 전략
- 기본 키 제약 조건: null 아님, 유일, 변하면 안 됨
- 권장: Long 형 + 대체키 + 키 생성 전략사용
다양한 연관관계 매핑
테이블
- 외래 키 하나로 양쪽 조인 가능
- 사실 방향이라는 개념이 없음
객체
- 참조용 필드가 있는 쪽으로만 참조 가능
- 한쪽만 참조하면 단방향
- 양쪽이 서로 참조하면 양방향
다대일[N:1]
다대일 단방향 -> 가장 많이 사용하는 연관관계, 다대일의 반대는 일대다
if) 사람 : 팀
@Entity
public class Member{
@Id
@GeneratedValue
private Long id;
private String username;
@ManyToOne // 다대일
@JoinColumn(name = "team_id") // 외래키 주인은 다
private Team team;
}중요 포인트는 외래키의 주인은 다대일에서 다가 같는다.
다대일 양방향 -> 양쪽을 서로 참조하도록 개발
@Entity
public class Team {
@Id @GeneratedValue
@Column(name = "team_id")
private Long id;
private String name;
@OneToMany(mappedBy = "team")
private List<Member> members = new ArrayList<>();
}mappedBy를 사용 -> 읽기 전용
일대대[1:N]
일대다 단방향 일이 연관관계의 주인
객체와 테이블의 차이 때문에 반대편 테이블의 외래 키를 관리하는 특이한 구조
일대다 단방향 매핑의 단점
- 엔티티가 관리하는 외래 키가 다른 테이블에 있음
- 연관관계 관리를 위해 추가로 UPDATE SQL 실행
- 일대다 단방향 매핑보단 다대일 양방향 매핑을 사용
일대다 양방향
이런 매핑은 공식적으로 존재 X
@JoinColumn(insertable = false, updatable = false)
읽기 전용 필드를 사용해서 양방향처럼 사용하는 방법
다대일 양방향을 사용하자
일대일 [1:1]
일대일 관계는 그 반대도 일대일
주 테이블 or 대상 테이블에 외래키를 선택할 수 있다
외래 키에 데이터베이스 유니크(UNI) 제약조건 추가
일대일 주 테이블 단방향
@Entity
public class Member{
@Id @GeneratedValue
@Column(name = "member_id")
private Long id;
@Column(name = "username")
private String name;
@OneToOne
@JoinColumn(name = "locker_id")
private Locker locker;
}다대일 단방향 매핑과 유사하다.
일대일 주 테이블 양방향
@Entity
public class Locker {
@Id
@GeneratedValue
private Long id;
private String name;
@OneToOne(mappedBy = "locker")
private Member member;
}
다대일 양방향 매핑처럼 외래 키가 있는 곳이 연관관계의 주인이 된다.
반대편은 mappedBy적용 -> 읽기 전용
일대일 정리
주 테이블에 외래 키
- 주 객체가 대상 객체의 참조를 가지는 것처럼 주 테이블에 외래 키를 두고 대상 테이블을 찾음
- 객체지향 개발자 선호
- JPA 매핑 편리
- 장점: 주 테이블만 조회해도 대상 테이블에 데이터가 있는지 확인 가능
- 단점: 값이 없으면 외래 키에 null 허용
대상 테이블에 외래 키
- 대상 테이블에 외래 키가 존재
- 전통적인 데이터베이스 개발자 선호
- 장점: 주테이블과 대상 테이블을 일대일에서 일대다 관계로 변경할 때 테이블 구조 유지
- 단점: 프록시 기능의 한계로 지연로딩으로 설정해도 항상 즉시 로딩됨
다대다 [N:N]
다대다가 존재하긴 함
@JoinTable로 연결테이블을 지정해 줌
@ManyToMany 제약: 필드 추가 X, 엔티티 테이블 불일치
실무에서 사용 X
따라서 중간계층을 두고 일대다 + 다대일로 만들어야 함
상속관계 매핑
관계형 데이터베이스는 상속관계 x
슈퍼타입 서브타입 관계라는 모델링 기법이 객체의 상속과 유사
- 각각 테이블로 변환 -> 조인 전략
- 통합 테이블로 변환 -> 단일 테이블 전략
- 서브타입 테이블로 변환 -> 구현 클래스마다 테이블 전략
@Inheritance(strategy=InheritanceType.xxx)
- JOINED: 조인 전략
- SINGLE_TABLE: 단일 테이블 전략
- TABLE_PER_CLASS: 구현 클래스마다 테이블 전략
@DiscriminatorColumn(name="DTYPE")
- 분류 테이블을 DTYPE으로 설정 default값임
@DiscriminatorValue("XXX")
- 분류된 클래스들에 해당하는 이름을 설정
조인 전략
장점
- 테이블 정규화
- 외래 키 참조 무결성 제약조건 활용가능
- 저장공간 효율화
단점
- 조회 시 조인을 많이 사용, 성능 저하
- 조회 쿼리가 복잡함
- 데이터 저장 시 INSERT SQL 2번 호출
단일 테이블 전략
장점
- 조인이 필요 없으므로 일반적으로 조회 성능이 빠름
- 조회 쿼리가 단순함
단점
- 자식 엔티티가 매핑한 컬럼은 모두 null허용
- 단일 테이블에 모든 것을 저장하므로 테이블이 커질 수 있다.
- 상황에 따라서 조회 성능이 오히려 느려질 수 있다.
구현 클래스마다 테이블 전략
추천 x
장점
- 서브 타입을 명확하게 구분해서 처리할 때 효과적
- not null 제약조건 사용 가능
단점
- 여러 자식 테이블을 함께 조회할 때 성능이 느림
- 자식 테이블을 통합해서 쿼리 하기 어려움
@MappedSuperclass
- 상속관계 매핑 X
- 엔티티 X, 테이블과 매핑 X
- 부모 클래스를 상속받는 자식 클래스에 매핑 정보만 제공
- 조회, 검색 불가
- 직접 생성해서 사용할 일이 없으므로 추상 클래스 권장
- 테이블과 관계없고, 단순히 엔티티가 공통으로 사용하는 매핑 정보를 모으는 역할
- 주로 등록일, 수정일, 등록자, 수정자 같은 전체 엔티티에서 공통으로 적용하는 정보를 모을 때 사용
@MappedSuperclass
public abstract class BaseEntity {
private String createdBy;
private LocalDateTime createdDate;
}공통 매핑 정보가 필요할 때 사용
@Entity
public class Member extends BaseEntity{
@Id @GeneratedValue
@Column(name = "member_id")
private Long id;
@Column(name = "username")
private String name;
}사용한 곳에 extends 해서 사용