GoogleとAmazonを産んだデータベース革命 第3話：リレーショナルモデルという名の秩序
作者のかつをです。
第九章の第3話、お楽しみいただけましたでしょうか。
少し理論的な話になりましたが、この「リレーショナルモデル」の誕生がコンピュータの歴史における非常に大きな転換点でした。
すべてのデータを「表」と見なすという、シンプルで強力なアイデア。その美しさを感じていただければ幸いです。
※この物語は史実を基にしたフィクションです。登場する人物、団体、事件などの描写は、物語を構成するための創作であり、事実と異なる場合があります。
長い孤独な思索の末、テッド・コッドはついに一つの完璧な答えにたどり着いた。
彼が混沌としたデータの迷宮に持ち込もうとした秩序。
その名は、「リレーショナルモデル（関係モデル）」。
そのアイデアの核心は驚くほどシンプルだった。
「すべてのデータは、ただの『表』として表現すればいい」
樹木のような複雑な階層構造ではない。
蜘蛛の巣のような入り組んだ関係性でもない。
ただ、誰の目にも一目瞭然な、「テーブル（表）」というただ一つの形式。
例えば、「社員」というテーブルがある。
そこには「社員番号」「氏名」「所属部署」といった列がある。
そして一行一行に、それぞれの社員のデータ（レコード）が格納されていく。
「部署」という別のテーブルもある。
そこには「部署コード」「部署名」といった列がある。
そして、ここからが魔法の始まりだった。
これらのバラバラに見えるテーブルを、互いに「関連」づけることができる。
「社員」テーブルの「所属部署」という列と、「部署」テーブルの「部署コード」という列。
この共通のキーを手がかりに、二つのテーブルを自在に結合させることができるのだ。
このシンプルな仕組みさえあれば。
「経理部に所属するすべての社員の氏名を一覧表示せよ」
といった複雑な要求にも、瞬時に応えることができる。
もはやプログラマーは、データが物理的にどこにどのように格納されているかなど一切気にする必要はない。
ただ、数学的に厳密に定義された「関係代数」というシンプルな言語で、データベースに命令を下すだけ。
データの「何が（What）」欲しいかを宣言するだけでいい。
そのデータを「どうやって（How）」取ってくるかは、すべてデータベースシステム自身が考えてくれる。
アプリケーションとデータが完全に分離された、美しい世界。
それはコペルニクスが天動説を地動説にひっくり返したのと、同じくらい革命的な発想の転換だった。
データの周りをアプリケーションが振り回されるのではない。
データこそが宇宙の中心であり、アプリケーションはその周りを回る惑星にすぎない。
コッドは、この自らが構築した完璧な理論体系に惚れ惚れとしていた。
それは単なるコンピュータの技術ではなかった。
彼の目には、それは宇宙の真理にも似た一つの芸術作品のように映っていた。
問題は、この美しすぎる芸術をIBMの現実主義的なエンジニアたちにどうやって理解させるか、だった。
最後までお読みいただき、ありがとうございます！
この「What（何が）」と「How」を分離するという考え方は、SQLという現代のデータベース言語にそのまま受け継がれています。プログラマーは欲しいデータを宣言するだけで、複雑な内部処理を意識する必要がないのです。
さて、完璧な理論を手にしたコッド。
しかし、彼の戦いはここからが本番でした。
次回、「社内での孤立」。
彼の理論はIBM社内で激しい逆風に晒されます。
物語の続きが気になったら、ぜひブックマークをお願いします！
ーーーーーーーーーーーーーー
もし、この物語の「もっと深い話」に興味が湧いたら、ぜひnoteに遊びに来てください。IT、音楽、漫画、アニメ…全シリーズの創作秘話や、開発中の歴史散策アプリの話などを綴っています。
▼作者「かつを」の創作の舞台裏
https://note.com/katsuo_story
