🔙뒤로가기

요구사항 분석

기능 목록

Untitled

도메인 모델 분석

graph TD
	Member1[Member] -- 일대다 관계 --> Order1[Order]
  Order1 <-- 다대다 관계 --> Product1[Product]

  Member2[Member] -- 일대다 관계 --> Order2[Order]
  Order2 -- 일대다 관계 --> OrderItem
  Product2[Product] -- 다대일 관계 --> OrderItem
%% 주석
Member1 -->|잘못된 방법| Product1
Member2 -->|올바른 방법| OrderItem

<aside> ⚠️ 다대다 관계는 왜 문제인가?

  1. 하나의 주문(Order)에서 여러 개의 상품( Product)를 주문할 수 있다. → 고객이 A 상품과 B 상품을 함께 주문할 수 있다.
  2. 한 상품(Product)는 여러 개의 주문(Order)에 포함될 수 있다. → A 상품이 다른 고객들에 의해 여러 번 주문될 수 있다.

실제 데이터베이스 설계에서 다대다 관계를 직접 사용하는 것은 복잡하고 관리가 매우 어렵다. 아래에는 다대다 관계를 풀어내지 않고 그대로 테이블로 설계했을 때 발생하는 문제의 실제 예시이다.

  1. 주문 수량 관리: 주문과 상품 사이에 직접적인 다대다 관계가 있다면, 주문 수량을 어떻게 관리할 것인지가 모호해진다. 이 경우, 각 주문에 대해 구매한 상품의 수량을 저장할 수 있는 공간이 없다.
  2. 주문 별 상품 할인 정보 관리: 각 주문별로 상품 할인 정보가 다를 수 있다. 예를 들어, 특정 주문에서 상품 A에 대한 할인률이 10%인 경우가 있고, 다른 주문에서는 20% 할인률을 적용할 수도 있다. 다대다 관계에서는 이러한 주문별 상품 할인 정보를 저장하고 관리하기 어렵다.

이런 문제를 해결하기 위해 중간 테이블을 사용할 수 있다. 이 테이블은 주문(Order)과 상품(Product) 사이의 관계를 저장하고, 주문 수량이나 할인 정보 등의 추가 정보를 포함할 수 있다. 이를 통해 주문과 상품 간의 관계를 더욱 명확하게 표현할 수 있으며, 데이터베이스 관리가 더 쉬워진다.

실무에서는 중간 테이블의 이름으로 보통 OrderItem, OrderLine, OrderDetail, LineItem이라는 이름을 사용한다.

</aside>

테이블 설계

Untitled

엔티티 설계와 매핑

classDiagram
    class Member {
        id: Long
        name: String
        city: String
				street: String
        zipcode: String
    }
    class Order {
        id: Long
        memberId: Long
        orderDate: Date
        status: OrderStatus
    }
    class OrderItem {
        id: Long
        orderId: Long
        orderPrice: int
        count: int
    }
    class Item {
        id: Long
        name: String
        price: int
        stockQuantity: int
    }
    Member "1" -- "*" Order : has
    Order "1" -- "*" OrderItem : has
    Item "1" -- "*" OrderItem : has

데이터 중심 설계의 문제점