階層型DBMSの深淵：仮想ペアリングによる物理制約の突破
おい、設計レビューを始めるぞ。
今回のテーマは「仮想ペアリング（Virtual Pairing）」だ。
リレーショナルデータベース（RDB）に毒された頭のまま階層型DBMS（IMS等）を触ると、必ずここで致命傷を負う。親ポインタと子ポインタのツリー構造という「物理的な絶対秩序」の前に、多くのエンジニアが「あ、ここ別のツリーのデータと紐付けたいんですけど、どうすれば……？」とフリーズする。
MFT（Multiple Field Type）やセグメント間の双方向ポインタで泥沼にハマった者、あるいは冗長なデータ複製を作って整合性地獄に落ちた者に告ぐ。
物理的に離れたセグメントを論理の絆で結び、I/Oコストを最小化しながら複雑な多対多を調停する――それが「仮想ペアリング」だ。
今日のコードレビューでは、この仮想ペアリングのメカニズム、DDLによる厳格なスキーマ定義、そして実務で生き残るためのパフォーマンスチューニングの極意を叩き込む。心して聞け。
—
1. なぜ「物理の制約」に抗う必要があるのか？
階層型DBMSの基本思想は「1対多（1:N）の厳格な親子関係」だ。
だが、現実世界のビジネスロジックは残酷なまでにネットワーク的だ。例えば、「顧客（CUSTOMER）」セグメントと「商品（PRODUCT）」セグメントがあったとする。1人の顧客が多くの商品を購入し、1つの商品は多くの顧客に買われる（N:Mの関係）。
これを純粋な階層構造だけで表現しようとすると、以下の2つの地獄のどちらかに落ちる。
1. データ重複地獄（冗長化）: 商品セグメントを顧客ツリーの配下に丸ごと複製する。更新時の不整合祭りが確定する。
2. 物理ポインタの暴走: ツリーの境界を越えて直接物理アドレス（RBAなど）を埋め込む。ストレージ再編成（Reorganization）のたびにポインタが腐敗し、夜間バッチが爆死する。
ここで登場するのが仮想ペアリングだ。
実体を片方のセグメント（物理親）にのみ置き、もう片方のセグメントには「あちらのセグメントのこの実体を指す論理的な影（仮想ペア）」を配置する。物理的な実体は1つでありながら、あたかも両方のツリーに存在するかのように振る舞わせる――これが、先人たちが編み出した美しきアーキテクチャだ。
—
2. DDLによるスキーマ定義：仮想ペアリングの実装パターン
百聞は一見に如かずだ。仮想ペアリングをどのようにDDL（Data Definition Language）で表現するのか、実務レベルの定義を見てみよう。
ここでは、「親ツリー（物理側）」と、そこへ論理的に接続する「子ツリー（論理側・仮想側）」を構築する。
— =====================================================================
— 階層型DBMS スキーマ定義：仮想ペアリングの例
— =====================================================================
— 1. 物理データベースのルート：顧客セグメント (PRIMARY)
DATABASE CUSTDB;
AREA CUST_AREA;
SEGMENT NAME IS CUSTOMER;
— セグメント長: 120バイト
BYTES 120;
— 顧客IDを物理的なシーケンスキーとする
OWNER IS SYSTEM;
IDENTIFIED BY CUST_ID TYPE CH(8);
— 顧客の基本情報フィールド定義
FIELD NAME IS CUST_ID, POS 1, TYPE CH(8);
FIELD NAME IS CUST_NAME, POS 9, TYPE CH(32);
— 2. 物理子セグメント：注文明細セグメント (PHYSICAL CHILD)
SEGMENT NAME IS ORDER_ITEM;
BYTES 64;
— 顧客セグメントに属する物理的な「1:N」の子供
PARENT IS CUSTOMER;
IDENTIFIED BY ORDER_NO TYPE CH(10);
FIELD NAME IS ORDER_NO, POS 1, TYPE CH(10);
FIELD NAME IS PROD_CODE, POS 11, TYPE CH(8);
FIELD NAME IS QTY, POS 19, TYPE BINARY(4);
— =====================================================================
— 3. 仮想ペアリングの核心：商品マスタツリーからの論理接続
— =====================================================================
— 別データベース（または別セグメント）にある商品マスタ側からの逆引き定義
DATABASE PRODDB;
AREA PROD_AREA;
SEGMENT NAME IS PRODUCT;
BYTES 100;
OWNER IS SYSTEM;
IDENTIFIED BY PROD_CODE TYPE CH(8);
FIELD NAME IS PROD_CODE, POS 1, TYPE CH(8);
FIELD NAME IS PROD_DESC, POS 9, TYPE CH(40);
— ★ ここがポイント：仮想ペア（VIRTUAL PAIR）の定義
SEGMENT NAME IS V_ORDER_REF;
BYTES 4; — 最小限の制御情報（実体への論理ポインタを保持）
— 商品マスタの配下に配置されるが、実体はCUSTDB側のORDER_ITEMを指す
PARENT IS PRODUCT;
— 物理的な実体（ORDER_ITEM）と論理的にペアを組む宣言
— SOURCE句により、どの実体セグメントの「影」であるかを指定する
SOURCE IS CUSTDB.ORDER_ITEM VIRTUAL;
— 論理親ポインタ（LIP: Logical Interleaved Pointer）が自動生成される
チーフアーキテクトのコードレビュー解説：
- `SOURCE IS … VIRTUAL`: この1行が仮想ペアリングの命だ。`PRODUCT`ツリーから見ると、このセグメントはあたかも自分の子供のように振る舞うが、実際のデータ実体は`CUSTDB.ORDER_ITEM`に存在する。
- データの実体は1つ: 更新は常に物理側（`CUSTDB.ORDER_ITEM`）で行う。仮想側（`V_ORDER_REF`）は読み取り専用、あるいは透過的な参照窓口として機能するため、データの二重更新リスクがゼロになる。
—
3. アプリケーションからのアクセスとトラバーサル（DML）
設計ができたら、次はアプリケーションがどう動くかだ。階層型DBMSのナビゲーショナル言語（ホスト言語埋め込みのDML）を用いて、仮想ペアリングをどう横断（トラバース）するかを示す。
「ある商品が、どの顧客のどの注文に含まれているか」を逆引きするシナリオを考えてみよう。
/ =====================================================================
- ホスト言語（COBOL/C混じりの仮想コード）による仮想ペアリングのトラバーサル
- ===================================================================== /
void find_customers_by_product(const char target_prod_code) {
/ 1. PRODUCTセグメントの位置づけ (ルートアクセス) /
DB_MOVE(“PRODDB”, “PRODUCT”, target_prod_code);
EXEC DML FIND FIRST PRODUCT WHERE PROD_CODE = :target_prod_code;
if (DB_STATUS != DB_OK) {
printf(“Product not found: %s\n”, target_prod_code);
return;
}
printf(“=== Product: %s の購入顧客一覧 ===\n”, target_prod_code);
/ 2. 仮想ペアセグメント（V_ORDER_REF）の反復取得 /
/
- ここがミソ。PRODUCTの子供を舐めているついでに、
- 自動的に物理側のORDER_ITEMセグメントへの論理パスが解決される。
/
while (1) {
EXEC DML FIND NEXT V_ORDER_REF WITHIN PRODUCT;
if (DB_STATUS == DB_EOF) {
break; / これ以上注文はない /
}
/
- 3. 論理ペアを介して、反対側の物理親（CUSTOMER）へジャンプする
- 仮想ペアリングの真骨頂：論理パス（Lpath）の逆転
/
EXEC DML GET UNIQUE CUSTOMER
VIA V_ORDER_REF.CUSTOMER; / 顧客セグメントまで一気に遡る /
if (DB_STATUS == DB_OK) {
printf(” -> 顧客ID: %.8s, 顧客名: %.32s\n”,
customer.cust_id, customer.cust_name);
}
}
}
このコードの美しいところは、アプリケーションエンジニアが複雑な物理アドレスの解決やハッシュテーブルの結合（JOIN）を一切意識する必要がない点だ。DBMSのエンジンが、仮想ペアに仕込まれた論理ポインタを辿って、一瞬で物理親（CUSTOMER）へとワープしてくれる。
—
4. 堅牢な設計とパフォーマンス上の「死角」
さて、ここからがチーフアーキテクトとしての本領発揮だ。教科書通りの美しい設計だけでは、現場の商用環境で夜間バッチを沈没させる。仮想ペアリングを使う上で、お前らが絶対に押さえておかなければならない3つの鉄則（死角）を授ける。
① メンテナンス（再編成：Reorganization）の呪縛
仮想ペアリングは、異なるセグメント間で「ポインタ（論理アドレスまたはRBAベースのポインタ）」を張り合っている。
物理セグメント側（今回の例では `CUSTDB.ORDER_ITEM`）でレコードの削除・挿入が頻発し、データベースの再編成（Reorg）を怠ると、ポインタが宙を浮く、あるいはチェインが切断される。
- 対策: 物理側と仮想側のエリアは、必ず同期してリオーガナイズする運用手順（JCL等）を組め。片方だけ再編成したら、システムは即座にパニックを起こす。
② デッドロックの温床
仮想ペアリングをまたいだ更新処理を行う場合、物理ツリーのロックと論理ツリー（仮想ペア側）のロックが異なる順序で取得されると、綺麗にデッドロックが発生する。
- 対策: 仮想ペアを経由した逆方向の更新は極力避け、更新は常に「物理親」を起点とした単一方向の階層パスに限定せよ。原則として、仮想ペア側は「参照（Read-only）」として割り切るのがプロの設計だ。
③ ポインタチェインの肥大化とI/Oコスト
1つの物理セグメントに対して、何万もの仮想ペアが紐付くような「スター型」の偏ったモデリングをするとどうなるか？
物理セグメント側の削除や更新の際、それに紐づくすべての仮想ペア（論理ポインタのチェイン）をDBMSが辿って整合性をとるため、1件のDELETE文が数千件の連鎖I/Oを引き起こし、CPUとディスクを焼き尽くす。
- 対策: 1つの親に対する仮想ペアの数（ファンアウト）が数千を超えることが予想される場合、仮想ペアリングの採用を即座に諦め、中間セグメント（ジャンクション・セグメント）を物理的に配置する設計に変更しろ。
—
5. 総括
仮想ペアリングは、階層型DBMSの硬直した物理構造に「しなやかな論理の翼」を与えるための、極めて高度な設計パターンだ。
これを使いこなせば、RDBのような重厚な結合（JOIN）コストを支払うことなく、ミリ秒単位の超高速なナビゲーションと、データ重複のないクリーンなスキーマを両立できる。
だが、忘れるな。
「強力な機能には、相応の運用の代償が伴う」。
構造の裏にあるポインタの仕組み、再編成の依存関係、そしてロックの順序。これらすべてを脳内に焼き付けた上でコードを書け。
今日のレビューはここまでだ。
さっさと自席に戻って、自分の設計書の仮想ペアリング部分をもう一度見直し、ポインタの整合性と再編成計画を確認しろ。解散！
コメント