【実務・中級編】ペアセグメント – 階層型DBMS

諸君、よく集まってくれた。
今日は、階層型DBMS（IMS等）における設計の「急所」とも言える「ペアセグメント（Paired Segments）」について講義する。

リレーショナルデータベース（RDB）の外部キー制約に慣れきった若手エンジニアが、階層型DBMSの設計に足を踏み入れると、まずその「物理構造の制約」に絶望する。しかし、その制約こそが、極限のパフォーマンスを引き出すための鍵だ。

「ツリー構造で多対多をどう表現するか？」
この問いに対する解が、ペアセグメントだ。生半可な理解で組めば、データの不整合とI/Oの地獄を見る。心して聴くように。

—

1. なぜ「ペア」が必要なのか：階層型の限界を超える

階層型DBMSの本質は「親子関係の物理的な近接性」にある。しかし、現実は非情だ。
例えば、「受注（Order）」と「部品（Part）」を考えてみろ。

受注から見れば、どの部品を注文したか知りたい（受注→部品）。
部品から見れば、どの受注に使われているか知りたい（部品→受注）。

これを一つのツリーで表現しようとすると、どちらかを主、どちらかを従にするしかない。だが、業務は両方向からのアクセスを要求する。この「論理的な双方向性」を、物理的なツリー構造を維持したまま解決する仕組みが論理関係（Logical Relationship）であり、その実体こそがペアセグメントだ。

2. 「物理ペア」と「仮想ペア」：設計思想の分岐点

ペアセグメントには、大きく分けて2つの実装形態がある。ここが設計者の腕の見せ所だ。

① 物理ペアリング（Physical Pairing）

同じ論理子セグメントを、両方のツリーに物理的に重複して格納する。

メリット: どちらのパスから辿っても、物理的にそこにデータがあるため、参照性能が極めて高い。
デメリット: 更新時だ。一方を更新すれば、DBMSは裏でもう一方のコピーも更新しなければならない。これに伴うI/Oコストと、万が一の不整合リスクを覚悟しろ。

② 仮想ペアリング（Virtual Pairing）

実体は片方にしか置かず、もう一方には「ポインタ」だけを置く。

メリット: データの実体は一つ。ストレージを節約でき、更新時の整合性管理がシンプルになる。
デメリット: ポインタを辿る際に別ブロックへのランダムアクセスが発生する。高負荷なオンライン処理では、この数ミリ秒が致命傷になる。

3. DDL（DBD）における定義の真髄

では、具体的な定義（DBD: Data Base Description）を見てみよう。ここでは「受注DB」と「部品DB」を繋ぐ例を想定する。

受注データベース (ORDER DBD)

DBD NAME=ORDERDB,ACCESS=HDAM,…

SEGM NAME=ORDER,BYTES=100,PARENT=0

論理子セグメントの定義
部品DBのPARTセグメントを論理親(LPARENT)として指し示す
PAIR属性で、部品DB側のペアセグメントを指定する

SEGM NAME=ORDPART,PARENT=ORDER, X
SOURCE=((PARTORD,DATA,PARTDB))
LCHILD NAME=(PART,PARTDB),PAIR=PARTORD,PTR=PAIRED

部品データベース (PART DBD)

DBD NAME=PARTDB,ACCESS=HIDAM,…

SEGM NAME=PART,BYTES=200,PARENT=0
LCHILD NAME=(ORDPART,ORDERDB),PAIR=PARTORD

ペアセグメントの実体

SEGM NAME=PARTORD,PARENT=PART, X
PTR=PAIRED, X
SOURCE=((ORDPART,DATA,ORDERDB))

解説:

`LCHILD` と `PAIR` キーワードによって、二つのセグメントが「運命共同体」であることを宣言している。
`PTR=PAIRED` を指定することで、DBMSに対して双方向のポインタ維持を強制する。
物理的な格納位置は別々だが、アプリケーションからはあたかも「部品の下に受注があり、受注の下に部品がある」ように見える。これが論理的な魔法だ。

4. 堅牢な設計パターンのための「鉄則」

現場でレビューをする際、私が必ずチェックするポイントだ。

A. データの局所性を意識せよ

ペアセグメントを定義する際、「どちらが頻繁に参照されるか」を徹底的に分析しろ。
頻繁に検索される側のツリーに実データを配置し、逆側を仮想セグメントにするのが定石だ。無駄なポインタ追跡（DASDのアーム移動）は、システムのレスポンスを確実に蝕む。

B. 交差データ（Intersection Data）の最小化

ペアセグメントには「注文数量」や「納期」といった、親子関係に付随するデータ（交差データ）を持たせることができる。
しかし、ここに巨大な可変長データを入れるのは三流の仕事だ。交差データが肥大化すると、ペアリングの更新コストが指数関数的に増大する。

C. 再編成（Reorganization）の運用設計

論理関係を持つDBの再編成は、単一DBのそれとは比較にならないほど複雑だ。
片方を再編成すれば、もう片方のポインタも張り替える必要がある。ペアセグメントを導入するということは、「運用フェーズのダウンタイム設計を背負う」ことと同義だと理解せよ。

5. パフォーマンス上の注意点：デッドロックの温床

ペアセグメントは、実はデッドロックの温床でもある。
アプリケーションAが受注DBから部品DBへアクセスし、同時にアプリケーションBが部品DBから受注DBへアクセスしたとする。
物理ペアリングやポインタ更新が発生する場合、DBMS内部で両方のレコードにロックがかかる。

「論理的な循環参照は、物理的なロック競合を招く」

これを回避するには、アクセス順序をプロジェクト全体で標準化（例：常に受注→部品の順でロックを取る等）するか、更新頻度が極めて高い場合はペアリングをあえて崩し、アプリケーション側で整合性を担保する「非正規化」の決断が必要になることもある。

結論

ペアセグメントは、階層型DBMSにおける「柔軟性」の象徴だ。しかし、それは物理構造という「重力」に抗うための高度な仕組みであることを忘れてはならない。

1. 物理か仮想か、参照頻度をもとに冷徹に判断せよ。
2. ポインタの連鎖が引き起こすI/Oコストをミリ秒単位で計算せよ。
3. 運用コスト（再編成）を設計に組み込め。

これができれば、君の設計したシステムは数十年耐えうる堅牢な基盤となるだろう。
今日の講義はここまでだ。質問がある者は、DBDGENのリストを持って私の席に来い。