● 小生は、まず、プロダクト としての RDB を習い覚え、次に、コッド 関係 モデル を研修した。

　第 12章を執筆した理由は、第 11章までが--いな、この書物全体が--、「Ｔ字形ＥＲ手法」 を理論的に検討することを目的としていたので、逆に、Ｔ字形 ER手法は実践的な技術ではない、と邪推されることを恐れたからである。コッド 関係 モデル の強み・弱みを知り尽くして、かつ、（プロダクト としての） RDB の特徴を知り尽くして、Ｔ字形 ER手法を作ったことを感じてほしかったので、（極めて簡単な記述になっているけれど、） RDB の特徴をまとめておいた。

　小生の専門領域は、当初、DBA であった。小生が 30歳の頃--いまから、20数年ほど過去のことであり、当時、アシスト 社に勤めていたが--、RDB は、いまだ、日本では使われておらず、RDB を、日本のなかに導入・普及することが、小生の仕事であった。当時のいきさつを、本稿のなかで、詳細に述べるつもりはないので、「起業家 ビル・トッテン の IT ビジネス 奮闘記」 （コンピュータ・エージ 社）を読んでいただければ幸いである。

　小生は、まず、プロダクト としての RDB を習い覚え、次に、コッド 関係 モデル を研修した。つまり、RDB の技術を最初に覚えて、そのあとで、理論 （コッド 関係 モデル） を習得した。
　小生が アシスト 社で担当した RDB は、DATACOM/DB であった。小生は、いまでも、DATACOM/DB を高く評価している--小生が、RDB の技術を覚えた最初の プロダクト だから思い入れがつよいというのではなくて、DATACOM/DB は技術的に最高級の プロダクト だから （--ただし、当時、C/S 形態も ウェッブ もなかったので、それらに対する配慮はされていないが）。

　
● 「INDEX-only」 の原型は、DATACOM/DB が搭載していた 「LOCATE」 コマンド である。

　DATACOM/DB は、当時、すでに、「traversal-table」 を回避するために、手続き型言語の COBOL が、（inverted 型の インデックス を使って、） テーブル に対して、（レコード 単位ではなくて、） 「エレメント （element）」 単位に アクセス することを実現していた。しかも、LOCATE コマンド を搭載して、「INDEX-only」 を実現していた。RDB の理論--コッド 関係 モデル--の観点から判断すれば、DATACOM/DB が提示した アクセス 法 は 「邪道」 になる。だから、当時、DATACOM/DB は、世間では、リレーショナル・データベース と云われないで、「リレーショナル 型」 データベース と云われていた（笑）。

　さて、ここまで綴れば、小生の技術が、DATACOM/DB を起点にしていることを、すでに気づいた人たちもいるでしょう（笑）。すなわち、「traversal-table」 を回避するために、レコード・アット・ア・タイム を セット・アット・ア・タイム のように使う 「INDEX-only」 の着想は、DATACOM/DB の技術 （technique と mechanism） を起点にしています。
　小生が提示した 「INDEX-only」 と DATACOM/DB が搭載している 「INDEX-only」 （LOCATE コマンド） は違うけれど、DATACOM/DB のやりかたを起点にして、さらに一般化したやりかたが、小生の 「INDEX-only」 である。

　
● 「ビュー （view）」 と 「traversal-table の回避」 を同時に実現するのが 「INDEX-only」 である。

　セット・アット・ア・タイム のからくりを教えてくれたのが DATACOM/DB でした。「create view」 や 「order-by」 を使えば、「traversal-table」 が生成されるからくりを教えてくれたのが、DATACOM/DB でした--基幹系 システム 向きの RDB として、「traversal-table」 を回避するために、DATACOM/DB は、「create view」 も 「order-by」 も搭載しないで、（しかし、「view」 を扱えるように、） 「エレメント」 単位の レコード・アット・ア・タイム を搭載していた。しかも、「inverted 型の」 インデックス と、LOCATE コマンド を使った 「gereric search」 を併用すれば、インデックス を使って複数 テーブル を join して、データ を読まないで、データ の値を読み込むことができる。

　「論理 ビュー （logical view）」 と 「（「traversal-table」 を回避した） 高 パフォーマンス」 という二律背反を、同時に実現するために、小生が、当時から、狙っていたのが、「レコード・アット・ア・タイム を セット・アット・ア・タイム のように使う 『INDEX-only』」 だった。
　DATACOM/DB の DBA であったことを今でも誇りに思っているし、DATACOM/DB の DBA であったことが、小生の仕事の起点となっている。

　
● コッド 関係 モデル は、「独習」 した。

　DBA をやって、それから、DA になった。
　コッド 関係 モデル は、最初、データ 設計に関する入門書 （たとえば、Martin J. の書物とか） を読んで、データ 正規化のやりかたを覚えた。また、恩師 エリック （Eric G. Vesely） が、コッド 正規形を「簡単に」 作る ツール を設計して--当時、ADPAC 社が、PM/SS という CASE ツール のなかに、そのやりかたを搭載していたが--、コッド 正規形の作りかたを、実地に指導してもらい、さらに、構造化手法の Gane/Sarson 法も、OJT のなかで教わった。
　ちなみに、小生は、Warnier/Orr 法を、アーサー・アンダーセン 社に勤めていたとき、習得していた。

　コッド 正規形は、実地に使う単純な技術として、いくつかの簡単な正規化手順を覚えれば済むことだが、DATACOM/DB の DBA をやっていた小生には、物足らなかった--いま思えば、関係 モデル を、簡単な正規形構成としてまとめた コッド 氏の天才を驚嘆しているが。

　小生は凝り性の性質なので、正規化手順を覚えるのみでは物足らないので、いよいよ、コッド 関係 モデル の原文を読むことにした。しかし、数学基礎論の素養のない小生が、コッド 論文を読んでも、皆目、理解できなかった。「原理」 を知るためには、数学基礎論を習得していなければならないことを痛感した小生は、数学基礎論を独習した。

　しかし、数学基礎論を学習するために、指導してくれる人がいなかったので、学習途上、遠回りをしてしまった。数学を、とにかく、学習すればよい、と思い、岩波書店出版の数学基礎講座 シリーズ を購入して、数学全般の基礎知識を習得しなければならないと思い込んで、第一冊目から、順次、読み始めて、第一冊目の途中で挫折した。「集合と論理」 に的をしぼれば良い、と気づいたのは、いっぽうで、ウィトゲンシュタイン の書物 （「論理哲学論考」） を読んでいたことが幸いした。

　「集合と論理」 に的をしぼってからは、学習が捗った。集合論を学習していて、コッド 関係 モデル を理解するためには、ZF の公理系 （セット 概念） を理解すればよいことがわかった。すなわち、ZF の公理系のなかで、「集合」 概念として、直積集合と 「対 （unordered pair）の公理」 と 「空集合の公理」 を確認して、「論理」 として、第一階述語論理 （変項の領域が個体にかぎられている） の体系であることを理解すれば、コッド 関係 モデル を読むことができる。

　
● traversal-table は、セット・アット・ア・タイム 法の 「宿命」 である。

　上述した検討をふまえて、「セット・アット・ア・タイム法」 として、以下の点を、まとめた。

　（1） 理論的には、関係 モデル を理解するために、ZF の公理系を学習して直積集合を理解すればよい。

　（2） 技術的には、セット・アット・ア・タイム 法は、直積集合を前提にしている。

　（3） プロダクト として、セット・アット・ア・タイム 法を実現するには、以下の点に対応しなければならない。
　　　　[ traversal-table を生成しなければならない。]

　　　　- 複合選択 （AND/OR） に対応するために、「同一 row 上の検証」 をしなければならない。
　　　　- （セット のなかの メンバー を並べるために、） 「order-by」 に対応しなければならない。

　本 エッセー では、「舞台ウラ」 まで述べているので、このほかに説明の仔細はいらないでしょう。初版では、「直積集合」 （205 ページ） を説明するために、（コッド 関係 モデル が使った やりかた ではなくて、「直積集合」 そのもの-の考えかたを理解してもらいたかったので、） それぞれの セット として 「主体集合」 （従業員とか部門とか） を例にしましたが、以後の版では、（コッド 関係 モデル を考慮して、） セット を 「属性値集合」 に修正しました。
　ただし、「直積集合」 の説明のなかで、私は、「null」 を認めていない点に注意して下さい。メンバー の 「存在 （在ること）」 を前提にした セット に対して、私は、null を認めないし、できるかぎり、2値論理のなかで データ を演算したいと考えています。勿論、データ 演算 のなかで--たとえば、outer join のなかで--「null」 は起こりますが、私が論点にしているのは、あくまで、atomic な定義域 （属性値集合） を前提にして 「個体」 （論理的意味論として、指示規則のなかで 「真」 を検証する対象） を直積集合で構成するなら、個体の属性のなかで 「null」 を認めたくない、ということです。

　コッド 関係 モデル は、論理的意味論として、「null」 を認めています。「null」 は、意味論上、多義 （unknown と undefined） になるので、「値」 を演算するなら、4値論理を使わなければならない。コッド 関係 モデル は、4値論理を前提にしています。また、関係 モデル では、メンバー の 「並び」 が実現されていなければならないのですが、「整列集合を構成することができない」 ことを コッド 氏は認めています。私は、コッド 関係 モデル を実地に適用する際、これらの問題点 （「null」 と 「並び」） を除去することを考えました。すなわち、「null」 を認めないで、2値論理のなかで データ 構造を構成して、「関係」 では、対称性と非対称性を扱うことを考えました。それらを考慮して、コッド 関係 モデル を 「意味論的に拡張した」 モデル が TM （Ｔ字形 ER手法） です--ただし、関係の対称性・非対称性は、（コッド 関係モデル では、属性値を対象にしているのですが、） TM では、階を 1つ上にして、個体 （entity） のあいだで考慮している点に注意して下さい。

　そして、セット・アット・ア・タイム 法の 「弱点」 （「traversal-table の生成」） を回避するために、プロダクト としての RDB が、バージョンアップ のなかで （コッド 関係 モデル とは無関係な） indexing を搭載してきたので、indexing を view のように使う 「INDEX-only」 を考えた次第です。言い換えれば、レコード・アット・ア・タイム 法を セット・アット・ア・タイム 法のように使う やりかた を導入しました。この やりかた は、一見、tricky （邪道） のようにみえますが、関係 モデル の弱点 （traversal-table） を回避して、かつ、長所 （logical view） を活かすために、理論としての コッド 関係 モデル と プロダクト としての RDB を調整して、セット・アット・ア・タイム 法を実現した至極当然な やりかた です。レコード・アット・ア・タイム 法を セット・アット・ア・タイム 法のように使えば、traversal-table を生成しないし、order-by もいらない。