일반적으로 관계형 DB에서는 객체지향 언어에서 다루는 "상속"이라는 개념이 존재하지 않는다 그대신 "슈퍼타입 - 서브타입"같은 모델링 기법을 통해서 우회적으로 상속을 구현할 수 있다 슈퍼타입 - 서브타입 논리적 모델을 실제 DB에 들어가는 물리적 모델로 구현하는 방법은 총 3가지가 존재한다 "각각 테이블"로 변환 "통합 테이블"로 변환 "서브타입 테이블"로 변환 1. 각각 테이블로 변환 - "조인 전략 (Super Type + Sub Type)" 조인 전략이란 엔티티 각각을 일단 모두 테이블로 만들어준다 그리고 "자식 테이블"은 부모 테이블의 PK를 자신의 PK이자 FK로 사용한다 조회할때는 당연히 Join을 많이 사용하게 된다 >> @Inheritance(strategy = InheritanceType..

관계형 데이터베이스에서는 애초에 "정규화된 테이블" 2개로 다대다 관계를 표현할 수 없다 따라서 다대다 관계를 {일대다 - 다대일}로 풀어주는 "연결 테이블"을 사용한다 Member & Product는 다대다 관계이므로 "Member_Product"라는 연결 테이블을 통해서 {일대다 - 다대일}로 풀어버렸다 하지만 객체에서는 객체 2개로 "다대다 관계"를 만들어낼 수 있다 각 객체마다 상대방 객체를 컬렉션화 시켜서 관리하면 된다 1. 다대다 단방향 Member (N - 주인) @Getter @NoArgsConstructor(access = AccessLevel.PROTECTED) @Entity @Table(name = "member") public class Member { @Id @GeneratedVa..

일대일 관계는 양쪽이 서로 하나의 관계만 가지는 관계이다 따라서 일대일 관계에서는 "어느 쪽이든 FK를 가질 권리"를 보유하고 있다 참고로 일대일 연관관계에서 FK에는 반드시 UNIQUE도 추가해줘야 한다 왜냐하면 UNIQUE 제약조건을 추가해주지 않으면 일대일이 아니라 일대다가 되기 때문이다 1. 주 테이블 FK 일반적으로 "개발자" 입장에서는 주 테이블에 FK가 있는 것을 선호한다 왜냐하면 주 테이블에 FK가 있어야 더 편리하게 매핑할 수 있기 때문이다 대상 테이블에 FK가 존재한다면 본인이 아닌 상대방의 column을 관리해야 하기 때문 (1) 주 테이블 FK - 단방향 일반적으로 생각해보면 "User는 Ticket 하나를 소유할 수 있다"이므로 User를 "주테이블"로 생각해서 매핑해보자 User..

일대다 관계는 다대일 관계 반대 방향이다 일대다 관계는 엔티티를 하나 이상 참조할 수 있으므로 자바 컬렉션(Collection, List, Set, Map)중에 하나를 사용해서 관리해야 한다 현재 포스팅에서의 도메인간 관계는 다음과 같다 - 하나의 User는 여러개의 Locker를 가질 수 있다 - 하나의 Locker는 하나의 User에 의해서만 소유될 수 있다 1. 일대다 단방향 일대다 단방향은 특이하게 일(1)쪽에서 상대(N) 엔티티의 외래키를 관리하는 구조로 이루어져 있다 보통 자신이 매핑한 테이블의 FK를 관리하는데 이 경우는 반대쪽 테이블에 있는 FK를 관리하는 특이항 구조이다 왜냐하면 FK는 반드시 "다"쪽에 있어야 하는데 "다"쪽인 Locker를 보면 현재 FK를 매핑할 수 있는 참조 필드가..

당연하지만 다대일 관계의 반대는 항상 일대다 관계이고 일대다 관계의 반대는 항상 다대일이다 DB Table에서 {일(1) & 다(N)} 관계에서 FK는 항상 다(N)쪽에 존재한다. 따라서 객체 양방향 관계에서 연관관계의 주인은 항상 다(N)쪽이다 1. 다대일 단방향 다대일 단방향은 가장 많이 사용하는 연관관계이고 가장 대표적인 연관관계이다 당연히 다대일 연관관계의 반대는 일대다이다 Member(N) @Getter @NoArgsConstructor(access = AccessLevel.PROTECTED) @Entity @Table(name = "member") public class Member { @Id @GeneratedValue(strategy = GenerationType.IDENTITY) @Col..

객체는 "참조"를 사용해서 관계를 맺고, 테이블은 "외래키(FK")를 통해서 관계를 맺는다 따라서 우리는 "객체의 참조"와 "테이블의 FK"를 매핑시켜야 한다 JPA를 사용하려면 반드시 알아야하고 이해해야 하는 부분이고 가장 어려운 부분이다 방향 방향에는 [단방향 & 양방향]이 존재한다 위의 예제는 "단방향"이고 이를 {객체 참조 - 테이블 FK}로 매핑하면 다음과 같다 @Entity @Table(name = "member") public class Member { @Id @GeneratedValue(strategy = GenerationType.IDENTITY) @Column(name = "member_id") private Long id; @Column(length = 10) private Strin..

JPA에서 가장 중요한 작업은 "Entity와 Table을 정확히 매핑"하는 것이다 엔티티 매핑 : @Entity Entity는 정의한 domain에 붙여주는 것이다 @Entity를 붙인 domain은 JPA가 관리하는 domain이 된 것이다 연관관계 & column명 & ... 등은 추후에 설명 속성 @Entity에는 적용할 수 있는 속성이 "name" 1가지이다 name이란 JPA에서 사용할 Entity 이름을 지정한다 default는 클래스 이름을 그대로 사용한다 다른 패키지에 이름이 동일한 Entity가 존재한다면 이 name을 활용해서 구분해줘야 한다 >> 나중에 JPQL에서 엔티티를 대상으로 쿼리를 생성하기 때문에 도메인끼리 겹치는 이름이 존재할 경우 name으로 반드시 구분해줘야 한다 (패..

EntityManagerFactoroy & EntityManager EntityManagerFactory는 이름 그대로 "EntityManager"를 생산하는 공장이라고 보면 된다 일반적으로 DB를 하나만 사용하는 Application은 EntityManagerFactory 또한 하나만 생성한다 EntityManagerFactory는 여러 thread가 동시에 접근해도 thread-safe하므로, 서로 다른 thread간에 공유가 가능하다. 하지만 EntityManager는 내부에 "DataSource(Connection Pool)"를 유지하면서 DB와 통신하기 때문에 서로 다른 thread간에 절대로 공유하면 안된다 EntityManager는 User의 Request별로 하나씩 생성이 된다 영속성 컨텍..