データベース設計を考える際、概念データモデルの段階で「イベント」をそのままエンティティとして扱ってしまい、後で設計が苦しくなることがあります。
今回はその理由を簡単な例で整理します。
1. 問題になりやすい具体例（NG例）
・注文
・申込
・契約
これらをそのままエンティティ（テーブル）として定義したくなることがあります。
注文
├ 注文ID
├ 顧客ID
├ 商品ID
├ 注文日
├ 状態（受付中／完了／取消）
一見すると問題なさそうに見えます。
2. なぜこの設計がつらくなるのか
• 状態が更新されるたびに過去情報が消える
• 「いつ・なぜ」状態が変わったか分からない
• 取消・再処理・再申込に弱い
特に履歴管理が要件に出た瞬間に破綻しやすい。
3. 考え方の整理
• 顧客・商品 → 実体
• 注文・申込 → イベント（状態変化を伴う）
イベントは「1レコード＝1状態」で考えると設計しやすい。
イベントは、
• 履歴として残すのか
• 状態管理が必要か
を意識して設計する必要があります。
4. 理想の具体例（改善後）
実体テーブル
顧客
├ 顧客ID（PK）
├ 氏名
商品
├ 商品ID（PK）
├ 商品名
イベント＋履歴テーブル
注文
├ 注文ID（PK）
├ 顧客ID（FK）
├ 注文日
注文履歴
├ 注文履歴ID（PK）
├ 注文ID（FK）
├ 状態（受付中／完了／取消）
├ 更新日時
✔ 状態変更は「履歴として追加」
✔ 過去状態が追える
✔ 再処理・取消要件に対応しやすい
5. デスぺ視点でのポイント
データベーススペシャリスト試験（午後Ⅱ）では、
• 状態遷移
• 履歴管理
• 再処理
が要件に含まれることが多く、イベントを安易に1エンティティで済ませると減点されやすいです。
まとめ
・問題例 → なぜダメか → 理想例の順で考える
・イベントは状態変化を前提に設計する
・履歴は別エンティティとして扱うと安定する