indexing は、コッド 関係 モデル と無関係であり、プロダクト としての RDB が、バージョンアップ のなかで、上積みした技法である。したがって、RDB は、セット・アット・ア・タイム 法と レコード・アット・ア・タイム 法の 2つの アクセス・メソッド を搭載している--そのほかの アクセス 技法として、ハッシュ 技法を搭載している プロダクト もある。

　ディレクトリ （directory） には、以下の情報が収録されている。

　（1） データベース の定義情報 [ CREATE TABLE、CREATE COLUMNS など ]
　（2） オープン・テーブル 情報 （open-table）^（参考）
　（3） アクセス に関する定義情報 [ CREATE VIEW、CREATE INDEX など ]

　
　レコード・アット・ア・タイム 法の インデックス 情報も、セット・アット・ア・タイム 法の ビュー 情報も、いずれも、アクセス 情報であって、RDB は、定義情報として、それらを同等に扱う。つまり、定義情報としては、レコード 系も、セット 系も、同じということである。それらの違いは、定義情報を確認したあとで、実地の アクセス では、以下のようになる。

　（1） レコード 系は、インデックス 情報を確認したあとで、インデックス・ファイル をアクセス する。^（注意）
　（２） セット 系は、ビュー 情報を確認したあとで、テーブル を スキャン （table-scan） する。

　
● 「CREATE INDEX」 を 「CREATE VIEW」 の代わりに使う。

　RDB が、定義情報として、インデックス 情報と ビュー 情報を同等に扱うなら、セット 系の アクセス を レコード 系の アクセス のように使うことができる、ということになる。言い換えれば、traversal table を生成しないようにするには、アクセス 単位の ビュー を、そのまま、インデックス にすれば良い、ということである。つまり、「CREATE INDEX」 を 「CREATE VIEW」 の代わりに使えば良い、ということである。たとえば、CREATE VIEW (a, b, c) の代わりとして、CREATE INDEX (a, b, c) を使えば良い、ということである。そうすれば、インデックス・ファイル を参照した時点で--テーブル を アクセス しなくても--、データ 値を入手できる。

　「CREATE INDEX」 を 「CREATE VIEW」 の代わりに使うことを 「INDEX-only」 という。「INDEX-only」 を使えば、当然ながら、「order-by」 句を使わなくても良い。「INDEX-only」 を使えば、traversal-table を生成しないし、テーブル を アクセス しないので、高 パフォーマンス を実現できる。

　
● インデックス の更新負荷を高めないようにするために、「キー の定義表」 を作成する。

　ただし、（「INDEX-only」 では、データ 値を扱う ビュー の代わりに インデックス を使っているので、） 1つの テーブル に対する インデックス の数が増えれば増えるほど、インデックス の更新負荷は高くなる。インデックス の更新負荷が高くなればなるほど、パフォーマンス は落ちる。 「INDEX-only」 を使ういっぽうで、更新負荷を高めないようにするために、「効果的・効率的な」 インデックス を設計しなければならない。そのために作成するのが、「キー の定義表」 である。

[ 本稿、次回に続く ]

　
（参考）
　テーブル が、オープン されているかどうか、という情報。

（注意）
　ただし、データ の アクセス は、ビュー 単位である。

　聞くところによれば、2 チャンネル だか どこかの Wiki だかで、「Ｔ字形 ER手法が遺したのは、『resource と event』 だけだね」 とか 「Ｔ字形 ER手法が遺したのは、『INDEX-only』 だけだね」 という記述があったそうです。こういう 小賢しい 言いかたをされるのは実に心外 （不愉快） ですね。

　「INDEX-only」 は、たあいもない （very easy） 技術ですが、それを考えるためには、RDB の internals を知っていなければならないし、セット・アット・ア・タイム 法と レコード・アット・ア・タイム 法を熟知していなければならない。
　ちなみに、「INDEX-only」 は、TM （Ｔ字形 ER手法） とは、べつの論点です。

　すべての データ が メモリー のなかに収まって、データ 演算の すべてが メモリー のなかで実行できるようになれば、「INDEX-only」 などいらない。いずれ、そういう時代がくるかもしれない。「INDEX-only」 は、テクノロジー が進歩するにつれて、その有用性が弱まって、ついには、消え去る運命の技術です。しかし、事業過程・管理過程が ことば を使って営まれているかぎりでは、TM の有用性は、そうそうに消え去らないでしょう。したがって、TM と 「INDEX-only」 をいっしょくたにして どうこう言われるのは心外です。TM を どうこう言うのであれば、TM が 「遺した--と言われている（笑）」 長所をふまえて、TM を超える技術を作れば良い。

　さて、「INDEX-only」 は、セット・アット・ア・タイム 法の 「view」 を レコード・アット・ア・タイム 法の indexing を使って実現する たあもない やりかたですが、「INDEX-only」 を効果的・効率的に使うためには、インデックス を的確に設計しなければならないでしょうね。その的確な indexing を設計するために、「キー （indexing） の定義表」 を作成します。「キー （indexing） の定義表」 については、「論考」 209ページ （あるいは、もう少し具体的に記述してある） 「赤本」 149ページを参照して下さい。

　「INDEX-only」 が最高に 「ききめ」 を出すためには、データ 構造が なんらかの正規形 （コッド 正規形あるいは TM 正規形） になっていなければならない。すなわち、リレーショナル 代数演算 （SELECT、JOIN）・集合論演算が I/O 化されていなければならない。非正規形に対しても、「INDEX-only」 は、或る程度、「ききめ」 を出しますが、非正規形であれば、1つの テーブル に対して、数多い インデックス を用意しなければならないので、かえって、パフォーマンス が低下します。その論点が、次回の論点です。