🪜

データモデリング―第2部　ER図の盛衰

に公開
ER 図
データモデリング
clm
idea

📘 第2部：ER図の盛衰 ― 時代の変化と構造的限界

ER図は長いあいだ、世界を統一した“共通言語”だった。
企業システムの土台はすべて ER図を中心に築かれ、
RDB と正規化の思想は揺るぎない前提となっていた。

その図はレビューの中心であり、教育の基礎であり、
データを語るならまず ER図、という文化が息づいていた。

その揺るぎない基盤は、誰もが長く続くと思っていた。
だが――時代は静かに、しかし確実に、別の方向へと流れ始める。

📘 第4章 DBMS の進化 ― ER図の前提が静かに揺らぎ始めた時代

インターネット普及後、
情報システムは企業内の閉じた世界から離れ、
外部・世界規模へと広がり始めた。
この変化はデータベースに対する要求を
劇的に押し上げていく。

可用性、性能、柔軟性、拡張性――
どれも“あれば良い”では済まない重要要件へと変わり、
DBMS はその期待に応えるべく急速に進化した。

まず、ユーザー増・データ増に伴い、
1台のDBでは支えきれない負荷が常態化する。
その結果、DBMSは複数ノード構成を本格的に採用し始めた。

  • レプリケーション
  • シャーディング
  • マルチリージョン
  • 自動フェイルオーバー
  • 冗長化クラスタ

これらは「単一の場所にデータがある」という
従来の前提をゆっくりと溶かしていく。

同時に、アプリケーション側の複雑化に伴い、
データ構造そのものにも柔軟さが求められるようになった。

  • JSON／ネスト構造
  • 複合インデックス
  • 部分インデックス
  • パーティション
  • 生成列・式インデックス
  • マテビュー
  • 行レベルセキュリティ（RLS）

DBMSは「保存と検索の装置」から、
運用・性能・可用性まで扱う総合基盤へと進化した。

この進化によって、
データ構造はもはや“概念モデルだけでは捉えきれない”
多様な要因（性能・配置・拡張・セキュリティ）に
影響されるようになる。

一方、ER図は

  • 単一DB
  • 単一スキーマ
  • 単一整合性
    という比較的静的な前提で設計されていた。

この前提と、
DBMSが現実世界に合わせて獲得した
分散化・可用性・柔軟性という新しい性質との間に、
少しずつ“設計上の距離”が生まれ始める。

まだこの時点では、
ER図が破綻したわけではない。
しかし「関係さえ描けばすべて説明できる世界」から
ゆっくりと外れていったことは確かだった。

その変化はやがて NoSQL の登場へとつながり、
ER図の弱点が本格的に露わになっていく。

📘 第5章：NoSQL の登場 ― “関係では捉えきれない世界” への回答

DBMS が分散化・柔軟化を進めていたその頃、
アプリケーションはさらに複雑になっていった。

Web サービスは “情報を保存する” だけでは済まず、
高速な読み取り・大量の同時アクセス・スキーマの急拡張
といった要求を次々と突きつけるようになる。

SNS、ブログサービス、ゲーム、EC――
これらの業務では、
「構造よりスピード」「正規化より柔軟性」が優先される
ケースが急増していった。

そんな状況で登場したのが NoSQL である。

NoSQL は、それまでの常識を覆す方針を掲げた。

  • スキーマレス（スキーマ固定を前提にしない）
  • 水平スケール前提（ノードを足せばスループットが伸びる）
  • 高い書き込み性能
  • 整合性の段階的許容（最終的整合性など）
  • 用途特化（Key-Value / Document / Column / Graph）

これは、RDB が緻密化・複雑化していく方向とは
まったく違う回答だった。

RDB は「すべてを一貫して扱う」ための技術を磨いてきた。
一方 NoSQL は、「要件に合う最小構造でスケールさせる」という
割り切りと最適化に振り切った。

ここで世界は二方向へ広がる。

ひとつは、正確さと整合性を求める RDB の進化。
もうひとつは、速度と柔軟性を求める NoSQL の進化。

そして企業システムの多くは
どちらかではなく 混在しながら 使われるようになっていく。

  • マスタ・台帳は RDB
  • ログ・イベントは NoSQL
  • キャッシュ的用途は Key-Value
  • 分析向けには列指向

こうして「データは複数の形で存在する」時代に入り、
ひとつのデータモデルだけでは説明しきれない現実
が生まれた。

NoSQL は RDB の代替ではなく、
“RDB では扱いきれない領域” に対する新しい答えだった。

ただ、この流れが ER図にとって致命的だったのは、
NoSQL の多くが

  • リレーションを持たない
  • 正規化を前提としない
  • スキーマが可変である
  • 文書や配列・ネストを前提にする

という、ER図が想定していた
「関係モデルの前提」を根本から覆す構造だったことだ。

こうして、
「ER図で説明できない領域」が、世界の主要データ領域に拡大していく
という状況が生まれる。

第1章で始まった “前提の揺らぎ” は、
ここで明確な形となり、
ER図にとっては初めての本格的な領域外が誕生した。

次章では、この流れの中で
ER図が「何を表現できないのか」
という弱点を、具体的に掘り下げていく。

📘 第6章：ER図の弱点 ― 時代が変わったときに露呈したもの

ここからは、
時代の変化によって表面化した“ER図そのものの弱点”
を整理する章。

弱点①　カラム要素を表現できない

“列レベルで必須なのに、ER図では表現不能”

  • トリガー（UPDATE/INSERT の自動処理）
  • 複合インデックス（複数列での最適化）
  • 外部キーの例外（NO ACTION / SET NULL などの詳細）
  • CHECK 制約（値域やルールの保証）
  • 生成列（派生列）

→ どれも論理設計より “実用運用そのもの” に直結する要素。
ER図はこれらを載せる場所を持たない。

弱点②　ビュー・テーブル要素を表現できない

“構造全体の重要要素なのに、ER図が守備範囲外”

  • ビュー（抽象化された読み取り専用の疑似テーブル）
  • マテビュー（性能改善の核）
  • パーティション（巨大テーブルを扱う仕組み）

→ どれも現代のスケーラビリティや性能設計の中心なのに、ER図の世界では“透明人間”になる。

弱点③　役割（ROLE）が表現できない

ER図は「どのデータがどう関係するか」は描けるが、
誰がそのデータにアクセスできるか（ROLE/権限境界）を描けない。

実務では、

  • 参照専用ロール
  • 更新可能ロール
  • テナント別ロール
  • 行レベル/列レベルの権限制御

など、権限設計がデータ設計の一部になっている。

しかしER図には
GRANT/REVOKE や RLS を含む“アクセス構造”を残す場所がなく、
結果として 図と運用の間に大きな空白が生まれる。

弱点④　意図（Intent）が残らない

ER図には
「なぜそうしたのか」 が残らない。

  • なぜ非正規化したのか
  • なぜ重複を許したのか
  • なぜキーを分けたのか
  • 権限設計の理由が残らない
  • どのパターンを想定した設計なのか

“図を見ても理由が分からない”という問題が
大規模システムで深刻化する。

弱点⑤　分散構造が描けない

  • シャーディング／シャードキー
  • 整合性の粒度（コンシステンシー）

これらは
概念的関係図では表現できない。

まとめ　弱点は“時代が変わった”ことで浮き彫りになった

ER図は弱い図法だったのではない。
時代があまりにも広がりすぎ、
扱うべき構造が複層化しすぎた。

結果として
“ER図だけでは世界を描けない”
という現象が避けられなくなった。

ER図は今も重要だが、
“これまでの守備範囲”では現代のデータ世界を支えられなくなっている。

📘 第7章：ER図の課題 ― なぜ “そのままの形” では時代に適応できなかったのか

7.1　課題①：世界が多様化し、ER図の前提が揺らいだ

かつてデータはテーブルと関係で統一できたが、
現代では用途に応じて 複数の構造 を持つ。

  • ドキュメント
  • カラムファミリ
  • キー・バリュー
  • グラフ

これらは、
「単一の構造を前提にしたモデル」では統一できない世界を生み出した。

しかしこの多様化は、同時に
“複数構造を抽象化して扱うモデリング体系が必要である”
という方向性も示している。
ER図が扱える範囲と、抽象化によって扱うべき範囲の整理が課題として浮かび上がった。

7.2　課題②：標準SQLの進化に、ER図は役割を分担できなかった

標準SQL もこの30年で進化し、
制約・最適化・派生・物理構造まで記述できる範囲を広げてきた。

一方でER図は、
論理構造を描く図として固定化され、
標準拡張に追従する枠組みを持たなかった。

その結果、
SQLが「概念 → 論理 → 物理」を一貫して扱えるのに対し、
ER図は “論理のみ” を担当し続ける形で止まってしまった。

しかしこれは、
概念・論理・物理をレイヤとして分け、ER図は“論理レイヤ”として再定義すべき
という課題を示したとも言える。
役割を絞れば、ER図は依然として有効である。

7.3　課題③：DB固有機能の爆発的発展を吸収する枠組みがなかった

現代DBは標準SQLを超える固有機能で競い合っている。

  • JSONB とその索引
  • GIN / GiST / BRIN
  • RLS
  • 生成列・式インデックス
  • パーティション
  • Extension

こうした機能は性能と表現力の中核を担うが、
ER図はこれらを “図としてどう扱うか” の枠組みを持たなかった。

しかし、これも
ER図に全てを押し込むのではなく、
“ER図が扱う範囲” と “DB固有設計が扱う範囲” を分離すべき
という課題を浮かび上がらせた。
分担設計によって補完しあう方向性が必要である。

7.4　課題④：設計意図（Intent）が残らない

現代システムでは、構造そのものだけでなく、
「なぜその構造にしたのか」という設計意図（Intent） が
後続工程・運用・次の設計判断にとって重要になる。

しかし ER図は、
実体・属性・関係といった“形”の情報を表現するには優れているものの、
「この列はなぜ必要なのか」
「この関係は何を保証するためなのか」
「この非正規化はどんなトレードオフの結果なのか」
といった“判断の背景”を残す仕組みを持たない。

もちろん、意図を別ドキュメントとして補えばよいのだが、
ER図と設計意図をセットで扱う文化や指導が十分に浸透してこなかった。

そのため現場では、

  • 目的が伝わらない
  • 意図を知らないまま変更される
  • “図に描いていない部分”が消える
  • 過去の判断を再発明する

といった問題が繰り返される。

これは ER図そのものの欠陥ではないが、
意図を残す習慣を支えるレイヤが体系として用意されていなかったことが課題である。

次世代モデリングでは、
構造と意図を並走させ、意図が自然に残る運用を前提にする必要がある。

7.5　まとめ：課題が示す“ER図の守備範囲”

ER図にはいくつもの課題が見えてきた。
それらは単なる弱点ではなく、

「ER図がどこまで担えるか」
「どこから先は別のモデリングが必要か」

という “守備範囲” を示している。

抽象化のモデリングにおいて、ER図の功績は今なお大きい。
しかし、抽象を現代の設計へ具現化していく段になると、
ER図の守備範囲ではカバーしきれない領域が増えすぎた。

データの形が多様化し、
流れと意図が設計の中心になった現代では、
構造をただ描くだけでなく、複数の構造やレイヤを橋渡しする“抽象層”を持つこと自体が設計になる。

第3部では、その抽象層をどう設計し、
どう運用に落とすかを具体化していく。

🌟 第2部：完

次は 第3部：次世代への提言 ― 新しいモデリングの姿 へ。

Discussion