【入門編】データ独立性の限界 – 階層型DBMS

やあ、よく来たね。データベースの世界へようこそ。
今日は、現代のデータベース（RDB）の「ご先祖様」にあたる、階層型DBMSというちょっと頑固で、でも非常に興味深い技術について話をしよう。

「古い技術なんて学ぶ意味があるの？」と思うかもしれないね。だが、この構造を知ることは、今のデータベースがなぜあんなにも自由で柔軟なのかを理解するための「一番の近道」なんだ。

さあ、腰を下ろして、少しだけ歴史の旅に出ようか。

—

階層型DBMSを一言で言うと、「情報の家系図」だと思えばいい。

君が「会社」というデータを管理したいとする。そこには「部署」があり、その中に「社員」がいる。さらに、社員の下には「所有している備品」がぶら下がっている。

これを図にすると、ちょうど「親から子へ」と枝分かれしていく樹木のような形になるだろう？
この「親・子・孫」という固定された親子関係でデータを管理するのが階層型DBMSの正体だ。

この構造は非常にシンプルで、実は「読み取り」に関しては爆速なんだ。データが物理的に隣り合わせに並んでいるから、コンピュータが迷子にならずに一直線にデータを拾えるからね。

—

さて、ここからが本題だ。なぜ現代では階層型が主流ではなくなったのか。その理由は「構造変更の悪夢」にある。

想像してみてほしい。君が管理している「会社データ」の構造が、こんな風にガチガチに決まっているとする。

[部署] ─── [社員] ─── [備品]

ある日、上司がこう言った。「ねえ、今後は『備品』を特定の『社員』に紐づけるんじゃなくて、『部署』直属の管理にしたいんだ」と。

リレーショナルデータベース（今の主流）なら、テーブルの関連付けを変えるだけで済むことが多い。だが、階層型は「家系図の書き換え」を意味するんだ。

1. 物理的なデータの並び順をすべて修正する必要がある。
2. その構造を前提に書かれた「プログラム（アプリケーション）」をすべて書き直さないといけない。

これを「物理構造と論理構造が密結合している」と言う。
まるで、「家を増築するために、基礎から作り直さなきゃいけない」ようなものだ。これでは、ビジネスのスピードに追いつけないよね。

—

もう少し身近な例で説明しよう。

君が図書館の館長だと想像してくれ。本を「ジャンル」→「著者」→「タイトル」という順で棚に並べている。
もし、ある日「著者」という分類を廃止して、すべての本を「出版社」で管理したくなったらどうなる？

今の棚を全部空にして、本をすべて出し、出版社ごとに並べ直す必要があるよね。さらに、館内の案内表示（プログラム）もすべて作り直さなきゃいけない。

これが階層型DBMSの「限界」なんだ。「データにたどり着くルート（道筋）を、最初から決め打ちしておかなければならない」という制約が、変化を拒んでしまうんだよ。

—

階層型DBMSは、現代の柔軟なデータベースが「何と戦って、何を解決したのか」を教えてくれる貴重な反面教師だ。

今の君たちが使っているSQL（RDB）は、この「ルートの固定」という呪縛から解放されるために、「データをバラバラに保存して、必要な時に必要な分だけつなぎ合わせる」という賢い戦略をとっているんだ。

ここをクリアすれば、「なぜデータベースを正規化するのか」「なぜ柔軟なクエリが必要なのか」という本質的な問いへの答えが見えてくるはずだよ。

どうだい、少しはデータベースを見る目が変わったかな？
もし分からないことがあれば、いつでも聞いてくれ。エンジニアとしての旅は、まだ始まったばかりだからね。