【実務・中級編】物理子ポインタ (PC) – 階層型DBMS

物理子ポインタ（PC）の真実：なぜ今、我々は「階層型」の原点に立ち返るべきなのか

こんにちは。チーフアーキテクトの私だ。
今日のコードレビュー、あるいはアーキテクチャ設計レビューで、また君たちは「とりあえず全件JOIN」や「複雑なグラフDBの導入」で頭を悩ませていないか？

データ構造の歴史を紐解けば、我々は常に「関係性（リレーション）」をどう物理メモリ上に配置し、いかに高速にスキャンするかという戦いの歴史を歩んできた。リレーショナルデータベース（RDB）やNoSQL全盛の今であっても、基幹系システムの深部やメインフレームの領域、あるいは超高速なインメモリキャッシュの設計思想において、「階層型DBMS（Hierarchical DBMS）」の根幹技術は生き続けている。

今回は、その階層型DBMSの心臓部であり、すべてのポインタナビゲーションの源流である「物理子ポインタ（Physical Child Pointer: PC）」にスポットを当てる。
リファレンスを読むだけでは決して分からない、ハードウェアの物理特性を見据えた実務レベルの設計論を伝授しよう。

—

1. 物理子ポインタ（PC）とは何か：アーキテクチャの解剖

階層型DBMS（IBMのIMSなど）において、データはツリー構造（階層構造）で物理的に格納される。
親セグメント（Segment）と子セグメントの関係を物理的に結びつける最小にして最強の武器、それが物理子ポインタ（PC）だ。

RDBのように「外部キー（Foreign Key）を保持し、実行時にハッシュ結合やマージ結合で突合する」というアプローチとは根本的に異なる。PCは、「親セグメントのプレフィックス（接頭辞）領域に、最初の子セグメントが格納されている物理ディスク上のアドレス（または相対位置）を直接書き込んでおく」というアプローチをとる。

概念スキーマと物理配置のギャップ

論理的なツリー構造を考えてみよう。

[企業セグメント: 001]
└── [部署セグメント: 100] <── 親から最初の子への物理ポインタ（PC） └── [従業員セグメント: 5000] ディスク（あるいは連続した実メモリ空間）上において、このツリーがどう配置されるか。親セグメントの直後に最初の子セグメントがダイレクトに配置されるわけではない。データ更新の柔軟性を担保するため、各セグメントは独立したブロックに分かれて存在し得る。ここでPC（Physical Child Pointer）の出番だ。
親セグメントの制御ブロック（Prefix）の内部には、必ず最初の子を指すポインタスロットが存在する。

この「最初の子を指す」という一点突破の仕組みこそが、深さ優先探索（Depth-First Search）におけるオーバーヘッドを極限まで削ぎ落とす鍵となる。

—

2. DDLとスキーマ定義：物理ポインタの指定を読み解く

現代の我々が書くSQLのような宣言的言語とは異なり、階層型DBMSのDDL（DBD：Database Description）では、ポインタの振る舞いをハードウェアに近い粒度で静的に定義する。

以下は、仮想的な階層型スキーマ定義（DBD）の例だ。

— データベース定義のイメージ（IMS DBDGEN風）
DBD NAME=CORPDB, ACCESS=HIDAM
SEGM NAME=COMPANY, PARENT=0, BYTES=100
FIELD NAME=COMP_ID, SEQ, BYTES=4, START=1
SEGM NAME=DEPT, PARENT=COMPANY, BYTES=150
— ここで物理子ポインタ(PC)の方式を指定する
LCHILD NAME=(EMP,CORPDB), POINTER=SNGL, PTR=TWIN
FIELD NAME=DEPT_ID, SEQ, BYTES=4, START=1
SEGM NAME=EMP, PARENT=DEPT, BYTES=200
FIELD NAME=EMP_ID, SEQ, BYTES=5, START=1

チーフアーキテクトからのコードレビュー指摘

> 「おい、この `POINTER=SNGL` の指定、本当に意図通りか？」

`POINTER=SNGL`（Single Child Pointer）：親から最初の子へのポインタ（PC）のみを保持する。兄弟セグメントへのポインタを持たないため、メモリ節約にはなるが、2番目以降の子を探すときは先頭から順に辿る（Sequential Scan）必要がある。
もし子セグメントの数が数千件に及ぶ場合、このSNGL設計は致命的なレイテンシ（CPUバウンドなスキャン）を引き起こす。
子が多いことが分か双方向ツインポインタ（`PTR=TWIN`）や、最初と最後を指すポインタの併用など、アクセスパスのカーディナリティ（Cardinality）を見極めたポインタ戦略が不可欠だ。

—

3. 実務で直面するパフォーマンスの罠と堅牢な設計パターン

実務の現場で、ジュニアエンジニアがやりがちなミスと、それを回避するための設計パターンを共有しよう。

罠：親を更新した際の「ポインタ連鎖の破壊」

RDBであれば、親のIDが変わっても外部キー側をカスケード更新すれば済む話が多い。しかし、階層型DBMSにおける物理子ポインタ（PC）は、物理アドレスやダイレクトな位置情報に強く依存しているケースがある。

セグメントの挿入・削除・更新（ISR/DLT/REPL）が頻発する高負荷なトランザクションシステムにおいて、PCの再配線（Pointer Rewiring）が不適切だと、データ破損（Pointer dangling）や、ページ分割（Page Split）による激しいI/O競合を引き起こす。

堅牢な設計パターン：ポインタ・ストラクチャの最適化

1. アクセス頻度に基づくポインタ種別の選定

1対1、または1対少数の場合（子数が固定・少数）： `POINTER=SNGL` でミニマムに保ち、キャッシュ効率を最大化する。
1対多の場合（子数が変動・多数）： 物理双子ポインタ（Physical Twin Backward/Forward: PTF/PTB）を併用し、子探索のオーダーを $O(N)$ から $O(1)$ またはツリー特有の効率的なパスに落とし込む。

2. ストレージの断片化（Fragmentation）の予測管理

PCを辿るということは、ポインタが指す先が物理的に離れたブロック（エクステント）にある場合、ランダムI/Oの嵐が発生することを意味する。
定期的な再編成（Reorganization）ジョブを設計に組み込み、論理的に近いセグメントが物理的にも近接して配置されるよう、DBDの `RMNAME` やフリースペース（Free Space）のパラメータチューニングを怠るな。

—

4. まとめ：なぜこの知見が現代のエンジニアに必要なのか

「階層型DBMSなんてレガシーだ」と切り捨てるのは簡単だ。
しかし、考えてみてほしい。現代のインメモリDB、グラフデータベースのインデックス、さらにはCPUキャッシュのポインタ管理にいたるまで、「ある実体から、最も関係性の深い次の実体へダイレクトにジャンプする」というPC（物理子ポインタ）の思想は、高速化の究極の解として形を変えて生き続けている。

RDBのJOIN地獄に直面したとき、あるいはマイクロサービス間の複雑な参照整合性に頭を悩ませたとき、原点である「物理的なポインタによるパスの確立」という発想を持てるか否か。それが、凡百のエンジニアと、システムの本質を見抜く真のアーキテクトを分かつ境界線だ。

次の設計レビューでは、ただ「正規化されているか」を見るのではない。
「そのデータ構造の物理的なポインタの軌跡は、CPUキャッシュとディスクI/Oにどう優しく作用しているか」を語れるようになってくれたまえ。期待している。