【実務・中級編】インデックスポインタの種類 – 階層型DBMS

はじめに：リレーショナルな怠惰を捨て、ポインタの深淵へ

現代のシステム開発において、我々はRDBMSの「インデックス」や「外部キー」という抽象化された概念に甘やかされすぎています。SQLを1行書けば、裏側でRDBMSがよしなにB-Treeを辿り、データを結合してくれる。しかし、ミリ秒以下の極限の応答速度と、テラバイト級の超高頻度トランザクションを支える階層型DBMS（Hierarchical DBMS）の世界では、そのような「魔法」は存在しません。

階層型DBMSにおけるデータアクセスとレコード間の結合（関係性）の実態は、「生のポインタ（Pointer）」そのものです。

ポインタの設計を一歩誤れば、データベースの再編成（Reorganization）のたびにバッチ処理が何時間も停止し、最悪の場合はポインタの破損（Pointer Corruption）によってデータベース全体が沈黙します。

本稿では、階層型DBMSにおける関係表現の双璧である「物理的な直接ポインタ（Direct Pointer）」と「論理的なシンボリックポインタ（Symbolic Pointer）」のアーキテクチャを解剖し、現代のテックリードが設計レビューで示すべき「極限の使い分け」を伝授します。

—

1. 2つのポインタの構造的本質

階層型DBMS（例えばIBMのIMSなど）において、あるセグメント（レコード）から別のセグメントへのリンク、あるいは副索引（セカンダリ・インデックス）から実データへの参照は、以下のいずれかの方式で実装されます。

【直接ポインタ (Direct Pointer)】
[インデックス / 元セグメント] ——(直接 RBA を指す)——> [ターゲットセグメント]
(物理アドレス: 0x00A3F4)

【シンボリックポインタ (Symbolic Pointer)】
[インデックス / 元セグメント] ——(論理キーを保持)——> [サーチキーによる再検索] —> [ターゲットセグメント]
(Key: “EMP-10023”)

① 直接ポインタ（Direct Pointer / Physical Pointer）

直接ポインタは、ターゲットとなるセグメントが格納されているストレージ上の物理的な位置（多くはRBA: Relative Byte Address（相対バイトアドレス）や、ブロック番号＋スロット番号）を直接保持する方式です。

アクセス機構: メモリ上のアドレス、またはディスク上の物理位置をダイレクトにシークするため、インデックス参照からデータ取得までのI/Oオーバーヘッドは実質的に「ゼロ」です。
物理的特性: ターゲットセグメントがディスク上で1バイトでも移動した場合、このポインタは即座に無効（ハングアップやデータ不整合の原因）になります。

② シンボリックポインタ（Symbolic Pointer / Logical Pointer）

シンボリックポインタは、ターゲットセグメントを特定するための「論理キー（連結キー：Concatenated Key）」そのものをポインタ領域に格納する方式です。

アクセス機構: ターゲットのキー（例：`部門コード + 社員番号`）を保持し、そのキーを使ってデータベースの主アクセスパス（HIDAMのIndexなど）を経由して再度ターゲットを検索します。
物理的特性: ターゲットセグメントがディスク上のどこに移動しようが、主キーが変わらない限り、ポインタ自体を更新する必要は一切ありません。

—

2. DDL（DBD: Database Description）における定義例

階層型DBMSにおけるスキーマ定義言語（DBD）で、これらがどのように定義されるかを見てみましょう。ここでは、IMSのDBD（Database Description）の設計思想をベースにした具体的な定義例を示します。

パターンA：直接ポインタ（Direct Pointer）を採用した高速参照設計

セカンダリ・インデックス（副索引）から、ターゲットである「社員セグメント（EMPLOYEE）」を直接ポインタ（`PTR=P` または `PTR=PHIDAM`）で指し示す設計です。

物理直接ポインタを使用したインデックス定義例

DBD NAME=EMPIDXDB,ACCESS=INDEX

インデックス・セグメント定義
PTR=P (Physical) を指定し、ターゲットの物理RBAを直接保持させる

SEGM NAME=INDXSEG,PARENT=0,BYTES=16
FIELD NAME=(EMPNO,SEQ,U),BYTES=6,START=1

LCHILDでターゲットセグメントを指定。
PTR=SNGL (Single Link) により、物理的な直接ポインタを構築する

LCHILD NAME=(EMPSEG,EMPDB),INDEX=EMPNO,PTR=SNGL
DBDGEN
FINISH
END

解説: `PTR=SNGL`（または物理ポインタ指定）により、インデックスセグメントの内部には、ターゲットである `EMPSEG` の物理RBA（4バイトまたは8バイトのバイナリ値）が直接書き込まれます。

パターンB：シンボリックポインタ（Symbolic Pointer）を採用した疎結合設計

論理的関係（Logical Relationship）において、別データベースにある「部門セグメント（DEPT）」を、シンボリックポインタ（`PTR=SYMB`）を用いて参照する設計です。

シンボリックポインタを使用した論理リンク定義例

DBD NAME=EMPDB,ACCESS=HDAM,RMNAME=(DFSHDC40,3,100,5)

SEGM NAME=EMPSEG,PARENT=0,BYTES=150
FIELD NAME=(EMPNO,SEQ,U),BYTES=6,START=1

論理親子関係を定義。
PTR=SYMB を指定し、物理RBAではなく「部門コード（DEPTID）」という
論理キー（LPCK: Logical Parent Concatenated Key）を保持させる。

LCHILD NAME=(DEPTSEG,DEPTDB),PTR=SYMB

DBDGEN
FINISH
END

解説: `PTR=SYMB` が指定された場合、`EMPSEG` の中には相手先である `DEPTSEG` の物理アドレスではなく、`DEPTID` というキーデータそのものが埋め込まれます。アクセス時は、このキーを用いて `DEPTDB` を検索します。

—

3. チーフアーキテクトが示す「極限の選択基準」

これら2つのポインタは、「実行時パフォーマンス」と「運用・保守コスト（再編成コスト）」の完全なトレードオフ関係にあります。設計レビューにおいて、あなたが下すべき判断基準をマトリクスで示します。

設計の黄金律（The Golden Rules）

1. 「単一データベース内」かつ「参照頻度がミリ秒以下」なら、迷わず「直接ポインタ」を選択せよ。
同一の物理領域（同じデータベースファイル内）で完結する親子関係やインデックスは、再編成も同一単位で行われるため、直接ポインタのデメリット（再構築コスト）を最小化できます。
2. 「異なるデータベース間（マルチDB）」の参照は、例外なく「シンボリックポインタ」にせよ。
これを直接ポインタで繋いだ瞬間、システム全体のデータベースが「一蓮托生」となります。データベースAを再編成するために、関係のないデータベースB、C、Dもすべて巻き込んでオフラインにし、ポインタ再構築を実行しなければならなくなります。これは運用設計における「死の宣告」です。
3. 書き込み（挿入・削除）頻度とデータ移行の頻度を算出せよ。
データの追加・削除が激しく、頻繁に空き領域（Free Space）のクリーンアップ（再編成）が必要なセグメントに対して直接ポインタを乱発すると、毎週末のメンテナンスウィンドウが再編成バッチだけで破綻します。

—

4. 実務で陥る2大アンチパターンと回避策

アンチパターン①：ポインタ・スパゲッティ（Direct Pointer across Databases）

現象: 開発初期の「パフォーマンス最優先」という盲目的なスローガンのもと、別個に定義された3つのデータベース（顧客、受注、在庫）の間をすべて直接ポインタ（`PTR=PHIDAM`等）で結合した。
悲劇: 本番稼働後、データ量の増加に伴い「顧客データベース」の再編成が必要になったが、直接ポインタの整合性を保つために「受注」と「在庫」のデータベースも同時にロックし、巨大なポインタ修復ユーティリティを走らせる羽目になった。バッチ処理時間が予定の4倍に膨れ上がり、月曜の朝までにオンラインシステムが起動しなかった。
アーキテクトの処方箋:

データベースの物理境界を跨ぐ結合は、いかなる理由があろうともシンボリックポインタ（`PTR=SYMB`）で論理的に結合し、物理的な結合度を完全に遮断（デカップリング）してください。

アンチパターン②：シンボリック・デスループ（Symbolic Pointer in High-Frequency Loops）

現象: 運用の容易さを重視し、同一データベース内の「親セグメント（注文）」から「子セグメント（注文明細）」へのアクセスにシンボリックポインタを採用した。
悲劇: 1回のトランザクションで100件の明細をループ処理するバッチプログラムにおいて、明細を取得するたびにインデックスの再検索（二重ルックアップ）とランダムI/Oが多発。CPU使用率が100%に張り付き、処理性能が目標の1/10以下に低迷した。
アーキテクトの処方箋:

同一データベース内の密結合な親子関係には、物理的な親・子・兄弟ポインタ（`PTR=PHYSICAL`、`PTR=TWIN`）を使用し、ディスク上の物理的なポインタチェーン（Pointer Chain）を順次シークする設計に修正してください。

—

おわりに：技術の本質は「結合度のコントロール」にある

階層型DBMSにおける直接ポインタとシンボリックポインタの使い分けは、現代のソフトウェア設計における「密結合（Tight Coupling） vs 疎結合（Loose Coupling）」の議論そのものです。

物理ポインタ（直接）は、極限のパフォーマンスを得る代わりに、物理配置というインフラレイヤーにスキーマを密結合させます。
論理ポインタ（シンボリック）は、I/Oという代償を払うことで、運用の独立性と柔軟性を手に入れます。

この古典的かつ究極のトレードオフを理解し、DDLのパラメータ一行にその意図を込めること。それこそが、何十年経っても色褪せない堅牢なシステムを構築するチーフアーキテクトの矜持です。あなたの設計書にあるそのポインタ指定、本当にシステムの運用ライフサイクルに耐えられますか？今一度、見直してみてください。