エドガー・F・コッドのリレーショナルモデル：なぜSQLがビジネスを制したか

大きな着想：関係としてのテーブルとしてデータを扱う

単純に言えば、リレーショナルモデルは情報をテーブル（コッドが「リレーション」と呼んだもの）の集合として保存し、共有された値を通じてそれらを結び付けます。

テーブルは整然とした格子です：

• 行は個々の事物を表します（1人の顧客、1件の請求、1件の支払い）。
• 列はそれらの事物の属性を表します（顧客名、請求日、金額）。

これがビジネスデータにとって重要だった理由

ビジネスのデータは孤立して保持されることはありません。販売には顧客、商品、価格、営業担当、日付が関わり、それぞれ変化の速さや所有チームが異なります。初期のシステムはこれらを密に結合した、変更が難しい構造で保存することが多く、報告が遅くなり、変更がリスクになり、「簡単な質問」でも驚くほどコストがかかりました。

リレーショナルモデルはより明確なアプローチをもたらしました：概念ごとに別々のテーブルを持ち、必要なときにそれらをつなぐ。顧客情報をすべての請求に重複して記録する代わりに、顧客を一度だけ保存して請求から参照する。これにより矛盾（同一顧客の綴りが2通り存在するなど）が減り、更新が予測しやすくなります。

期待値の設定：信頼できる一貫性

明確に定義されたテーブルとそれらを接続するルールを重視することで、モデルは新しい期待を設定しました：多くの人やシステムが書き込みを行うときでも、データベースは成長しても矛盾を防ぐべきだ、という期待です。

プレビュー：SQLがどう続いたか

コッドのモデル自体はクエリ言語ではありませんでしたが、それはインスピレーションを与えました。データが関係したテーブルにあるなら、次の標準的な方法が必要です：

• 欲しい行を選ぶ（select）、
• 必要ならテーブルを結合する（combine）、
• レポート用に結果を要約する（summarize）。

その道筋がSQLへとつながり、モデルを日常のチームがビジネスデータに問いを投げて再現可能で監査可能な答えを得る実用的な方法に変えました。

コッド以前：初期のデータシステムが苦戦した理由

リレーショナルモデル以前、多くの組織は重要な情報をファイルに保存していました—しばしばアプリケーションごとにひとつのファイル。給与は自分の記録、在庫は別、カスタマーサービスはまた別の「顧客」バージョンを持っていました。各システムが孤立して動き、その孤立が予測可能な問題を生み出しました。

ファイルベースのシステム：始めるのは速いが成長は難しい

初期のデータ処理は通常、単一目的のカスタムファイル形式とプログラムで作られていました。データの構造（各フィールドがどこにあるか、レコードがどう並ぶか）はそれを読むコードに強く結びついていました。つまり小さな変更—新しいフィールドの追加、商品カテゴリの名称変更、住所フォーマットの変更—でも複数のプログラムを書き直す必要がありました。

重複はエラーと余分な作業を生む

チームが単一の真実のソースを簡単に共有できないため、データを複製していました。顧客の住所は販売ファイル、配送ファイル、請求ファイルに存在するかもしれません。

住所が変わると、すべてのコピーを更新しなければなりません。どれかのシステムの更新を忘れると不一致が生じ、請求が間違った場所に送られたり、出荷が遅れたり、サポート担当が見る画面によって「事実」が異なることになりました。データのクリーンアップは一度きりの修正ではなく定期的なプロジェクトになりました。

レポートやアドホックな質問は手間がかかった

ビジネスユーザーは「製品Xを買って後に返品した顧客は誰か？」のような質問をしますが、それに答えるには本来一緒に動くよう設計されていないファイルをつなぎ合わせる必要がありました。チームはしばしばワンオフのレポート抽出を作り、それがさらにコピーと不一致の機会を生みました。

結果として：レポートサイクルは遅く、「ちょっとした質問」もエンジニアリング作業になりました。

企業が必要としていたもの

組織は複数のアプリケーションが頼れる共有データを求めており、矛盾と重複を減らしたかった。また、基盤となる保存を毎回作り直さずに新しい問いができる仕組みも必要でした。そのギャップがコッドの鍵となるアイデアの舞台を整えました：データを一貫した、アプリケーションから独立した方法で定義し、システムが壊れることなく進化できるようにすることです。

エドガー・F・コッドとは？

エドガー・F・コッドは英国出身の計算機科学者で、大部分のキャリアをIBMで過ごし、組織が情報を効率よく保存・検索する方法に取り組みました。1960年代、ほとんどの「データベース」システムは綿密に管理された書棚に近く、データは堅固で事前定義された構造で保存され、構造を変えるにはアプリケーションを書き換える必要がありました。そのもろさは、ビジネスの成長や要求の変化に対してチームを苛立たせていました。

1970年の論文が会話を変えた

1970年、コッドは長いタイトルの論文（“A Relational Model of Data for Large Shared Data Banks”）を発表し、驚くほど単純なアイデアを提案しました：データを関係するテーブルとして表現し、それらを問い合わせ・結合するための形式化された操作集合を使うというものです。

高いレベルでは、論文はこう主張しました：

• データは物理的な保存方法とは独立に記述されるべきである。
• クエリは何を欲しいかに焦点を当てるべきで、どうナビゲートするかではない。
• データ間の関係は共有値（キー）を通じて表現されるべきで、ハードコードされたポインタではない。

数学的基盤が重要だった理由

コッドはセット理論と論理に基づいて提案を裏付けました。それは学問的な見せ場ではなく、データベース設計に明確で検証可能な土台を与えました。形式的なモデルがあれば、クエリが正しいか、二つのクエリが等価か、結果を変えずにどう最適化するかを推論できます。ビジネスソフトウェアでは、これはスケールや進化の際の驚きを減らすことに直結します。

既存のデータベース思想への挑戦

当時、多くのシステムは階層モデルやネットワークモデルに依存しており、開発者は定義済みの経路に沿ってデータを「ナビゲート」していました。コッドのアプローチはデータベースが重い仕事をすべきだと主張し、この考え方に挑戦しました。アプリケーションは保存レイアウトを知る必要はなく、欲しい結果を記述すべきで、データベースはそれを効率よく生成する方法を見つけるべきだという分離が、SQLと長く生き残るデータベースを可能にしました。

コアの構成要素：リレーション、行、列

コッドのリレーショナルモデルは単純な着想から始まります：事実をリレーション（多くの人がテーブルと認識するもの）に格納するが、それを「賢いスプレッドシート」ではなくデータを記述する厳密な方法として扱うこと。リレーションはあなたのビジネスが関心を持つ事柄についての述語の集合です：顧客、注文、支払い、商品、出荷など。

リレーション（テーブル）

リレーションは一種の事実パターンを表します。例えば、Orders リレーションは「注文にはID、日付、顧客、合計がある」という事実を捉えるかもしれません。重要なのは各リレーションが明確に定義された意味を持ち、各列がその意味の一部であることです。

行（タプル）

行（コッドはタプルと呼んだ）はその事実の一つの具体例：ある特定の注文です。リレーショナルモデルでは行に固有の「位置」はありません。5行目が特別ではなく、重要なのは値とそれらを定義するルールです。

列（属性）

列（属性）はリレーション内の一つの特定の性質です：OrderDate、CustomerID、TotalAmount。列は単なるラベルではなく、どのような種類の値が許されるかを定義します。

ドメイン：値の一貫性を保つ

ドメインは属性に許される値の集合です—OrderDateには日付、TotalAmountには正の数、Statusには制御されたコード一覧（例：Pending, Paid, Refunded）など。ドメインは曖昧さを減らし、日付表記の混在や数値フィールドに "N/A" を入れるような微妙なエラーを防ぎます。

“リレーショナル”はスプレッドシートではなく“接続”を指す

“リレーショナル”は顧客と注文のようにリレーション間で事実が繋がることを指し、請求、報告、監査、カスタマーサポートといった一般的な業務を、情報の重複なしに可能にします。

キーと関係：データを正しく保つ接着剤

テーブルは単独でも役に立ちますが、ビジネスデータが意味を持つには事実を信頼して結び付ける必要があります：どの顧客がどの注文を出したか、どの商品が注文に含まれていたか、いくら請求されたか。キーはそれらの接続を信頼できるものにする仕組みです。

主キー：安定した識別子

主キーは行を一意に識別する列（または列の組）です。行の「名札」のように考えてください。重要なのは安定性です：名前やメール、住所は変わるが内部IDは変わるべきではありません。

良い主キーは重複や曖昧さを防ぎます。もし二人の顧客が同じ名前でも、主キーがあれば区別できます。

外部キー：テーブル間のリンク

外部キーは別のテーブルの主キーを格納する列です。これによりすべてのデータをコピーすることなく関係を表現できます。

例えば、販売を次のようにモデル化できます：

• customers (customer_id PK, name, email)
• orders (order_id PK, customer_id FK → customers.customer_id, order_date)
• order_items (order_item_id PK, order_id FK → orders.order_id, product, quantity, price)

制約：“孤児”や矛盾したデータの防止

外部キー制約はガードレールのように働き、次を防ぎます：

• 孤児レコード：存在しない customer_id を参照する注文。
• 矛盾する更新：注文が参照している顧客を削除してしまう（明示的にカスケードを選ばない限り）。

実務的には、キーと制約によりチームはレポートとワークフローを信頼できます。データベースが関係を強制することで、請求、出荷、サポートのバグが入り込みにくくなります—データが不可能な状態に静かに流れることを防げるからです。

正規化：クリーンなデータ、少ない驚き

正規化はリレーショナルモデルがデータの矛盾を防ぐやり方です。同じ事実を複数箇所に保存すると、あるコピーを更新して別のコピーを忘れるのは簡単で、そこから請求書が間違った住所に送られる、レポートが一致しない、画面ごとに顧客の状態が異なる、といった問題が生じます。

正規化が防ごうとするもの

実務的には正規化は次のような問題を減らします：

• 重複：同じ事実（顧客住所など）を多くの行で繰り返すこと。
• 更新異常：変更が複数回必要になり、部分的な更新が起きること。

また 挿入異常（注文がないと新しい顧客を追加できない）や 削除異常（最後の注文を削除したら顧客情報も消えてしまう）を避けます。

1NF、2NF、3NF—直感的な理解

理論を深く知る必要はありませんが、考え方は簡単です：

第一正規形（1NF）：各フィールドは原子的に保つ。顧客に複数の電話番号があるなら、一つのセルに詰め込まず別テーブルや別行にする。

第二正規形（2NF）：テーブルの識別が複数列に依存する（複合キー）場合、非キー属性はその全部に依存するようにする。注文行はその行の数量や価格を持つべきで、顧客住所を入れるべきではない。

第三正規形（3NF）：別の場所に属する副次的事実を取り除く。テーブルが CustomerId と CustomerCity の両方を持っているなら、都市は通常顧客テーブルに置くべきで、すべての注文にコピーすべきではない。

トレードオフと「十分に良い」設計

正規化を進めると通常テーブル数と結合が増えます。これにより一貫性は高まるが、レポートが複雑になったり場合によってはパフォーマンスに影響することもあります。多くのチームはコアエンティティに対して3NFを目標にし、読み取り中心のダッシュボードなどでは計測に基づいて選択的に非正規化します。

関係代数：クエリの背後にある論理

関係代数はリレーショナルモデルの“数学”です：あるテーブル（行の集合）を別のテーブルへと変換するための少数の正確な操作の集合。

この正確さが重要です。ルールが明確なら、クエリ結果も明確です。フィルタ、整形、結合を行ったときに何が起きるかを、非文書化の振る舞いや手作業のナビゲーションに頼らずに予測できます。

コア操作（平易な言葉で）

関係代数は合成可能な構成要素を定義します。重要なもの三つ：

• Select（選択）：欲しい行を選ぶ。

  例："先月の注文だけ"、"フランスの顧客だけ"。同じ列を保ちながら行数を減らす。

• Project（射影）：欲しい列を選ぶ。

  例："顧客名とメールを表示"。論理的に同じ行を保ちながら不要な列を落とす。

• Join（結合）：別のテーブルから関連する事実を組み合わせる。

  例："注文に顧客の詳細を付ける"（customer_id のような共有識別子を使う）。出力は別々に保存されていたフィールドを一つにまとめた新しいテーブルになる。

業務データで結合が中心になる理由

業務データは自然に顧客、注文、請求、商品、支払いなどの主題に分かれています。その分離は各事実を一度だけ保存するのに役立ちますが、答えを出すには再結合が必要になることが多いです。

結合は意味を保ちながらその再結合を行う正式な方法です。顧客名をすべての注文行にコピーしておいて後でつづりを直す手間をかける代わりに、顧客を一度だけ保存して必要に応じて結合します。

予測可能な結果、驚きのない動作

関係代数は行の集合に対する操作として定義されるため、各ステップの期待される結果は明確です：

• フィルタはどの行が含まれるかに影響する。
• 射影はどの列が見えるかに影響する。
• 結合はテーブル間で事実がどう組み合わされるかに影響する。

これが後にSQLを実用的にした概念的バックボーンです：クエリは即ち一連の定義済み変換であり、場当たり的なデータ取得ではないのです。

理論からSQLへ：リレーショナルモデルを実用化するまで

コッドのリレーショナルモデルはデータの意味（リレーション、キー、操作）を記述しましたが、日常的に人々が使える親切な方法を規定してはいませんでした。SQLはそのギャップを埋めました：リレーショナルの考えを可読な言語に変え、アナリスト、開発者、データベース製品が共有できるようにしました。

SQLと“純粋な”リレーショナルモデルの違い

SQLは関係代数に触発されていますが、コッドの理論を完全に実装したわけではありません。

重要な違いの一つは欠損値（NULL）の扱いです。古典的な関係理論は二値論理（真／偽）に基づくのに対し、SQLはNULLを導入して三値論理（真／偽／不明）をもたらしました。もう一つの違いは関係理論が集合（重複なし）を扱うのに対し、SQLは明示的に防がない限り重複行を許す点です。

それでも、SQLは中核的な約束を保ちました：欲しい結果を記述すると（宣言的クエリ）、データベースがそれを実現する手順を見つけます。

簡単な年表：論文から製品へ

コッドは1970年に基礎的論文を発表しました。1970年代、IBMは初期プロトタイプ（特に System R）を開発し、リレーショナルデータベースが実際のワークロードで十分に高速に動作し、高水準なクエリ言語が効率的な実行計画にコンパイルできることを実証しました。

並行して、学術界と商用の努力がSQLを前進させました。1980年代後半にはANSI/ISOによるSQLの標準化が進み、各ベンダーが独自拡張を持ちながらも共通言語に収束しました。

可読なクエリ言語が重要だった理由

SQLは問いを投げるコストを下げました。すべてのレポートにカスタムプログラムを書く代わりに、チームは直接質問を表現できるようになりました：

• GROUP BY を使った地域別・月別の売上
• 注文、サブスクリプション、解約を結合した顧客の解約コホート分析
• フィルタと集計で数秒で答える運用ダッシュボード

実務でSQLが簡単にしたこと

業務ソフトウェアにとって、SQLの結合と集計の組み合わせは画期的でした。財務チームは請求と支払いを照合でき、プロダクトチームはコンバージョンファネルを分析でき、オペレーションは在庫と履行を監視できました—すべて同じ共有された構造化データモデルへのクエリで行えます。

この使いやすさが、リレーショナルモデルを研究の枠組みから日常ツールへと押し上げた大きな理由です。

信頼をスケールさせる：整合性、トランザクション、ACID

ビジネスシステムの成否は信頼にかかっています。データを「保存する」だけでは不十分で、正しい残高、正確な在庫数、信頼できる監査トレイルを、多数のユーザーが同時に使っても維持しなければなりません。

トランザクション：一つの業務操作を一つの単位として扱う

トランザクションは一連の変更を一つの業務操作としてまとめます。例："$100を移動する"、"注文を出荷する"、"給与処理を確定する"。これらは複数のテーブルや複数の行に影響します。

重要なのは全か無かの振る舞いです：

• すべてのステップが成功すればトランザクションはコミットされる。
• どれかが失敗すれば（ネットワーク障害、検証エラー、クラッシュ）、ロールバックされ、データベースは何も起きていない状態に戻る。

これにより、ある口座からお金が引かれたが相手口座に入らない、在庫が減ったが注文が記録されない、などの状況を避けられます。

平易な言葉でのACID

ACIDは企業が頼る保証の短縮形です：

• Atomicity（原子性）：前述の全か無か。
• Consistency（整合性）：データベースはルール（例：数量は負にならない）を破る変更を許さない。
• Isolation（独立性）：同時作業が偶発的な干渉を生まない。
• Durability（永続性）：一度確定した結果はクラッシュ後も消えない。

制約とトランザクション：システムが正直でいる仕組み

主キー、外部キー、チェックなどの制約は無効な状態が記録されるのを防ぎます。トランザクションはテーブル間の関連更新が一緒に到着することを保証します。

実務では：注文が保存され、その注文行が保存され、在庫が減り、監査ログに記録される—これらがすべて一緒に行われるか、まったく起きないかのどちらかです。この組み合わせこそがSQLデータベースが本番の業務ソフトウェアを支える理由です。

なぜSQLデータベースがビジネスソフトの中核になったのか

SQLデータベースが「勝った」のは流行だからではなく、多くの組織の考え方や仕事の進め方に合致したからです。会社は顧客、請求書、商品、支払い、従業員といった繰り返し現れる構造化されたもので満ちており、それぞれ属性のセットを持ち、予測可能に関連します。リレーショナルモデルはこの現実に自然にマッピングします：顧客は複数の注文を持ち、注文は行アイテムを持ち、支払いは請求に整合します。

日常的な業務ワークフローに自然に合う

ビジネスプロセスは一貫性と追跡可能性を前提に作られています。財務が「どの請求が未払いか？」と問うとき、あるいはサポートが「この顧客はどのプランか？」と問うとき、どのツールやチームが問おうとも答えは同じであるべきです。リレーショナルデータベースは事実を一度だけ保存して参照する設計で、矛盾を減らし再作業のコストを下げます。

標準ツール群がSQLをデフォルトにした

SQLが普及するにつれて、エコシステムが形成されました：レポーティングツール、BIダッシュボード、ETLパイプライン、コネクタ、トレーニングなど。これにより導入コストが下がりました。データがリレーショナルデータベースにあれば、一般的なレポートや分析ワークフローにカスタムの接着コードなしで接続しやすいことが多いです。

アプリは変わるがデータ契約は変わるべきでない

アプリケーションは素早く進化します—新機能、新しいUI、新しい統合。よく設計されたスキーマは耐久的な契約のように振る舞います：サービスや画面が変わっても、コアのテーブルと関係がデータの意味を安定して保ちます。この安定性がSQLデータベースが信頼できる中心になる大きな理由です。

スキーマは所有権と責任を明確にする

スキーマはデータを整理するだけでなく役割を明確にします。チームは「顧客とは何か」「どのフィールドが必須か」「レコードはどう繋がるか」を合意できます。主キーと外部キーにより、誰がレコードを作成し誰が更新できるか、ビジネス全体で何を一貫させるべきかが明示化されます。

限界、批判、代替の台頭

リレーショナルデータベースは予測可能で安全であることで地位を築きましたが、すべてのワークロードに最適というわけではありません。SQLシステムへの多くの批判は一つのツールをすべての仕事に使うことへの批判に近いです。

厳格なスキーマが迅速な変化を遅らせる場面

リレーショナルスキーマは契約です：テーブル、列、型、制約が「有効なデータ」を定義します。共有理解には良いですが、プロダクトがまだ進化中のときはチームの足を引っ張ることがあります。

毎週新しいフィールドを出すような場合、マイグレーション、バックフィル、デプロイの調整がボトルネックになり得ます。良いツールがあっても、スキーマ変更は計画が必要です—特にテーブルが大きいかシステムを常時稼働させる必要があるとき。

NoSQLが出てきた理由（ターゲットとした課題）

“NoSQL”はリレーショナル思想への全面的な反発ではなく、特定の問題への応答でした：

• スケールアウトの必要：水平分割や分散が簡単な仕組みを求めた。
• 柔軟なデータ形状：ドキュメントやキー・バリューストアは進化するネストデータをテーブル再設計なしに保存しやすい。
• 特殊な性能要件：ワイドカラム、検索エンジン、グラフDBは特定アクセスパターンに最適化される。

多くのこれらのシステムは豊富な結合や強い一貫性を犠牲にして、速度、柔軟性、分散性を得ました。

混合現実：リレーショナル＋非リレーショナル

現代の多くのスタックはポリグロットです：コアの業務記録にはリレーショナルデータベースを使い、イベントストリーム、検索インデックス、キャッシュ、ドキュメントストアを解析や読み取り重視の用途に併用します。リレーショナルモデルが真実のソースとして残り、他が読み取りや特殊なクエリを担います。

チームが考えるべき判断基準

選択時には以下に注目してください：

• 整合性要件：絶対に間違ってはいけないトランザクションがあるか？
• クエリの複雑さ：結合、レポート、アドホックな問合せに頼るか？
• スケールパターン：書き込み集中、グローバル分散、突発的な負荷か？

一般的なデフォルトはコアデータにSQLを使い、リレーショナルモデルが明確に限界を作る場合にのみ他を追加することです。

今日に活かすべきこと：業務アプリを作るチームへの教訓

コッドのリレーショナルモデルは歴史だけでなく、ビジネスデータを信頼しやすく、変更しやすく、報告しやすくする習慣のセットです。アプリが複数のストレージを混在させていても、リレーショナル的な考え方は注文、請求、顧客、在庫といった「記録のシステム」には強いデフォルトです。

実務的なテーブル設計のポイント

まずビジネスが関心を持つ現実世界の名詞（Customers, Orders, Payments）をテーブルとしてモデリングし、それらを関係でつなぎます。

後での痛みを防ぐためのルール：

• 各テーブルに安定した主キーを与える（多くは代理ID）。名前やメールのような可変フィールドに依存しない。
• 関係には外部キーを使う。データベースが壊れた参照を止められるようにする。
• 繰り返される・複数値フィールドは別テーブルに分ける（例：CustomerPhones）。
• 事実とラベルを分ける：数値の金額と通貨コードは別にして、フォーマット済み文字列を保存しない。

これらの原則を実製品に落とし込むには、スキーマの意図とアプリケーションコードを一致させるツールがあると便利です。例えば、Koder.ai はチャットプロンプトから React + Go + PostgreSQL アプリを生成でき、正規化されたスキーマ（テーブル、キー、関係）を素早く試作しつつ、準備ができたらソースコードをエクスポートできます。

データベースアプローチを選ぶときに問うべき質問

データが強い正確さの保証を必要とするなら：

• 複数の更新にまたがるトランザクションが必要か（例：注文作成 + 在庫確保 + 支払い試行）？
• 監査や財務のためにアドホックな問合せに頼るか？
• エンティティ間でデータを結合する必要があるか（顧客 ↔ 注文 ↔ 出荷）？

多くの場合これらに「はい」が多ければ、リレーショナルデータベースが最もシンプルな道です。

捨てるべき誤解

「SQLはスケールしない」は言い過ぎです。SQLシステムはインデックス、キャッシュ、リードレプリカ、必要ならシャーディングなど多様な方法でスケールします。ほとんどのチームは真のDB限界に到達する前にモデリングやクエリの問題に遭遇します。

「正規化はすべてを遅くする」も不完全です。正規化は異常を減らし、パフォーマンスはインデックス設計、クエリ設計、計測に基づく選択的非正規化で管理します。

コッドの持続的影響

コッドはチームに共通の契約を与えました：データを関連テーブルに配置し、定義済みの操作で操作し、制約で保護するという契約です。この契約があるからこそ日常のソフトウェアは何年にもわたって進化しても「いつ、何が、なぜ起きたか？」といった基本的な質問に答え続けられるのです。