【実務・中級編】 ポインタの種類と実装 – 階層型DBMS

はじめに：なぜ今、階層型DBMSのポインタ設計を極めるのか

「RDBのSQLで`JOIN`を書けばデータはつながる」――そう思っている世代のエンジニアに、一度問いかけたい。
「そのデータ結合は、物理ディスクのどのバイト位置を指し、何回のポインタトラバーサルで完了しているか？」 と。

金融の勘定系や航空予約システムなど、ミリ秒単位のレスポンスと絶え間ない超高スループットが求められるミッションクリティカルの極致では、今なお階層型DBMS（IBM IMS DBなど）がシステムの中核を担っている。その圧倒的な速度の秘密は、クエリエンジンによる論理演算ではなく、「セグメント間に張り巡らされた物理ポインタ（Direct Address / RBA: Relative Byte Address）を直接辿る」 という究極の物理アーキテクチャにある。

階層型DBMSにおけるDDL（DBD: Database Description）で指定する`PTR=`（ポインタ定義）パラメータのたった一言は、ディスクリートなデータ構造そのものを決定づける。ポインタの選択を誤れば、バッチ処理の所要時間が10分から8時間に膨れ上がり、データベースのポインタ壊れ（Pointer Disruption）という悪夢を引き起こす。

本稿では、テクニカルリードの視点から、階層型DBMSにおけるポインタ構造のすべてを解剖し、堅牢かつ極限までチューニングされたデータベース設計の技法を伝授する。

—

1. セグメント結合を支える「物理ポインタ」のメカニズム

階層型DBMSにおけるポインタは、セグメントのプレフィックス（ヘッダー領域）に直接格納される4バイト（または8バイト）の相対バイトアドレス（RBA）だ。インデックスを介さず、メモリやIOブロック上のアドレスを直撃する。

ポインタは大きく分けて「物理ポインタ」と「論理ポインタ」に分類される。まずは基盤となる物理ポインタの3大要素から解剖しよう。

[ Root Segment: 顧客 ]
│ │
│ └──────────────────────┐ (Physical Child: PC)
▼ ▼
[ Segment: 注文 A ] ──────► [ Segment: 注文 B ] (Physical Twin: PT)
│ (Physical Parent: PP)
▼
[ Root Segment: 顧客 ]

(1) 物理兄弟ポインタ (Physical Twin Pointer: PT / PTB)

同一の親を持つ、同一セグメントタイプのリストを結ぶポインタだ。

• PT (Physical Twin Forward): 次の兄弟セグメントのアドレスを指す。単方向リスト構造。
• PTB (Physical Twin Backward): 前の兄弟セグメントのアドレスも指す。双方向リスト構造。

(2) 物理子ポインタ (Physical Child Pointer: PC / PCB)

親セグメントから、その直下にある子セグメント（最初および最後）へ降りるためのポインタだ。

• First Child Pointer (PC): 長男（最初のセグメント）を指す。
• Last Child Pointer (PCB): 末っ子（最後のセグメント）を指す。

(3) 物理親ポインタ (Physical Parent Pointer: PP)

子セグメントから直近の物理親セグメントへ逆引きするためのポインタだ。
通常、単なるツリー下降では不要に見えるが、全件走査（Scan）からの復帰や、後述する論理関係（Logical Relationship）構築時のルート到達において決定的な役割を果たす。

—

2. N:M関係を打ち破る「論理ポインタ (Logical Pointer)」

階層型データ構造の最大の弱点は「1つの子は1つの親しか持てない（1:N木構造）」点にある。これを破り、実質的なN:M（多対多）リレーショナル構造を階層型で実現する秘技が「論理関係」であり、それを支えるのが各種の論理ポインタだ。

【物理ツリー 1】 【物理ツリー 2】
[ 注文セグメント ] [ 商品マスター ]
│ ▲
▼ │ (Logical Parent Pointer: LP)
[ 注文明細セグメント ] ──────────┘
(Logical Child)

• LP (Logical Parent Pointer): 論理子セグメントから、別ツリーにある「論理親セグメント」を直接指し示すポインタ。
• LT / LTB (Logical Twin Forward / Backward Pointer): 同一の論理親に紐づく「論理子」同士を結ぶポインタ。
• LPC / LCP (Logical Child First / Last Pointer): 論理親から、最初/最後の「論理子」を指し下ろすポインタ。

この論理ポインタにより、アプリケーションからは「注文ツリーの下に商品情報がぶら下がっている」ようにも、「商品ツリーの下に購入された注文一覧がぶら下がっている」ようにも見せることができる。設計者は、この物理アドレスの交差点（Cross-Link）を完璧に制御しなければならない。

—

3. DDL（DBD定義）によるポインタ構造の実装仕様

実際の開発で使われるIMS DBD（Database Description）のコード例をもとに、ポインタがどう定義され、物理構造にどうマッピングされるかを検証する。

以下のコードは、「顧客（Root）― 注文（Child）― 明細（Logical Child）」 の階層構造を定義したDDLの抜粋だ。

• DATABASE DESCRIPTION (DBD) – POINTER CONFIGURATION EXAMPLE

DBD NAME=SALEDB, ACCESS=(HDAM,VSAM), OSAM, RMNAME=(DFSHDC40,1,1000)

• — ROOT SEGMENT: CUSTOMER —

SEGM NAME=CUST, BYTES=150, PTR=TWIN
FIELD NAME=(CUSTID,SEQ,U), BYTES=10, START=1, TYPE=C

• — CHILD SEGMENT: ORDER (HIGH FREQUENCY INSERT/DELETE) —
• PTR=(TWINBWD, DBLE)
• -> Physical Twin Backward + Physical Child Double (First & Last)

SEGM NAME=ORDER, PARENT=CUST, BYTES=200, X
PTR=(TWINBWD, DBLE)
FIELD NAME=(ORDNO,SEQ,U), BYTES=12, START=1, TYPE=C

• — LOGICAL CHILD SEGMENT: LINEITEM —
• PTR=(TWIN, LPARNT)
• -> Physical Twin Forward + Logical Parent Pointer

SEGM NAME=LINEITEM, BYTES=80, X
PARENT=((ORDER,SNGL),(PRODDB,PRODSEG,VIRTUAL)), X
PTR=(TWIN, LPARNT)
FIELD NAME=(ITEMNO,SEQ,U), BYTES=4, START=1, TYPE=C

DBDGEN
FINISH
END

DDL設定の解剖と意味

1. `SEGM NAME=ORDER, PTR=(TWINBWD, DBLE)`

• `TWINBWD`: ORDERセグメントのプレフィックスにPT（Forward）とPTB（Backward）の2つのポインタ（計8バイト）を確保する。これにより、任意のORDERセグメントの削除時、前後のポインタを即座につなぎ替えることが可能になる。
• `DBLE` (Double Child): 親であるCUSTから見たORDERへのポインタとして、First Child (PC) と Last Child (PCB) の2つ（計8バイト）を持たせる。

2. `SEGM NAME=LINEITEM, PTR=(TWIN, LPARNT)`

• `LPARNT`: 別データベース `PRODDB` の `PRODSEG` を指すLP（Logical Parent Pointer: 4バイト）をプレフィックスに組み込む。これにより、`LINEITEM` を読んだ瞬間にI/Oオーバーヘッド最小で `PRODSEG`（商品情報）へジャンプできる。

—

4. テクニカルリードが伝授する「ポインタ設計パターン」とパフォーマンスの罠

設計レビューで「デフォルト設定で通しました」という言い訳は許されない。ポインタ構造の選択は、アプリケーションのアクセスパターンと100%合致していなければならない。

パターン1：高頻度「削除（Delete）」が発生するセグメントには `TWINBWD` が絶対条件

• アンチパターン: `PTR=TWIN`（単方向ポインタ）のまま、日中で大量のセグメント削除を行う。
• 何が起きるか: 単方向リストの途中要素を削除する場合、DBMSは前方のポインタを更新するために、親からそのセグメントに至るすべてのツリーを先頭から順次走査（Scan）しなければならない。1件削除するたびに大量のランダムReadが発生し、バッチが死ぬ。
• 解法: 削除が発生するセグメントには必ず `TWINBWD`（双方向ポインタ）を定義せよ。自分自身が「前のポインタ」を持っているため、O(1) の計算量でポインタの付け替えが完了する。

パターン2：時系列ログ・追加専用セグメントには `DBLE`（First + Last Pointer）を適用せよ

• アンチパターン: 1つの親に数千件の履歴データ（Child）がぶら下がる構造で、デフォルトの `SNGL`（First Childのみ）を使用する。
• 何が起きるか: 新規履歴を「末尾に追加（Insert Last）」しようとするたびに、DBMSはFirst ChildからPTポインタを数千回辿って末尾を探す（O(N)のI/O）。
• 解法: `PTR=DBLE`（または `PTR=PAIRED` 等）を指定し、親に Last Child Pointer を持たせよ。直撃で末尾アドレスを取得し、即座に挿入（O(1)）が可能になる。

[ Single Pointer (SNGL) の悲劇 ]
Parent ──► Child 1 ──► Child 2 ──► … ──► Child 9999 ──► (新規挿入位置)
(9999回のポインタトラバーサルが発生)

[ Double Pointer (DBLE) の極致 ]
Parent ──────┬───────────────────────────────► Child 9999 ──► (新規挿入位置)
└─► Child 1 (直接アクセス)

パターン3：ポインタチェインの断片化（Fragmentation）と物理レイアウト

どれほど完璧なポインタ設計を行っても、セグメントの挿入・更新・削除が繰り返されると、ポインタが指す先が物理的に離れたディスクブロックに散逸する。これがポインタの断片化だ。

• 症状: アプリケーションはポインタを1つ辿るたびに、別ブロックへのランダムディスクI/Oを余儀なくされ、CPU使用率は低いのにWait時間だけが増大する。
• 対策:

1. DDL設計時に `BYTES` 長とブロックサイズ（`BLOCK` / `SIZE`）の比率を精密に計算し、1つのルートとその主要な子は可能な限り同一ブロック（DB RECORD）内に収まるレイアウトにする。
2. 定期的な Reorg（データベース再構成機能） の実行パイプラインを運用設計に組み込む。Reorgにより、散らかったポインタチェインが物理的に隣接するアドレスへ再配置（Unload/Reload）され、パフォーマンスが劇的に回復する。

—

まとめ：ポインタの1バイトに魂を込めよ

階層型DBMSにおけるポインタ定義は、単なる「データ形式の指定」ではない。それは「ハードウェアのメモリとストレージ上で、CPUにどのようにデータを走査させるか」という物理命令そのものだ。

• 兄弟走査の頻度、挿入・削除のパターンをプロファイルしたか？
• 不要なポインタを定義して、セグメント・プレフィックスのオーバーヘッド（領域の無駄遣い）を発生させていないか？
• 逆に、数バイトを惜しんだために、バッチ処理でO(N)の走査地獄を発生させていないか？

DDLを書くときは、頭の中に物理ディスクのバイト配列を浮かべよ。1つの `PTR=` パラメータに魂を込め、極限のパフォーマンスを叩き出す設計を行ってほしい。