コッド 関係 モデル は、セット 概念と第一階述語論理を前提にして構成されています。そして、その モデル は、「relational completeness （完備性）」 を証明されています。

　コッド 関係 モデル では、データ 正規形を構成する技術として数学的な関係 （関数） が使われています。その一般形は、「直積集合」 を使った以下の式です。

　　　　R { s₁ ∈ X₁, s₂ ∈ X₂, ・・・, s_n ∈ X_n ∧ P (s₁, s₂, ・・・, s₁) }.

　すなわち、X₁, X₂, ・・・, X_n の それぞれの集合 （セット） の直積を構成して、それぞれの集合 （セット） から選ばれた メンバー の組のなかで、「真」 である組を 「存在」 （ソリューション） としています。ちなみに、それぞれの集合 （セット） から選ばれた メンバー を P (s₁, s₂, ・・・, s_n) において並べている点 （全順序になっている点） にも注意していてください。

　なお、直積集合は、「選択公理」 の観点からも説明できます。すなわち、（空でない） 集合──ここでは、X₁, X₂, ・・・, X_n のこと──から、それぞれ、ひとつずつ メンバー を選んできて並べたら──ここでは、P (s₁, s₂, ・・・, s_n) のこと──集合になる、ということ。それぞれの集合 （セット） から メンバー を選んできて並べて作った集合のことを タプル （tuple） と云います。単純に言えば、タプル とは、「組」 のことです。

　数学では、「関係」 を ふつう 2項で構成します──すなわち、R (a, b) [ 関数としては、f (x, y) ] というふうに。コッド 関係 モデル では、「関係」 を多項 （n-項） で構成している点が特徴です。ちなみに、n-項関係は、推移律を使えば、2項関係として構成することもできます。

　さて、コッド 関係 モデル は、直積集合を使った n-項関係で （現実的事態に対応する） 「個体」 を構成している点が特徴です。すなわち、それぞれの集合 （セット） として、アトリビュート の集合を構成して、それらの集合のなかから メンバー を選んで タプル を構成して、その タプル が現実的事態と対比して 「真」 である組を 「実存 （ソリューション）」 としている、という点が特徴です。たとえば、以下の構成を考えてみます。

　　{ 001 ∈ 番号、A ∈ 名称、56 ∈ 年齢 }.
　　{ 002 ∈ 番号、B ∈ 名称、25 ∈ 年齢 }.
　　{ 003 ∈ 番号、C ∈ 名称、46 ∈ 年齢 }.
　　　　　　　　　　　：
　　　　　　　　　　　：

　この構成では、それぞれの アトリビュート の メンバー は、縦列に列挙されている、という点が特徴です。すなわち、集合 （セット） は、縦列で示されているということ。そのために、この構成上、縦列に アクセス する やりかた を 「セット・アット・ア・タイム 法」 と云っています。いっぽうで、それらの アトリビュート で構成される 「個体」 は タプル （横列） として構成されています。言い換えれば、構文論上、メンバー は縦列に列挙され、意味論上、「個体」 は横列で構成されている、ということ。すなわち、事実的な 「F-真」 は、横列で構成されている、という点が特徴です。

　こういう構成に対して、複合選択条件 （OR とか AND を使った複合選択条件） を適用すれば、「同一 タプル 上の アトリビュート である」 ことを検証しなければならない──その点を、本編 （「実践編-13」） で説明しています。「同一 タプル 上の アトリビュート である」 ことを検証するためには、traversal table を用意しなければならない。

　そして、こういう構成では、メンバー を縦列に列挙しているので、単一選択条件を適用すれば、縦列の メンバー を順次数え上げなければならない──いわゆる 「table-scan」 ということ。もし、すべての メンバー を枚挙しないで並べるのであれば──言い換えれば、order-by を使うのであれば──、メンバー を並べるための作業域 （traversal table） を用意しなければならない。

　「セット・アット・ア・タイム 法」 では、traversal table は 「宿命の ファイル」 です。すなわち、単一選択条件において order-by を適用すれば traversal table を作るし──もし、order-by を使わないのであれば、すべての メンバー を数え上げるしかないし──、複合選択条件において、「同一 タプル 上の検証」 をするために traversal table を作るということ。したがって、traversal table を作れば、資源を費消して パフォーマンス が悪くなるのは当然の帰結でしょう。

　RDB で高 パフォーマンス を実現するのであれば、table-scan （枚挙） をしないで、かつ、traversal table を作らないようにするのが コツ です。その点を次回以降で説明します。 □