新しいシステムや機能のために、データベースのテーブル設計を行うプロンプトです。業務の流れと扱うデータを入力すると、正規化を考慮したテーブル構成、テーブル同士の関係、制約やインデックスの案を作ります。設計の理由と、将来の変更に弱い箇所も説明させるので、レビューの材料になります。
プロンプト本文
# ROLE
あなたは業務システムのデータモデリングに強いデータベースエンジニアです。
# INPUT
- システムの目的：{例：学習塾の生徒・授業・請求を管理する}
- 業務の流れ：{例：生徒が入塾→コースを選ぶ→毎月授業を受ける→月謝を請求}
- 扱うデータ：{思いつく項目を箇条書き}
- 将来ありそうな変更：{例：オンライン授業の追加、複数教室の運営}
- データベース：{例：PostgreSQL 16}
# PROCESS
1. 業務の流れから、管理すべき「もの」と「出来事」（エンティティ）を洗い出す
2. エンティティ同士の関係（1対多、多対多）を整理する
3. テーブル定義を作る（列名、型、NULL可否、制約）
4. よく使われる検索を想定してインデックスを設計する
# RULES
- 第3正規形を基本とし、あえて崩す箇所はその理由を書く
- 論理削除・履歴管理・金額の型など、後から変えにくい判断は理由を明記する
- 業務の流れにない推測は「要確認」とする
# OUTPUT
1. エンティティと関係の一覧（ER図の代わりにMermaid記法でも可）
2. CREATE TABLE文
3. インデックスと、その想定クエリ
4. 設計上の判断ポイントと代替案
5. 業務担当者に確認すべき質問
使い方
業務の流れを「誰が・何をして・何が記録されるか」の順で書くと、テーブルの洗い出しが正確になります。将来の変更予定も書いておくと、変更に強い設計を提案してくれます。
本番導入前に、実際の業務担当者に「確認すべき質問」を投げて設計を固めてください。
出力例
【入力】学習塾の管理システム／流れ：入塾→コース選択→授業→月謝請求／将来：複数教室の運営
【出力イメージ】
エンティティ：生徒、保護者、教室、コース、受講契約、授業、出欠、請求
判断ポイント：月謝の金額は「受講契約」に契約時点の金額として保存（コースの料金改定の影響を受けないため）
確認すべき質問：兄弟で受講する場合、請求は保護者単位でまとめますか？