🪜

データモデリング―第1部　ER図の誕生

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

📘 第1部：ER図の誕生 — 概念としてデータを捉える技術のはじまり

📘 第1章：誕生前 ― データは“物理構造に従属する”時代

私たちが当たり前のように「モデリング」と呼んでいるこの行為は、
かつては存在していなかった。
データを整理することはできても、
その“概念”を描く手段はなかった。

1950 年代から 60 年代、世界にあったのは 計算機とプログラムだけ。
データとは、プログラムを動かすための“材料”であり、
データ自身の構造が議論されることはほぼなかった。

当時主流だったのは 階層型モデル（Hierarchical Model）。
IBM の IMS が象徴的存在で、
“ルート → 子 → 孫” の木構造へとデータを押し込む方式だった。

この世界観では、データはプログラムが読みに行きやすいように
物理的な位置づけで並べられた存在だった。
「顧客 → 注文 → 明細」という構造に一度決めてしまえば、
その逆向きの検索（明細→注文→顧客）や、
別の“主役”の視点での扱いは極端に難しかった。

つまり、階層型モデルは
“物語の主役をひとりに固定し続ける世界” だった。

1960 年代後半になると、この制約の限界が見え始めた。
企業システムは複雑化し、
データ間の関係は階層構造の範囲を超え始めた。

そこで登場したのが ネットワーク型モデル（Network Model）。
CODASYL が規格化し、複雑なリレーションを扱えるようになった。
しかし柔軟性の代償として構造はどんどん複雑化し、
リンクは絡み合い、
「このレコードに辿り着くにはこの経路しかない」
という、別の意味で強い制約が生まれてしまった。

さらに悪いことに、
ネットワーク型モデルはアプリケーションと密結合で、
プログラムのロジックがデータ構造に貼りつくようになっていた。

  • 検索には専用の経路定義が必要
  • 構造を変えるとプログラム全体が作り直し
  • 概念的な設計は存在しない

こうした事情により、保守性は深刻だった。

そしてもうひとつ、決定的な問題があった。

この時代にはまだ、「データそのものを概念として捉える」という発想が存在していなかった。

データは「レコード」「フィールド」「ファイル」といった
物理的な単位で語られ、
“この情報は何を表しているのか”
“業務の構造はどうなっているか”
という問いは、
プログラムの都合の裏側に隠れていた。

1960〜70年代前半の設計書には、いまのような
概念モデル図は登場しない。
あるのはファイルレイアウト表と処理手順の説明だけ。

  • データは概念ではなく物理
  • 業務構造はプログラムに埋没
  • モデリングという行為そのものが存在しない

そんな“空白の時代”が続いていた。

1970 年、E.F. Codd が リレーショナルモデル を発表し、
データを「関係」として扱うまったく新しい視点を提案した。
しかし当時はまだ SQL が普及しておらず、
抽象理論として扱われていたため、
「これをどう図にするのか？」という問いは未解決だった。

この“空白”が、ある革新のために残されていた。

📘 第2章：誕生 ― ER図が“データを概念として語る”世界を開いた

1976 年、Peter Chen が
Entity–Relationship Model を発表した。

これは単なる新しい図の描き方ではなかった。
データを概念として扱うための理論そのものだった。

Chen は明確に宣言している。

「データは、現実世界の概念を表現する手段である」
「物理実装からは独立したモデルを持つべきである」

これは当時としては、革命的な価値観だった。

ERモデルの核心は、次の三つの要素から成る。

① 実体（Entity） ― “何が対象なのか” を示す単位

顧客、注文、製品、現場…。
業務上意味を持つ対象を“独立したもの”として定義する。
主キーという概念もここで強調され、
識別の一貫性が設計の第一原則となった。

② 関係（Relationship） ― “どう繋がるのか” を表現する

顧客は注文をし、
注文は明細を持ち、
製品はカテゴリに属する。

現実世界のつながりをそのまま表現できることは、
それまでのデータモデルにはなかった発想だった。

③ 属性（Attribute） ― 実体を形づくる情報

名前、日付、金額、数量など、
実体を構成する情報を整理する枠組みが整えられた。

ER図はここで
概念 → 論理 → 物理 の三層構造を固定した。
この思想は、それまで曖昧だった設計手順を
体系として立ち上げる原動力となった。

カーディナリティ、弱実体、複合属性、多値属性…
抽象概念を表現するための図法が揃ったことで、
世界中の研究者・教育者・エンジニアが ER図を採用し始めた。

商用 RDB（Oracle、DB2、Ingres）が成熟し、
SQL が標準化されるにつれ、
ER図は“データ設計の当たり前”になっていく。

そしてついに、
ER図はデータモデリングの中心言語として世界を統一した。

📘 第3章：黄金期 ― ER図が世界を圧倒した時代

ER図は誕生から数十年にわたり、
世界の企業システムを支える中心的存在となった。

その時代はまさに、
ER図が世界を圧倒した時代 だった。

3.1　企業システムを“統一”した共通言語

この時代の業務システムは、
会計、在庫、販売、購買、物流、金融、製造など、
あらゆる分野で ER図をベースに設計された。

プロジェクトに関わる

  • 企画担当
  • 設計者
  • DB エンジニア
  • アプリ開発者
  • テスター
  • 運用担当

すべてが 同じ図を囲んで議論できた。

ER図は技術ではなく、
コミュニケーションの基盤として機能していた。

3.2　正規化・SQL・RDBとの“黄金比”

ER図がこれほど普及した理由のひとつは、
当時の RDB の思想と完璧に噛み合ったことにある。

  • 正規化の理論
  • リレーショナルモデル
  • SQL
  • ACID トランザクション
  • 一貫性と整合性を重視する業務要件

これらすべてが ER図と強く結びつき、
論理設計 → 物理設計 → 実装 の流れを自然に作り出した。

ER図は“絵”ではなかった。
RDB の本質と接続する“思考の手段”だった。

3.3　教育とツールが普及を後押しした

  • ERwin
  • PowerDesigner
  • ER/Studio
  • Oracle Designer

主要 CASE ツールはすべて ER図ベースで構築され、
仕様変更やレビューの標準言語になった。

大学の情報系学部では、
「ER図を描けること」が
データベースを理解する最低条件として扱われた。

新人研修でも最初に教わるのは ER図。
レビューの場では ER図がなければ議論が始まらない。
それほどまでに、設計文化の根幹として浸透した。

3.4　図が“設計思想の記録”として機能していた

ER図は単なる構造図ではなく、
設計者の意図を写し取る“アーカイブ”として機能した。

  • どの情報が本質か
  • どこからどこへ関係が伸びているか
  • なぜ主キーがそうなっているか
  • どの結合が正当か

これらが一枚の図に凝縮され、
仕様変更もレビューもスムーズに進んだ。

大規模システムの品質を守ったのは、
ER図という揺るぎない土台だった。

3.5　黄金期の総括

ER図は、

  • 企業の基幹データを構造化し
  • チームの会話を統一し
  • 論理と物理の橋をかけ
  • 長期運用の安定性を確保し

時代を作った。

ER図は、データモデリングを世界に根づかせた英雄だった。

3.6　そして、静かに“次の時代”の足音が聞こえ始めた

ER図と RDB が不動の中心にあったその頃、
世界の片隅で、異なる方向を見据えた新しい設計思想が芽生え始めた。

ユーザー数の急増、常時接続、世界規模のトラフィック。
そんな圧力の中で、既存の枠とは違った形のデータ技術が生まれた。

名は NoSQL。

まだ小さな兆しにすぎなかったが、
それは確かに“別の未来”の気配を帯びていた。

黄金期は続いていた――
しかし世界は、ゆっくりと次の章へ向かい始める。

🌟 第1部：完

この続きは
第2部：ER図の盛衰 ― 現代の課題
へ続く。

Discussion