ORM - DBDiagram 작성해보기

안녕하세요.

Hynn 입니다.

 

ORM의 실제 사용작성을 하기 전, Diagram 에 대한 기록을 위한 포스팅을 작성하겠습니다.

Diagram 은 말 그대로, 설계도 입니다.

작성자가 Code 로 기능을 구현하기 전에, 이러한 기능을 어떻게 작성할지, 어떻게 그려낼지에 대한 관계도 입니다.

실제 예제를 위한 코드 작성은 간단한 게시판을 작성할 예정이지만, Diagram 은 관계도가 가장 예제가 잘 활용될 수 있는 것으로 준비했습니다.

 

===============

1. ORM Diagram 예제보기

2. Diagram 살펴보기

===============

 

1. ORM Diagram 예제보기

먼저 대표적으로 사용되는 Shopping Mall 을 기준으로 Diagram 을 작성해보겠습니다.

사용자분들의 편의를 위해 Diagram 의 대표적 사이트 2곳을 같이 소개해드리겠습니다.

자신의 상황에 맞게 사용하시면 좋을 듯 합니다.

두곳다 무료/유료를 지원하고 있습니다.

 

DBDiagram

DBDiagram 은 우리가 친숙하게 Text(Code)를 작성하면 오른쪽 화면에 GUI 형태로 자동으로 그려내는 Diagram 입니다.

무료버전에서도 꽤나 폭 넓게 지원을 하고 있고, SQL Import/Export 지원이 가능합니다.

무료버전 주요 특징은 아래와 같습니다.

• SQL Import/Export 지원
• 최대 10개의 Diagram 가능
• Public & Embedded Diagram 지원
• PDF/PNG 내보내기 가능

QuickDBD

제가 실제 사용예시로 올려드린 그림의 DB Diagram 웹 입니다.

작성일 기준(2023.01.16) 현재 기간한정 무료 프로버전 제공으로 인해 2개월 가량은 손쉽게 사용이 가능합니다.

직관적인 코드작성을 통해 GUI 로 표현이 가능합니다.

위에서 소개했던 DB Diagram 에 비해서 제약사항이 다소 있어, 용도에 맞게 사용하시는게 좋습니다.

 

이 QuickDBD 는 아래의 제약사항이 있습니다.

 

• Diagram Table : 최대 10개
• Diagram 개수 : 1개

2. Diagram 살펴보기

이제 본격적으로 살펴보도록 하겠습니다.

실제작성한 풀 코드먼저 공개하도록 하겠습니다.

 

UserInformation
-
IDX PK int autoincrement
UserID string
UserPW string
UserName string
UserEmail string
UserAddress string
UserPhoneNumber Number
UserBirth Number
UserGender string
UserAllowEventMailing string
UserAllowEventMailingDate datetime.now()

BirthCoupon
-
BirthCouponIdx pk int autoincrement
IDX FK - UserInformation.IDX

EventMailing
-
EventMailingIDX pk int autoincrement
IDX FK - UserInformation.IDX
UserAllowEventMailingDate - FK - UserInformation.UserAllowEventMailingDate
DeniedEvetMailingDate timestamp.now()

DeliveryList
-
IDX FK - UserInformation.IDX int autoincrement
DeliverName string
DeliverPhoneNumber number
DeliverAddress string
DeliverNote text

ShopProduct
-
ProductIDX pk int
ProductName string
ProductPrice string
ProductOption string
ProductCoverImage img

ProductDetail
-
ProductIDX FK - ShopProduct.ProductIDX
TotalDeliveryTime FK - DeliverySystem.TotalDeliveryTime
ProductDefaultPrice number
ProductOptionPrice number
Product_Description text
ProductImage img
ProductCountPurchase int


DeliverySystem
-
DeliveryIDX PK int
PurchaseIDX FK - ProductPurchase.PurchaseIDX
DeliverNumber number
DeliveryStartDate datetime
DeliveryCompleteDate datetime
TotalDeliveryTime datetime

ProductPurchase
-
PurchaseIDX pk int autoincrement
ProductIDX FK - ShopProduct.ProductIDX
UserIDX FK - UserInformation.IDX
PurchaseItem string
PurchaseCount number
PurchaseDate datetime.now()

ProductReview
-
ProductIDX FK - ShopProduct.ProductIDX
IDX FK - UserInformation.IDX int
ProductCountPurchase int
ProductReviewDetail text
ProductReviewImg FK - ProductReviewImg.ProductReviewImg

ProductReviewImg
-
ProductReviewImgIDX PK INT Autoincrement
ProductReviewImg img

PaymentSystem
-
PaymentIDX pk int
PurchaseIDX FK - ProductPurchase.PurchaseIDX
PaymentTypeIDX FK - PaymentType.PaymentTypeIDX
PaymentDetailType FK - PaymentMEthod.PaymentDetailType

PaymentType
-
PaymentTypeIDX pk int
PaymentType string

PaymentMethod
-
PaymentMethodIDX pk int
PaymentDetailType string

ProductRate
-
ProductIDX FK - ShopProduct.ProductIDX
IDX FK - UserInformation.IDX
ProductCountPurchase int
ProductRate string

EasyPayment
-
IDX FK - UserInformation.IDX
PaymentTypeIDX FK - PaymentType.PaymentTypeIDX
PaymentBillingAddress string
PaymentMethodIDX FK - PaymentMethod.PaymentMethodIDX
BillingEmail string
PaymentPassword string

 

코드의 작성단계는 간단하지만, 쉽지 않은 과정을 거쳐야 합니다.

먼저 각 테이블을 어떻게 설계할지가 필요합니다.

 

굳이 순서도로 구현하자면, 각 역활을 나누어야 합니다.

• 회원영역
• 상품영역
• 결제영역

쇼핑몰은 일반적으로 위 3개의 영역으로 나뉘게 됩니다.

즉 회원정보를 기반으로 하는 영역, 상품정보에 관한 영역, 결제에 관련된 영역 이렇게 3개를 나누고 그에 맞게 테이블을 설계해야 합니다.

 

여기서 먼저 회원정보를 살펴보자면 아래와 같이 구성이 가능합니다

위 쇼핑몰 DB Diagram 을 구성할 때는 비회원은 기능에서 배제하고 작성했습니다. 그렇기 때문에, 전제조건은 접근할 수 있는 모두가 [회원] 이어야 하기때문에, 비회원의 대한 조건은 배제가 가능합니다.

 

• 회원가입/회원정보 관련 Table
• 이벤트이메일 동의/발송여부 Table
• 생일 이벤트 발송 Table
• 배송정보 Table

이러한 테이블들을 각각 필요한 정보를 모두 작성해봅니다.

여기서는 중복이 되도 관계가 없습니다. 중복이 되면 어떠한 테이블간의 연결이 필요한지를 알 수 있기 때문입니다.

 

그리고 이제 쇼핑몰의 메인 컨텐츠인 상품을 살펴야 합니다.

• 상품정보
• 상품 세부정보
• 상품 구매정보
• 상품 리뷰정보
• 상품 리뷰 이미지정보
• 상품 평가정보

위 역시 마찬가지입니다.

위 테이블을 먼저 고려하게 된다면, 이제 이 테이블에 어떠한 정보를 담아야 하는지를 모두 작성해야 합니다.

역시 여기서는 중복을 고려하지 않고, 먼저 작성을 해서 그려내야 합니다.

 

그리고 결제테이블 역시 마찬가지 입니다.

 

• 간편결제 정보
• 결제방법
• 결제기록

위 정보를 가지고 정보를 이제 나누게 됩니다.

하지만 여기서 각각의 3개의 영역에서도 겹치는 부분이 있습니다.

가령 예를 들어 현재의 정보만을 가지고 조합할 때, 쇼핑몰에서 볼 수 있는 통계가 필요할 수 있습니다.

대표적으로 배송정보와 결제시점을 가지고 평균 배송일을 DB화 할 수도 있습니다.

혹은 구매자의 정보를 통해 구매자의 평균 나이,성별 등을 알수도 있습니다.

 

그리고 어떠한 결제수단을 사용자들이 많이 선호하는지도 알 수 있습니다. (ex. 소액결제, 카드결제, 무통장입금..)

그리고 간편결제의 비중을 알 수도 있습니다.

 

즉, 자신이 설계하고자 하는 사이트의 위와 같은 기능을 모두 고려하여 작성이 되어야 합니다.

그리고 이것이 모두 작성이 된다면, 실제 부모요소, 자식요소의 연결을 지어야 합니다.

예를들어, 사용자 정보가 되는 "UserInfo" 가 필요한 Table 은 모두 회원가입시 담기는 Table 이 부모요소가 되고, 그에 연결된 항목들은 모두 자식요소로 적용됩니다.

 

이러한 형태로 중복된 것을 하나씩 지워나가며 설계를 하면 쉽게 마무리가 됩니다.

즉 Diagram 에서 가장 중요한것은 어떠한 기능을 설계할 것이고, 어떠한 정보를 수집하고 그를 저장할지에 대한 설계가 가장 중요하다고 할 수 있습니다.

 

실제 작성에서도 가장 중요한 정보이다 보니, 이러한 정보를 꼭 잘 사전에 설계하시기를 바라겠습니다.

 

감사합니다.