「非正規形と事業解析 [（D） の扱い]」 （245ページ） には、非正規形として、導出項目としての （D） と、単なる複写項目としての （D） がある、と記述されている。そして、「論理 データベース 論考」では、ターボ・ファイル は、「対照表のなかに、 『resource』 の アトリビュート を複写した ファイル」 と記述されている。

　以上の観点から判断すれば、「event」 や 「VE」 に対して、「resource」 の アトリビュート を複写したら、ターボ・ファイル の （D） と同じではないか、というふうに考えるかもしれない。しかし、「event」 のなかに、アトリビュート が複写されても、（ターボ・ファイル ではなくて、） 「event」 のなかに、「冗長性」 が起こっているとしか考えない──つまり、（D） は、対照表と 「event」 では、「扱いかた」 が ちがう。

　対照表は、「event」 の原型である。対照表のなかに、「DATE （取引日）」 が帰属すれば──正確には、帰属できるなら──、「event」 として作用する。しかし、対照表には、「event」 が示さない性質もある。たとえば、以下を考えてみる （329ページ 参照）。

　従業員
　｛従業員番号、従業員名称、・・・｝.

　部門
　｛部門 コード、部門名称、・・・｝.

　従業員. 部門. 対照表
　｛従業員番号（R）、部門 コード（R）｝.

　
　さて、「従業員. 部門. 対照表」 は、「DATE （配属日）」 を仮想することができるので、「配属」 という 「event」 を示している──ただし、認知番号が付与されていないので、entity として認知されていない。

　したがって、この対照表は、「event」 として、「過程としての組織化 （organizing）」 を示しているが、いっぽうでは、「結果としての組織 （organized、organization）」 という 「構成」 も示している。この 「結果としての構成」 が、──もし、「DATE」 を、つよく適用しないなら──「validation-rule」 として作用する性質である。そして、この 「結果としての構成」 という性質は、「event」 には、ない。

　ほとんど すべての対照表は、「結果としての構成」 を示す性質を帯びている。というのは、2項関係が、構文論的に、そのまま、2項態として とどまれば、「結果としての構成」 であるし、2項関係が、意味論的に、新たな事態を示すなら──つまり、3項態になれば──、「過程としての事象」 になる。

　とすれば、対照表が、2項態のままで とどまっていれば、それぞれの 「resource」 の包摂関係を判断して、被包摂の 「resource」 に帰属する すべての アトリビュート を複写しても、正規形に近い状態になる。たとえば、

　従業員
　｛従業員番号、従業員名称、・・・｝.

　部門
　｛部門 コード、部門名称、・・・｝.

　従業員. 部門. 対照表
　｛従業員番号 （R）、従業員名称 （D）、・・・、部門コード （R）｝.

　
　以上の構造のなかから、「resource」 の従業員 entity を外してみてほしい。
　そうすれば、以下のように──もし、被包摂の entity に帰属する （R） （D） を外したら──、コッド 正規形になる （笑）。

　部門
　｛部門 コード、部門名称、・・・｝.

　従業員. 部門. 対照表
　｛従業員番号 （R）、従業員名称 （D）、・・・、部門 コード （R）｝.

　
　すなわち、対照表は、2項関係を、そのまま、「構成」 として とどめるか、あるいは、意味論的に、新たな 「過程」 を生成して、3項態として作用するか、という特徴があるので、対照表に対して、「resource」 の アトリビュート を複写することは、「event」 のなかに、（D） を置くことに比べて、「意味」 が ちがう。したがって、対照表に対して、（D） を置くことを、「ターボ・ファイル」 というふうに呼んで、ほかの （D） と切り離している。

　そして、ターボ・ファイル の考えかたを、さらに、「弱く適用すれば」、join して、なんらかの情報を作ることを 「構成」 というふうに拡大解釈すれば、スーパー・ターボ・ファイル になる。また、ウルトラ・スーパー・ターボ・ファイル は、「なんでもあり （as you like）」 なので、説明はいらないでしょう （笑）。