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 | データモデル設計 |
業務の言葉でエンティティとリレーションシップを識別する。この段階では物理的な実装を考えない。ユースケースの「名詞」がエンティティ候補になる。
概念モデルを具体的なテーブル構造に落とし込む。正規化は第 3 正規形を基本とし、パフォーマンス要件に応じて非正規化を検討せよ。
PlantUML を使用して ER 図を作成する。テーブル間の関係を可視化することで、設計レビューの効率が上がる。
docs/design/data-model.md として出力する既存の docs/design/data-model.md がある場合は、まずその内容を確認する。不足しているエンティティや更新が必要なリレーションシップのみを修正する。
Example:
ユーザー: 「概念モデルはできた。論理モデルを作りたい」
回答: 既存の data-model.md の概念データモデルを確認し、
各エンティティのテーブル定義（カラム・データ型・制約）を作成する。
主キー・外部キーの設計を行い、ER 図を PlantUML で更新する。
orchestrating-analysis — 分析フェーズ全体のワークフロー案内analyzing-architecture — 前段のアーキテクチャ設計analyzing-domain-model — 並行して進めるドメインモデル設計analyzing-tech-stack — 後続の技術スタック選定（DB 選定に影響）