【実務・中級編】セカンダリインデックス – 階層型DBMS

階層型DBMSの「呪縛」を解く：セカンダリインデックスという名の反逆

諸君、現場で階層型DBMS（IMSやその亜種）を扱っていると、「親から子へ」という厳格な物理ポインタの鎖に窒息しそうになることはないか？

ルートからセグメントを辿り、期待するリーフに到達するまで何回I/Oを叩いている？もし「検索条件がルートのキーではない」という理由だけで全件スキャン（全セグメントスキャン）を許容しているなら、今すぐそのキーボードから手を離してこの記事を読んでくれ。

今日は、階層型DBMSにおける「セカンダリインデックス（Secondary Index）」という、物理構造への反逆手段について語る。

—

1. なぜ「物理的な鎖」を断ち切る必要があるのか

階層型DBMSの最大の美徳であり、かつ最大の呪縛は「物理的な位置関係がデータ構造そのものである」という点だ。

物理的アクセスパス: 親 → 子 → 孫と辿る構造は、階層に沿った処理には最強だが、突発的な「属性値による検索」には極めて脆弱だ。
セカンダリインデックスの本質: これは、物理的な階層構造の外側に「論理的な索引」を構築する行為だ。ポインタを直接辿るのではなく、インデックスという名の「ショートカット」を物理階層の横に並行して敷設する。

2. アーキテクチャの急所：インデックス・データベースの裏側

セカンダリインデックスを導入する際、初心者は単なる「高速化ツール」と捉えがちだが、プロは「物理的なI/Oオーバーヘッドの増大」を同時に計算に入れる。

インデックス・データベース（IDB）: 実際のデータとは別の領域にキーとポインタのペアが保持される。
更新時のコスト: データを更新するたびに、このIDBも更新しなければならない。インデックスを貼りすぎれば、OLTPの書き込みスループットは確実に死ぬ。

実務的な設計判断基準

高頻度の検索: 1日に何度も実行されるクエリには必須。
低い更新頻度: 書き込みが集中するセグメントにインデックスを貼るな。物理的な整合性維持だけでシステムが悲鳴を上げる。
カーディナリティ: キーの選択性が低い（重複が多すぎる）場合、インデックスを引いた後の物理アクセスで結局全スキャンに近いI/Oが発生する。

3. 「スパース」か「デンス」か：設計の分かれ道

インデックスの設計において、「どのセグメントを指すか」という判断が運命を分ける。

ルートセグメントを指す: 最も一般的。物理的な階層の入り口を特定する。
下位セグメントを指す: ここが腕の見せ所だ。特定の条件に合致する「孫セグメント」へ直接ジャンプする。ただし、これを行うと物理的な親子関係の整合性よりも、インデックス側の更新整合性が優先され、運用上の複雑さが増す。

概念的なインデックス定義のイメージ
「顧客ID」ではなく「メールアドレス(属性)」で直接「注文詳細」にアクセスする例

/
CREATE INDEX IDX_ORDER_BY_EMAIL
ON SEGMENT ORDER_DETAIL (EMAIL_ADDRESS)
/

注意：このインデックスを定義することで、
注文データ更新時にインデックス領域への排他制御が発生する。
トランザクション分離レベルとの兼ね合いを必ず考慮せよ。

4. パフォーマンスを殺さないための「鉄の掟」

1. 「インデックス・オンリー・アクセス」を狙え:
インデックスの中に必要な属性値を含めてしまえば、物理セグメントまで読みに行く必要はない。これをやるとI/Oは劇的に改善する。
2. インデックスの「鮮度」を疑え:
階層型DBMSは、物理再編成（Reorg）の際にインデックスの再構築が必須となることが多い。再編成を怠ると、インデックスのポインタが物理的な断片化に引きずられ、ゴミの山と化す。
3. 複合インデックスの罠:
条件が複数ある場合、単一のインデックスを複数作るよりも、複合インデックスを一発作る方がI/O効率が良い。だが、その分キー長が長くなり、インデックスの階層（深さ）が深くなるトレードオフを忘れるな。

最後に：エンジニアとしての矜持

階層型DBMSは、現代のRDBのようにオプティマイザが全自動で最適な経路を選んでくれるわけではない。「どのパスを通るか」を決めるのは、設計者である君の意志だ。

セカンダリインデックスは、物理構造の制約を打破する強力な武器だが、同時にシステムの複雑性という負債を抱える諸刃の剣でもある。「なんとなく検索を速くしたいから」という理由で安易にインデックスを増やすのは、素人のやり方だ。

「このインデックスは、物理的なデータ配置の弱点をどうカバーし、どの程度の更新負荷と引き換えに、どの程度のレスポンスを奪い取るのか？」

この問いに、数値で即答できる人間だけが、階層型DBMSを真に使いこなせると言える。現場の設計レビューで、この視点を忘れないでほしい。

健闘を祈る。