【入門編】論理親ポインタの物理実装 – 階層型DBMS

こんにちは！データベースの世界へようこそ。
今日は、少しレトロだけど、すべてのデータベースの「基礎の原点」である階層型DBMSについて、一緒に楽しく学んでいきましょう。

「階層型」と聞くと、なんだか難しそうに聞こえるかもしれませんね。でも大丈夫。ここをクリアすれば、データがどうやって綺麗に整理されてつながっているのか、その本質がバッチリマスターできますよ！

今回は、その中でもちょっと通なテーマ「論理親ポインタの物理実装」について、専門用語をできるだけ使わずに、日常の例えを交えて優しく紐解いていきますね。

—

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

階層型DBMSの構造は、よく「会社の組織図」や「家系図」に例えられます。

一番上に「社長（親）」がいて、その下に「部長（子）」がいて、さらにその下に「課長（孫）」がいる……というように、データが一本の木（ツリー）のようにピラミッド状につながっているのが特徴です。

通常、この世界では「親から子へは簡単にたどり着ける」ようになっています。社長は自分の部署の部長をすぐに呼び出せますよね。

でも、ちょっと待ってください。
現場の「課長」の立場から、「私の上の部長は誰だっけ？」「さらにその上の社長は誰だっけ？」と、下から上に逆戻りしたくなったとき、どうすればいいでしょうか？

ここで登場するのが、今回の主役である「論理親ポインタ（逆参照の仕組み）」です。

—

2. 「論理親ポインタ」って要するに何のこと？

日常で例えてみましょう。

あなたは大きな会社の、ある「プロジェクトチーム（子）」に所属しています。
会社の中では、本社ビル（親）から指令が下りてきます。普通は「本社 $\to$ プロジェクトチーム」という一方通行の連絡網（物理的な道）しかありません。

しかし、プロジェクトチーム側からも「これ、どの本社の部署からの指示だっけ？」とすぐに確認できるように、チームの机の上に「本社の担当部署へ直通する専用の赤い内線電話（＝論理親ポインタ）」を置いておくことにしました。

この「下から上にピッと繋ぎ止めるための目印やアドレス」のことを、データベースの世界では論理親ポインタと呼んでいます。

—

3. なぜこの「逆向きの道」が必要なの？

「上から下に行けるんだから、下から上も同じ道を戻ればいいじゃない？」と思いますよね。

しかし、昔のコンピュータの世界や、データをガチガチに固めて効率よく管理する階層型DBMSの世界では、道は基本的に「一方通行（片道切符）」で作る方が、データ容量を節約できて処理も速かったのです。

そのため、あえて「下の子から、上の親を直接指し示すメモ（ポインタ）」を物理的に書き込んでおく必要がありました。これが「論理親ポインタの物理実装」の正体です。

—

4. 実際のスキーマ定義（設計図）を見てみよう

言葉だけだとイメージしにくいので、簡単なイメージ図と設計図（DDL風）を見てみましょう。ここでは初心者向けに、極力シンプルなコード風で表現しますね。

【会社組織のツリー構造イメージ】
[本社 (親)] ━━━━ (ポインタ) ━━━━┓
┃ ┃
┗━━━━ [プロジェクト (子)] ━━┛
(ここに論理親ポインタが仕込まれている！)

これをデータベースの言葉（スキーマ定義）で表現すると、ざっくり以下のようになります。

— 親データ（本社）の定義
SEGMENT TOP HEADQUARTERS
FIELD DEPT_NAME CHAR(50); — 部署名

— 子データ（プロジェクト）の定義
SEGMENT SUB PROJECT
FIELD PROJ_NAME CHAR(50); — プロジェクト名

— ★ここがポイント！親（本社）へ戻るための物理ポインタを定義する
POINTER TO PARENT HEADQUARTERS
VIA PHYSICAL_ADDRESS; — 本社の場所を直接指し示すメモ

【ここに注目！】
`POINTER TO PARENT` という部分が、まさに「赤い内線電話」の設置工事です。子どものデータの中に、「私の親御さんは、ハードディスクのこの住所にいますよ」という具体的な番地（物理アドレス）を書き込んでおくことで、双方向の行き来ができるようになります。

—

5. 運用する上での注意点（整合性という名のルール）

この便利な「論理親ポインタ」ですが、運用する上では一つだけ厳重に守るべきルールがあります。それは「お引越しのときの連絡ミスに気をつけること」です。

もし、親データ（本社）が別の場所にお引越ししたとします。
そのとき、子データ（プロジェクト）の机の上にある「赤い内線電話のメモ（論理親ポインタ）」を書き換え忘れたらどうなるでしょうか？

子から上に連絡しようとしたとき、「あれ？電話番号が変わっていて繋がらないぞ……！？」という大パニックが起きてしまいます。これをデータベースの世界では「参照整合性の崩壊」と呼びます。

そのため、階層型DBMSを運用するシステムでは、親を移動・削除するときには、必ず子側のポインタもセットで綺麗にメンテしてあげるという優しい気配り（仕組み）が必要不可欠なのです。

—

まとめ

いかがでしたか？
「論理親ポインタの物理実装」なんて、呪文のような難しい名前がついていましたが、中身を紐解いてみれば「迷子にならないように、子ども部屋に置いてある親への直通連絡メモ」という、とってもシンプルで温かみのある仕組みでしたよね。

ここさえ押さえておけば、データがどうやって上下につながり、どうやってお互いを認識しているのかという、データベースの根本的な嗅覚がグッと身についたはずです。

基礎をしっかり理解したあなたなら、どんな複雑なデータベース構造に出会っても怖くありません。ぜひこの調子で、データベースの深淵なる世界を楽しんでいってくださいね！