🎬 データモデリング ―序章　三層理論の舞台裏

まえがき：これは物語。しかし、いくつかの事実でできている。

ここに書いた内容は「事実＋物語」でできている。
事実は引用として明示し、
物語部分は想像と推測に基づいたフィクションだ。

ただし――
この物語は、ただの昔話ではない。

データの世界では長いあいだ、

• モデリングは“企業ごとのやり方”として成熟し（デファクトに広がり）
• SQLは“標準化された共通言語”として整備され
• RDB製品は“独自路線”で差別化し、ロックインの軸を作っていった

という、少しねじれた三本立てで進化してきた。

その結果、
「意味と構造と実体が、同じ方向を向いていない」
という状態が、いまも続いている。

物語として読むことで、
なぜデータモデリングが今日まで「分裂したまま」なのか。
なぜ新しい再編の余地があるのか。

その背景を、少しでも感じ取ってもらえたら嬉しい。

---

第1章：1975 以前 ― 静かなる地殻変動

■1960〜1970年代：ファイルシステムの時代
階層型 DBMS（IMS）やネットワーク型 DBMS（CODASYL）が主流だった。

冷たいメインフレームの排熱が、研究室の床をゆっくり揺らしていた。
巨大な計算機の前に立つ人たちは、まだ「データ」をひとつの塊として扱っていた。
階層、ネットワーク、そしてプログラムと密接に結びついた世界。
データは“管理されるもの”ではなく、“埋め込まれたもの”だった。

現場では、データ構造はプログラムの書き方そのものだった。
構造を変えるたびに、アプリケーションは書き直し。
担当者が変われば、データの意味も消える。
何かがおかしい――
けれど、まだ誰もその「おかしさ」を言語にできなかった。

そんな中、静かに動いていた者たちがいた。
“データとは何か” をプログラムから切り離して考えよう、と。

それが、後に革命を起こす火種になる。

---

第2章：1980 年以前 ― ふたつの思想の衝突

2.1 ANSI の「三層スキーマ」

■1975年、ANSI/SPARC 委員会
委員会は「三層スキーマ（外部・概念・内部）」を公表した。
データ独立性を目指す理論モデルとして後年多く引用される。

1975年。
会議室の空気は乾いていた。
理論家たちは、データを階層化しようとしていた。
外部、概念、内部。
構造の独立性。
アプリケーションとデータの分離。

それは“壮大な理論”だった。
ただし、図も道具もなかった。
実務者に渡しても動く気配がない、遠い遠い未来図だった。

2.2 翌年、ER 図が世界を変える

■1976年、Peter Chen
Chen は “Entity–Relationship model” を論文で公表した。

翌年、1976年。
一枚の図が登場した。
研究者の論文から生まれた図でありながら、
現場が「そのまま」使える図だった。

実体。
関係。
属性。

それらを一枚に描く。
概念と論理が一つの紙に溶ける。
人はそれを「ER 図」と呼んだ。

この瞬間、世界は静かに二分された。

• ANSI：理論モデル（使われない）
• ER：現場の道具（爆発的に普及）

ふたつの思想は、すれ違ったまま進み始めた。

2.3 標準化されなかった理由

本来なら ER 図は標準化されてもおかしくなかった。
ANSI 三層理論も ER モデルも、本質的には競合しないからだ。

• ANSI：データ独立性の思想
• ER：モデル化の技法

本来なら統合できた。
しかし――
ANSI はそれをしなかった。

もし統合すれば、ANSI 三層は「ER に飲み込まれる」ことになる。
三層スキーマは理論として語り継がれるが、
現場では誰も使わない“教科書の中の概念”として沈む。

そして ER は現実の現場で勝ち続け、
三層スキーマは“読み物”として残った。

そのズレが、その後 50 年続く“分裂”の始まりだった。

---

第3章：1980〜2000 ― SQL 標準化とベンダーの台頭

3.1 SQL 標準化の始まり

■1986年、ANSI SQL 初版（SQL-86）標準化
Oracle・IBM・Ingres などが採用し、RDB 時代が本格化。

SQL の標準化が始まると、
DB ベンダーは猛烈な速度で“実装競争”に走り出した。

• Oracle
• IBM DB2
• Sybase
• Ingres
• Informix

それぞれが独自拡張を行い、
「標準 SQL」は建前となっていく。

このとき、
もし ER が標準化されていたら
物語は少し違っていたかもしれない。

3.2 ベンダー独自機能が“鍵”となる

RDB ベンダーは、性能向上と囲い込みのために
独自機能を増やしていった。

• 独自のデータ型
• 独自の関数
• 独自のトランザクション制御
• 独自の最適化
• 独自のDDL拡張

顧客は一度選ぶと抜けられない。
いわゆる ベンダーロックイン の時代が始まる。

3.3 ER 図は“作図ツール化”した

ER 図は実質、モデリングツールとセットで広まった。

しかしツールは――
論理と物理を一枚に詰め込み、
インデックスまで図で表し始めた。

図は重くなり、
“本来の意図を伝える図” ではなく、
“実装構造を書き出す図” になっていった。

ER 図は、
本来の目的を忘れたまま、
SQL とベンダー独自機能に引きずられていく。

---

第4章：2000 年以降 ― OSS の台頭とカオスの再来

4.1 OSS の反撃

■2005年以降、PostgreSQL/MySQL が中大規模へ普及
クラウド時代の後押しもあり OSS が急速に浸透。

商用 DB の価格は跳ね上がり続けた。
特に某 O 社は、
ライセンス体系と保守費用で強気の姿勢を崩さず、
ユーザー企業は徐々に疲弊していく。

その反動として、
OSS の普及は加速度的に進んだ。

4.2 モデリングはさらに分裂する

• NoSQL
• ドキュメント型
• 列指向
• KVS
• Graph DB
• クラウドネイティブ DB

もはや「正しいモデリング」は存在しなくなった。
ER 図は多くの領域で“古典”となり、
ANSI 三層は“教科書の中の思想”となった。

世界は、
モデリング体系が標準化されなかった“その時代の遺産” を、
背負ったまま進むことになった。

---

第5章：エピローグ ― 50 年のすれ違いの果てに

1975〜2025 の 50 年。
データモデリングは一度も標準化されなかった。
理由は単純で、
“誰も同じ方向を向いていなかった”からだ。

• ANSI：思想を守る
• ER：現場を救う
• ベンダー：独自機能で競争する
• ツール：実装を吐き出す装置になる

そして今日、
データ構造の複雑性は増し、
モデリングは“個人のスキル”に戻ってしまった。

だが――
今だからこそ、
再構築の余地がある。

その“次に目指す場所”を、本編で語っていこう。

---