본 게시글은 하단 강의를 듣고 학습한 내용을 제 생각으로 요약, 정리한 글입니다.
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를 스키마로 변환하는 법(자세히)
1.
모든 개체는 릴레이션으로 변환 + 존재종속 개체까지 같이 해도 됨
•
복합 속성은 복합 속성 속 단순 속성만 릴레이션의 속성으로 넣어줌
•
다중값 속성은 독립적인 릴레이션(약한 개체의 릴레이션)으로 분할
2.
모든 관계는 릴레이션으로 변환
•
속성: 관계의 속성 + 연관 개체들의 기본키 속성
•
기본키: 다대다(연관 개체들의 기본키 합집합), 일대다(다 개체의 기본키), 일대일(연관 개체들 중 하나의 기본키)
•
외래키: 연관 개체들의 기본키
3.
존재 종속 관계의 특성을 릴레이션에 반영(약한 개체의 속성과 키 결정)
•
속성: 약한 개체의 속성 + 강한 개체의 기본키
•
기본키: 강한 개체의 기본키 + 약한 개체의 기본키 합집합
•
식별관계 릴레이션은? 바뀐 약한 개체를 토대로 일대다 방법 다시 적용하면 됨.
◦
속성: 관계의 속성 + 연관 개체들의 기본키 속성
◦
기본키: 다 개체(약한개체)의 기본키
4.
관계 릴레이션의 중복 제거(일대다와 일대일 관계 제거)
•
관계 릴레이션은 기본키가 같은 개체 릴레이션이 있다면 거기로 모든 속성 이동함
•
관계와 기본키가 일치하는 개체: 일대다(다 개체의 기본키), 일대일(연관 개체들 중 하나의 기본키), 존재종속==일대다(약한 개체(다 개체)의 기본키))
•
3원 관계
◦
속성: 관계의 속성 + 연관 개체들의 기본키
◦
기본키: 다대다대다(연관 개체들의 기본키 합집합) 다대일대일(다 개체의 기본키)
◦
관계와 기본키가 일치하는 개체: 다대일대일(다 개체의 기본키)
◦
존재종속-> 약한개체는 강한개체들 쌍에 대해 일대다임
7. 추가 예시
•
erd
•
스키마
게시글 작성자가 직접 만든 그림입니다. 퍼갈 시 출처로 블로그 링크 첨부 바랍니다.
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 스크립트로 사용할 땐 정제 필요함
create table category (
category_id bigint not null,
name varchar(255),
parent_id bigint,
primary key (category_id)
);
create table category_item (
category_id bigint not null,
item_id bigint not null
);
create table delivery (
delivery_id bigint not null,
city varchar(255),
street varchar(255),
zipcode varchar(255),
status varchar(255),
primary key (delivery_id)
);
create table item (
dtype varchar(31) not null,
item_id bigint not null,
name varchar(255),
price integer not null,
stock_quantity integer not null,
artist varchar(255),
etc varchar(255),
author varchar(255),
isbn varchar(255),
actor varchar(255),
director varchar(255),
primary key (item_id)
);
create table member (
member_id bigint not null,
city varchar(255),
street varchar(255),
zipcode varchar(255),
name varchar(255),
primary key (member_id)
);
create table order_item (
order_item_id bigint not null,
count integer not null,
order_price integer not null,
item_id bigint,
order_id bigint,
primary key (order_item_id)
);
create table orders (
order_id bigint not null,
order_date timestamp,
status varchar(255),
delivery_id bigint,
member_id bigint,
primary key (order_id)
);
alter table category
add constraint FK2y94svpmqttx80mshyny85wqr
foreign key (parent_id)
references category;
alter table category_item
add constraint FKu8b4lwqutcdq3363gf6mlujq
foreign key (item_id)
references item;
alter table category_item
add constraint FKcq2n0opf5shyh84ex1fhukcbh
foreign key (category_id)
references category;
alter table order_item
add constraint FKija6hjjiit8dprnmvtvgdp6ru
foreign key (item_id)
references item;
alter table order_item
add constraint FKt4dc2r9nbvbujrljv3e23iibt
foreign key (order_id)
references orders;
alter table orders
add constraint FKtkrur7wg4d8ax0pwgo0vmy20c
foreign key (delivery_id)
references delivery;
alter table orders
add constraint FKpktxwhj3x9m4gth5ff6bkqgeb
foreign key (member_id)
references member;
Java
복사
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;
코드 수정 예시
코드 수정 및 결과
6) 컬렉션 초기화
•
컬렉션은 필드에서 바로 초기화 하는 것이 안전하다.
•
null 문제에서 안전하다.
•
하이버네이트는 엔티티를 영속화 할 때, 컬랙션을 감싸서 하이버네이트가 제공하는 내장 컬렉션으로 변경한
다.
•
만약 getOrders() 처럼 임의의 메서드에서 컬력션을 잘못 생성하면 하이버네이트 내부 메커니즘에 문제가 발생할 수 있다.
•
따라서 필드레벨에서 생성하는 것이 가장 안전하고, 코드도 간결하다.
7) 테이블, 컬럼명 생성 전략
•
하이버네이트 기존 구현: 엔티티의 필드명을 그대로 테이블의 컬럼명으로 사용
◦
( SpringPhysicalNamingStrategy )
◦
뒷부분 대충 들음
8) Cascade
•
코드 수정
◦
Order.java
9) 연관관계 편의 메서드
•
정의) 연관관계 세팅을 더 편하게 해주는 것
•
특징)
◦
위치는 control하는 쪽이 들고 있는 것이 좋음
◦
양방향일 때 쓰면 좋음
•
코드 수정
◦
Order.java
◦
Category.java