こんにちは！データベースの世界へようこそ。
今日は、少しレトロだけど、現代のデータベースの基礎がすべて詰まっている「階層型DBMS」の世界を覗いてみましょう。
「階層型」と聞くと難しく聞こえるかもしれませんが、実は私たちの日常にあふれている仕組みなんですよ。ここをクリアすれば、データベースの「データを綺麗に整理整頓するルール」の本質がバッチリマスターできますよ！
肩の力を抜いて、カフェでお茶でも飲みながら聞いてくださいね。
—
1. 階層型DBMSってなぁに？（日常の例えで理解する）
現代の主流であるリレーショナルデータベース（表形式のやつですね）とは違い、階層型DBMSは「家族の家系図」や「会社の組織図」のように、親子関係がガッチリと決まっているデータ構造をしています。
例えば、あなたのお財布の中にある「ポイントカード」を想像してください。
- 親： 財布
- 子： ポイントカード
「財布」がなければ、「ポイントカード」だけを宙に浮かすことはできませんよね。財布（親）があって初めて、その中にカード（子）が入る。これが階層型DBMSの基本の形です。
この世界では、データ同士が「物理的（ハードウェア的なつながり）」、「論理的（意味上のつながり）」、そして「仮想的（見せかけのつながり）」という3つのペアリング（結びつき）で管理されています。それぞれのルールを見ていきましょう。
—
2. データの「お片づけルール」：参照整合性制約とは？
データベースで一番怖いのは、「親がいなくなったのに、子が一人ぼっちで迷子になること」です。
例えば、「お財布を捨てた（削除した）のに、中に入っていたポイントカードが空中に浮いている」なんてホラーですよね？
これを防ぐためのルールが「参照整合性制約（ルール）」です。
階層型DBMSでは、データを「挿入する」「削除する」「置き換える（更新する）」ときに、このルールが厳しく発動します。
それぞれのペアリングにおけるルールの適用範囲を、優しく紐解いていきましょう。
—
3. 3つのペアリングにおけるルールの違い
① PHYSICAL（物理ペアリング）：「運命共同体の絆」
データがハードディスク上で、文字通り「物理的に隣同士」にくっついて保存される最も強い結びつきです。
- 削除時のルール：
親を削除すると、子どもも問答無用で一緒に消滅（カスケード削除）します。
例：「財布（親）」をゴミ箱に捨てたら、中に入っていた「カード（子）」も自動的にゴミ箱行きです。
- 挿入時のルール：
親が絶対に存在していないと、子どもを新しく作れません。
- 置換（更新）時のルール：
物理的なアドレスが変わるため、システム全体に影響が及ばないよう厳しく制御されます。
② LOGICAL（論理ペアリング）：「心でつながる絆」
物理的には離れた場所にあるデータ同士を、ポインタ（目印の矢印）で結ぶ方式です。
- 削除時のルール：
親を削除しようとしたとき、「子どもがいるから親は消せません！」とエラーになるか、「子どもの目印を消して、子どもを孤児にする（あるいは別の親に付け替える）」という優しいルールが選べます。
例：「部署（親）」をなくすとき、所属している「社員（子）」を別の部署に異動させないと部署を消せない、というイメージです。
- 挿入・置換時のルール：
論理的なつながり（矢印）の向きが正しいか、矛盾がないかが厳しくチェックされます。
③ VIRTUAL（仮想ペアリング）：「その場限りの幻の絆」
データの実体は別の場所にありながら、まるでそこにあるかのように「見せる」ペアリングです。
- 削除・挿入・置換時のルール：
実体を伴わない「見かけ上のつながり」なので、親側の操作に子どもが直接巻き込まれることはありません。
例：ショートカットアイコン（仮想）をゴミ箱に入れても、大元のアプリ（実体）が消えないのと同じです。
—
4. スキーマ定義のイメージを覗いてみよう
言葉だけだとイメージしにくいので、階層型DBで使われるスキーマ定義言語（DDLの祖先のようなもの）の雰囲気をコードブロックで見てみましょう。
— 【階層型スキーマ定義のイメージ】
— 財布（WALLET）という親の中に、カード（CARD）という子がぶら下がる構造を定義します。
DATABASE WalletSystem;
SEGMENT WALLET ( — 親セグメント（物理ペアリングの基準）
WALLET_ID CHAR(5),
WALLET_NAME CHAR(20)
);
SEGMENT CARD DEPENDS ON WALLET ( — 子セグメント（親に依存するルールを明示）
CARD_ID CHAR(5),
CARD_NAME CHAR(20),
— ※ここに「親が消えたら子も消す」という削除ルール（CASCADE）が裏で連動します
);
> 💡 先輩エンジニアからのワンポイントコメント
> このように、`DEPENDS ON`（依存関係）をコードで明示することで、DBMSが自動的に「親子の絆」を守ってくれるようになります。
—
まとめ：ここをクリアすればバッチリ！
いかがでしたでしょうか？ 階層型DBMSにおけるルールは、一見すると厳しく感じるかもしれません。しかし、これらはすべて「データの秩序を守るための優しい制限」なのです。
- PHYSICAL（物理）： 親が消えたら子も運命を共にする（運命共同体）
- LOGICAL（論理）： 子どもの行く先を決めてから親を動かす（お世話が必要）
- VIRTUAL（仮想）： 見た目だけのつながりなので実体に影響しない（気楽な関係）
この3つの違いと、削除・挿入時の「親子のルール」さえ押さえておけば、階層型DBMSの基本はもうバッチリマスターできていますよ！
古い技術に見えて、データの親子関係を管理する思考のベースは、現代のオブジェクト指向やツリー構造のプログラミングにもしっかりと受け継がれています。ぜひこの機会に、データベースの奥深さを楽しんでみてくださいね。
コメント