|
2007年 3月16日 |
特論-5 セット・アット・ア・タイム 法 |
|
|
2012年 2月16日 補遺 |
|
|
|
コッド 関係 モデル を搭載した RDB の アクセス 法は、セット・アット・ア・タイム 法 （テーブル 構造上、縦列のアクセス） になる。というのは、直積集合を前提にした n-項関係 R { s1 ∈ X1, s2 ∈ X2, ..., sn ∈ Xn } では、集合 （セット） は、縦列に メンバー を配置するから。 セット・アット・ア・タイム 法 （関係 モデル） は、NDB の chained 構造を打破して、「logical view」 を実現した点が特徴であるが、いっぽうで、以下の 2点を、構造上、避けられない。 （1）
MAX-SIO
の無制限
（セット の メンバー を、すべて、数える） つまり、セット の メンバー を、すべて、数えて--いわゆる 「table-scan」--、複合選択条件 （「AND」 「OR」 を使った検索） では、関係 R を使って個体を横列に構成して、いっぽうで、縦列に アクセス するので、複合検索条件が 「同一の」 個体を指示しているのかどうか を調べなければならないので、資源を多大に費消する しくみ である。また、テーブル 構造上、primary-key として作用する縦列 （column） の メンバー が、なんらかの規則で並べられていても--たとえば、昇順とか降順とか--、ほかの縦列の メンバー は、並んでいない （整列されていない）。そのために、primary-key 以外の縦列に対して アクセス する際、table-scan のあとで、「view」 を構成する メンバー を並べたければ、「order-by」 句を使わざるを得ない。そして、「order-by」 を使えば、メンバー を並べる （sort） するために、「traversal table」 を作る。 これらの 2点 （「MAX-SIO の無制限」 と 「traversal table の生成」） は、「logical view」 という長所を実現しながらも、いっぽうで、RDB の弱点 （多大な資源費消と劣悪な パフォーマンス） とされてきた。すなわち、長所と短所が表裏一体になっている。 これらの 2点を解消するために、プロダクト としての RDB は、バージョンアップ のなかで、コッド 関係 モデル のほかに、テーブル 構造上、「indexing」 （レコード・アット・ア・タイム 法） を搭載してきた。「indexing」 の搭載は、あきらかに、コッド 関係 モデル との乖離である。言い換えれば、プロダクト としての RDB は、コッド 関係 モデル と一致していない--いちぶ、コッド 関係 モデル をふくんでいるが、ほかの技術 （technique と mechanism） を搭載してきた。プロダクト としての RDB が、コッド 関係 モデル と乖離した点は、以下の諸点である。 （1）
コッド 氏が提示した 4値
Logic
を搭載しなかった。 次回は、セット・アット・ア・タイム 法を前提にしている テーブル 構造に対して、プロダクト としての RDB が、どのように 「indexing」 を搭載しているのかという点を述べる。 |
|
[ 補遺 ] （2012年 2月16日） SQL は、その後 （1998年？）、「配列」 も認めた。時計の針を逆に廻した。 |
|
|
|||
|
|
|||