本編では、B-tree 構造には、以下の 2つの弱点があることを指摘しています。

　　（1） たぐる

　　（2） ゆらぐ

　セット・アット・ア・タイム 法に上積みされた indexing （B-tree） 構造は、「上積み」 と謂ったように、そもそも、コッド 関係 モデル とは関係がない。言い換えれば、プロダクト としての RDB は、その内部構造において index を識別できない。試しに、以下の テスト を実施してみればいい。

　　（1） ｛ a, b, c } という 3つの column を用意する。

　　（2） それらの columns に対して以下の index-key を作る。

　　　　　CREATE INDEX (a, b, c) [ by ascending ]. （昇順）

　　（3） 次に、それらの columns に対して以下の index-key を作る。

　　　　　CREATE INDEX (a, b, c) [ by dscending ]. （降順）

　そして、たとえば、ORACLE あるいは DB2 において、（3） の index-key を使って、(a, b, c) を 「降順」 で表示してみてください──昇順でしか表示されないでしょう。

　すなわち、同じ column(s) に対して create index を定義すれば──たとえ、by ascending と by dscending として条件を変えたとしても──、optimizer は、ふたつの index を見分けることができない。もし、indexing が RDB の internals として構成されていれば、それらの indexes を べつべつのものとして扱うはずです。indexing は、RDB （正確に言えば、テーブル 構造を基底にした セット・アット・ア・タイム 法） と無関係です。

　そこで、上積みされた indexing を使って view を構成するのが 「INDEX-only」 です。つまり、CREATE VIEW (a, b, c) の代わりに CREATE INDEX (a, b, c) を定義して、SELECT （および JOIN） を実行する、ということ。そうすれば、セット・アット・ア・タイム 法の弱点である traversal table を生成しないで、高 レスポンス を実現できます。ただし、「INDEX-only」 では、前述した 「同じ column(s) に対する by ascending と by dscending のちがい」 を optimizer は認識しないので、しかるべき対応を講じます （その対応法は、本 エッセー では割愛します）。

　B-tree を たぐらないようにするためには、null-key を使って、「木」 上において、対象外となっている道を除去します──ただし、null-key は B-tree から除去されるということが前提です [ たいがいの RDB は、そうしていますが、そうしない RDB もあるようです ]。null-key の使いかたは、RDB の マニュアル を読んでください。

　B-tree が揺らぐ原因は、たいがい、付値 （データ の値） にあると思っていいでしょう。例えば、以下を考えてみます。

　（1） 「取引先」 テーブル の基数 （データ 件数） は 100 である。

　（2） 「受注」 テーブル の基数は 1,000 である。

　（3） 取引先 a は、受注の 30％ を占めている。

　（4） 取引先 a に対して、取引先番号の値を 0001 としていて、取引先 データ のなかで下組にいる。

　さて、「取引先」 と 「受注」 の割合は、「100 対 1,000」 で、平均すれば、ひとつの取引先には、10 の受注があることになりますが、取引先 a は受注の 30％ を占めているので、「偏り （skewness）」 が生じています。しかも、取引先 a の番号には 001 が付値されていて、「取引先」 のなかで下組に属しているので、index-key として、（取引先番号, 受注番号） を作れば、取引先 a は indexing の B-tree （leaf） のなかで前方に格納されます。今後も、取引が、この 「偏り」 で実施されれば、取引先 a の受注があるたびに、（取引先番号, 受注番号） の low-level index は split します──したがって、high-level index が再編成される頻度も増えるでしょう。こういう事態に対しては、しかるべき対応を講じなければならない （その対応法は、本 エッセーでは割愛します）。

　「INDEX-only」 は高 レスポンス を実現しますが、万能ではない。「INDEX-only」 の使用上の注意点を本編で示しておきました。データ が すべて メモリー 内に格納されるのであれば、「INDEX-only」 などという テクニック は無用です。

　
（参考）

ひとつの集合 (セット) A を、たとえば、ふたつの組 A₁ A₂ に分けることを 「切断」 といい、( A₁, A₂ ) で表わします。A₁ に属する メンバー の値は A₂ に属する どの メンバー の値よりも小さい。A₂ を 「上組 （上級）」 と云い、A₁ を 「下組 （下級）」 と云います。 □