目的
UPDATE（更新）を極力なくし、INSERT中心のシンプルなデータモデルを作って
システムの複雑さを抑える。
1. 手順全体の流れ
-
エンティティを抽出
5W1H（Who / What / When / Where / Why / How）に下線を引き、
それぞれをエンティティ候補とする。 -
リソースとイベントに分類
- リソース (Resource) … “モノ・人・場所・時間”など 日時を持たない
- イベント (Event) … “行動・出来事”など 必ず日時を１つだけ持つ
-
イベントの日時は１つだけ
１イベント＝１日時（INSERTのみ、UPDATE禁止）になるよう分割する。 -
リソースに隠れたイベントを洗い出す
リソースに「更新日時」「削除フラグ」を入れたくなったら、
それは見落としているイベントがあるサイン。 -
非依存なリレーションは交差エンティティに分ける
例）部門と社員 →所属テーブルを挟む。
INSERTだけで関係を表現し、NULL外部キーや後更新をなくす。
2. 押さえておきたいポイント
| ポイント | なぜ重要？ |
|---|---|
| UPDATEを減らす | UPDATEはルールが複雑になりがち。INSERT Onlyにするとシンプル |
| イベント中心設計 | お金を生むのは業務イベント。ER図でも中心に描く |
| 登録/更新日時の乱用禁止 | 「原因解析用」と言っても１世代しか記録できず役立たない |
| “マスタ/トランザクション”分類は使わない | あいまいで議論が発散するため |
| 削除フラグより区分化 | 本当に消すか、区分（退職社員など）で扱いを分けるかを明示 |
3. 実装時のヒント
-
スーパータイプ / サブタイプ
区分で扱いが変わるリソースは ER 図で明示し、実装は- シングルテーブル継承
- 具象テーブル継承
- クラステーブル継承
などパターンを選択。
-
世代管理（履歴 vs. 未来）
- 過去だけなら「シングル世代テーブル」。
- 過去＋未来なら「世代バージョン＋タグ」方式などを検討。
-
交差エンティティの履歴
現在の関係を高速に引けるよう、
「配属（履歴イベント）」と「所属（現在の関係）」を分ける。
4. まとめ
イミュータブルデータモデルは “更新をなくす設計” であり、
- イベントを細かく分けて INSERT Only にする
- リソース更新の裏にあるイベントを逃さない
- NULL外部キーや削除フラグに頼らない
ことで 保守が楽でバグりにくいシステム を実現する手法です。