やあ。ようこそ、データ構造の深淵へ。
今日は、現代のデータベースの祖先とも言える「階層型DBMS」について話をしよう。今のエンジニアは「とりあえずRDB（リレーショナルデータベース）」で思考停止しがちだが、データの本質を理解するには、この「階層型」という古い巨人を知ることが不可欠なんだ。
準備はいいかい？ さあ、深い森へ分け入っていこう。
—
「家系図」という名の呪縛
まず、階層型DBMSをイメージしてみてほしい。一番わかりやすい例は「Windowsのフォルダ構成」や「家系図」だ。
あるデータ（親）の下に、複数のデータ（子）がぶら下がる。その子にはまた孫がいる……という、きれいに枝分かれしたツリー構造。これが階層型の基本形だ。
- 親（ルート）
- 子（ブランチA）
- 孫（リーフ1）
- 子（ブランチB）
この構造は、整理整頓が得意な人間にとって非常に直感的で、「どこに何があるか」が迷子になりにくいという強みがある。
「多対多」の悲劇：君のデータはどこにいる？
さて、ここからが本題だ。なぜ階層型が「過去の遺物」になり、現代のDBMS（RDBなど）に取って代わられたのか。それは「多対多の関係」に直面したとき、システムが悲鳴を上げるからだ。
想像してほしい。君が「学校の成績管理システム」を作っているとしよう。
- 「生徒」という階層がある。
- 「授業」という階層もある。
ある生徒（Aくん）は、複数の授業（数学、物理、化学）を受けているよね。逆に、一つの授業には複数の生徒が参加している。
これが「多対多」の関係だ。
階層型DBMSは、一本の木しか許さない「一夫一婦制」のような世界なんだ。だから、「生徒」を親にすると、授業データは生徒の数だけコピーしてぶら下げなければならない。逆に「授業」を親にすると、今度は生徒データが授業の数だけコピーされる。
もしデータをコピーし続けたらどうなるか？
1. データの不整合（悪夢の始まり）：
Aくんの住所が変わったとしよう。もしAくんのデータが「数学のクラス」と「物理のクラス」の両方にコピーされていたら？ 両方を修正し忘れると、システムの中で「Aくんは別の場所に住んでいることになっている」という矛盾が起きる。
2. ストレージの無駄遣い：
昔はメモリもストレージも高価だった。同じ名前や住所を何十回も書き込むなんて、エンジニアにとっては罪に近い行為だったんだ。
日常で例えるなら「教科書の貸し出し」
君が図書館の司書だと思ってくれ。
「数学の教科書」を棚に置くとき、借りている生徒の名前をわざわざ教科書の表紙に書き込んでいくとする。もしその生徒が別の教科書も借りていたら、また別の場所で同じ生徒の名前を書き込むことになるよね。
もしその生徒が引っ越して連絡先が変わったら？ 全ての教科書の表紙を追いかけて書き直さないといけない。これが階層型DBMSで「多対多」を表現するときの苦しみなんだ。
ここをクリアすれば、君はもう基本をマスターしたも同然だ
階層型DBMSの弱点は、「柔軟な関係性を表現しようとすると、データが分裂（重複）してしまうこと」にある。
- 階層型の勝ちパターン：親・子関係が明確なもの（組織図、フォルダ構造、部品表など）。
- 階層型の負けパターン：複雑に絡み合う人間関係や、商品と購入履歴のような多対多の関係。
現代のRDBは、この「多対多」を解消するために「テーブルを分け、IDという糸で結びつける」という革命を起こした。でもね、階層型という「データの親子関係」という概念そのものは、今もJSONやXML、そしてオブジェクト指向プログラミングの中に生き続けているんだ。
—
今日のまとめ
- 階層型はツリー構造：シンプルで美しいが、融通が利かない。
- 多対多は鬼門：無理に階層に押し込めようとすると、データが重複してシステムが崩壊する。
- 歴史を知ることは武器になる：なぜ今の技術がその形をしているのか、その「理由（痛み）」を知ることで、君は単なるコーダーから「アーキテクト」へ一歩近づけるはずだ。
どうだい、階層型の持つ「美しさと脆さ」が少しは伝わったかな？
もし次に、複雑なデータ構造に頭を抱えることがあったら、今日のこの話を思い出してほしい。その時、君はきっと、より良い設計への道筋を見つけられるはずだよ。
またいつでも相談してくれ。エンジニアの冒険は、まだ始まったばかりだ。
コメント