やあ、よく来たね。データベースの世界へようこそ。
君は今、「階層型DBMS」という、ITの歴史の礎を築いた巨人たちの足跡に触れようとしている。現代のエンジニアの多くはSQL（リレーショナル型）しか知らないけれど、この「階層型」と、その対局にある「ネットワーク型」の本質を理解することは、システム設計における「データの持ち方の美学」を知ることに他ならない。
今日は、専門用語の辞書を閉じて、僕と一緒に「情報の整理術」の話をしよう。
—
1. 階層型DBMS：家系図のような「絶対的な支配」
階層型DBMSを理解する一番の近道は、「WindowsやMacのフォルダ構成」を想像することだ。
フォルダの中にフォルダがあり、その中にファイルがある。この構造には、たった一つの鉄則がある。「親は一つ。子は親に従う」ということだ。
- 例えるなら： 「大企業の人事組織図」
- 社長の下に部長がいて、その下に課長がいて、その下に社員がいる。
- 社員は、必ず一人の上司の配下にしか所属できないよね。
これが階層型DBMSの基本だ。「親子関係」が明確で、アクセス速度が驚くほど速い。なぜなら、辿るべき道筋（パス）が一本道だからだ。
[社長]
└── [営業部長]
├── [東京営業課]
└── [大阪営業課]
※ 迷う余地がない。社長から東京営業課へ行くルートは一つしかない。これが階層型の強みであり、同時に「柔軟性の欠如」という弱点にもなる。
—
2. ネットワーク型（CODASYL）：網の目のような「社交界」
一方で、階層型の「親は一人」という制限に窮屈さを感じた当時の先人たちは、「ネットワーク型（CODASYL）」という仕組みを生み出した。
これは、「SNSの人間関係」に近い。
- 例えるなら： 「大学のサークルと学生の関係」
- 一人の学生（子）は、「テニスサークル」と「軽音サークル」の両方に所属できる。
- 一人の学生に対して、複数の親（サークル）が存在する。
階層型では、「学生」というデータを「テニスサークル」の下に置くか、「軽音サークル」の下に置くか、どちらか一つを選ばなければならなかった。しかし、ネットワーク型なら、網の目のようにデータを繋ぐことができるんだ。
[テニスサークル] ──┐
├─ [学生：佐藤さん]
[軽音サークル] ──┘
※ 佐藤さんは二人の親（所属先）を持っている。これが「多対多」の構造だ。
—
3. なぜ今、この比較が重要なのか？
「先生、じゃあネットワーク型の方が優秀なんじゃないですか？」と君は思うかもしれないね。確かに論理的にはそう見える。
しかし、現実はそう甘くない。「便利さ」は「複雑さ」の代償を払わなければならないんだ。
| 特徴 | 階層型 | ネットワーク型 |
| :— | :— | :— |
| 構造 | 木構造（ツリー） | 網構造（グラフ） |
| 繋がり | 1対多（シンプル） | 多対多（複雑） |
| 速さ | 爆速（道が一つ） | 複雑な検索は遅くなる傾向 |
| 管理 | 迷わない | 網の目が絡まりすぎて管理が困難 |
階層型は「規律」を重視し、ネットワーク型は「自由」を重視した。
階層型は「迷わない」けれど「窮屈」。ネットワーク型は「柔軟」だけれど「複雑すぎて、一度絡まると解くのが地獄」だったんだ。
—
4. 最後に：エンジニアとしての視点
僕がこの世界に入った頃、この二つのどちらを使うかで夜通し議論したものだよ。
今の君たちが使っているリレーショナルデータベース（SQL）は、この二つの長所をいいとこ取りしつつ、数学的な理論で「管理の複雑さ」を解決した、いわば「進化の到達点」なんだ。
でもね、「なぜリレーショナルが生まれたのか？」という問いの答えは、今日話した「階層型とネットワーク型の葛藤」の中にある。
「データの関係性は、木のように単純な方がいいのか？ それとも網のように複雑な方がいいのか？」
システムを設計する時、この問いに立ち返ってみてほしい。どんなに技術が進化しても、データの本質は「誰と誰が繋がっているか」というシンプルな関係性に集約されるからね。
さあ、これで君は階層型DBMSの「魂」に触れた。あとは、実際に古いシステムの構造図を眺めてみるといい。きっと、そこには設計者の「美学」が見えてくるはずだよ。
何か分からないことがあったら、いつでも聞きに来なさい。応援しているよ。
コメント