🗄️

DBの根元から Part01 - コンピュータの記憶からSQLの誕生まで

に公開
SQL
Database
Computer science
history
idea

DBの根元から Part01

はじめに

こんなSQL文を見たことがありますか？

SELECT name FROM users WHERE age > 20;

この1行で「20歳より上のユーザーの名前を全て取得する」ことができます。まるで英語のような自然な文章でデータを操作できる、とても便利な技術です。

でも、不思議に思いませんか？なぜこんなに簡単にデータを取得できるのでしょうか？コンピュータが発明された1940年代、人々はどうやってデータを管理していたのでしょうか？

この記事では、パンチカードの時代から現代まで、データ管理技術がどのように進化してきたかを辿ります。歴史を知ることで、今使っている技術がいかに革命的で便利なものかが実感できるでしょう。また、「なぜこの技術が生まれたのか」を理解することで、技術への理解がより深まるはずです。

プロローグ：そもそもコンピュータって何だっけ？

データベースの話の前に、そもそもコンピュータって何なのでしょうか。

実は、コンピュータの本質って驚くほどシンプルです。

コンピュータの3つの基本機能

  • 入力（Input） - キーボードやマウスでデータを受け取る
  • 処理（Process） - 計算したり、データを加工したり
  • 出力（Output） - 画面に表示したり、印刷したり

そして、もう一つ超重要なのが記憶（Storage） - データを保存しておく機能です。

この「記憶」には、性質が全く違う2つのタイプがあります。

  1. 一時的な記憶（メモリ/RAM）
  • 超高速でアクセスできる
  • 非常に高価
  • 電源を切ると全て消える
  • 例：いま作業中のExcelファイル
  1. 永続的な記憶（ストレージ）
  • アクセスは比較的遅い
  • 安価で大容量を確保できる
  • 電源を切っても残る
  • 例：保存したExcelファイル

しかし、ここで重要な課題が生まれました。この「永続的な記憶をどのように効率よく管理するか」という問題です。実は、この課題こそがデータベース技術発展の出発点となったのです。

第1章：原始時代 - パンチカードからファイルシステムへ（1940-1960年代）

1940-50年代：パンチカードの時代

想像してみてください。1950年代のオフィス。コンピュータはまだ部屋いっぱいの巨大な機械でした。

当時のデータはパンチカードに保存されていました。厚紙に穴を開けて情報を記録するという、今では想像しにくい方法です。

パンチカードのイメージ

┌──────────────────────────┐
│ ● ●   ●     ●   ●        │ ← 穴の位置で情報を表現
│   ●     ●       ●   ●    │
│     ●         ●       ●  │
└──────────────────────────┘
社員ID: 001  名前: 佐藤太郎

ところが、このパンチカードには致命的な問題がありました。
まず、物理的な媒体であるため、カードが傷みやすく、企業では数万枚ものカードを物理的に管理する必要がありました。
さらに深刻だったのは、特定の情報を探すときには、全てのカードを順番に確認するしか方法がなかったことです。
これでは効率的な情報管理など到底不可能でした。

1960年代：磁気テープ時代の到来

パンチカードの物理的制約を克服するため、1960年代には磁気テープが実用化されました。
これは、昔のカセットテープのように磁気を使ってデータを順番に記録できる画期的な技術でした。カードと違って物理的に傷むこともなく、大容量のデータをコンパクトに保存できるようになったのです。

しかし、磁気テープにも問題がありました。

さらに深刻だったのは、データの重複問題でした。

具体例：田中さんの住所変更シナリオ

給与システム用のテープ
┌───────────────────┐
│ 田中一郎           │
│ 住所: 東京都新宿区  │  ← 新住所に更新
│ 給与: 50万円       │
└───────────────────┘

人事システム用のテープ
┌──────────────────┐
│ 田中一郎           │
│ 住所: 東京都渋谷区  │  ← 更新し忘れた！
│ 入社日: 2020/04/01 │
└───────────────────┘

結果として、

  • 給与明細は新住所に届く
  • 人事部は旧住所を参照
  • データに矛盾が発生

この「データ重複」と「不整合」の問題が、次の時代への扉を開きます。

第2章：DBMSの黎明期（1960年代後半-1970年代）

階層型データベース（Hierarchical Database）

1960年代後半、IBMが画期的なシステムを開発しました。IMS（Information Management System）です。

これは、データをツリー構造（木の枝のような構造）で管理する仕組みでした。

階層型データベースは、確かに画期的でした。親子関係が明確で、親から子へと辿る高速なデータアクセスが可能になったからです。

階層型データベースの構造例

会社
├─ 営業部
│  ├─ 佐藤太郎（営業マネージャー）
│  └─ 鈴木花子（営業担当）
└─ 技術部
   ├─ 田中一郎（開発チームリーダー）
   └─ 山田次郎（エンジニア）

この構造では、「営業部の社員一覧を取得する」といった操作は非常に高速でした。会社→営業部→各社員と、親から子へと一方向に辿るだけで済むからです。

しかし、現実のビジネスは複雑でした。

階層型データベースの問題

構造があまりにも硬直的すぎたのです。特に問題だったのは、一つの子が複数の親を持てないという制約でした。

こんなケースに対応できない

田中一郎さんが
- 技術部のチームリーダー
- 営業部の技術顧問（兼任）

→ 一人の人が「2つの親」を持つことができない

このような複雑な組織関係は、階層型では表現不可能でした。データを重複して保存するか、どちらか一方の関係を諦めるしかなかったのです。現実のビジネスは複雑で、単純な階層構造では対応しきれなかったのです。

ネットワーク型データベース（Network Database）

階層型の制限を緩和したのがネットワーク型です。これなら複数の部署に所属することも表現できます。

ネットワーク型データベースの構造例

技術部 ←─────┐
  ↑         │
  │         │
田中一郎 ─→ 営業部
            ↓
          佐藤太郎

ネットワーク型の仕組み
ネットワーク型は、ポインタ（データの場所を指し示す「住所」のようなもの）を使って、複雑な関係を表現しました。

ところが、ネットワーク型データベースは新たな悪夢をプログラマーにもたらしました。
複雑な関係を表現できるようになりましたが、プログラミングが非常に難しくなったのです。

データ取得の手順（イメージ）

「営業部に所属する技術者」を探す場合

1. 社員テーブルを先頭から1人ずつ確認
2. その人の「部署への住所（ポインタ）」を辿って部署を確認
3. 営業部なら、「職種への住所（ポインタ）」を辿って職種を確認
4. 技術者なら出力、違えば次の人へ
5. 全員チェックするまで繰り返し

→ まるで迷路を歩くような作業

簡単なデータ取得でさえ、このように社員レコードを開き、部署へのポインタを辿り、部署レコードを開き、さらにプロジェクトへのポインタを辿る...といった複雑な手順を延々と繰り返す必要がありました。これはまるで迷路を歩くような作業で、プログラミングは極めて複雑になりました。

さらに深刻だったのは、データ構造を少しでも変更すると、それに依存する全てのアプリケーションを書き直さなければならなかったことです。
新人プログラマーが入社しても、この複雑なデータ構造を理解するだけで数か月を要し、生産性は著しく低下していました。

なぜこれらのデータベースモデルが問題だったのか

実際に開発現場で働く人の立場で考えてみてください：

  1. 学習コストが異常に高い

    • 新人が戦力になるまで半年以上かかる
    • データ構造図を理解するだけで1ヶ月

  2. メンテナンス性が最悪

    • 「部署コード」を1つ変更するだけで、20個のプログラムを修正
    • バグの影響範囲が予測困難

  3. 開発速度が遅い

    • 簡単な検索機能でも100行のコード
    • SQLなら1行で済む処理に1日かかる

これではビジネスのスピードについていけません。ここで革命が起きます。

第3章：革命！関係モデルの誕生（1970年）

エドガー・コッド博士の論文

1970年6月、IBMの研究者エドガー・コッド博士が一本の論文を発表しました。

タイトル："A Relational Model of Data for Large Shared Data Banks"

彼は言ったのです。「データをテーブル（表）で表現すればいいじゃないか」と。

関係モデルが革命的だった理由

従来のアプローチでは、データを複雑な構造（ツリーやネットワーク）に無理やり押し込めていました。これに対してコッド博士は、まったく異なるアプローチを提案しました。データを人間にとって最も自然な形である「表」で表現し、データ間の関係性は別途管理するという発想です。

これはまさに、私たちが日常的に使っているExcelの表と同じ形式でした。この発想が天才的だったのは、プログラマーでなくても直感的に理解できるデータ表現を実現したことです。複雑なポインタを辿る必要もなく、ただ表を見るだけでデータの構造が把握できるようになったのです。

関係モデルを構成する5つの基本概念

  1. テーブル（Table）
    データを行と列の表形式で格納する
社員テーブル
┌────────┬────────┬──────┬──────┐
│ 社員ID │  名前  │ 年齢 │ 部署 │
├────────┼────────┼──────┼──────┤
│  001   │佐藤太郎│  30  │ D01  │
│  002   │鈴木花子│  25  │ D01  │
│  003   │田中一郎│  35  │ D02  │
└────────┴────────┴──────┴──────┘
  1. 行（Row）
    一人の社員情報など、一つのデータのまとまり
  2. 列（Column）
    名前、年齢など、データの属性
  3. 主キー（Primary Key）
    各行を一意に識別する値（社員IDなど）
  4. 外部キー（Foreign Key）
    他のテーブルとの関係を表す値（部署IDなど）

データ独立性という革新的概念

しかし、コッド博士の本当の天才性は、データ独立性という概念にありました。これは2つの側面から構成されています。

物理的データ独立性では、データが実際にハードディスクのどこに、どのように保存されているかを変更しても、アプリケーション側は全く影響を受けません。一方、論理的データ独立性では、データ構造を変更しても、既存のアプリケーションへの影響を最小限に抑えることができます。

この威力を具体例で見てみましょう。

従来（ネットワーク型DB）の場合

社員テーブルに「メールアドレス」列を追加
↓
データ構造が変わる
↓
このテーブルを使う全てのプログラムを修正
↓
100個のプログラムを書き直し

関係モデルの場合

社員テーブルに「メールアドレス」列を追加
↓
メール機能を使わないプログラムは修正不要！
↓
新しい機能だけ追加すればOK

これによって、ビジネスの変化に柔軟に対応できるようになりました。

第4章：SQLの誕生と標準化（1970年代）

SQL以前の世界

コッド博士の論文は素晴らしかったのですが、一つ問題がありました。「どうやってデータを取り出すか」の具体的な方法が決まっていなかったのです。

昔のデータ取得（ネットワーク型DB）

// 営業部の社員を取得
SET current_db TO company_db
FIND FIRST department WHERE name = '営業部'
WHILE found DO
  FIND NEXT employee WITHIN department
  PRINT employee.name
END

これは読みにくく、プログラマーしか書けませんでした。

IBMの革命的な取り組み：SEQUELからSQLへ

コッド博士の理論を実際のシステムに実装するため、1974年にIBMのサンホセ研究所で重要なプロジェクトが始動しました。ドナルド・チェンバレンとレイモンド・ボイスを中心とする研究チームは、関係モデルを実装した世界初の実用的システム「System R」を開発しました。そして、このシステムを操作するための言語として、最初にSEQUEL（Structured English QUEry Language）という名前で開発されました。後に商標権の問題からSQLという名前に変更されましたが、このシステムこそが現代のリレーショナルデータベースの原型となったのです。

革命的だったのは、英語の文章に近い構文で書ける宣言型言語だったことです。

SELECT 名前
FROM 社員
WHERE 部署 = '営業部';

これなら普通の人にも理解できます。『営業部の社員から名前を選択して』と読めますね。

宣言型言語という革命

従来の手続き型アプローチでは、データを取得するために詳細な手順を全て指示する必要がありました：

// 従来の手順（ネットワーク型DBの場合）
1. 部署テーブルを開く
2. '営業部'を順番に探す
3. 見つかったら社員テーブルに移動
4. その部署の社員を一人ずつ取得
5. 結果をリストに追加
...（延々と続く）

一方、SQLの宣言型アプローチでは、欲しい結果だけを指示します：

SELECT 名前 FROM 社員 WHERE 部署 = '営業部';

「どのような手順でデータを取得するか」は、データベース管理システム（DBMS）が自動的に最適な方法を判断してくれます。

この違いの例え

  • 従来の方法 = 「右に100m進んで、次に左に50m進んで...」（具体的な道順を指示）
  • SQLの方法 = 「駅まで行きたい」（目的地だけを指示、経路はナビが自動で選択）

これは画期的な変化でした。プログラマーは複雑な手続きから解放され、「何をしたいか」というビジネスロジックに集中できるようになったのです。

実際のSQLを体験してみよう

理論だけではイメージが湧きにくいので、架空の会社の人事データベースを例に、SQLがどれほど簡単かを体験してみましょう。

1. データ作成

-- 部署テーブルを作成
CREATE TABLE 部署 (
    部署ID TEXT PRIMARY KEY,
    部署名 TEXT NOT NULL
);

-- 社員テーブルを作成
CREATE TABLE 社員 (
    社員ID TEXT PRIMARY KEY,
    名前 TEXT NOT NULL,
    年齢 INTEGER NOT NULL,
    給与 INTEGER NOT NULL,
    部署ID TEXT NOT NULL,
    FOREIGN KEY (部署ID) REFERENCES 部署(部署ID)
);

-- 部署データを挿入
INSERT INTO 部署 (部署ID, 部署名) VALUES 
('D01', '営業部'),
('D02', '技術部');

-- 社員データを挿入
INSERT INTO 社員 (社員ID, 名前, 年齢, 給与, 部署ID) VALUES 
('001', '佐藤太郎', 30, 400, 'D01'),
('002', '鈴木花子', 25, 350, 'D01'),
('003', '田中一郎', 35, 500, 'D02'),
('004', '山田美咲', 28, 420, 'D02');

2. SELECT（選択）

全社員の名前と年齢を取得：

SELECT 名前, 年齢 FROM 社員;

3. WHERE（条件）

30歳以上の社員：

SELECT 名前, 年齢 FROM 社員 WHERE 年齢 >= 30;

4. JOIN（結合）

社員と部署を結合：

SELECT 社員.名前, 部署.部署名
FROM 社員
JOIN 部署 ON 社員.部署ID = 部署.部署ID;

関係モデルの真の威力は、データを適切に分割して管理することで、重複を避けつつ柔軟にデータを組み合わせられる点にあります。これにより、データの整合性を保ちながら、様々な角度から情報を分析できるようになったのです。

SQLの標準化への道のり

SQLが注目されると、多くの企業が独自のデータベース製品を開発し始めました。しかし、これが新たな問題を生み出しました。各社が独自機能を追加した結果、会社ごとに「SQL方言」が生まれてしまったのです。

SQL方言の例

-- Oracle
SELECT TOP 10 * FROM users;

-- MySQL  
SELECT * FROM users LIMIT 10;

-- PostgreSQL
SELECT * FROM users LIMIT 10;

同じ「先頭10件を取得」でも、書き方が微妙に違います。これでは、せっかくのSQLの汎用性が損なわれてしまいます。

この混乱を解決するため、業界全体で標準化への取り組みが本格化しました。

年 標準名 主な内容
1986 SQL-86 最初の標準（ANSI）
1987 SQL-87 ISO標準として採用
1992 SQL-92 大幅拡張（JOIN構文の標準化など）
1999 SQL:1999 トリガー、再帰クエリなど追加
2003 SQL:2003 XML対応
2011 SQL:2011 時系列データ対応
2016 SQL:2016 JSON対応
2023 SQL:2023 プロパティグラフクエリ対応

1986年、アメリカ国家規格協会（ANSI）がSQL-86として最初の標準を制定しました。翌1987年には国際標準化機構（ISO）もこれを採用し、SQLは名実ともに国際標準となりました。

その後、標準化は継続的に進化を続けましたが、特に転換点となったのが1992年のSQL-92でした。この改定により、JOIN構文をはじめとする基本的なSQL構文が統一され、現在私たちが使っているSQLの基礎が確立されました。近年では、XML対応（SQL:2003）、JSON対応（SQL:2016）、プロパティグラフクエリ対応（SQL:2023）など、時代の変化に合わせて機能拡張が続けられています。

興味深いことに、標準が存在する一方で、各DBMSベンダーは独自の拡張機能も提供し続けています。しかし重要なのは、基本部分が共通していることです。

標準化の恩恵

  • 一度SQLの基本を習得すれば、Oracle、MySQL、PostgreSQL、SQL Serverなど、どのデータベースでも基本操作は同じ
  • 転職先で違うデータベースを使っていても、基本は変わらない
  • 学習コストを大幅に削減できる

まとめ

この記事では、コンピュータの基本的な記憶の仕組みから始まり、パンチカードの時代を経て、現在私たちが使っているSQLの誕生までの歴史を辿りました。

この記事で重要なポイントを整理します。

  1. データベース技術の根源

    • コンピュータの「永続的な記憶をいかに効率的に管理するか」という課題から生まれた

  2. 古い技術の限界が新技術を生む

    • 階層型・ネットワーク型データベースの複雑さが、関係モデルという革命的発想を生み出した

  3. 関係モデルとデータ独立性

    • 「表」という直感的な表現により、誰でも理解できるデータ管理を実現
    • データ構造の変更が既存システムに与える影響を最小化

  4. 宣言型言語の革命

    • SQLは「何が欲しいか」だけを指示する新しいプログラミングパラダイム
    • 複雑な手続きは全てDBMSが自動で最適化

  5. 標準化の価値

    • 一度覚えれば様々なデータベースで応用できる汎用性を獲得

技術の歴史を辿ることで、現在私たちが当たり前のように使っているデータベース技術が、実は多くの試行錯誤と技術的ブレークスルーの積み重ねによって生まれたものであることが理解できたのではないでしょうか。パンチカードの時代から現在のSQLまで、一見すると技術的な進歩に見えるものも、実際には人間の根本的な課題「情報をいかに効率的に管理し、活用するか」への挑戦の歴史だったのです。

シリーズナビゲーション

この記事は「DBの根元から」シリーズの第1回です。

シリーズ全体

次の記事
Part02：商用DBMSとオープンソース革命 →では、OracleやSQL Serverの商用DBMS時代から、MySQLやPostgreSQLのオープンソース革命までを詳しく解説しています。

GitHubで編集を提案

Discussion