[스프링부트와 JPA 활용1] 2. 도메인 설계 + 직접 DB 그려보기

본 게시글은 하단 강의를 듣고 학습한 내용을 제 생각으로 요약, 정리한 글입니다.
실전! 스프링 부트와 JPA 활용1 - 웹 애플리케이션 개발 - 인프런 | 강의
초급자를 위해 준비한 [웹 개발, 백엔드] 강의입니다. 실무에 가까운 예제로, 스프링 부트와 JPA를 활용해서 웹 애플리케이션을 설계하고 개발합니다. 이 과정을 통해 스프링 부트와 JPA를 실무에서 어떻게 활용해야 하는지 이해할 수 있습니다. 스프링 부트, 실무에서 잘 쓰고 싶다면? 깊이있는 설계와 개발을 경험해 보세요. 본 강의는 자바 백엔드 개발의 실전 코스를 시작하는 첫 강의입니다.
https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81%EB%B6%80%ED%8A%B8-JPA-%ED%99%9C%EC%9A%A9-1

1. 요구사항 분석

회원 → 회원 가입, 회원 목록

이름, 도시, 거리, 우편번호

상품 → 상품 등록, 상품 목록

상품명, 가격, 수량, 저자, ISBN

주문(회원+상품) → 상품 주문, 주문 내역

주문회원, 상품명, 가격, 주문수량, 상태, 일시

2. 도메인 모델과 테이블 설계

1. 과정 간단 정리

게시글 작성자가 직접 만든 표입니다. 퍼갈 시 출처로 블로그 링크 첨부 바랍니다.

2. ERD

게시글 작성자가 직접 만든 그림입니다. 퍼갈 시 출처로 블로그 링크 첨부 바랍니다.

3. 스키마

4. erd+스키마 → DB 테이블 분석

5. 스프링에서 엔티티 설계

양방향 참조

ex) 회원-주문의 관계에서 회원도 주문 가지고, 주문도 회원 가짐

하지만, 실제 DB에서 외래키는 주문만 가짐.
외래키 값을 수정할 수 있는 건 주문만 가능함. 주문이 관계의 주인임.

즉, 주문의 member 필드의 값을 수정하면 외래키 member_id가 수정됨

1:1 관계

access 많이 하는 곳에 외래키 주기 (필수는 아님)

n:n 관계

단방향으로 해도 되지만 양방향으로 예제 보여줌
1:다, 다:1 관계로 풀어내는 중간테이블이 있어야함
단점) 필드 추가가 불가능함 → 실무에선 거의 못씀

6. erd를 스키마로 변환하는 법(자세히)

모든 개체는 릴레이션으로 변환 + 존재종속 개체까지 같이 해도 됨

복합 속성은 복합 속성 속 단순 속성만 릴레이션의 속성으로 넣어줌

다중값 속성은 독립적인 릴레이션(약한 개체의 릴레이션)으로 분할

모든 관계는 릴레이션으로 변환

속성: 관계의 속성 + 연관 개체들의 기본키 속성

기본키: 다대다(연관 개체들의 기본키 합집합), 일대다(다 개체의 기본키), 일대일(연관 개체들 중 하나의 기본키)

외래키: 연관 개체들의 기본키

존재 종속 관계의 특성을 릴레이션에 반영(약한 개체의 속성과 키 결정)

속성: 약한 개체의 속성 + 강한 개체의 기본키

기본키: 강한 개체의 기본키 + 약한 개체의 기본키 합집합

식별관계 릴레이션은? 바뀐 약한 개체를 토대로 일대다 방법 다시 적용하면 됨.

속성: 관계의 속성 + 연관 개체들의 기본키 속성
기본키: 다 개체(약한개체)의 기본키

관계 릴레이션의 중복 제거(일대다와 일대일 관계 제거)

관계 릴레이션은 기본키가 같은 개체 릴레이션이 있다면 거기로 모든 속성 이동함

관계와 기본키가 일치하는 개체: 일대다(다 개체의 기본키), 일대일(연관 개체들 중 하나의 기본키), 존재종속==일대다(약한 개체(다 개체)의 기본키))

3원 관계

속성: 관계의 속성 + 연관 개체들의 기본키
기본키: 다대다대다(연관 개체들의 기본키 합집합) 다대일대일(다 개체의 기본키)
관계와 기본키가 일치하는 개체: 다대일대일(다 개체의 기본키)
존재종속-> 약한개체는 강한개체들 쌍에 대해 일대다임

7. 추가 예시

스키마

3, 4. 엔티티 클래스 개발1, 2

1) 코드 (Entity Class)

개체(Entity), 속성(Field) 별로 구분하여 정리함

base dir: src/main/java/jpabook/jpashop/

개체: 회원

domain/Member.java

속성: 회원id(PK), 주문list, 이름, 주소

주소

domain/Address.java

개체: 주문

domain/Order.java

속성: 주문id(PK), 회원(FK), 배송(FK), 주문상품list, 주문날짜, 주문상태

주문상태 (열거형으로 만듦)

domain/OrderStatus.java

개체: 배송

domain/Delivery.java

속성: 배송id(PK), 주문, 배송주소, 배송상태

배송상태 (열거형으로 만듦)

domain/DeliveryStatus.java

개체: 주문상품

domain/OrderItem.java

속성: 주문상품id(PK), 주문(FK), 상품(FK), 주문금액, 주문수량

개체: 상품

domain.item/Item.java

공통 속성: 상품id(PK), 카테고리list, 이름, 가격, 재고수량
추가 속성: 타입 별 속성 (상속으로 만듦)

Book

속성: 공통속성 + 추가속성(author, isbn)

domain.item/Book.java

Album

속성: 공통속성 + 추가속성(artist, etc)

domain.item/Album.java

Movie

속성: 공통속성 + 추가속성(director, actor)

domain.item/Movie.java

개체: 카테고리

domain/Category.java

속성: 카테고리id(PK), 상품list, 이름, 부모, 자식

2) 실행 결과 (DB)

회원 테이블

주문 테이블

배송 테이블

주문 상품 테이블

상품 테이블

카테고리 테이블

카테고리-상품 테이블

실행된 SQL문 → 실제로 DDL 스크립트로 사용할 땐 정제 필요함

5. 엔티티 설계시 주의점 + 추가 설정

1) 엔티티에는 가급적 Setter를 사용하지 말자

예제에서는 설명을 쉽게하기 위해 엔티티 클래스에 Getter, Setter를 모두 열고, 최대한 단순하게 설계했지만,

실무에서는 가급적 Getter는 열어두고, Setter는 꼭 필요한 경우에만 사용하는 것을 추천

이론적으로 Getter, Setter 모두 제공하지 않고, 꼭 필요한 별도의 메서드를 제공하는게 가장 이상적이다.
하지만 실무에서 엔티티의 데이터는 조회할 일이 너무 많으므로, Getter의 경우 모두 열어두는 것이 편리하다.

Getter는 아무리 호출해도 호출 하는 것 만으로 어떤 일이 발생하지는 않는다.
하지만 Setter는 문제가 다르다. Setter를 호출하면 데이터가 변한다.
Setter를 막 열어두면 가까운 미래에 엔티티에가 도대체 왜 변경되는지 추적하기 점점 힘들어진다.
그래서 엔티티를 변경할 때는 Setter 대신에 변경 지점이 명확하도록 변경을 위한 비즈니스 메서드를 별도로 제공해야 한다

2) 엔티티 식별자 ≠ 테이블 PK 커럼명

엔티티의 식별자는 id 를 사용하고 PK 컬럼명은 member_id 를 사용했다.

엔티티는 타입(여기서는 Member )이 있으므로 id 필드만으로 쉽게 구분할 수 있다.
하지만, 테이블은 타입이 없으므로 구분이 어렵다.
따라서, 테이블은 관례상 테이블명 + id 를 많이 사용한다.

3) 다대다 관계

실무에서는 @ManyToMany 를 절대 사용하지 말자

@ManyToMany 는 편리한 것 같지만, 중간 테이블( CATEGORY_ITEM )에 컬럼을 추가할 수 없고, 세밀하게 쿼리를 실행하기 어렵기 때문에 실무에서 사용하기에는 한계가 있다.
중간 엔티티( CategoryItem 를 만들고 @ManyToOne , @OneToMany 로 매핑해서 사용하자.

정리하면 대다대 매핑을 일대다, 다대일 매핑으로 풀어내서 사용하자.

4) 값 타입

값 타입은 변경 불가능하게 설계해야 한다.

@Setter 를 제거하고, 생성자에서 값을 모두 초기화해서 변경 불가능한 클래스를 만들자.
JPA 스펙상 엔티티나 임베디드 타입( @Embeddable )은 자바 기본 생성자(default constructor)를 public 또는 protected 로 설정해야 한다. public 으로 두는 것 보다는 protected 로 설정하는 것이 그나마 더 안전하다.
JPA가 이런 제약을 두는 이유는 JPA 구현 라이브러리가 객체를 생성할 때 리플랙션 같은 기술을 사용할 수 있도록 지원해야 하기 때문이다.

5) 모든 연관관계는 지연로딩으로 설정! [매우 매우 중요]

즉시로딩

정의) Member를 조회할 때 연관된 Order를 다 한번에 조회해버리는 것
단점)

예측 어려움
어떤 SQL이 실행될 지 추적하기 어려움
특히 JPQL을 실행할 때 N+1 문제가 자주 발생한다

JPQL select o From order o; → SQL select * from order
100+1(order)

특징) 절대로 쓰면 안됨

지연로딩

정의) 연관된 엔티티를 함께 DB에서 조회해야 하면, fetch join 또는 엔티티 그래프 기능을 사용함
특징)

실무에서 모든 연관관계는 꼭 지연로딩( LAZY )으로 설정해야 한다
@XToOne(OneToOne, ManyToOne) 관계는 기본이 즉시로딩이므로 직접 지연로딩으로 설정해야 한다.

ManyToOne

FetchType fetch() default EAGER;

OneToMany

FetchType fetch() default LAZY;

코드 수정 예시

코드 수정 및 결과

jpabook.jpashop에서 마우스 우측클릭 → 파일에서 찾기 (혹은 ctrl+shift+f)

fetch = FetchType.LAZY → ctrl+enter 하여 add static import → fetch = LAZY

결과

6) 컬렉션 초기화

컬렉션은 필드에서 바로 초기화 하는 것이 안전하다.

null 문제에서 안전하다.

하이버네이트는 엔티티를 영속화 할 때, 컬랙션을 감싸서 하이버네이트가 제공하는 내장 컬렉션으로 변경한 다.

만약 getOrders() 처럼 임의의 메서드에서 컬력션을 잘못 생성하면 하이버네이트 내부 메커니즘에 문제가 발생할 수 있다.

따라서 필드레벨에서 생성하는 것이 가장 안전하고, 코드도 간결하다.

7) 테이블, 컬럼명 생성 전략

하이버네이트 기존 구현: 엔티티의 필드명을 그대로 테이블의 컬럼명으로 사용

( SpringPhysicalNamingStrategy )
뒷부분 대충 들음

8) Cascade

코드 수정

Order.java

9) 연관관계 편의 메서드

정의) 연관관계 세팅을 더 편하게 해주는 것

특징)

위치는 control하는 쪽이 들고 있는 것이 좋음
양방향일 때 쓰면 좋음

코드 수정

Order.java
Category.java