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

すすむ >>

「Ｔ字形ＥＲ データベース設計技法」を読む