ITエンジニアで、リレーショナルデータベース（RDBMS）やSQLを触ったことがないという方はほぼいないでしょう。しかし、RDBMSの概念がどのように誕生し、どのような理論に基づいているのかを皆さんはご存知でしょうか。
本記事では、リレーショナルデータベースが生まれるきっかけとなった基礎論文の概要と、そこで提唱された主要な概念が現代のSQLやRDBMSでどのように実現されているかを解説します。
- コッドの基礎論文の概要と背景
- 階層型データモデルの欠点
- データ独立性（Data Independence）
- リレーション（Relation)
- 鍵（Primary Key / Foreign Key）
- 正規化（Normalization）
- 関係代数と演算: SQLの原型
- まとめ
コッドの基礎論文の概要と背景
エドガー・F・コッドによる1970年の論文 「A Relational Model of Data for Large Shared Data Banks」 は、現代のリレーショナルデータベースマネジメントシステム（RDBMS）の理論的基礎を築いた記念碑的な論文です。
1970年当時、データの管理は「階層型」や「網型（ネットワーク型）」が主流でした。これらはデータが「物理的な構造（ポインタや親子関係）」に強く依存しており、データ構造を変更するとプログラムも修正しなければならないという欠点がありました。
コッドはこの論文で、「データと物理的な実装を分離し、数学的な集合論（述語論理）に基づいた構造にすべきだ」と提唱しました。これが「リレーショナルモデル（関係モデル）」の誕生です。
これにより、データの物理的な実装からユーザーを解放し（データ独立性）、高度な記述力を持つ言語でデータを操作できる基盤を提示しました。
階層型データモデルの欠点
当時使われていた階層型データベースの最大の問題は、「物理構造と論理構造が密結合している」点にありました。
論文で示された例
部品（Part）と、その部品を使うプロジェクト（Project）が、以下の階層関係でファイルに保存されているとします。
ファイル F
- Part (part ID, name, description)
- Project (project ID, name, quantity committed)
プロジェクトに使われた部品の数量（quantity committed）を知りたい場合、アプリケーションは「ファイルFを開き、Partを探し、その子であるProjectを辿る」という、データの格納順序や物理的なパスに依存したコードを書く必要がありました。
もし、効率化のためにデータの保存形式が「ファイルF（Part）とファイルG（Project）」に分割されるなどの変更が行われると、既存のアプリケーションプログラムはデータを見つけられず、壊れてしまいます。
データ独立性（Data Independence）
コッドは、アプリケーション側がデータの物理的構造を知る必要がなく、物理構造が変わってもプログラムが壊れない状態（物理的独立性）を理想としました。
特に、以下の3つの依存性の排除を強調しています。
- 順序依存性： データがどのような順番でファイルに書き込まれているか。
- インデックス依存性： どの列にインデックスが貼られているか。
- アクセスパス依存性： ポインタなどで連結されたデータの辿り方。
現代の実装
現代のエンジニアは、データの並び順やファイルの配置を気にせず、SQLという宣言型言語で「何（What）が欲しいか」を伝えるだけです。RDBMS内の「クエリ最適化（オプティマイザ）」が、最も効率的な「どう（How）取得するか」を自動的に判断します。
リレーション（Relation)
コッドの論文の核心は、論理的なデータ構造に数学的な「リレーション」を採用したことです。
よくある誤解として「リレーション＝テーブル間の関係（リレーションシップ）」と思われがちですが、数学的には「表そのもの」をリレーションと呼びます。
理論的な定義
リレーションとは、わかりやすく言えば「表の各行の集合」です。表の各列を全て集めると表全体になるのはスプレッドシートを思い浮かべるとイメージできるかと思います。
数学的な定義では、リレーション R は複数の集合（ドメイン）の直積の部分集合、つまり「タプルの集合」です。
- ドメイン (Domain)： 値の集合（例：すべての従業員番号の集合）。
- タプル (Tuple)： 各ドメインから選ばれた値の組（行）。
- リレーション (Relation)： タプルの集合（表）。
| 姓（ドメイン1） | 名（ドメイン2） |
| 田中 | 太郎 |
| 佐藤 | 花子 |
重要： 集合であるため、リレーション内には「重複する行」は存在せず、「行の順序」も意味を持ちません。
現代の実装
現代のRDBMSでは、用語が以下のようにマッピングされています。
- リレーション –> テーブル（表）
- リレーションの各列 –> カラム（列）
- タプル（Tuple） –> レコード（行）
鍵（Primary Key / Foreign Key）
- 論文のポイント： ポインタによるデータの関連付けを廃止するため、各タプルを一意に識別する「主キー（Primary Key）」と、他のリレーションを参照するための「外部キー（Foreign Key）」を定義しました。j
- 現代の実装：
PRIMARY KEY制約やFOREIGN KEY制約として実装されています。これにより、ポインタを使わずに「データそのものの値」によって関連性を表現できるようになりました。
正規化（Normalization）
- 論文の提唱： 複雑な階層構造（繰り返し項目やネストされた表）を排除し、単純な値のみで構成される「第1正規形」へと変換するプロセスを提案しました。
- 現代の実装： データベース設計の基本です。1つのセルに複数の値を入れない、データの重複を排除して更新異常を防ぐ、といった設計指針はすべてここから始まっています。
関係代数と演算: SQLの原型
コッドは、リレーションを操作するための演算（制限、射影、結合など）を定義しました。これが現在のSQLの構文に直接つながっています。
- 制限 (Selection / Restriction)： 条件に合う行を取り出す（SQLの
WHERE）。 - 射影 (Projection)： 必要な列だけを取り出す（SQLの
SELECT列名）。 - 結合 (Join)： 共通の属性を持つ2つのリレーションをつなぐ（SQLの
JOIN）。
まとめ
現在私たちが当たり前のように使っているRDBMSやSQLは、1970年の論文で示された「データは数学的な集合として扱うべきである」というコッドの思想に基づいています。
物理的なポインタを辿る時代から、宣言的なSQLでデータを操作する時代へ。このパラダイムシフトがなければ、現代の複雑なWebアプリケーションやビッグデータ解析は実現しなかったでしょう。
論文は11ページと非常にコンパクトです。原文にあたることで、「なぜSQLはこのような構造なのか」という本質的な理解が深まるはずです。
論文の提唱概念と現代の実装の対応表
| 論文の提唱概念 | 現代の実装 |
| データ物理構造の分離 | リレーショナルデータベース（RDBMS） |
| リレーション | テーブル（表） |
| 属性 (Attribute) | カラム（列） |
| タプル (Tuple) | レコード（行） |
| ドメイン (Domain) | データ型 / 制約 |
| 主キー (Primary key) | 主キー制約 |
| 外部キー (Foreign key) | 外部キー制約 |
| 正規化 | 正規化理論 |
| 射影 (Projection) | SELECT 句 |
| 制限 (Selection) | WHERE 句 |
| 結合 (Join) | JOIN 句 |
参考文献:
- E.F. Codd, “A Relational Model of Data for Large Shared Data Banks” (1970) https://www.seas.upenn.edu/~zives/03f/cis550/codd.pdf