【入門編】副次インデックス – 階層型DBMS

こんにちは！アーキテクチャの裏側まで知り尽くした、ちょっと古いシステムも愛するシニアエンジニアです。

今日は、少しレトロだけど計算機科学のロマンが詰まった「階層型DBMS（データベース管理システム）」の世界へあなたをご案内します。

「階層型データベース？今どき何それ？」と思うかもしれませんが、データ構造の原点であり、現代のツリー構造やJSONの祖先とも言える非常に美しい仕組みです。

今回のテーマは「副次インデックス（ふくじインデックス）」。
「ここをクリアすれば、階層型DBMSの基本はバッチリマスターできますよ！」というマイルストーンになる大切な部分です。難解な専門用語は置いておいて、まずは日常の例えから優しく紐解いていきましょう。

—

階層型DBMSは、データを「親と子」の樹木（ツリー）のようにつなげて管理する仕組みです。

身近なもので例えると、「会社の組織図」や「家系図」を思い浮かべてください。

この世界では、データは必ず「一本の道（ルート）」で上から下へとつながっています。例えば「営業部の鈴木さん」を探すときは、必ず「会社」から「営業部」という階段を下りていかなければなりません。

この「上から順番にたどるための道順」を、メインのインデックス（ポインタ）と呼びます。

—

さて、ここで問題です。
「営業部の鈴木さん」を探すときは上から順にたどれば簡単に見つかりますが、もしあなたが総務の担当者で、こう聞かれたらどうでしょう？

> 「部署はどこでもいいから、『鈴木』という苗字の社員を全員リストアップして！」

階層型DBMSの基本のルールでは、「会社＞部署＞社員」という上から下への道順しかありません。「苗字」という横断的な情報は、メインの道としては用意されていないのです。

もしメインの道だけで探そうとすると、すべての部署の扉を一つずつ開けて、中を覗いていかなくてはなりません。データが何百万件もあったら、定時までに仕事が終わらない大惨事です。

—

ここで登場するのが、今回の主役である「副次インデックス（Secondary Index）」です。

副次インデックスを日常に例えるなら、電話帳の「五十音順の索引」です。
会社の組織図（メインの道）とは別に、「『す』のページを開けば、鈴木さんがどこにいるか一発でわかる引き出し」を横にこっそり用意しておくイメージです。

階層型DBMSにおいて、この副次インデックスは、本来のきれいなツリー構造を乱さずに、「別の切り口（横断的な検索）」を可能にするための魔法の裏口なのです。

—

ここで、少しだけコード（スキーマ定義言語：DDL）の雰囲気を覗いてみましょう。初心者の方でもパッと見でイメージできるように書きますね。

— 1. メインのツリー構造を定義する（親子の関係）
DATABASE CompanyTree {
— 親セグメント：部署
SEGMENT Department {
Field dept_id;
Field dept_name;
}

— 子セグメント：社員（部署にぶら下がる）
SEGMENT Employee DEPENDENT ON Department {
Field emp_id;
Field emp_name; — 社員名
Field emp_age; — 年齢
}
}

— 2. 副次インデックスを定義する（裏口の作成）
— 「部署に関係なく、社員の名前（emp_name）で素早く検索したい！」という指示
SECONDARY INDEX idx_emp_name ON Employee (emp_name);

【ここがポイント！】
`SECONDARY INDEX` という一行を書くことで、DBMSは「社員名（emp_name）」の索引を裏側で自動的に作ってくれます。これにより、プログラム側は複雑なツリーのジャンプを意識せず、「名前で探す」というシンプルな命令を投げることができるようになります。

—

いかがでしたか？副次インデックスの役割が見えてきたのではないでしょうか。

データベースの世界は、一見すると難解な用語のオンパレードですが、本質は「にいかに速く、スマートに目的のデータにたどり着くか」という工夫の歴史です。

ここをクリアできたあなたなら、現代のリレーショナルデータベースやNoSQLが持つインデックスの概念も、スッと理解できるはずです。基本はいつの時代も同じですからね。

それでは、次のステップでも一緒に楽しくエンジニアリングを極めていきましょう！バッチリお疲れ様でした！