---
name: analyzing-data-model
description: PlantUML の ER 図を使用したデータモデル設計を支援。概念→論理データモデルの段階的設計とテーブル定義。「データモデルを設計したい」「ER 図を作りたい」「テーブル定義を作成したい」「データベース設計を始めたい」「正規化を検討したい」といった場面で発動する。データモデルを先に設計することで、実装時のテーブル設計の手戻りを防ぐ。
---

# データモデル設計

PlantUML の ER 図を使用して、概念データモデル→論理データモデルの順でデータモデルを設計する。

データモデルはシステムの「記憶」を定義する設計。ドメインモデルが業務ロジックの構造を表すのに対し、データモデルはデータの永続化構造を定義する。両者の整合性がシステム全体の一貫性を保証する。

## 参照ドキュメントとテンプレート

| 種類 | パス | 備考 |
|------|------|------|
| ガイド | @docs/reference/データモデル設計ガイド.md | データモデル設計の進め方詳細 |
| テンプレート | @docs/template/設計.md | 編集禁止。コピーして使用する |
| 入力 | @docs/requirements/requirements_definition.md | 要件定義 |
| 入力 | @docs/requirements/business_usecase.md | ビジネスユースケース |
| 入力 | @docs/requirements/system_usecase.md | システムユースケース |
| 入力 | @docs/requirements/user_story.md | ユーザーストーリー |
| 入力 | @docs/design/architecture_backend.md | バックエンドアーキテクチャ |
| 入力 | @docs/design/architecture_frontend.md | フロントエンドアーキテクチャ |
| 成果物 | `docs/design/data-model.md` | データモデル設計 |

## 概念データモデル作成

業務の言葉でエンティティとリレーションシップを識別する。この段階では物理的な実装を考えない。ユースケースの「名詞」がエンティティ候補になる。

- **エンティティの識別**: ユースケースとユーザーストーリーから管理対象を抽出する
- **リレーションシップの定義**: エンティティ間の関係（1:1、1:N、N:N）を明確にする

## 論理データモデル作成

概念モデルを具体的なテーブル構造に落とし込む。正規化は第 3 正規形を基本とし、パフォーマンス要件に応じて非正規化を検討せよ。

- **テーブル定義**: カラム名、データ型、制約を定義する
- **主キー・外部キーの設計**: 識別子の戦略（自然キー/サロゲートキー）を決定する
- **正規化の適用**: 第 3 正規形まで正規化し、必要に応じて非正規化の判断を記録する

## ER 図作成

PlantUML を使用して ER 図を作成する。テーブル間の関係を可視化することで、設計レビューの効率が上がる。

## 作成の進め方

1. 入力ドキュメント（要件定義、アーキテクチャ設計）を確認する
2. @docs/reference/データモデル設計ガイド.md を読み込む
3. 概念データモデル→論理データモデルの順に作成する
4. ドメインモデルとの整合性を確認しながら `docs/design/data-model.md` として出力する

## 途中から再開する場合

既存の `docs/design/data-model.md` がある場合は、まずその内容を確認する。不足しているエンティティや更新が必要なリレーションシップのみを修正する。

**Example:**

```
ユーザー: 「概念モデルはできた。論理モデルを作りたい」
回答: 既存の data-model.md の概念データモデルを確認し、
      各エンティティのテーブル定義（カラム・データ型・制約）を作成する。
      主キー・外部キーの設計を行い、ER 図を PlantUML で更新する。
```

## 注意事項

- 要件定義とアーキテクチャ設計が完了していることが前提。未完了でも進めて構わない
- ER 図は必ず PlantUML で作成する。テキストベースの図はバージョン管理と差分レビューに適している
- ドメインモデルとの整合性を常に確認する。データモデルとドメインモデルの乖離は実装時の混乱を招く
- タスク項目（リスト）の前には空行を入れる（Markdown Lint 準拠）

## 関連スキル

- `orchestrating-analysis` — 分析フェーズ全体のワークフロー案内
- `analyzing-architecture` — 前段のアーキテクチャ設計
- `analyzing-domain-model` — 並行して進めるドメインモデル設計
- `analyzing-tech-stack` — 後続の技術スタック選定（DB 選定に影響）