【入門編】二次索引(セカンダリインデックス)の概念 – 階層型DBMS

こんにちは！データベースの世界へようこそ。
チーフアーキテクトの私だ。今日は、少しレトロでありながら、データ構造の美しさが凝縮された「階層型DBMS」の、ちょっとマニアックで面白い機能についてお話ししよう。

「階層型DBMS」って聞くと、なんだか難しそうに聞こえるよね。
でも、大丈夫。ここをクリアすれば、データの仕組みに対する見方がガラリと変わるはずだ。
今回は、その中核をなす「二次索引（セカンダリインデックス）」というテーマを、日常の例えを交えながら優しく解きほぐしていくよ。

肩の力を抜いて、コーヒーでも飲みながら聞いてほしい。

—

1. そもそも「階層型DBMS」ってどんなもの？（会社組織で例えてみよう）

二次索引の話をする前に、ベースとなる「階層型」の仕組みをイメージしておこう。

階層型データベースとは、データを「親と子」の樹木（ツリー）のような構造で管理する仕組みだ。身近なもので例えるなら、会社の「組織図」そっくりなんだ。

社長（ルート） が一番上にいて、
その下に 部長（親） がいて、
さらにその下に 課長やメンバー（子） がぶら下がっている。

この構造のいいところは、「社長から見た部長」「部長から見たメンバー」という一本道の親子関係が非常に分かりやすいこと。

例えば、「社長」から出発して、「〇〇部長」の部屋に行き、その部下の「××さん」のデータを取り出す……というルートなら、迷うことなく一瞬でたどり着ける。これが階層型DBMSの得意技だ。

—

2. 「一本道」の弱点：裏口がない！？

さて、ここで問題発生だ。

君が新人社員だとしよう。ある日、上司からこう言われた。
「おい、名簿番号『EMP-9999』の社員のデータを今すぐ持ってきてくれ！」

階層型データベースの普段の探し方は、「社長＞総務部＞〇〇課＞ EMP-9999」というふうに、上から順番にルートを辿る（これを「従属的なアクセス」と言うよ）ことになっている。

もし、君が「EMP-9999」という番号しか知らず、どの部署の何という課に所属しているのか知らなかったらどうなるだろう？
すべての部署のドアを一枚ずつノックして、「EMP-9999さん、ここにいますか？」と探して回るハメになる。これじゃあ、膨大な時間がかかって仕事にならないよね。

本来の「親子関係（階層）」以外のキー（手がかり）で、目的のデータに一発でたどり着きたい。
そんなときに登場する救世主が、今回のお題である「二次索引（セカンダリインデックス）」なんだ。

—

3. 二次索引（セカンダリインデックス）ってなに？

一言で言えば、二次索引とは「裏口の電話帳」や「ビルの総合案内板（インデックス）」のようなものだ。

さっきの例で言うと、会社の入り口に「社員番号順索引ボード」を置いておくイメージ。
このボードには、こう書いてある。

`EMP-0001` ＝開発部＞第一開発課＞山田さん
`EMP-9999` ＝営業部＞関東営業課＞佐藤さん

これがあれば、「EMP-9999」とだけ言われても、一瞬で「あ、営業部の佐藤さんだな！」と居場所（パス）が特定できるよね。そして、居場所が分かれば、あとは階層型データベースの得意な一本道でシュッとアクセスできる。

これが、階層構造（メインの道）とは別の軸でデータを引くための仕組み、「二次索引」の正体だ。

—

4. スキーマ定義（DDL）のイメージを見てみよう

さて、エンジニアらしく、これをデータベースの世界でどう定義するのか、少しだけコード（スキーマ定義言語：DDL）のイメージを覗いてみよう。

専門用語は極力省くけれど、雰囲気を感じ取ってほしい。

— 1. メインの階層構造（会社組織）の定義
DATABASE CompanyTree {
— 社長（ルート）
RECORD President {
CEO_Name STRING
};

— 部長（子）
RECORD Department {
Dept_ID INT,
Dept_Name STRING
} PARENT IS President;

— 社員（孫）
RECORD Employee {
Emp_ID INT, — 社員番号
Emp_Name STRING — 氏名
} PARENT IS Department;
};

— 2. ここからが本題！裏口の電話帳「二次索引」の定義
— 社員番号（Emp_ID）を使って、所属を気にせず社員を探せる索引を作るよ
CREATE SECONDARY INDEX Emp_Id_Index
ON Employee (Emp_ID)
USING Tree; — 索引の構造を指定（ここではツリー構造）

【ちょっとしたコードの解説】
前半の `CompanyTree` では、社長から部署、部署から社員へと繋がる「綺麗な一本道」を定義している。
そして最後の `CREATE SECONDARY INDEX` が、今回の主役だ。「社員番号（Emp_ID）をキーにして、迷子にならずに社員データへワープできる裏口を作ってくれ！」とデータベースにお願いしているわけだね。

この定義をしておくだけで、データベースの裏側が自動的に「逆引きの電話帳」をメンテナンスしてくれるようになる。

—

5. 先輩エンジニアからのアドバイス

ここまで読んでくれてありがとう。どうだろう、二次索引のイメージは掴めたかな？

最後に、実務でこの仕組みを扱うときの「ちょっとした知恵」を授けておこう。

便利だけど、万能じゃない

「裏口（索引）」をたくさん作れば作るほど、データを新しく追加したり書き換えたりするときに、裏口の電話帳も一緒に書き換える手間が増える。これをエンジニアの世界では「更新コストがかかる」と言うんだ。
だから、「何でもかんでも索引をつければいい」というわけではない。ここぞという検索キー（よく使うキー）を見極めて絞るのが、腕の見せ所だよ。

階層型DBMSは古い技術だと言われることもあるけれど、データの親子関係をガッチリ固定して高速に処理する思想は、現代のモダンなデータベース（JSONドキュメントDBなど）にも脈々と受け継がれている。

ここをクリアできれば、君はもうデータベースの構造の本質をかなり深く理解したも同然だ。
自信を持って、次のステップへ進んでいこう！バッチリマスターできたはずだよ。