階層型DBMSの深層：論理関係の制約と物理オーバーヘッドの極限制御
こんにちは、チーフアーキテクトの私だ。
今日のコードレビューで、また「親セグメントの削除に伴う子セグメントの巻き添え削除（Cascade Delete）」を安易に設計したジュニアエンジニアがいた。リ relational DB脳のまま階層型DBMS（IMSなど）を触ると、必ずここで致命傷を負う。
現代のエンジニアから見れば「レガシーの骨董品」に映るかもしれない階層型DBMSだが、その実態は「物理アドレスの偏執的なまでの最適化によって極限の性能を叩き出す、孤高のハードウェア直結型エンジン」だ。
今回は、データ構造とDDLにおける「論理関係の制約」「ポインタの整合性維持」「物理オーバーヘッドの管理」について、実務の現場で生き残るための知見を叩き込む。
—
1. 階層型DBMSにおける「論理関係」の残酷な現実
リレーショナルデータベース（RDB）では、外部キー（Foreign Key）を貼れば、テーブル間の結合は論理的に解決され、オプティマイザがよしなにやってくれる。しかし、階層型DBMSの世界には「オプティマイザの優しさ」など存在しない。
階層型（Hierarchical）の本質は、物理的なツリー構造（Parent-Child）だ。しかし、現実世界のデータは綺麗なツリー構造には収まらない。多対多、あるいはツリーを跨いだ参照関係を表現するために導入されたのが「論理関係（Logical Relationship）」である。
ここで最初のトラップがある。
論理関係を定義する場合、セグメントの配置には厳格な物理的制限が伴う。
セグメント配置の制約：物理親と論理親
論理関係において、データを指す側を論理子（Logical Child）、指される側を論理親（Logical Parent）と呼ぶ。
- ルール： 論理親セグメントは、必ず既存の物理データベース（または別の物理階層）に存在しなければならない。
- 制約： 階層型DBMSのDDL（DBD：Database Description）では、論理関係を定義する際、物理的なストレージ上のブロック配置とポインタの向きを完全に調停する必要がある。
実務設計において、論理子をどの物理階層にぶら下げるかで、I/Oコストが文字通り「10倍」変わる。
—
2. DDL設計と論理関係の実際（DBD定義の勘所）
言葉だけでは伝わらないだろう。IBMのIMS DBを例に、論理関係を持つDBD（Database Description）の設計パターンを見てみこう。
— 【概念設計】
— 物理DB A: 顧客セグメント (ROOT) -> 契約セグメント (CHILD)
— 物理DB B: 製品セグメント (ROOT)
— 論理関係: 契約セグメント（論理子）が、製品セグメント（論理親）を参照する
これを定義するDBDの抜粋だ。
- 物理DB A の定義（契約データベース）
DBD NAME=CONTDB,ACCESS=HDAM,RMNAME=(DFSHDC40,100,500)
- 1. 顧客セグメント（物理親・ルート）
SEGM NAME=CUSTSEG,PARENT=0,BYTES=100
FIELD NAME=(CUSTID,SEQ,U),START=1,BYTES=10
- 2. 契約セグメント（物理子であり、かつ論理子）
SEGM NAME=CONTSEG,PARENT=CUSTSEG,BYTES=150
FIELD NAME=(CONTID,SEQ,U),START=1,BYTES=15
- ※ここで論理親（製品DB）との接続を宣言する
LCHILD NAME=(PRODSEG,PRODDB),POINTER=LOGICAL
設計レビュー時のチェックポイント
1. POINTER=LOGICAL の指定: ポインタの持ち方に `L-PTR`（論理親ポインタ）や `V-PTR`（仮想ポインタ）を指定するが、ここを誤ると双方向ポインタの更新時にデッドロックの温床になる。
2. 削除ルールの明記（RULESパラメータ）:
論理親を削除する際、論理子が残っている場合の挙動（`VIRTUAL`, `NEVER`, `CASCADE`）を誤って設定すると、孤児ポインタ（Dangling Pointer）が生まれ、データベース全体が破損する。実務では原則として `RULES=(VIRTUAL,RESTRICT)` を選び、アプリケーション層で整合性を担保せよ。
—
3. ポインタの整合性維持：物理アドレス直撃の恐怖
RDBのインデックスは、レコードが移動してもB+Treeのキーが変わるだけだ。しかし、階層型DBMSの多くは、セグメント間のリンクを「RBA（Relative Byte Address：相対バイトアドレス）」や、ダイレクトな物理アドレスポインタで保持している。
これが何を意味するか？
レコードの更新や再配置（REORG）が発生すると、ポインタの書き換えコストが発生する。
[物理親セグメント]
│
▼ (RBAポインタ: 0x004F2A)
[論理子セグメント] ─── (論理親ポインタ) ───> [外部の論理親セグメント]
堅牢な設計パターン：ポインタ腐敗を防ぐ防衛策
- 物理キー順アクセス（HISAM）からダイレクトアクセス（HDAM）への移行時の注意:
ハッシュアクセス（HDAM）を使用する場合、論理親へのポインタがRBAではなく「ISRT（挿入時のロジック）」や「HIOE」に依存していると、データベースの再編成（Reorganization）のたびにポインタの解決処理（Pointer Resolution）が必要になる。
- バッチ処理での整合性担保:
論理関係が絡むセグメントを一括更新するバッチでは、必ずチェックポイント／リスタート機能を作り込め。途中で異常終了した場合、物理ポインタと論理ポインタの不整合（Twin Chainの切断）が起き、リカバリが地獄と化す。
—
4. 物理構造のオーバーヘッド管理
「階層型は速い」というのは、単一の階層をトップダウンで舐めるときだけの神話だ。論理関係や二次索引（Secondary Index）を導入した瞬間、階層型DBMSは極めて重いオーバーヘッドを背負う。
アーキテクトが管理すべき3大オーバーヘッド
1. プレフィックス・スペース（Prefix Space）の肥大化
セグメントの先頭には、親や子、双子（Twin）を指すためのポインタ領域（Prefix）が必ず付く。論理関係を張ると、このプレフィックス領域に「論理親ポインタ」や「論理子ポインタ」が追加され、データ本体よりもポインタの方が大きいという本末転倒な現象が起きる。セグメントサイズ設計では、プレフィックスのバイト数を常に計算に入れろ。
2. ストレージの断片化（Fragmentation）
論理関係を持つセグメントの動的な挿入・削除は、OSのヒープメモリのような断片化を呼ぶ。定期的なアンロード／ロード（Reorg）をサボると、I/O効率が急激に劣化する。
3. カスケード更新のコスト
論理親のキーを変更した場合、それを指すすべての論理子のポインタチェーンを辿って修正するか、あるいは論理関係を再構築する必要がある。RDBの `ON UPDATE CASCADE` と違い、物理アドレスの書き換えを伴うため、トランザクションのロック期間が跳ね上がる。
—
チーフアーキテクトからの提言
階層型DBMSにおける論理関係の設計は、「物理制約とのダンス」だ。
データをどう配置し、どのポインタで結び、どのタイミングで再編成を行うか。そのすべてをエンジニアが手でコントロールしなければならない。
もしあなたが今、レガシーな階層型DBMSの改修や、それに類似した極限の低レイヤーデータ構造を設計しているなら、次の格言を思い出してほしい。
> 「ポインタを制する者は、システムを制す。だが、ポインタに溺れる者は、障害の夜に泣く。」
安易な論理関係の多用は避けよ。どうしても多対多や複雑な参照が必要な場合は、アプリケーション層でキーの保持に留めるか、本当にその物理オーバーヘッドを許容できるか、DBDの定義書を抱きしめてもう一度熟考せよ。
健闘を祈る。設計レビューで不備を見つけたら、容赦なく差し戻すからそのつもりで。
コメント