階層型DBMSの深層：双方向論理関係（Bidirectional Logical Relationships）による極限のスキーマ設計
こんにちは。チーフアーキテクトの私だ。
今日のコードレビューで、また「論理親子関係の方向性」を安易に決めた設計を見かけた。リレーショナル脳のまま階層型DBMS（IMS等）に手を出すと、こうしてシステムの寿命を縮める悪臭（Bad Smell）を放つコードが生まれる。
リレーショナルデータベース（RDB）であれば外部キーとJOINで解決できる話も、ポインタ迷路である階層型DBMSの世界では、物理的・論理的なアクセスの「向き」がパフォーマンスとデータ整合性の生死を分ける。
特に、双方向論理関係（Bidirectional Logical Relationships）の設計を誤れば、バッチ処理は爆発的に遅くなり、メンテナンス時には無限ループの悪夢を見る。
今日は、この「双方向論理関係」をいかに美しく、かつ鉄壁のパフォーマンスで実装するか、私の知見のすべてを叩き込む。心して読め。
—
1. 階層型DBMSにおける「論理関係」のパラダイム
まず前提を共有しよう。階層型DBMSの基本は「物理的親子関係（Physical Parent/Child: PC）」だ。これは一つのデータベース（DBD）内で完結し、高速なセグメント・シーケンシャル・アクセスを担保する。
しかし、現世界の複雑なデータ構造は、単一のツリー構造には収まらない。そこで登場するのが論理関係（Logical Relationships）だ。
あるセグメント（論理親：Logical Parent）が、別のツリーに属するセグメント（論理子：Logical Child）から参照される構造を指す。
通常、論理関係は単方向（論理子から論理親へのポインタを持つ）で定義されることが多い。しかし、実務上の複雑なビジネスロジック――例えば、「ある顧客に紐づく全契約のトラッキング」と「ある契約から辿る顧客の属性変更履歴の逆引き」を同時に、かつミリ秒単位で要求されるケースにおいて、単方向ポインタでは太刀打ちできなくなる。
ここで双方向論理関係の出番となる。
—
2. スキーマ定義（DBD）の極意：双方向の実装
百聞は一見にしかずだ。DBD（Database Description）の定義を見てみよう。
ここでは、「顧客（Customer）」ツリーと、別管理されている「契約（Contract）」ツリーを、双方向の論理関係で結ぶスキーマの例を示す。
==============================================================
- 顧客DBD (CUSTDBD) と 契約DBD (CONDBD) の双方向論理関係定義
==============================================================
- — 1. 顧客セグメント側 (論理親の定義) —
DBD NAME=CUSTDBD
SEGM NAME=CUSTROOT,BYTES=50
FIELD NAME=(CustID,SEQ,U),BYTES=10,START=1
SEGM NAME=CUSTINF,BYTES=200,PARENT=CUSTROOT
- — 2. 契約セグメント側 (論理子と双方向ポインタの定義) —
DBD NAME=CONDBD
SEGM NAME=CONROOT,BYTES=100
FIELD NAME=(ConID,SEQ,U),BYTES=12,START=1
- 論理子の定義: CUSTDBDのCUSTINFを論理親(LP)とする
- 双方向を実現するため、LPTR（論理親ポインタ）とTWIN/PARENTポインタを指定
SEGM NAME=CONLCHLD,BYTES=150,PARENT=CONROOT,
LCHILD=(CUSTINF,CUSTDBD)
- 交差データや論理双方向の制御フィールド
FIELD NAME=(CustXRef,SEQ,M),BYTES=10,START=1
ここで重要なのは、論理子セグメント（`CONLCHLD`）側から論理親（`CUSTINF`）へのポインタ（`LPTR`）だけでなく、論理親側からも論理子を逆引きするための双方向ポインタ（Logical Twin / Logical Parent pointers）の構築だ。
アーキテクトの視点：ペアレント・ポインタの呪縛
双方向論理関係を定義する場合、DBMS内部では「論理的親ポインタ（LP）」と「論理的双方向ツインポインタ（LTW）」が維持される。
書き込み時（Insert/Replace）のオーバーヘッドが単方向に比べて跳ね上がることを忘れてはならない。「本当に双方向からのトラバースが毎秒何万回も発生するのか？」を設計レビューで必ず問い正せ。なんとなく便利そうだからという理由で双方向化する者は、私のプロジェクトでは即座に差し戻しだ。
—
3. 実務における使用例：逆引きアクセスのコードパターン
アプリケーション側（COBOLやPL/I、あるいは現代的なC/C++バッチ）から、この双方向論理関係をどう叩くか。
「契約ID」から「顧客情報」を引き、さらにそこから「同一顧客を持つ別の契約群」を逆引きする典型的なパターンをイメージしてほしい。
> ==========================================================
> 契約IDを起点に、論理親(顧客)を経由して逆引きを行う処理
> ==========================================================
ROUTINE-BIDIRECTIONAL-ACCESS.
> 1. 契約ツリーからターゲットの契約セグメントを直撃
MOVE ‘CONLCHLD’ to DLI-SEG-NAME.
MOVE ‘GU ‘ to DLI-FUNCTION.
CALL ‘CBLTDLI’ USING DLI-FUNCTION
PCB-CON
CONLCHLD-IO-AREA
DLI-SSA-CONTRACT.
IF DLI-STATUS NOT = ‘ ‘
GO TO ERROR-HANDLER.
> 2. 【核心】論理親ポインタを辿って顧客セグメントへジャンプ
> 双方向関係が定義されているため、コードレスで親側へ飛べる
MOVE ‘CUSTINF’ to DLI-SEG-NAME.
MOVE ‘GN ‘ to DLI-FUNCTION.
CALL ‘CBLTDLI’ USING DLI-FUNCTION
PCB-CON
CUST-IO-AREA
DLI-SSA-LOGICAL-PARENT.
IF DLI-STATUS NOT = ‘ ‘
GO TO ERROR-HANDLER.
DISPLAY ‘Linked Customer ID: ‘ CUST-ID.
> 3. 顧客側から、双方向ポインタを使って「他の契約」を逆引きスキャン
> これが双方向論理関係の真骨頂である。
PERFORM UNTIL DLI-STATUS = ‘GE’
MOVE ‘GN ‘ to DLI-FUNCTION
CALL ‘CBLTDLI’ USING DLI-FUNCTION
PCB-CON
CONLCHLD-IO-AREA
DLI-SSA-LOGICAL-TWIN
IF DLI-STATUS = ‘ ‘
DISPLAY ‘Another Contract Found: ‘ CON-ID
END-IF
END-PERFORM.
このコードの美しさは、物理的なデータ配置の制約を超えて、あたかもRDBの双方向JOINのようにデータを自在にスキャンできる点にある。しかし、その裏でポインタチェーンが物理ブロックを跨いで奔走していることを忘れてはならない。
—
4. パフォーマンス上の注意点と堅牢な設計パターン
双方向論理関係は諸刃の剣だ。実務で痛い目を見ないための「3つの鉄則」を授けよう。
鉄則1: メンテナンス（更新・削除）時のカスケード負荷を予測せよ
双方向関係において、論理親側でデータが削除（DLET）された場合、論理子側のポインタ整合性を保つためにDBMS内部で膨大な処理（ポインタの切断・更新）が走る。
- 対策: 更新頻度が極めて高いセグメント間を双方向論理関係で結ぶな。マスター・トランザクション分離の原則を厳守し、参照系が95%を超えるマスタ対リファレンスの関係に限定せよ。
鉄則2: 物理ストレージの局所性（Locality）の崩壊を防ぐ
論理子セグメントは、物理親とは別のDBD（別ファイル群）に存在することが多い。双方向ポインタを辿るたびにI/Oのランダムシークが発生する。
- 対策: データベース・チューニング（DBDGENの`RMNAME`やストレージグループ設計）において、関連する論理親と論理子は同一あるいは近接したDASDボリューム（またはSSDプール）に配置し、ヘッドの移動を最小限に抑えよ。定期的なリオーガナイゼーション（Reorg）によるポインタのデフラグは義務である。
鉄則3: 循環参照（Circular Reference）の完全排除
論理親から論理子へ、そして別のパスを介して元の親へ戻るような循環参照を双方向で構築した場合、ポインタチェインが無限ループに陥り、オンラインTUXEDOやCICSのトランザクションがハングアップする。
- 対策: スキーマ設計書の段階で、DAG（有向非巡回グラフ）の数理モデルを徹底的に検証し、レビューを通すこと。
—
5. チーフアーキテクトからの総括
階層型DBMSにおける双方向論理関係は、レガシーな技術の遺物などではない。データの物理配置とポインタのトポロジーを完全に支配した者だけが扱える、超高効率な高速トラバース機構だ。
RDBの「何でもJOINできる甘え」を捨て、データの流れる方向と頻度を極限まで計算し尽くして組まれた双方向スキーマは、現代の分散データベースすら凌駕するスループットを叩き出す。
設計レビューでこの構造を描くときは、ポインタの数だけ重い責任を背負っていることを自覚しろ。
美しく、無駄のない、切れ味鋭いスキーマデザインを期待する。以上だ。
コメント