【入門編】論理データベースの制限事項 – 階層型DBMS

こんにちは！データベースの世界へようこそ。
今日は、少しタイムスリップした気分で、データベースの歴史の原点であり、現代のシステム設計のルーツでもある「階層型DBMS（データ管理システム）」についてお話ししますね。

「古い技術でしょ？」なんて侮ってはいけません。ここで学ぶ『制限事項』の考え方は、実は現代のクラウドアーキテクチャやNoSQLの設計思想にも深く通じる、エンジニアとして知っておくべき「構造の美学」が詰まっているんです。

今回は、専門用語をできるだけ使わずに、日常の身近な例えを交えながら、優しく、そして本質的なところまで紐解いていきましょう。
ここをクリアすれば、階層型DBMSの基本はバッチリマスターできますよ！

—

1. 階層型DBMSって、なにをイメージすればいい？

現代の主流であるリレーショナルデータベース（RDB）が「表（エクセルみたいなもの）の組み合わせ」だとすれば、階層型DBMSは「家族の家系図」や「会社の組織図」そのものです。

一番上に「社長（親）」がいて、その下に「部長（子）」がいて、さらにその下に「課長（孫）」がいる……というように、データが必ず「1対多（一本の太い幹から枝分かれする）」のピラミッド構造で綺麗に整理されています。

日常の例え：会社の組織図で考えてみよう

例えば、ある会社の社員名簿を作るとします。

親（トップ）： 営業本部
子（その下）： 第一営業部、第二営業部
孫（その下）： 第一課、第二課……

この世界では、「子は必ずたった一人の親を持つ」という厳格なルールがあります。「第一営業部は、営業本部の下にしか属せない」のと同じです。他の部署が「うちでも第一営業部のデータが欲しいな」と思っても、この世界ではなかなか自由にシェアできません。これが、のちに大きな特徴（制限）になってきます。

—

2. システム設計の壁！「論理関係の深さ」という制限

階層型DBMSでシステムを設計するとき、一番最初に直面するのが「深さ（ツリーの階層の限界）」という物理的制約です。

家系図を思い出してください。自分から見て、親、祖父母、曾祖父母……と遡っていくと、いつかは果てにたどり着きますよね。階層型DBMSでも、データがつながる「深さ」にはシステムごとに限界（マックスここまで！）が決められていました。

なぜ「深さ」に制限があるの？

コンピュータのメモリやディスクの仕組み上、データを奥へ奥へと探していく（これを専門用語で「ポインタを辿る」と言います）とき、階層があまりに深すぎると、一番下にあるデータにたどり着くまでに膨大な時間がかかってしまいます。

浅い構造： 処理が爆速ですが、複雑な現実の社会を表現しきれません。
深い構造： いろんな要素をきれいに分類できますが、一番下のデータを探すのに苦労します。

「現実の世の中はそんなに単純じゃない！社員が複数のプロジェクトにまたがって参加することだってあるよ！」と思いませんでしたか？そう、まさにその通りなんです。この「1人の親しか持てない」「深さに限界がある」という制限を突破するために、のちにリレーショナルデータベースが生まれることになります。歴史のロマンを感じますよね。

—

3. ポインタの最大数：枝分かれの限界

もう一つの大きな制限が、「1つの親から生やせる子どもの数（ポインタの最大数）」です。

ポインタというのは、いわば「次のデータはあっちだよ！」と指し示す矢印（看板）のようなもの。階層型DBMSの内部では、この矢印を物理的にメモリやディスク上に配置して、データ同士をつないでいます。

日常の例え：タコの足は何本まで？

例えば、「親」である一つの部署に、何人の「子（社員）」をぶら下げられるでしょうか。
もしシステムが「1つの親につき、子どものポインタは最大10個までです」と決めていたらどうなるでしょう？

11人目の新入社員が入ってきたとき、その部署の直下にはもうデータを繋げなくなってしまいます。「あれ？満員電車みたいにギュウギュウで、もう新しい矢印が入らないぞ！」という状態ですね。

実務の世界では、この「物理的に割り当てられた矢印の数（ポインタの容量）」を計算し尽くしてスキーマ（データの設計図）を書く必要がありました。少しでも見積もりが狂うと、システムが動かなくなるというシビアな世界だったのです。

—

まとめ：制限を知ることは、全体の本質を知ること

お疲れ様でした！ここまで、階層型DBMSの「論理的な深さ」や「ポインタの制限」について見てきました。

階層型DBMSの基本： 家系図や組織図のように、上から下へ綺麗にデータがつながる。
制限の正体： 「子は親を1人しか持てない」「深さや枝分かれ（ポインタ）の数に物理的な限界がある」。

一見すると「不便な制限だなぁ」と感じるかもしれません。しかし、「あえて構造を制限し、決められた道筋（ポインタ）を高速に辿る」という割り切りがあったからこそ、当時の限られたコンピュータの性能でも、驚異的なスピードでデータを処理することができたのです。

この「構造化の美学と制約のトレードオフ」は、現代のマイクロサービスやデータベース設計においても全く色褪せない、エンジニアにとって最も大切な思考の土台となります。

この基本さえ押さえておけば、どんなに複雑な新しいデータベース技術に出会っても、その本質をスッと見抜くことができますよ。
さあ、この調子で次のステップへ進みましょう！