やあ。よく来たね。
今日は、コンピュータの歴史を語る上で避けては通れない、けれど現代では少し「伝説の秘宝」扱いされている「階層型DBMS」について話をしよう。
君が普段使っているリレーショナルデータベース（RDBMS）とは全く異なる、けれど非常に直感的で面白い世界だ。ここをマスターすれば、データの「構造」を見る目が一段階鋭くなるはずだよ。
—
1. 階層型DBMSとRDBMS：その根本的な違い
まずは、この2つの違いを「図書館」で例えてみようか。
- 階層型DBMSは「家系図」や「組織図」だ。
親がいて、その下に子がいて、さらにその下に孫がいる。この「親子関係」をポインタ（直接的な住所録のようなもの）でガッチリ繋いでいるんだ。
- RDBMSは「名簿の組み合わせ」だ。
「生徒名簿」と「クラス名簿」という別の表を用意して、IDという共通の項目を鍵にして、必要な時にパズルのように組み立てる。
なぜ「ポインタ」が重要なのか？
階層型DBMSは、データの住所を直接知っているんだ。「Aさんのデータは、ここから右に3歩進んだ場所にある」と分かっているから、爆速で目的地にたどり着ける。
一方でRDBMSは、「誰のデータだっけ？」と毎回名簿を突き合わせて検索する。だから柔軟だけど、少し手間がかかるんだね。
—
2. 日常で例える：iPhoneの「フォルダ」
君がiPhoneやPCで使っている「フォルダ」を思い出してほしい。
- ルート（一番上）
- 写真フォルダ
- 2023年
- 旅行.jpg
- 食事.jpg
- 2024年
- 猫.jpg
これがまさに階層型だ。「旅行の画像が見たい」と思ったら、「写真 → 2023年 → 旅行.jpg」という一本道を辿る。迷う余地はないよね？ これが「ナビゲーション型」の真髄だ。
もしこれをRDBMSでやろうとすると、「写真テーブル」と「年テーブル」を結合して…という手順が必要になる。階層型は「最初から構造が出来上がっている」から、アクセスが極めてシンプルなんだ。
—
3. 構造の違いをコードで眺めてみる
実際に、データにアクセスする時の「考え方」の違いを疑似コードで見てみよう。
【階層型】「ナビゲーション」のイメージ
// 親ノード（部署）から、ポインタを辿って子ノード（社員）へ直接飛ぶ
部署 = “開発部”
社員ポインタ = 部署.最初の社員へ移動() // ポインタを辿る
while (社員ポインタ != NULL) {
print(社員ポインタ.名前)
社員ポインタ = 社員ポインタ.次の社員へ移動() // 次のポインタへジャンプ
}
// 迷路を一本道で走るような感覚だね
【RDBMS】「集合論・宣言的アクセス」のイメージ
— 「どう辿るか」ではなく「何が欲しいか」を命令する
SELECT 名前
FROM 社員テーブル
WHERE 部署 = ‘開発部’;
— データベースが勝手に最適なルート（検索方法）を考えてくれる
—
4. なぜ階層型は「伝説」になったのか？
じゃあなぜ、今の世界はRDBMSばかりなのか？ それは「変化」に弱いからなんだ。
階層型は「親子関係」があまりに強固すぎる。もし、「部署」と「社員」の関係が複雑になって（例えば、一人の社員が複数のプロジェクトを掛け持ちするなど）、関係が網の目状になったら、ポインタの管理がパンクしてしまう。
「家系図」を書き直すのは大変だよね？ だから、柔軟にデータを組み替えられるRDBMSが主流になったのさ。
—
最後に：エンジニアとして持つべき視点
「じゃあ、古い技術なんて勉強しなくていいの？」と思うかもしれない。でも、それは違う。
現代のプログラミングでも、JSONデータを扱うときや、ディレクトリ構造を操作するとき、あるいはXMLを解析するとき、君たちは無意識に「階層型」の思考を使っている。
- RDBMSの知識は「データを整理して管理する能力」を育む。
- 階層型の知識は「データの構造を直感的に捉える能力」を育む。
この2つを両方持っているエンジニアは、現場でトラブルが起きた時、データのどこが詰まっているのかを即座に視覚化できるんだ。
どうだい？ 階層型DBMSの「一本道で目的地へ一直線」という潔さ、少しは伝わったかな。
この感覚を持っていれば、君のデータ設計スキルは一段上のレベルに到達したと言っていい。またいつでも聞きに来ておくれ。応援しているよ。
コメント