しかも、当初、コッド 論文を忠実に プロダクト 化すれば、旧来の データベース の物理的束縛から解放されて 「論理 view」 を実現できる長所があるいっぽうで、資源を多大に消費して、パフォーマンス が悪いという弊害が起こった。そこで、リレーショナル・データベース の製造元は、パフォーマンス を改善するために、primary-key を unique-key とみなすように index-key を搭載しました。そして、1990年代末には、SQL の国際基準が分岐や配列を認めました。ここに至って プロダクト の リレーショナル・データベース は コッド 論文とは大きく乖離しました。私は、コッド 論文から乖離した リレーショナル・データベース の プロダクト が悪いと言っているのではなくて──実際、index-key を逆手にとった 「INDEX-only」 を私は 1980年代から使っていたので──、レコード・アット・ア・タイム 法のほうが システム・エンジニア や プログラマ には扱いやすいのは確かでしょうし、コッド 氏が力説していた 4値論理は実務的に使いにくい。

　コッド 論文から乖離した リレーショナル・データベース の プロダクト に慣れ親しんでいると、うっかりすれば データ・モデル には キー （index-key） が必須であるというような勘違いをしてしまう。実際、TM に対しての非難のなかで、「TM には キー （index-key） がないので、実務では使えない」 という非難があったそうです （苦笑）──ただし、その非難は、私が直接に聞いたのではなくて、又聞きなので、正確な引用ではないことを断っておきます。TM で使っている個体指定子は、コッド 正規形の primary-key と ほぼ同じですが、原帳票などに実際に使われている ××番号/○○コード のことを指しています （したがって、index-key ではない）。それがゆえに、本節では、あえて太字で次の文を綴ったしだいです──

　　　　事業分析のモデルをつくるためには、「キー（index-key）」 という考えをまず捨ててください。