k2works/analyzing-data-model

データモデル設計

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 選定に影響）