어제보다 성장하기

1.3 회원테이블분석

Member 테이블

Member_ID

NAME

|CITY : VALUE TYPE/임베디드 타입 그대로 필드로 내려온 것이다.

|STREET : VALUE TYPE/임베디드 타입 그대로 필드로 내려온 것이다.

|ZIPCODE : VALUE TYPE/임베디드 타입 그대로 필드로 내려온 것이다.

설명

-1:1 맵핑이다.

-이름과 임베디드 타입인 주소(Address), 그리고 주문(orders) 리스트를 가진다.

Delivery 테이블

Delivery_ID

STATUS

CITY :　VALUE TYPE/임베디드 타입 그대로 필드로 내려온 것이다.

STREET　:　VALUE TYPE/임베디드 타입 그대로 필드로 내려온 것이다.

ZIPCODE　:　VALUE TYPE/임베디드 타입 그대로 필드로 내려온 것이다.

설명

-회원 엔티티의 Address 임베디드 타입 정보가 회원 테이블에 그대로 들어갔다.

이것은 DELIVERY 테이블도 마찬가지다.

ITEM 테이블

ITEM_ID(상품 ID)

-상속관계 맵핑 기본편에서 설명한 3가지 전략중 가장 단순한 싱글테이블 전략을 사용했다.

 싱글테이블전략은 한테이블에 DTYPE으로 구분해서 다 넣는다.

 일반적으로 성능이 잘 나온다.

-단점이라하면 필드에 ARTIST,ETC,AUTHOR,ISBN,DIRECTOR,ACTOR 전부 섞여서 싱글테

 이블에 들어간다.

-앨범, 도서, 화 타입을 통합해서 하나의 테이블로 만들었다. DTYPE 컬럼으로 타입을 구분한

 다.

Orders 테이블

ORDER_ID (주문 ID)

MEMBER_ID (Foreign Key, 회원 ID)

DELIVERY_ID (Foreign Key, 배송 ID)

참고

-테이블명이 ORDER가 아니라 ORDERS인 것은 데이터베이스가 order by 때문에 예약어로 잡고 있는 경우가 많다.

 그래서 관례상 ORDERS를 많이 사용한다.

주문상품테이블

주문상품 ORDER_ITEM

ORDER_ITEM_ID

ORDER_ID (FK)

ITEM_ID (FK)

ORDERPRICE (주문한 상품가격)

COUNT (주문한 상품 개수)

카테고리(CATEGORY)

CATEGORY_ID

PARENT_ID (FK)

NAME

CATEGORY_ITEM

CATEGORY_ID (FK)

ITEM_ID (FK)

설명

-객체에서는 카테고리가 아이템리스트를 가져도 되고

아이템이 카테고리리스트를 가져도 된다.

양쪽 컬렉션을 만들면 객체는 다대 다로 만들 수 있지만

관계형데이터베이스는 일반적 설계로는 그렇게 할 수 없다.

중간에 매핑 테이블(CATEGORY_ITEM)을 두어,

1대(CATEGORY) 다(CATEGORY_ITEM) 관계 및 다대(CATEGORY_ITEM) 1(ITEM)로 풀어

낸다.

참고

*강의에서는 객체를 구분하기 위해 DB에 대문자를 사용했다.

-실제 코드에서는 DB에 소문자 + _(언더스코어) 스타일을 사용하겠다.

-데이터베이스 테이블명, 컬럼명에 대한 관례는 회사마다 다르다.

 보통은 대문자 + _(언더스코어)나 소문자 + _(언더스코어) 방식 중에 하나를 지정해서

 일관성 있게 사용한다. 강의에서 설명할 때는 객체와 차이를 나 타내기 위해 데이터베이스

 테이블, 컬럼명은 대문자를 사용했지만, 실제 코드에서는 소문자 + _(언더스코 어) 스타일을

 사용하겠다.

1-2. 회원 엔티티 분석

1.회원(Member)엔티티

회원(Member)

id: Long

-회원엔티티에 공통속성은 id가 다 있다.

-id=pk generating 해주는 id값 데이터베이스

 pk값(id값)은 long 값으로 해놓았다.

name:　String

-이름(string)

address: Address

-임베디드 타입(내장값타입)인 주소(Address : 설계도 하기 그림참고-value type address)

orders : List

-그리고 주문(orders) 리스트를 가진다.

2.주문 엔티티

주문(Order)

id

member : Member(회원정보)

orderItems : list (주문목록)

delivery : Delivery(배송정보)

orderDate : Date(주문한날짜)

status : OrderStatus(주문상태-주문,취소 등등)

-한 번 주문시 여러 상품을 주문할 수 있으므로 주문과 주문상품(OrderItem)은 일대다 관계 다.

-주문은 상품을 주문한 회원과 배송 정보, 주문 날짜, 주문 상태(status)를 가지고 있다.

-주문 상태는 열 거형을 사용했는데 주문(ORDER), 취소(CANCEL)을 표현할 수 있다.

3.주문상품 엔티티

주문상품(OrderItem)

-주문한 상품 정보와 주문 금액(orderPrice), 주문 수량(count) 정보를 가지고 있다.

 (보통 OrderLine, LineItem 으로 많이 표현한다.)

-주문상품을 추가한 다른 이유는 한번 주문시 여러 개의 상품을 담을 수 있는데

 주문시점시 주문한 상품의 개수 및 주문한 상품 가격정보가 필요하기 때문이다.

4.배송 엔티티

배송(Delivery)

id

order : order(주문정보, 배송지주소 아님)

address : Address(배송지주소-value type 값타입 주소를 재활용)

status : DeliveryStatus(배송현황)

-배송(Delivery): 주문시 하나의 배송 정보를 생성한다. 주문과 배송은 일대일 관계다.

-주문시 하나의 배송 정보를 생성한다. 주문과 배송은 일대일 관계다.

5.상품엔티티

상품(Item)

id

name (상품이름)

price: int (상품가격)

stockQuantity (상품재고)

categories: List(어느 카테고리에 매핑 되어 있는지에 대한 정보)

상품엔티티와의 상속관계

-상속관계로 Album, Book, Movie들이 있고,

 개별속성들이 상속관계로 다음과 같이 표현되어 있다.

Album - artist, etc

Book - author, isbn

Movie - director, actor

-이름, 가격, 재고수량(stockQuantity)을 가지고 있다.

 상품을 주문하면 재고수량이 줄어든다.

 상품의 종류로는 도서, 음반, 화가 있는데 각각은 사용하는 속성이 조금씩 다르다.

6. 카테고리엔티티

카테고리(Category)

id

name

items: List(카테고리가 가지고 있는 리스트)

parent: Category

(계층구조로 되어 있다. 내 부모가 누구인데, 자식(속성)은 여러개의 구조로 되어 있다라는 형태, 부모는 한개)

child: List

-카테고리(Category): 상품과 다대다 관계를 맺는다. parent, child로 부모, 자식 카테고리를

 연결한다.

7. 주소엔티티

주소(Address)

-값 타입(임베디드 타입)이다. 회원과 배송(Delivery)에서 사용한다.

설계구성도는 JPA에서 다룰 수 있는 모든관계개념들을 모두 넣어두었다.

1. Member와 Order - 1대 다 관계

2. Order랑 delivery - 1대 1 관계

3. Order와 OrderItem - 1대 다 관계

4. OrderItem과 Item - 다대 1 관계

5. Item과 Album,Book,Movie - 상속관계

6. Category와 Item - 다대 다 관계

실무에서 사용하기 애매한 것들

-Category와 item의 다대 다 관계(JPA@다대다관계)는 실제운영에서 사용하면 안된다.

 1대 다 또는 다대 1 관계로 풀어내야 한다.

-Member와 Order 1대 다 관계가 아닌, 시스템적으로는 동등한 관계로 보고 고민해야 한다.

-회원을 통해서 주문이 일어난다가 아니라, 주문을 생성할 때 Member가 필요하다라고 생각을 해야 한다.

-쿼리가 일어날 때도 주문 내역이 필요할 때 멤버를 찾아서 거기에 있는 주문 리스트를 가져 오는 것이 아니라,

 order에서도 필터링 조건에 멤버가 들어간다.

-그래서 사실상 1대 다의 컬렉션은 필요없다..

 자세한 것은 기본편강의에서 다루었다.

참고

회원이 주문을 하기 때문에, 회원이 주문리스트를 가지는 것은 얼핏 보면 잘 설계한 것 같지만,

객체 세상은 실제 세계와는 다르다. 실무에서는 회원이 주문을 참조하지 않고, 주문이 회원을 참조하는 것으로 충분하다. 여기서는 일대다, 다대일의 양방향 연관관계를 설명하기 위해서 추가했다.

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

a.회원, 주문, 상품의 관계

-회원은 여러 상품을 주문할 수 있다. 그리고 한 번 주문할 때 여러 상품을 선택할 수 있기에 주문과 상품은 다대다 관계

-하지만 이런 다대다 관계는 관계형 데이터베이스는 물론이고 엔티 티에서도 거의 사용하지 않는다.

-따라서 그림처럼 주문상품이라는 엔티티를 추가해서 다대다 관계를 일대 다, 다대 일 관계로 풀어냈다.

상품 분류

-상품은 도서, 음반, 화로 구분되는데 상품이라는 공통 속성을 사용하므로 상속 구조로 표현했 다.

b.회원과 주문 관계

-회원은 여러 주문을 할 수 있어서 회원과 주문의 관계는 1대 다의 관계이다.

c.회원과 주문, 주문과 상품 관계

-회원이 한번 주문할 때 여러개의 상품을 주문할 수 있다.

-상품도 여러 주문에 담길 수 있으면 다대 다 관계가 된다.

-하지만 이런 다대다 관계는 관계형 데이터베이스는 물론이고 엔티티에서도 거의 사용하지 않는다.

-그래서 1대 다 다 대 1의 관계 관계로 만들기 위해

 그림처럼 주문상품(테이블+주문수량)이라는 엔티티를 추가해서 다대다 관계를 일대 다,

 다대일 관계로 풀어냈다.

d.주문과 배송정보

-1대 1 관계

-주문할 때 배송정보를 입력할 수 있도록 해놓음

e.상품

-도서, 음반, 영화 로 타입이 나누어짐

f.상품과 카테고리

-상품은 카테고리에 매핑이 된다.

-하나의 카테고리에 여러 가지 상품이 들어갈 수도 있고,

 어떤 상품이 카테고리에 복수로 들어갈 수 있기 때문에

 다대 다 관계로 세팅

g.데이터베이스의 목적

(참고 블로그 http://kdskor.blogspot.com/2010/10/pk-fk.html)

-효율적이고, 성능면에서 매우 편리하며 신속하게 수많은 데이터들을 보관 및 관리하는 것

-그 중에서도 제일 우선시 되어야 하는 것이 데이터의 무결성이다.

 신속하게 처리한다 하더라도 데이터에 결점이 있다면 데이터는 쓸모가 없을 뿐 아니라,

 데이터의 결점으로 인하여 잘못된 결과를 초래

-데이터 무결성을 보장해주기 위해서 가장 기본적으로 필요한 것이 PK와 FK

h.PK(Primary Key)와 FK(Foreign Key)

PK

-데이터베이스 생성에서 가장 기본적으로 고려되는 것이 PK

-PK만큼 중요한 것이 FK

-PK는 테이블에서 오직한개만 존재

-PK가 데이터의 유일성을 보장

-테이블에서 PK를 조건으로 조회하여 한 개의 값만 나오거나 값이 나오지 않게 됨

FK

-외래 키는 참조하는 테이블에서 1개의 키(속성 또는 속성의 집합)에 해당하고,

 참조하는 측의 관계 변수는 참조되는 측의 테이블의 키를 가리킨다.

-관계형 데이터베이스에서 외래 키(외부 키, Foreign Key)는 한 테이블의 필드(attribute) 중 다른 테이블의 행(row)을

 식별할 수 있는 키

예)아파트테이블 세대테이블의 아파트코드값에

   아파트테이블의 아파트코드에 없는 값이 들어간다면?

   이 때 데이터를 저장 또는 수정시 아파트코드 데이터는 아파트 테이블에 있는 아파트코드

   가 맞는지 확인해야 하는데, 이것이 자동적으로 확인되도록 도와주는 것이 FK이다.