먼저 보는 기준

좋은 ERD는 이름보다 제약과 변화가 먼저 읽혀야 합니다.

실수 5가지는 결국 관계를 잘못 두거나, 값을 잘못 쪼개거나, 상태 변화를 빠뜨린 경우로 모입니다.
관계
직접 구현 가능한 관계인지, 업무 규칙과 카디널리티가 맞는지 확인합니다.
속성
검색·집계·수정 기준이 흐려지지 않도록 컬럼 분해와 계산 규칙을 정합니다.
상태
현재 값만 남길지, 변경 이력까지 저장할지 운영 의미를 먼저 정합니다.
놓치기 쉬운 판단
왜 문제가 되나
더 나은 모델링
관계
M:N 관계를 그대로 둠

학생-과목을 바로 연결하면 관계형 DB에서 관계를 담을 자리가 없어집니다.

수강 같은 교차 테이블로 분해해 학생ID·과목ID·성적을 함께 저장합니다.

속성
복합 속성을 한 컬럼에 저장

서울시 강남구 역삼동 123처럼 한 값으로 두면 검색, 정렬, 부분 수정 기준이 흐려집니다.

시·구·동·상세로 나누거나, 정규화 수준에 맞게 별도 구조로 빼서 다룹니다.

계산값
파생 데이터를 중복 저장

주문총액SUM(수량 × 단가)와 별도로 저장하면 갱신 이상이 생기기 쉽습니다.

기본은 계산으로 유도하고, 반정규화가 필요하면 누가 언제 같이 갱신하는지 규칙을 둡니다.

업무 규칙
카디널리티를 잘못 설정

1:NM:N을 잘못 잡으면 제약 조건과 화면 흐름이 실제 업무와 어긋납니다.

학생은 학과 하나만? 복수전공 허용? 같은 규칙을 먼저 확인한 뒤 관계 수를 정합니다.

상태
이력 관리가 빠짐

현재 상태만 있으면 pending → paid → shipped → delivered의 변화와 감사 추적이 사라집니다.

상태 변경이 중요한 도메인이라면 이력 테이블 필요 여부를 함께 판단합니다.

체크 포인트: ERD 품질은 개체 이름보다 관계 제약, 값의 분해 기준, 상태 변화 보존이 먼저 명확해야 올라갑니다.