階層型DBMSの深層：物理兄弟順方向／逆方向ポインタが導く極限のシーク最適化
おい、そこの設計レビューの途中だが、ちょっと手を止めて画面を見てくれ。
お前たちが今組み上げようとしているそのスキーマ定義、本当に「現場の泥臭いI/O負荷」に耐えうる代物か？ リレーショナルデータベース（RDB）の美しい正規化理論に毒された脳ミソのまま、高スループットが要求される基幹システムのバッチやオンラインを設計すると、本番稼働の初日に必ず痛い目を見る。
特に、IMS（Information Management System）に代表される階層型DBMSにおいて、データ構造の根幹をなす「ポインタ」の選択を誤ることは、自らシステムに爆弾を抱え込むと同義だ。
今回は、階層型DBMSのDDL（データ定義言語）および内部構造における「物理兄弟順方向ポインタ（Forward Physical Twin Pointer）」と「物理兄弟逆方向ポインタ（Backward Physical Twin Pointer）」に焦点を絞り、なぜこれらがプロのエンジニアによって厳密に設計されなければならないのか、その極限の知見を授けよう。
—
1. なぜ「双方向」なのか？：ポインタチェーンの物理的現実
階層型DBMSの基本概念をおさらいする時間はない。お前たちはすでに、セグメント（Segment）が親子関係（Parent-Child）のツリー構造をなし、同一の親を持つセグメント同士が「兄弟（Twin）」として物理的に連鎖していることを知っているはずだ。
初期の簡易的な階層型モデルでは、兄弟セグメントは片方向、すなわち「順方向（Forward）」のみのポインタで結ばれていた。親セグメントから最初の子へ、そして最初の子から次の兄弟へ……という単一の鎖だ。
だが、現場のエンジニアなら想像がつくだろう。「順方向ポインタだけでは、後ろに戻れない」という致命的な制約がある。
片方向ポインタの呪縛
兄弟セグメントの数が数千件に及ぶ巨大なセグメントオカランスにおいて、順方向ポインタだけで特定の後続レコードや末尾のレコードを処理しようとした場合、DBMSは常に親セグメントまで遡り、そこから先頭を起点としてO(N)の順次スキャン（Sequential Scan）を強いられる。
ここで登場するのが、物理兄弟逆方向ポインタ（Backward Physical Twin Pointer: PTB）である。順方向ポインタ（PTF: Physical Twin Forward）とペアで使用することで、同一親内の兄弟間を双方向に走査することが可能になる。
—
2. スキーマ定義（DDL）におけるポインタ指定の実践
実際の物理データベース定義（DBD: Database Definition）におけるポインタ指定がどう記述されるか、コードレビューのつもりで見てほしい。
——————————————————————
- データベース記述 (DBD) の例：物理兄弟双方向ポインタの定義
——————————————————————
DBD NAME=CUSTDB,ACCESS=HDAM,RMNAME=(DFSHDC40,100,500,2048)
- ルートセグメント：顧客マスタ
SEGM NAME=CUSTSEG,PARENT=0,BYTES=120,
PTR=T T = Twin (順方向ポインタのみ)
FIELD NAME=(CUSTID,SEQ,U),BYTES=10,START=1
- 子セグメント：受注トランザクション（双方向ポインタの指定）
SEgm NAME=ORDSEG,PARENT=CUSTSEG,BYTES=250,
PTR=(TB,L) TB = Twin Backward / L = Last Pointer
FIELD NAME=(ORDDATE,SEQ,M),BYTES=8,START=1
——————————————————————
コードの急所解説：`PTR=(TB,L)` の意味
この `PTR=(TB,L)` という指定こそが、今回のキモだ。
1. `TB` (Twin Backward):
順方向ポインタ（PTF）に加え、逆方向ポインタ（PTB）の生成をDBMSに指示する。これにより、ある兄弟セグメントから「直前の兄弟セグメント」へダイレクトに物理アドレスを辿ることが可能になる。
2. `L` (Last Pointer):
親セグメントのprefix（接頭辞）部に、最後尾の兄弟セグメントへのポインタを保持させるオプションだ。これを併用することで、末尾への直行アクセスがO(1)で実現する。
—
3. 順次スキャンと逆順スキャンのパフォーマンス・ダイナミクス
では、これらのポインタが実際のクエリ（あるいはそれに類するナビゲーショナルなアクセス）において、どのようにパフォーマンスを変えるのか。ロジカルに解説しよう。
パターンA：順方向ポインタ（PTF）のみの場合
- 動作: 先頭から目的のデータまでポインタを辿る。
- 逆順アクセス時の悲劇: 逆順（例えば、最新の受注データから古いデータへ遡る処理）が必要な場合、DBMSはわざわざ末尾まで順方向で走査して位置を特定するか、ワークエリアに全件展開してメモリ上で逆順ソートするしかない。I/OとCPUの無駄遣いだ。
パターンB：物理兄弟双方向ポインタ（PTF + PTB）の導入
- 動作:
- 順方向スキャン：`Current -> PTF -> Next` （O(1) / step）
- 逆順スキャン：`Current -> PTB -> Previous` （O(1) / step）
- 実務上のメリット:
「直近のトランザクションから過去へ5件分だけ逆順にチェックし、条件に合致したら即座に処理を打ち切る」といったプレディクティブな処理（早期脱出パターン）において、無駄な前方走査が完全に消滅する。バッチ処理の実行時間を数分単位で削り取ることが可能だ。
—
4. チーフアーキテクトが直伝する「設計の罠」とベストプラクティス
さて、ここまで聞くと「じゃあ、すべてのセグメントで `PTR=(TB,L)` を標準装備にすれば完璧だな！」と思うかもしれない。
……甘い。素人考えで全部のセグメントに双方向ポインタとラストポインタを張るな。
ここで、プロのエンジニアとしての設計判断基準を叩き込む。以下のトレードオフを忘れるな。
1. 更新コスト（I/Oオーバーヘッド）の代償
ポインタは「無料」ではない。セグメントの挿入（Insert）および削除（Delete）時、双方向ポインタ（PTF/PTB）が存在する場合、DBMSは前後のセグメントのポインタ値を書き換える必要がある。
- 片方向の場合：挿入時に「直前のセグメント」のPTFを書き換えるだけで済む。
- 双方向の場合：挿入時に「直前のセグメントのPTF」に加え、「直後のセグメントのPTB」、さらには必要に応じて「親のラストポインタ」まで、最大3箇所以上の物理ブロックの書き換え（あるいはダーティ化）が発生する。
- 結論: 更新頻度（OLTPの書き込み）が極めて高く、かつ逆順スキャンをほとんど行わないセグメントに `TB` を定義するのは、自分で自分の首を絞める行為だ。
2. ストレージ（プレフィックス）の肥大化
各セグメントの先頭には、ポインタを格納するためのプレフィックス領域が存在する。ポインタが増えれば増えほど、実データあたりの物理フットプリントが増大し、1物理ブロック（BLKSZ）に格納できるセグメントオカランスの数が減る。結果として、チェーンを辿るための物理I/Oの回数そのものが増えるという本末転倒な事態を招く。
—
5. まとめ：お前たちが取るべきアクション
今日のレビューの結論として、スキーマ設計におけるポインタ選定の指針をこう定義する。
1. 基本方針は「保守的」に始めよ
デフォルトは片方向（`PTR=T`）とし、パフォーマンス要件（特に逆順スキャンや末尾アクセスの頻度）が計測・証明されたセグメントにのみ、限定的に `TB` や `L` を導入せよ。
2. アクセスパターンの非対称性を見抜け
「このセグメントは圧倒的に最新データからの逆順参照が多い」という業務特性（ログ、履歴、時系列トランザクション）が明確な場合のみ、迷わず `PTR=(TB,L)` を採用しろ。その代わり、挿入時のコスト増はインフラ側（バッファプールチューニング等）で受けて立つ覚悟を持て。
データベースの物理構造を制する者が、システム全体のパフォーマンスを制する。
甘ったれた設計はコードレビューの段階で俺がすべて弾き返す。もう一度、自分たちの書いたDDLを隅々まで見直してこい。以上だ。
コメント