어제보다 성장하기

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에 소문자 + _(언더스코어) 스타일을 사용하겠다.

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

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

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

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

 사용하겠다.

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이다.