{ データ 構造、データ 演算、制約 }.

　この観点からすれば、TM は、モデル ではないでしょうね。というのは、TM は、データ を構成する規則を示しましたが、データ を演算する文法体系を示していないから。データ 演算は、コッド 関係 モデル の 「集合論演算および リレーショナル 代数演算」 を借用しているので。

　さて、モデル を { データ 構造、データ 演算、制約 } とすれば、コッド 関係 モデル は、「完全性 （relational completeness）」 を証明されています──ここでいう 「完全性」 とは、数学上の 「完全性」 であって [ すなわち、「完全性定理」 を満たしている、ということであって ]、日常の ことば でいう 「完全性」 という意味ではない点を注意してください。

　データ を構成する規則に限って言えば、TM は、コッド 関係 モデル に対して、意味論を 「強く」 適用した モデル です。でも、TM は、「不完全」 です──ここでいう 「不完全」 とは、数学上の 「不完全性」 であって、日常の ことば でいう 「不完全性」 ではない点に注意してください。言い換えれば、TM のなかで、「構成表 （対照表）」 が 「真」 であるにもかかわらず──無矛盾な文法に従って構成されたにもかかわらず──、「構成表 （対照表）」 が 「event」 とも 「resource」 とも判断できない、ということです。それ （「構成された」 個体が 「event」 とも 「resource」 とも判断できないこと） を避けるために、TM では、指示規則と生成規則のほかに、以下の 「『解釈』 の制約規則」 を付してします。

　　　　対照表が、その性質として、実 データ の 「日付」 をもつか、あるいは、
　　　　「日付」 を仮想したいとき、そのときに限り、対照表を 「event」 として
　　　　解釈する。

　TM を前提にして、集合論演算および リレーショナル 代数演算を使うことができます。

　さて、コッド 関係 モデル あるいは TM で構成された データ 構造に対して、「構造的 プログラミング」 を適用したら、当然ながら、コッド 関係 モデル も TM も 「使いにくい」。というのは、それらの モデル は、「構造的 プログラミング」 向けに作られた訳ではないから。ここで争点になるのが、プロダクト としての RDB が、SQL 上、「indexing」 「if」 および 「配列」 を導入してきたという点です。それらの拡張機能を使えば、「構造的 プログラミング」 の SQL を作ることができます。そして、そういう SQL に慣れ親しんだ プログラマ にしてみれば、コッド 関係 モデル や TM は 「使いにくい」 はずですし、実際、そういう プログラム に慣れ親しんだ人たちが、コッド 関係 モデル や TM を 「駄目 （使い物にならない）」 と非難していることを私は聞き及んでいます。

　しかし、SQL に対して、「indexing」 「if」 および 「配列」 などを──本来、セット・アット・ア・タイム 法とは無関係な （相容れない） 機能を──拡張機能として導入したことが、（コッド 関係 モデル を前提にして作られた） RDB を使うために 「現実解」 であったかどうかこそが争点にされるべきではないでしょうか。というのは、それらの機能を使わないほうが、単純な [ コントロール・フロー が単純な・見通しの良い、生産性・保守性の高い ] プログラム を作ることができるのだから。

　事実を もっと正確に言えば、かれらは、正しい 「構造的 プログラミング」 さえ守っていない。そして、そういう やりかた が、システム を錯綜した構成にしてしまい──しかも、コントロール・フロー を追跡しにくいために、ソース・コード を修正しても、修正の波及が計測できない状態になっていて──、システム が環境変化に対応できない状態になってしまっているという事実に対して、かれらは、プログラマ として──もし、かれらに、プロフェッショナル という意識があるなら──、どう感じているのかしら。「我流」 を押し通している かれらが 「モデル など使えない」 と言っているのであれば、私には、かれらが 「わがまま」 を言っているふうにしか見えない。

　
　（2008年 7月 8日）