今回は、セット・アット・ア・タイム 法の実装形 （プロダクト としての RDB） の 「からくり」 を解析にする。

　
　RDB （Relational Data Base） は以下の 2点を特徴としている。

　（1） データ 構造は 「テーブル」 構造である。
　（2） データ に対する アクセス は （view を使った） 「column 単位」 の アクセス である。

　テーブル 構造 （縦列と横列から構成される 2次元の flat-file） において、横列のことを 「row」 といい、縦列のことを 「column」 という。

[ 注意 ]
　セット・アット・ア・タイム 法を基本の アクセス・メソッド としている RDB では、「キー （indexing）」 は internals （内的構造） と無関係である。
　つまり、（RDB は、バージョンアップ のなかで 「CREATE INDEX」 を附加してきたが） 「CREATE INDEX」 は テーブル 構造に対して 「上積み」 された アクセス・メソッド なのであって、セット・アット・ア・タイム 法とは関係のない論点である。
　この点については──indexing については──、後日、記述する。

　以下の テーブル を前提とする。

　
　以下の SQL を実行する。

　SELECT count (...) FROM "服"
　WHERE　サイズ ＝ "M"　OR　色 ＝ "黒".

　
1. トラヴァーサル・テーブル

　セット・アット・ア・タイム は、セット を単位として、「カラム （column、縦列） 単位」 に アクセス するので、上述の SQL を実行すれば、以下のような アクセス 経路を辿る。

　（1） サイズ の カラム を走査 （scan） して、値が 「M」 である ROWID （002 と 003の 2つ） を得る。
　（2） さらに、色の カラム を走査して、値が 「黒」 である ROWID （003） を得る。

　複数の選択条件を──ここでは選言 （OR） であるが──、それぞれ単独に、カラム を走査すれば、検索結果として 3件の データ を得ることになるが、以下の 2つは同じ データ である。

　（1） サイズ の カラム を走査して得た ROWID ＝ 003
　（2） 色の カラム を走査して得た ROWID ＝ 003

　セット・アット・ア・タイム 法は カラム 単位の アクセス を原則にしているので、複数の選択条件 （AND/OR） が記述されたなら、同一 ROW であるかどうかの検証をしなければならない。
　同一 ROW の検証をするために、RDB は、一時的な作業域 （work-file） を用意する （生成する）。この作業域のことを 「トラヴァーサル・テーブル （traversal-table）」 という。

　RDB は、（複合選択条件に対して） カラム を走査しながら検索結果を トラヴァーサル・テーブル に書き込んで、すべての検索が終わってから、トラヴァーサル・テーブル のなかに書き込まれた データ に対して同一 ROW の検証をする。
　したがって、（トラヴァーサル・テーブル を生成して、同一 ROW の検証をすれば、） 資源が費消され、パフォーマンス は低下する。

　言い換えれば、多量 データ を対象にして、「CREATE VIEW」 を使って複合検索を実行すれば パフォーマンス が悪いので、なんらかの対応をしなければならないということである （──対応策については、後日、記述する）。

　
[ 注意 ]
　対象の データ が少量なら、「CREATE VIEW」 を使って、メモリー のなかで走査しても問題はない。
　ここで論点にしているのは、いわゆる 「基幹系」 と呼ばれている システム のなかで扱われている多量 データ （数百万件、数千万件） と多量 トランザクション である。
　数百万件の データ を join して──あるいは、複数の 「曖昧検索」 を使って──、「瞬きの」 レスポンス を実現することを目的にしている。

　SQL を 「最適に」 実行するために、RDB には、SQL を解析して 「最適な」 実行経路を判断する機能が搭載されている。その機能のことを 「オプティマイザ （optimizer）」 という。
　オプティマイザ は、以下のいずれかを基準にして、SQL の 「最短の アクセス 経路」 を判断する。

　（1） （最小の） I/O 回数
　（2） （最小の） CPU 量

　I/O 回数を判断基準にするやりかたを 「ルール・ベース」 といい、CPU 量を判断基準にするやりかたを 「コスト・ベース」 という。市販されている RDB は 「コスト・ベース」 を標準値 （default） にしている。

　SQL を実行したなら、かならず、実行 プラン を調べてほしい。
　なぜなら、（多量 データ と多量 トランザクション を前提とするなら） 実行 プラン のなかで以下の メッセージ が記述されていたらまずい （！）

　　悪い例：　TABLE SCAN　×××（数値）

　つまり、（多量 データ と多量 トランザクション を前提とするなら） 「TABLE SCAN」 は、資源を費消して、パフォーマンス が悪い、ということである。対応策については、後日、記述する。

TABLE SCAN　×××

　
[ 注意 ]
　対象の データ が少量なら、「CREATE VIEW」 を使って、メモリー のなかで走査しても問題はない。
　ここで論点にしているのは、いわゆる 「基幹系」 と呼ばれている システム のなかで扱われている多量 データ （数百万件、数千万件） と多量 トランザクション である。
　数百万件の データ を join して--あるいは、複数の 「曖昧検索」 を使って--、「瞬きの」 レスポンス を実現することを目的にしている。

　
　次回は、複合検索条件を、もう少し詳細に解析してみる。
　（「create view」 以外にも、「order-by」 を使わないほうがよい、という点を検証してみる。）