【入門編】ポインタオーバーヘッド – 階層型DBMS

こんにちは！データベースの世界へようこそ。
今日は、少しレトロでありながら、データベースの「超・基本」がぎっしり詰まった「階層型DBMS」についてお話ししますね。

「階層型」と言われてもピンとこないかもしれませんが、安心してください。
今回は、データベースが裏側でこっそり抱えている「ポインタのオーバーヘッド（おまけの容量）」という、ちょっとディープだけどめちゃくちゃ面白いテーマを、日常の例えを交えて優しく解きほぐしていきます。

ここをクリアすれば、データベースがメモリやディスク容量をどうやってやりくりしているのか、その本質がバッチリマスターできますよ！

—

1. 階層型DBMSって、なに？（身近な例えで理解する）

現代の主流である関係型DBMS（表形式のデータベース）とは違い、階層型DBMSは「家族の家系図」や「会社の組織図」のように、データをピラミッド状（親子関係）でつなぐ仕組みです。

例えば、あなたのお財布の中にある「ポイントカードのアプリ」を想像してください。

親（トップ）のデータ： あなたの会員情報（名前、住所など）
子（その下）のデータ： 今まで貯めたポイントの履歴や、保有しているクーポン

親データの「下」に、複数の子データがぶら下がっているイメージですね。
この「親子」をつなぐために、階層型DBMSは「ポインタ（矢印）」という目に見えない鎖をデータ同士につけています。

—

2. ポインタって、データベース界の「付箋と糸」

さて、今回の主役である「ポインタ」について深掘りしましょう。

ポインタとは、一言で言うと「次のデータがどこにあるのかを指し示す住所（アドレス）」のことです。
巨大な倉庫（ストレージ）の中に、膨大なダンボール箱（データ）が積み上げられているとします。
「親のダンボール箱」のフタの裏に、「うちの子の箱は、倉庫の3列目、上から5番目にあるよ！」と書かれたメモ用紙が貼ってありますよね。これがポインタです。

このポインタがあるおかげで、私たちは親子関係を瞬時にたどることができます。

ポインタの「おまけ」がもたらす悲劇（オーバーヘッド）

ここで問題になるのが、今回のテーマである「ポインタオーバーヘッド」です。

オーバーヘッドとは、簡単に言えば「本来やりたいこと以外にかかってしまう余分なコスト（容量や手間）」のこと。

データ本体： 会員の名前（例：山田太郎）＝ 10バイト
ポインタ（住所を示すメモ）： 次のデータへのアドレス＝ 4バイト（または8バイト）

データ本体がたったの10バイトなのに、あちこちをつなぐためのポインタが「あっちに1つ、こっちに1つ」と増えていくとどうなるでしょう？
なんと、データベース全体の容量の半分以上が、データ本体ではなく「ポインタ（ただの住所メモ）」で埋め尽くされてしまうなんてことが起きるのです。

これを、日常の買い物に例えてみましょう。

> 【例え話：過剰包装のお菓子】
> 小さなチョコレート（データ本体）が1個だけ欲しいのに、それを包むために頑丈な木箱に入れられ、さらにそれを持ち運ぶための大きな取っ手（ポインタ）がいくつも取り付けられている状態を想像してください。
> カバンの中身（ストレージ）は、チョコレートよりも「取っ手と木箱」でパンパンになってしまいますよね。これがポインタオーバーヘッドの正体です。

—

3. スキーマ定義（DDL）で見てみるポインタの影

実際に、階層型DBMSの設計図（スキーマ定義言語 / DDL）のイメージを見てみましょう。専門用語を省いて、概念だけをコード風に表現しますね。

— 親データ：顧客テーブル
DEFINE SEGMENT 顧客 (
顧客ID CHAR(5),
氏名 VARCHAR(20)
— ここには見えないけれど、「最初の子データ（注文）へのポインタ」が隠されています
);

— 子データ：注文テーブル
DEFINE SEGMENT 注文 (
注文ID CHAR(5),
商品名 VARCHAR(30),
金額 INT
— ここには、「親へのポインタ」「次の兄弟へのポインタ」が隠されています
);

この定義に従ってデータを100万件登録すると、DBMSは自動裏方作業として、すべてのレコードにポインタ（住所データ）を埋め込みます。

1つのレコードにつき、ポインタが平均3つあるとしましょう。
1ポインタが8バイトだとすると、1レコードあたり `3 × 8 = 24バイト` のおまけ容量が必要です。
それが100万件あれば、24メガバイト分もの「ただの矢印」のためにストレージが消費されることになります。

当時のエンジニアたちは、この限られたメモリやディスク容量をいかに節約するか、血のにじむような工夫をしていました。

—

4. チーフアーキテクトからのまとめ

階層型DBMSにおけるポインタオーバーヘッドは、「構造を分かりやすく、高速につなぐための必要経費」です。

メリット： ポインタをたどるだけで一瞬で親子関係のデータが取得できる（検索が爆速）。
デメリット： データ量に対して、ポインタが占める容量（オーバーヘッド）がバカにならないほど大きくなる。データの挿入や削除のたびに、ポインタの付け替え（メンテナンス）でデータベースが悲鳴を上げる。

現代のシステムでは、こうしたポインタの管理の手間や容量圧迫を解決するために、より柔軟な関係型DBMSやNoSQLが主流になりました。しかし、「データをどう配置し、どうやって迷子にならずに目的地（データ）にたどり着くか」というアーキテクチャの基本思想は、現代のどんな最先端データベースにも受け継がれています。

「ポインタという小さなメモ書きが、データベース全体のサイズと性能を握っている」――この感覚が掴めれば、あなたのエンジニアとしての視座はグッと深まっていますよ。

それでは、次回のデータベース探訪もお楽しみに！