こんにちは！データベースの世界へようこそ。
今日は、データベースの歴史の原点であり、今なお「爆速アクセスの究極形」の一つとして語り継がれる「階層型DBMS（データベース管理システム）」についてお話ししますね。
「データベースって、エクセルみたいな表（テーブル）が並んでいるやつじゃないの？」と思ったそこのあなた。実は、それよりもずっと昔からある、もっと直感的で、かつ強烈に速いデータの持ち方があるんです。
今回はその核心である「直接アドレス指定（ポインタ）」という技術について、専門用語をできるだけ使わずに、僕と一緒に紐解いていきましょう。
ここをクリアすれば、階層型DBMSの基本はバッチリマスターできますよ！
—
1. 現代のデータベースと、何が違うの？
私たちが普段よく使う最新のデータベース（関係型DBMS：RDB）は、データを「表」の形式で管理し、後から「この条件に合うデータを抽出して！」とパズルのように組み立てて探します。柔軟で非常に便利なんですが、データ量が増えると、どうしても「探し出すための計算時間」がかかってしまいます。
一方、今回学ぶ「階層型DBMS」は、データをまるで「会社の組織図」や「家系図」のように、ピラミッド型の親子関係でガッチリとつなぎ合わせます。
- 親データ：「本社」
- 子データ：「営業部」「開発部」「人事部」
- 孫データ：「開発部」の中の「Aチーム」「Bチーム」
この構造の何がすごいって、「上から順番に道をたどっていけば、迷子にならず一瞬で目的のデータにたどり着ける」という点なんです。
—
2. 「直接アドレス指定」って、要するにどういうこと？
さて、今回のテーマである「直接アドレス指定」です。なんだか難しそうな名前ですが、実体はとてもシンプルです。
日常の例で考えてみましょう。
あなたは広い遊園地で、友達の「Aくん」を探しています。
- 現代の一般的な探し方（検索）：
「園内にいる人全員の顔写真リスト」から、Aくんの特徴に一致する人を総当たりで探します（時間がかかる）。
- 直接アドレス指定の探し方（今回のテーマ）：
案内係の人が、「Aくんは、あそこにある観覧車の、上から3番目のゴンドラのなかに直接座っています」と、物理的な場所の「住所（番地）」を指し示してくれる。
データベースの世界でも全く同じです。
階層型DBMSでは、親データの記録の中に、「子供のデータが、ハードディスクの【どこ（物理的な位置）】に眠っているか」というメモ（＝ポインタ / 矢印）を直接書き込んでおきます。
コンピュータは、そのメモ（アドレス）を見るだけで、思考のスピードで一瞬にして子供のデータが置いてある場所にジャンプできるのです。
—
3. スキーマ定義（DDL）のイメージを見てみよう
百聞は一見に如かず。この親子関係と直接アドレス指定の仕組みを、データベースの設計図（スキーマ定義言語：DDL）のイメージで覗いてみましょう。
— 【階層型データベースのスキーマ定義イメージ】
— 1. 親となる「企業（COMPANY）」セグメントの定義
DATABASE COMPANY_DB;
SEGMENT COMPANY
DATA_LENGTH IS 128 BYTES;
— 企業の基本情報（社名、住所など）がここに格納されます
— 2. 子となる「部門（DEPARTMENT）」セグメントの定義
SEGMENT DEPARTMENT
PARENT IS COMPANY — 「COMPANY」が親であることを宣言
POINTER IS DIRECT_ADDRESS; — ★ここがキモ！物理アドレスを直接保持するポインタ
DATA_LENGTH IS 64 BYTES;
— 部門の情報（部門名など）が格納されます
【ちょっと解説】
この設計図のミソは、`PARENT IS COMPANY` で「誰が親か」を明確にし、見えない裏側でハードディスク上の場所を直接指し示す物理ポインタが組み込まれている点です。
SQLのように「WHERE句で条件を指定して探す」必要すらありません。親の場所さえ分かっていれば、ポインタをたどるだけで瞬時に子をゲットできるのです。
—
4. この仕組みの「光と影」を知る
ここまで聞くと、「直接アドレス指定って最強じゃん！全部これにすればいいのに！」と思われるかもしれません。しかし、世界を制した技術には必ず裏表があります。
☀️ 光（メリット）：圧倒的なスピード
余計な検索処理（インデックスの探索やテーブルの結合など）を一切行いません。メモリやハードディスクの「住所」をダイレクトに指すため、決められた階層を辿るアクセスにおいては、現代のどんなデータベースをも凌駕する爆速を発揮します。銀行の勘定系システムや、航空機の座席予約など、ミリ秒単位のスピードが命の世界で重宝されてきたのはそのためです。
🌧️ 影（デメリット）：構造変更の弱さ
「親から子へ一直線」という美しさの裏返しとして、「現実世界の複雑な関係性を表現しにくい」という弱点があります。
例えば、「1人の社員が、複数のプロジェクト（複数の親）に所属する」ようなケース。階層型では親が1つに固定されてしまうため、この構造を無理やり表現しようとすると、同じデータをあちこちに複製しなくてはならなくなります。また、途中に新しい階層を挟もうものなら、データベース全体の物理アドレスの配線をすべて貼り直し（再構築）する大工事が必要になります。
—
おわりに
いかがでしたでしょうか？
「直接アドレス指定」とは、複雑な迷路を解くような検索をせず、「あそこの棚の、左から3番目！」と、ハードディスク上の居場所を指し示す一本の強力な矢印（ポインタ）のことです。
私たちが普段使っているスマホのアプリやWebサービスでは、データが複雑に絡み合うため、柔軟な「関係型DBMS」が主役の座にいます。しかし、親子の主従関係がハッキリしていて、とにかくスピードが命という領域においては、この階層型DBMSの「直接アドレス指定」という思想は今でも色あせることなく、エンジニアたちのロマンを掻き立て続けています。
この基本さえ押さえておけば、データベースが「裏側でどうやって物理的にデータを掴みに行っているのか」という本質的なイメージがバッチリ掴めているはずです。
それでは、次のステップでも一緒に楽しくエンジニアリングの奥深さを探求していきましょう！
コメント