2007年 3月16日 特論-5 セット・アット・ア・タイム 法 >> 目次に もどる
2012年 2月16日 補遺  


 コッド 関係 モデル を搭載した RDB の アクセス 法は、セット・アット・ア・タイム 法 (テーブル 構造上、縦列のアクセス) になる。というのは、直積集合を前提にした n-項関係 R { s1 ∈ X1, s2 ∈ X2, ..., sn ∈ Xn } では、集合 (セット) は、縦列に メンバー を配置するから。

 セット・アット・ア・タイム 法 (関係 モデル) は、NDB の chained 構造を打破して、「logical view」 を実現した点が特徴であるが、いっぽうで、以下の 2点を、構造上、避けられない。

  (1) MAX-SIO の無制限 (セット の メンバー を、すべて、数える)
  (2) traversal table の生成 (複合検索条件では、同一 row 上の検証をしなければならない)

 つまり、セット の メンバー を、すべて、数えて--いわゆる 「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 を搭載しなかった。
  (2) SQL のなかに、(手続き言語系の) 「IF」 句を導入した。
  (3) テーブル 構造上、「indexing」 を導入した。

 次回は、セット・アット・ア・タイム 法を前提にしている テーブル 構造に対して、プロダクト としての RDB が、どのように 「indexing」 を搭載しているのかという点を述べる。



[ 補遺 ] (2012年 2月16日)

 SQL は、その後 (1998年?)、「配列」 も認めた。時計の針を逆に廻した。







  << もどる HOME すすむ >>
  「T字形ER データベース設計技法」を読む