2007年 4月 1日 特論-6 セット系 対 レコード 系 >> 目次に もどる
2012年 3月 1日 補遺  


 本節では、セット・アット・ア・タイム 法と レコード・アット・ア・タイム 法を対比している。

 セット・アット・ア・タイム 法は、「logical view」 を実現した長所があるが、いっぽうで、以下の弱点がある。

   (1) MAX-SIO を制限できない (table-scan)。
   (2) (複合選択条件では、) 同一 row 上の確認をしなければならない。

 (1) を回避して 1つの セット (縦列) のなかの メンバー を並べるために (SQL では) order-by を搭載したが、メンバー を並べる作業域 work-file として、RDB は traversal-table を生成する。また、(2) を実施するために、RDB は traversal-table を生成する。すなわち、traversal-table は、RDB の 「宿命の」 ファイル である。すなわち、SQL (DDL および DML) のなかで、「view」 「order-by」 あるいは compound Boolean selection (「AND/OR」 演算) を使ったら、RDB は traversal-table を生成する。

 プロダクト としての RDB は、バージョンアップのなかで、(セット・アット・ア・タイム 法用の) テーブル 構造に対して、indexing を搭載してきた (上積みしてきた)。そして indexing は、B-tree を導入した。121 ページに B-tree 構造を概説しているが、B-tree は、そもそも、どんな ランダム・アクセス に対しても、均等な レスポンス を実現するために導入された しくみ である。B-tree は、その しくみ 上、以下の弱点がある。

 (1) indexing を使った シーケンシャル・アクセス には向かない。
 (2) 階数が多くなれば、path を 「たぐる」。
 (3) low-level index が split すれば、high-level index は再編成され、「ゆらぐ」。

 単純に言い切れば、B-tree は、「たぐる」 「ゆらぐ」 という弱点がある。

 RDB 上で 「驚異的な」 高 パフォーマンス を実現するためには--しかも、「logical view」 を実現して--、前述した弱点を回避すれば良い。すなわち、traversal-table を生成しないようにして--言い換えれば、indexing を使うことになるのだが--、B-tree を 「たぐらない」 「ゆらがない」 ようにすれば良い。それを実現する技術が 「INDEX-only」 および 「null-keys」 である。

 「INDEX-only」 は、欲しい データ を欲しい順に並べて、(create view ではなくて、) create index を定義すれば良い。たとえば、(a, b, c) という tuple に対して、(a, c) を view として入手したいなら、create index (a, b) とする。(a, b) は、index の値として収納されるので、select (a, c) を実行すれば、RDB は、index のみに アクセス して、テーブル に アクセス しない。しかも、(a, c) は、(デフォルト では) 昇順に並んでいるので、order-by を使わなくてもいい。
 「INDEX-only」 の使いかたは、「黒本」 では記述しなかった。というのは、「黒本」 の先に出版された 「RAD」 のなかで述べたので。ただ、「RAD」 を絶版にしたので、「INDEX-only」 については、「論考」 あるいは 「赤本」 を参照されたい。

 「null-keys」 は、index-key の値を null にして、B-tree から index-key を排除する技術である。したがって、「null-keys」 を使えば、B-tree の階数を削減できる。ただし、プロダクト のなかには、「null-keys」 を B-tree から排除しない物もあるので注意されたい。
 「null-keys」 の使いかたも、「論考」 あるいは 「赤本」 を参照されたい。

 以上に述べてきたことを まとめれば、RDB 上、「驚異的な」 高 パフォーマンス を実現したいなら、レコード・アット・ア・タイム 法を セット・アット・ア・タイム 法のように使えば良い (indexing を view の代わりに使えば良い) ということである。

 なお、RDB を使っていながら、join を禁止にしている企業が多いそうである。join は、RDB の データ 演算の特徴点である。データ・モデルは、{データ、データ 演算、制約} の組である。RDB では、データ は、コッド 正規形で整えられた テーブル 構造で編成され、データ 演算は、集合論演算と リレーショナル 演算から構成されていて、リレーショナル 演算が {select、join、projection} 演算であり、制約は、テーブル 構造上の integrity である。言い換えれば、join を使わなければ、RDB の意味がないと云っていい。「INDEX-only」 で join すれば、「驚異的な」 高 パフォーマンス を実現できる。



[ 補遺 ] (2012年 3月 1日)

 RDB が マーケット に登場した 1980年代に私は 「セット・アット・ア・タイム 法」 という語を日本に普及したかったのですが [ RDB を語る時には、欧米では常に言及される語ですが ]──私の セミナー・講演・著作 などで盛んに紹介したにもかかわらず──遺憾ながら普及しなかった。







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