【入門編】論理アクセスパス – 階層型DBMS

こんにちは！データベースの世界へようこそ。チーフアーキテクトの私です。

今日は、少しレトロでありながら、現代のデータベースの基礎が詰まった「階層型DBMS（データベース管理システム）」についてお話しします。

「階層型って言われても、なんだか難しそう……」
そんな風に構えなくて大丈夫ですよ。ここをクリアすれば、データが裏側でどうやって繋がっているのか、その本質がバッチリマスターできますよ！

それでは、身近な例えから優しく紐解いていきましょう。

—

現代の主流であるリレーショナルDBMS（表形式のやつですね）とは違い、階層型DBMSは「家族の家系図」や「会社の組織図」のように、データがピラミッド型にカチッと結ばれているのが特徴です。

例えば、ある会社の本社組織を思い浮かべてみてください。

社長（親）がいなければ、その下の部門（子）は存在しません。開発部（親）がいなければ、その中にいるエンジニアたち（子）もぶら下がれませんよね。
この「1対多（親から子へ枝分かれする）」のガッチリとした上下関係を、そのままコンピュータの記憶領域に再現したのが階層型DBMSです。

—

さて、本題の「論理アクセスパス」と、データベースエンジンが裏側でやっている「物理アドレスの解決プロセス」についてです。

エンジニアが「開発部に所属する、新人エンジニアのデータが欲しい！」とデータベースにお願い（論理的なアクセス）を出すと、エンジンは裏側でどう動いているでしょうか？

日常の買い物で例えてみましょう。

1. 【論理的な指示】
あなた：「ねえ、A本店の、2階の棚にある、青い箱を取ってきて！」
2. 【物理アドレスの解決】
お手伝いロボット（データベースエンジン）の頭の中：

このように、私たちが「どのデータの集まりから、どの枝をたどって、このデータが欲しい」という論理的な関係（論理アクセスパス）を指定したとき、データベースエンジンは裏側で、ハードディスクのどこにそのデータがあるのかを示す「住所（物理アドレス）」を必死に逆引き・解決しているのです。

—

階層型DBMSでは、親から子へ、子から次の兄弟へと、データを繋ぐために「ポインタ（矢印・メモのようなもの）」という仕組みを大量に使います。

ここで、アーキテクトとして少し踏み込んだ話をしましょう。
このポインタを何重にもたどっていく構造（ポインタの多重参照）には、性能面で大きな特徴があります。

親から子へのパスが最初からガッチリ固定されているため、迷う余地がありません。決められた矢印をスルスルと辿っていくだけなので、データ構造が頭に入っていれば、目的のデータに一瞬でたどり着けます。

しかし、ここに「罠」があります。
もし、組織が複雑化して、「開発部の社員だけど、総務のプロジェクトも手伝っている」といった横の繋がり（多重継承やネットワーク的な関係）を無理やり階層型で表現しようとするとどうなるでしょう？

ポインタが複雑に絡み合い、

という多重参照の迷宮にエンジンの足を取られてしまいます。

これが、ポインタの多重参照が引き起こすパフォーマンスの悪化です。「あっちの道行き、こっちの裏道を通って……」とやっているうちに、データベースエンジンは息切れを起こし、CPUのパワーを大量に消費してしまうのです。

—

いかがでしたでしょうか？
古い技術に見えても、データの「繋がり」をどう辿るかという本質は、最新のグラフデータベースやクラウド時代のアーキテクチャにも脈々と受け継がれています。

ここさえ押さえておけば、どんなに複雑なデータベース構造に出会っても、裏側でエンジンがどう汗をかいているのかが手に取るようにわかるはずです。
それではまた、次のアーキテクチャ談義でお会いしましょう！