ERD(Entity Relationship Diagram)란?

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

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

엔티티

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

• 독립 엔티티
  • 다른 엔티티에 의존하지 않고 존재하는 것
• 종속 엔티티
  • 다른 엔티티에 의존하여 존재하는 것

속성

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

관계

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

• 실선 관계
  • 자식 엔티티의 기본키(PK) 가 부모 엔티티의 기본키를 포함할 때
  • 즉, 부모가 없으면 자식이 존재할 수 없음
• 점선 관계
  • 자식 엔티티가 부모 엔티티의 기본키를 포함하지 않고, 대신 부모의 키를 외래키(FK) 로만 가질 때
  • 자식이 부모의 존재에 “의존”은 하지만, PK 차원에서는 독립적이기 때문에 점선 관계가 됨

그림에서 '주문'은 다른 엔티티에 의존하지 않기 때문에 독립 엔티티이며, '주문 상세'은 '주문' 없이 존재하지 않기 때문에 종속 엔티티이다.
또한, '주문'과 '주문 상세'는 종속 관계(식별 관계)에 있어 실선으로 이어지고 하나의 '주문'은 하나 이상의 '주문 내역'과 1:N으로 연관된다.

마스터 자료와 트랜잭션 자료

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

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

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

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

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

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

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

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

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

이 단계에서 📌 ERD 주요 엔티티를 정의해보자! 정리가 길어서 아래에 작성해두었다.

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

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

이 단계에서 ☁️ ERD cloud로 ER 다이어그램을 만들어보자!

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

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

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

엔티티

체크항목	질문
이름	중복된 것 없나? 변수 스타일의 이름은 피할 것
필요성	꼭 필요한 것인가? 속성이 되어야 하지 않나?
일반화	일반화/특수화가 필요한가?

관계

체크항목	질문
다중도	1:1, 1:n 적합한가? 올바른 방향인가?
중복	중복되는 관계는 없는가?
이름	이름이 올바로 붙여 있는가? 관계 이름이 중복된 것은 없는가?

완전성

체크항목	질문
의존 관계	의존 관계와 독립 관계가 구별되어 정확히 표현되었나?
엔티티	빠진 엔티티는 없나?
연관	빠진 연관은 없나?

📌 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)