1-1. 왜 요구 사항 분석부터 시작하는가

데이터베이스 설계는 테이블 이름을 짓는 것에서 시작하지 않는다. 업무 요구 사항을 분석해서 “무엇을 관리해야 하는가?”를 먼저 정리하는 것에서 시작한다.

• 어떤 사용자들이 어떤 업무를 수행하는지 정리한다.
• 업무 흐름(업무 시나리오)을 간단히 그려본다.
• 화면, 엑셀, 보고서, 기존 시스템에서 이미 쓰이는 데이터 항목을 모은다.
• 대화, 인터뷰, 기획 문서에서 반복해서 등장하는 명사, 동사를 눈여겨본다.

이 중에서 반복적으로 등장하고, 장기적으로 관리해야 하는 명사들이 개념적 모델링에서 말하는 후보 엔티티와 속성이 된다.

예를 들어 쇼핑몰 서비스를 떠올려 보면 다음과 같은 단어들이 자연스럽게 나온다.

• 고객, 회원, 관리자
• 상품, 카테고리, 옵션
• 주문, 결제, 배송, 환불
• 장바구니, 쿠폰, 포인트

이 중에서 독립적으로 관리해야 하는 대상은 엔티티 후보가 되고, 단지 “부가 설명”에 가까운 것들은 속성 후보가 된다.

1-2. 요구 사항에서 엔티티/속성을 뽑는 간단한 요령

실무에서 자주 쓰는 간단한 요령을 정리하면 다음과 같다.

1. 명사 찾기

   요구 사항 문장, 화면 설계서, 기존 엑셀에서 명사를 모두 뽑는다.

   예: “고객이 상품을 주문하고 결제하면, 주문 상태를 배송으로 변경한다.”

2. 엔티티 후보와 속성 후보로 나누기

   • 독립적으로 여러 개가 존재하고, 각각을 구분해서 관리해야 하면 엔티티 후보로 본다.
     • 예: 고객, 상품, 주문, 결제, 배송
   • 엔티티를 설명해 주는 정보라면 속성 후보로 본다.
     • 예: 고객 이름, 고객 전화번호, 상품명, 상품 가격, 주문 일시, 배송지 주소

3. 관계 후보 찾기

   • 동사/행위를 보고 엔티티 간 관계를 찾는다.
   • 예: “고객이 상품을 주문한다.” → 고객과 주문 사이에 관계가 존재한다.
   • 예: “주문이 여러 상품을 포함한다.” → 주문과 상품 사이에 관계가 존재한다.

이 과정을 통해 현실 세계의 개념을 엔티티(명사), 관계(동사), 속성(세부 정보) 로 구조화하면, 이후 ERD를 그릴 준비가 된다.