DB 설계 A to Z 2강 — 요구사항 분석

1강에서 설계가 요구사항 분석부터 시작하는 다섯 단계라는 것을 봤습니다. 이번 편은 그 첫 단계를 다룹니다.

1. 왜 요구사항 분석이 가장 중요한가

설계 오류의 대부분은 SQL이 아니라 업무를 잘못 이해한 데서 시작합니다. "상품은 하나의 셀러가 공급한다"를 당연하게 받아들였는데, 실제로는 같은 상품을 여러 셀러가 번갈아 공급하는 위탁 판매 업무라면 모델 전체가 달라집니다.

구분	내용	예시
데이터 요구사항	무엇을 저장하는가	항목번호, 무게, 처리단계의 계획일/실적일
업무 규칙	데이터가 지켜야 할 규칙	실적일은 착수일보다 빠를 수 없다
처리 요구사항	어떤 조회·변경이 일어나는가	매일 아침 주문 단위 처리율 조회
비기능 요구사항	양, 속도, 보존, 보안	주문당 주문항목 3건, 처리 실적 3년 보관, 셀러는 자기 데이터만 조회

초보 설계는 첫 번째만 수집합니다. 하지만 물리 설계는 세 번째와 네 번째로 결정됩니다.

업무 설명 문장에서 후보를 기계적으로 뽑는 기법입니다.

"입점 셀러는 출고 담당자를 보유한다. 출고 담당자는 주문항목의 처리단계를 수행하고, 수행 시 투입 시수를 기록한다. 검수자는 완료된 처리단계를 검수하고 합격 여부를 판정한다."

주의할 점

유형	설명	예시	DB 구현 수단
구조 규칙	관계와 카디널리티	주문항목은 반드시 하나의 주문에 속한다	FK + NOT NULL
값 규칙	속성값의 범위	처리율은 0~100	CHECK
유일성 규칙	중복 금지	한 주문에 같은 상품은 한 줄로만 기록한다	UNIQUE (order_no, product_id)
행 간 규칙	여러 행에 걸친 조건	같은 담당자의 처리 시간은 겹칠 수 없다	배타 제약(PG), 트리거, 앱
흐름 규칙	상태 전이	검수 완료 후에만 출고 착수 가능	트리거, 앱 로직

이 표는 13강(제약조건 설계)의 입력이 됩니다. 업무 규칙을 문서화하지 않으면 제약조건을 설계할 근거가 없습니다.

1강의 문장 "한 처리단계는 여러 주문항목에 적용된다"를 확정하려면 다음 질문이 필요합니다.

2번 질문이 특히 중요합니다. 재처리가 있다면 (항목번호, 단계코드)는 더 이상 유일하지 않으므로 차수(seq)를 PK에 추가하거나 대리키를 도입해야 합니다.

업무와 엔티티의 관계를 표로 정리해 누락된 엔티티와 불필요한 엔티티를 찾습니다.

업무 \ 엔티티	주문	주문항목	처리단계	항목처리	담당자
주문 등록	C
주문항목 생성	R	C
처리단계 계획 수립		R	R	C
실적 입력		R		U	R
처리율 조회	R	R	R	R

점검 규칙:

물리 설계를 위해 최소한 아래 표를 채워둡니다.

엔티티	초기 건수	증가량	보관 기간	주요 접근 패턴
주문	200만	일 2만	영구	주문번호, 고객+기간
주문항목	600만	일 6만 (주문당 3건)	영구	주문번호로 조회
항목처리	1,800만	일 18만	5년	항목번호, 단계코드+기간
처리 실적	500만	일 5만	3년	처리일 범위, 담당자별

처리 실적은 일 5만 건, 3년 보관이면 약 5,500만 건입니다. 이 숫자가 16강에서 월 단위 파티셔닝을 결정하는 근거가 됩니다.

표준 용어	영문 컬럼명	동의어	정의
주문	order_no	오더, Order No	고객의 거래 단위를 식별하는 번호
주문항목	order_item	OI	주문의 상품 단위 구성 요소
실적일	actual_date	완료일	처리단계가 실제로 완료된 날짜

용어 사전은 컬럼 명명 규칙의 기준이 되며, 여러 팀이 같은 DB를 쓸 때 가장 큰 효과를 냅니다.