「RDBのインデックスが遅い」「NoSQLのネストが深すぎてクエリが破綻した」――そんな甘えた悲鳴を聞くたびに、私は静かに首を振る。
現代のエンジニアは、ハードウェアの潤沢なリソースと抽象化されたフレームワークに甘やかされすぎている。データ構造の真の極限状態、そしてミリ秒以下の超低レイテンシを数十年間にわたり担保し続けている階層型DBMS（代表格としてのIBM IMS DBなど）の世界では、設計の妥協はそのままシステムの死を意味する。
階層型DBMSにおいて、パフォーマンスの源泉は「物理的なポインタによるセグメント間のダイレクトな結合」だ。しかし、この圧倒的な速度と引き換えに、我々は極めて厳格な物理的・論理的制約を課されることになる。
今回は、階層型モデルにおける「論理データベース（Logical Database）」を設計する際、避けては通れない論理関係の制限事項、ポインタの最大数、そしてそれらを突破するためのアーキテクチャ設計について、実務レベルの知見を授けよう。
—
1. 物理と論理の境界：論理データベース（LDB）とは何か
階層型DBMSの基本構造は、1つのルートセグメントから枝分かれするツリー構造（物理データベース：PDB）である。しかし、現実のビジネスデータは単純な木構造には収まらない。「多対多（M:N）」の関係や、異なるツリー間の関連性を表現するために導入されるのが「論理関係（Logical Relationship）」であり、これらを再構成してアプリケーションに見せる仮想的な階層構造が「論理データベース（LDB）」だ。
ここで、物理的な親子関係（Physical Parent / Physical Child）とは別に、論理的な親子関係（Logical Parent: LP / Logical Child: LC）が定義される。
この美しいポインタの網の目を制御するのが、DBD（Database Description）によるスキーマ定義である。
スキーマ定義（DBD）の実例
以下に、顧客物理DB（CUSTOMER PDB）と、注文物理DB（ORDER PDB）を論理的に結合し、顧客から注文、注文から商品へとアクセス可能にするためのDBD定義の核心部を示す。
- =====================================================================
- CUSTOMER PHYSICAL DBD (顧客物理データベース定義)
- =====================================================================
DBD NAME=CUSTPDB,ACCESS=HDAM,RMNAME=(DFSHDC40,1,500,824)
SEGM NAME=CUSTOMER,BYTES=150,PARENT=0
FIELD NAME=(CUSTID,SEQ,U),BYTES=10,START=1,TYPE=C
- 論理親子関係の定義：ORDER PDB 内の ORDLC セグメントからの双方向ポインタを受け入れる
LCHILD NAME=(ORDLC,ORDPDB),PAIR=CUSTORD,POINTER=DBLE
SEGM NAME=CUSTADDR,BYTES=100,PARENT=CUSTOMER
FIELD NAME=(ADDRID,SEQ,U),BYTES=5,START=1,TYPE=C
DBDGEN
FINISH
END
- =====================================================================
- ORDER PHYSICAL DBD (注文物理データベース定義)
- =====================================================================
DBD NAME=ORDPDB,ACCESS=HIDAM
SEGM NAME=ORDER,BYTES=120,PARENT=0
FIELD NAME=(ORDID,SEQ,U),BYTES=12,START=1,TYPE=C
- 論理子セグメント（Logical Child）の定義
- 物理親は ORDER、論理親は CUSTPDB 内の CUSTOMER。
- POINTER=(LPARNT,PONLY) により、論理親へのダイレクトポインタ(4バイトRBA)を保持。
SEGM NAME=ORDLC,PARENT=((ORDER),(CUSTOMER,CUSTPDB)), X
BYTES=80,POINTER=(LPARNT,PONLY,LDBLE)
FIELD NAME=(ORDDATE,SEQ,U),BYTES=8,START=1,TYPE=C
- 仮想ペアセグメント（論理データベース側で見せるための定義）
SEGM NAME=CUSTORD,PARENT=CUSTOMER,SOURCE=((ORDLC,KEY,ORDPDB))
DBDGEN
FINISH
END
この定義により、ディスク上では異なる物理ファイルに格納されている「顧客」と「注文」が、メモリ上のアドレスを示す物理ポインタ（RBA: Relative Byte Address）によって直結される。
—
2. 極限の物理制約：なぜ「制限」が存在するのか
この超高速なポインタ駆動アーキテクチャを維持するため、階層型DBMSにはハードウェアおよびアドレッシングの限界から生じる、極めて厳格な物理的制限が存在する。これらを無視した設計は、コンパイル（DBDGEN）エラーになるか、最悪の場合、本番稼働後の凄まじいパフォーマンス劣化を引き起こす。
① 階層の深さとセグメント数の限界値（IMS DB標準）
- 物理階層の最大レベル数: 15レベル
- 物理セグメントタイプの最大数: 255タイプ
- 論理階層の最大レベル数: 15レベル
「なぜ15レベルなのか？」――それは、セグメントのプレフィックス（ヘッダ情報）に割り当てられる階層番号（Segment Code）が1バイト（実質的に制御ビットを除くとさらに制限される）で管理されているためだ。また、15階層を超えるトラバースは、メモリ内のバッファプール（DFSBPPRM）を食いつぶし、ポインタチェイス（Pointer Chasing）によるCPUオーバーヘッドを幾何級数的に増加させる。
② ポインタの最大数とセグメントプレフィックスの物理的限界
階層型DBMSにおいて、セグメントは「プレフィックス（Prefix）」と「データ（Data）」に分かれている。
+————————————————————————-+
| Segment Record |
+————————————————————————-+
| Prefix | Data |
+—————————————————-+——————–+
| Seg Code | Delete | Pointer 1 | Pointer 2 | … | User Payload |
| (1 B) | Byte | (4 B) | (4 B) | | (Application Data) |
+—————————————————-+——————–+
ポインタはすべて、プレフィックス領域に4バイトのダイレクト・アドレス（RBA）として埋め込まれる。
- 物理親子ポインタ（PCF / PCL）
- 物理兄弟ポインタ（PTF / PTB）
- 論理親子ポインタ（LCF / LCL）
- 論理親ポインタ（LP）
もし、1つのセグメントに無計画にポインタを定義するとどうなるか？
例えば、10個の論理関係と双方向兄弟ポインタを定義した場合、プレフィックスだけで `(10 + 2) 4 = 48` バイトを消費する。実データ（Payload）が 20バイトしかないセグメントの場合、データの半分以上がポインタのメタデータで占められるという「メタデータ肥大化（Prefix Bloat）」が発生する。
さらに、物理的な制約として、1つのセグメントタイプに定義できるポインタおよびLCHILDの総数は実質的に制限（実装によるが、最大カウンタ数やアドレッシング空間に依存）されており、これを極限まで使う設計は、後述する再編成（Reorganization）の地獄を招く。
—
3. 設計の罠：アンチパターン「スパイダーウェブ・スキーマ」
設計レビューで私が最も厳しく却下するのが、この「スパイダーウェブ（蜘蛛の巣）・スキーマ」だ。
[Customer PDB] [Order PDB] [Inventory PDB]
+———-+ +———-+ +———–+
| CUSTOMER |<============>| ORDER |<===========>| INVENTORY |
+———-+ +———-+ +———–+
|| || ||
|| (Logical) || (Logical) || (Logical)
\/ \/ \/
+———-+ +———-+ +———–+
| CUST_ADR |<------------>| ORD_ITEM |<----------->| SUPPLIER |
+———-+ +———-+ +———–+
RDBの感覚で「関連があるから」と、異なるPDB間で双方向の論理関係（Physical/Logical Parent-Child）を無秩序に張り巡らせた状態である。
なぜこれが致命的なのか？
1. ランダムI/Oの爆発（ポインタチェイス）:
LDBを介してセグメントを走査する際、OSのディスクI/Oはシークエンス（連続）読み込みではなく、広大なディスク空間内をRBAポインタに基づいて飛び回る「ランダムI/O」になる。これが数百万トランザクションで発生すると、DASD（ディスク）のI/Oキューがサチュレーションを起こす。
2. 再編成ユーティリティ（REORG）の停止:
階層型DBはデータの追加・削除に伴い、ポインタが断片化（フラグメンテーション）するため、定期的なREORG（再編成）が不可欠である。しかし、双方向論理関係で強固に結ばれた複数のPDBは、「同時に」アンロードおよびリロードしなければならない（データベース・プレリオーグ / ワークキット処理が必要）。
PDB AをREORGするためにPDB B, C, Dも巻き込んでオフラインにする必要が生じ、24時間365日の稼働要件は完全に崩壊する。
—
4. 堅牢な設計パターン：極限状態を切り抜けるアーキテクチャ
この物理的制約の中で、どうやって複雑なビジネスロジックを破綻させずに実装するか。プロのテックリードが採用する設計パターンを伝授する。
パターン1：一方向論理関係（Unidirectional）と記号ポインタ（Symbolic Pointer）のハイブリッド
可能な限り「物理ダイレクトポインタ（Direct RBA）」による双方向結合を避け、「記号ポインタ（Symbolic Pointer）」を併用する。
- 双方向ポインタではなく、一方向ポインタ(LPARNT)のみを定義
- かつ、相手方のキー情報をデータ領域に持たせる（Symbolic Key）
SEGM NAME=ORDLC,PARENT=((ORDER),(CUSTOMER,CUSTPDB)), X
BYTES=80,POINTER=(LPARNT,PONLY)
- メリット:
物理的な接続が「一方向（注文 -> 顧客）」のみとなるため、顧客PDBを再編成する際に、注文PDBの物理ポインタを書き換える必要がない（ポインタ解決の依存関係を断ち切れる）。
- トレードオフ:
逆方向（顧客 -> 注文）の検索はダイレクトRBAより低速になるが、これはセカンダリ・インデックス（Secondary Indexing）を局所的に配置することでカバーする。
パターン2：セグメントの非正規化（Denormalization）による階層の圧縮
「15レベルの制限があるから、12レベルで設計した」――それでは素人だ。実務では「最大でも3〜4レベル」に抑えるのが鉄則である。そのためには、RDB的な正規化を捨て、セグメントを意図的にフラット化する。
【BEFORE】（無駄な階層化：5レベル）
[CUSTOMER] (Root)
└── [CONTRACT] (Level 2)
└── [BILLING] (Level 3)
└── [HISTORY] (Level 4)
└── [DETAIL] (Level 5)
【AFTER】（非正規化・フラット化：2レベル）
[CUSTOMER] (Root)
└── [CONTRACT_BILL_HIST] (Level 2)
- 契約・請求・履歴を1つの可変長セグメント（Variable-Length Segment）に統合
階層型DBMSは、「1つの巨大なセグメントを読み込む方が、複数の小さなセグメントをポインタで手繰るよりも圧倒的に速い」という特性を持つ。ディスクI/Oの回数こそが絶対的なボトルネックだからだ。
—
5. 運用とチューニングの極意：RULES定義の罠
DBDのセグメント定義において、論理関係を定義するときに最も注意すべきパラメータが `RULES=`（インサート/リプレース/デリート・ルール）である。
- RULES=(Insert, Replace, Delete) の挙動指定
SEGM NAME=ORDLC,PARENT=((ORDER),(CUSTOMER,CUSTPDB)), X
BYTES=80,POINTER=(LPARNT,PONLY), X
RULES=(PLV)
ここで指定する `P` (Physical), `L` (Logical), `V` (Virtual) の挙動は、ポインタの整合性に直結する。
- `RULES=(,,,D)` (Delete Rule):
論理親（LP）が削除されたとき、論理子（LC）をどう処理するか。
- Physical (P): 論理子が残っている場合、論理親の物理削除は許されない。アプリケーションに「DX」ステータスコードが返る。
- Logical (L): 物理削除は受け付けるが、論理子側からのポインタが生きている限り、物理的にはディスクに残り続ける（ゴーストセグメント化）。
- Virtual (V): 論理親が削除されると、連鎖的にすべての論理親子関係のポインタがクリアされる。
テックリードの推奨:
基本的には `RULES=(P,P,P)` または強固な整合性を担保できる組み合わせ以外は認めてはならない。`V`（Virtual）や `L`（Logical）を安易に使うと、バグのあるアプリケーションが走った際、どこからも参照できない「孤立したセグメント（Orphaned Segment）」や「破損したポインタ」がデータベース内に埋もれ、数ヶ月後のシステムクラッシュまで検出できないという大惨事を引き起こす。
—
結論：制約は「限界」ではなく「美しさ」のルールである
階層型DBMSにおける「物理的制約」は、怠惰な設計者を排除し、ハードウェアの性能を120%引き出すための「神の設計図」である。
1. 論理関係は最小限に絞れ。 蜘蛛の巣のような設計は、運用の死（REORG不能）を意味する。
2. 階層は深くするな、横に広げよ。 セグメントの非正規化を恐れるな。
3. ポインタのプレフィックス・オーバーヘッドを常に計算せよ。 データとポインタの比率を意識せよ。
これらの制約を理解し、手懐けたとき、あなたの設計したシステムは、他のいかなる最新アーキテクチャをも凌駕する、極限の超高速トランザクション処理エンジンとして、今後数十年にわたり稼働し続けるだろう。魂を込めた設計を期待する。
コメント