산출물로 본 모델링 과정은 다음과 같다. 이 글에서는 개념적 설계인 ERD를 설계하는 방법을 알아보고 예제를 통해 ERD를 만드는 연습을 해보자.

1. 요구사항 분석 -> 요구사항 분석서

2. 개념적 설계 -> ERD

3. 논리적 설계 -> 관계형 모델

4. 물리적 설계 -> SQL

1. 요구사항 분석

어플리케이션을 만들기 위해서는 요구사항 분석을 먼저 해야할 것이다.

이때 어플리케이션의 요구사항을 데이터의 관점에서 바라보면 데이터 중심 설계가 된다. 이 방식에서 ERD 설계 과정을 거치면 가능해진다.

사용자 / 앱이 데이터베이스에게 요구하는 것은 무엇인가? 무엇을 어떻게 저장할 것인가? 를 초점 맞춰서 요구사항 분석을 한다. 이렇게 하면, 어떤 api를 할지도 명확해지기 때문에 추천하는 방식이다.

2. 개념적 설계

• 개념적인 설계 단계에서는 key 속성을 굳이 지정할 필요 없다.
• 개념 데이터 모델링에 집중하고 추후에 생성되는 종속 관계에 따라 key 속성을 지정한다.
• key 속성을 지정하지 않은 걸 네모 두겹으로 표현한다.

ERD(Entity Relationship Diagram)란?

ER 다이어그램은 실세계에 존재하는 물건을 여러 가지 속성을 가진 엔티티로 파악하고 엔티티(entity) 사이의 상호 관계를 관계(relationship)로 표현한 그림이다. ER 다이어그램의 속성은 데이터이므로 ER 다이어그램을 통해 시스템에서 사용하는 각 데이터의 상호 관계를 읽을 수가 있다.

데이터 모델링이란, 현실세계에서 응용 프로그램에 필요한 데이터를 분석 및 선택해서 물리적으로 저장하는 방법을 결정하는 정형화된 기법이다.

WHY?

• 견고한 백엔드 설계를 위해 데이터베이스 모델링이 필요하다.
• ERD는 RDBMS의 개념적 설계 및 데이터 모델링 기법으로 가장 널리 사용된다.

ER 다이어그램은 개체, 속성, 관계 3가지로 구성된다.

개체(Entity)

실세계에 존재하는 물건에 해당한다.

• 직사각형으로 표현한다. (Chen 표기법)
• 독립 엔티티
  • 다른 엔티티에 의존하지 않고 존재하는 것
• 종속 엔티티
  • 다른 엔티티에 의존하여 존재하는 것

속성(Attribute)

엔티티에 포함된 데이터가 속성이다.

• 타원으로 표현한다. (Chen 표기법)
• 키 속성: 개체마다 고유한 값을 가지는 속성
  • 키 속성은 밑줄로 표현하며 하나 이상 존재 가능

관계(Relationship)

엔티티 간의 연관을 나타내는 것으로 의존 정도에 따라 점선 또는 직선으로 표현한다.

• 실선 관계
  • 자식 엔티티의 기본키(PK) 가 부모 엔티티의 기본키를 포함할 때
  • 즉, 부모가 없으면 자식이 존재할 수 없음
• 점선 관계
  • 자식 엔티티가 부모 엔티티의 기본키를 포함하지 않고, 대신 부모의 키를 외래키(FK) 로만 가질 때
  • 자식이 부모의 존재에 “의존”은 하지만, PK 차원에서는 독립적이기 때문에 점선 관계가 됨
• 반드시 필요한 관계는 겹줄로 표현한다.
• 1:1, 1:M, M:N 의 세가지 관계가 존재한다.

그림에서 '주문'은 다른 엔티티에 의존하지 않기 때문에 독립 엔티티이며, '주문 상세'은 '주문' 없이 존재하지 않기 때문에 종속 엔티티이다.

또한, '주문'과 '주문 상세'는 종속 관계(식별 관계)에 있어 실선으로 이어지고 하나의 '주문'은 하나 이상의 '주문 내역'과 1:N으로 연관된다.

마스터 자료(리소스 엔티티)와 트랜잭션 자료(이벤트 엔티티)

• 리소스 엔티티
  • DB 설계에서 '마스터'가 될 수 있는 엔티티
  • ex) 거래처, 고객, 상품 등 기본적으로 필요한 데이터
• 이벤트 엔티티
  • DB 설계에서 트랜잭션이 될 수 있는 엔티티
  • ex) 주문, 발주 등 어떤 사건이 일어났을 때 발생하는 데이터

'고객'은 리소스 엔터티이므로 마스터가 될 수 있다. 하지만 '주문'은 트랜잭션이 되기 때문에 이벤트 엔티티이다.

리소스 엔티티와 이벤트 엔티티를 정의하는 방법을 알아보자.

Step 1. 리소스 엔티티 추출 및 정의

시스템 전체를 나타내는 요구 사항 분석 명세서 등으로부터 리소스 엔티티를 추출하고 영역을 정의한다.

설명, 제약, 규칙, 범위가 될 수 있는 것은 빠짐없이 찾아내서 엔티티의 영역을 정의한다. 이는 데이터 모델을 만들 때 필요한 것이다.

모든 엔티티는 충분히 의미가 있는 것이어야 한다. 즉, 각 엔티티가 '무엇을 위해 존재하는가?', '누가 관리를 할 것인가?'를 중심으로 체크한다.

Step2. 이벤트 엔티티 추출 및 정의

리소스와 마찬가지로 현재 파악 가능한 이벤트 엔티티를 찾아내고 각 영역을 정의한다.

관계에 대한 의미를 정의하는 문장은 '~한다'는 동사 구문을 갖게 된다. 화살표 방향에 따라 '부모 엔티티는 자식 엔티티를 ~한다.'로 통일하면 알기 쉬울 것이다.

이 단계에서 📌 ERD 주요 엔티티를 정리해보자!

📌 ERD 주요 엔티티 정리

1. 고객 (Customer) 엔티티

역할: 쇼핑몰을 이용하는 사용자

주요 속성: 고객ID(PK), 이름, 이메일, 주소, 연락처 등

관계:

• 고객 → 주문 (1:N, 고객은 여러 주문을 할 수 있음)
• 고객 → 장바구니 (1:1 또는 1:N).
• 고객 → 리뷰 (1:N, 여러 리뷰 작성 가능)

2. 상품 카테고리 (Category) 엔티티

역할: 상품을 분류하는 체계

주요 속성: 카테고리ID(PK), 카테고리명, 상위 카테고리ID(계층적 구조 가능)

관계:

• 카테고리 → 상품 (1:N, 한 카테고리에 여러 상품 소속)

3. 상품 (Product) 엔티티

역할: 판매되는 개별 상품

주요 속성: 상품ID(PK), 상품명, 가격, 재고수량, 설명 등

관계:

• 상품 → 주문상세 (1:N, 상품은 여러 주문에 포함될 수 있음)
• 상품 → 장바구니아이템 (1:N)
• 상품 → 리뷰 (1:N)
• 상품 → 카테고리 (N:1)

4. 주문 (Order)

역할: 고객이 상품을 구매하기 위해 생성하는 거래 단위

주요 속성: 주문ID(PK), 고객ID(FK), 주문일자, 배송주소, 주문상태

관계:

• 주문 → 주문상세 (1:N, 한 주문은 여러 상품을 가짐)
• 주문 → 트랜잭션 (1:N, 주문에 대해 여러 결제/환불 내역이 있을 수 있음)

5. 주문상세 (OrderDetail)

역할: 주문 안에 포함된 개별 상품 항목

주요 속성: (주문ID + 상품ID) = PK (복합키), 수량, 단가.

관계:

• 주문상세 → 주문 (N:1)
• 주문상세 → 상품 (N:1)

특징: 부모의 PK를 포함하므로 Identifying 관계(실선)

6. 장바구니 (Cart / CartItem)

역할: 고객이 결제 전 담아둔 상품 목록

주요 속성: 카트ID(PK), 고객ID(FK), 상품ID(FK), 수량

관계:

• 장바구니 → 고객 (N:1)
• 장바구니 → 상품 (N:1)

7. 상품리뷰 (Review)

역할: 고객이 구매한 상품에 대해 남기는 평가/코멘트

주요 속성: 리뷰ID(PK), 고객ID(FK), 상품ID(FK), 평점, 내용, 작성일

관계:

• 리뷰 → 고객 (N:1)
• 리뷰 → 상품 (N:1)

8. 트랜잭션 (Transaction)

역할: 주문에 대해 발생한 금전적 거래 내역 (결제, 취소, 환불 등)

주요 속성: 트랜잭션ID(PK), 주문ID(FK), 결제일자, 결제수단, 금액, 상태

관계:

• 트랜잭션 → 주문 (N:1)

Step3. 추출한 엔티티들 사이에 관계를 표현

추출한 엔티티 사이의 관계에 대한 의미를 파악하고 정의하는 단계이다. 모든 관계의 선은 방향성에 대한 이유가 있어야 한다.

이 단계에서 ERD 주요 엔티티 정리한 것을 바탕으로 ☁️ ERD cloud로 ER 다이어그램을 만들어보자!

• 리소스 엔티티는 보라색으로 지정해두었다.
• N:M 관계를 1:N 관계로 중간테이블로 분리한 엔티티는 주황색으로 지정해두었다.

Step4. ER 다이어그램 체크리스트

마지막으로 체크리스트로 제대로 ERD를 만들었는지 점검해보자.

엔티티

관계

완전성

다음 글에 이어서 논리적 설계와 물리적 설계에 대해 알아보도록 하겠다!