4강. 요구사항을 엔터티와 관계로 바꾸는 법

?1. 이번 강의에서 해결할 문제

“경기 후 랭킹을 보여준다”만으로 테이블을 만들면 현재 점수와 과거 순위, 경기 결과가 뒤섞입니다. 기능 문장을 데이터 질문과 불변 규칙으로 바꾸어 모델 후보를 찾습니다.

✓2. 학습 목표

✓이 강의를 마치면

• 명사·사건·규칙에서 엔터티와 관계 후보를 추출합니다.
• 현재 상태와 이력 데이터를 구분합니다.
• 요구사항 사전과 데이터 질문 목록을 작성합니다.

◇3. 핵심 개념

엔터티는 독립적으로 식별하고 수명 주기를 추적할 대상입니다. 속성은 엔터티 자체의 한 값이고 관계는 엔터티 사이의 의미입니다. “플레이어가 게임에 참가해 캐릭터로 점수를 얻는다”에서 플레이어와 게임은 엔터티, 참가는 match_results라는 사건 엔터티가 됩니다. 랭킹은 현재 계산 결과인지 시점별 스냅샷인지 요구사항으로 결정합니다.

§4. 단계별 예시

문서 경로: C:\dev\game-ranking-service\docs\database\04-requirements.md

docs/database/04-requirements.md

## 기능 문장
- 한 게임에는 2명 이상의 플레이어가 참가한다.
- 플레이어는 경기마다 한 캐릭터를 선택한다.
- 종료된 경기에는 참가자별 점수와 승패가 한 번만 기록된다.
- 시즌별 현재 순위와 과거 스냅샷을 조회한다.

## 엔터티 후보
- Player: 계정과 표시 이름
- Game: 모드, 시작·종료 시각, 상태
- Character: 캐릭터 식별과 이름
- MatchResult: Player와 Game의 참가 사건
- RankingSnapshot: 시즌·시점별 순위 이력

## 확인 질문
- 무승부를 허용하는가?
- 닉네임 변경 후 과거 화면에는 어떤 이름을 보이는가?
- 경기가 취소되면 결과와 랭킹은 어떻게 처리하는가?

PowerShell · 설계 문서 확인

Set-Location C:\dev\game-ranking-service
Get-Content .\docs\database\04-requirements.md

§5. 동작 원리

자연어의 명사는 엔터티 후보지만 모든 명사가 테이블은 아닙니다. 독립 식별, 여러 속성, 반복 발생, 다른 대상과의 관계가 있는지 확인합니다. 동사는 관계나 사건 테이블 후보가 되고 “반드시”, “한 번만”, “최대” 같은 표현은 제약 조건 후보가 됩니다.

!6. 자주 하는 실수와 해결법

!자주 하는 실수

• 화면 하나당 테이블 하나: 화면은 여러 사실을 조합한 결과입니다. 데이터의 수명과 식별 기준으로 나눕니다.
• 계산 가능한 값을 모두 저장: 승률처럼 원천 데이터에서 계산 가능한 값은 일관성 비용을 검토한 뒤 저장합니다.
• 모호한 규칙을 임의 해석: 무승부·취소·닉네임 이력처럼 모델을 바꾸는 질문은 요구사항에 명시합니다.

✎7. 직접 실습

✎직접 실습

1. “주간 상위 100명을 보여준다”를 데이터 질문 세 개로 분해합니다.
2. 다섯 엔터티의 식별자와 수명 종료 조건을 표로 작성합니다.
3. 아직 결정되지 않은 정책 질문을 최소 다섯 개 기록합니다.

?8. 이해 점검 질문 3개

?이해 점검

1. 자연어의 명사가 항상 엔터티가 아닌 이유는 무엇인가요?
2. 참가 관계를 별도 사건 엔터티로 만드는 이유는 무엇인가요?
3. 현재 상태와 이력을 구분하지 않으면 어떤 문제가 생기나요?

■9. 핵심 요약

■핵심 요약

좋은 모델은 테이블부터 그리지 않고 요구사항의 사실, 질문, 불변 규칙부터 정리합니다. 독립적으로 식별할 대상과 반복되는 사건을 분리하고 모호한 정책을 질문으로 남깁니다.