階層型DBMSの極意：PSB/PCBによる論理データ構造設計の深淵
こんにちは、チーフアーキテクトの私だ。
今日のコードレビュー、あるいは設計レビューの場において、「階層型DBMS（IMSなど）」の話題が挙がることは稀になった。世はすべからくリレーショナル、あるいはNoSQL、さらにはグラフDBの全盛期だ。
しかし、基幹系の深層、あるいは金融や航空といった絶対に止めてはならないミッションクリティカルな領域において、いまだに階層型DBMSの圧倒的な物理的整合性と予測可能なパフォーマンスは健在である。そして、その強さの源泉こそが 「物理構造からの完全な抽象化」、すなわち PSB（Program Specification Block） と PCB（Program Communication Block） による論理データベース記述に他ならない。
今回は、このPSB/PCBの本質を解き明かし、実務の現場で「どう設計すべきか」をロジカルかつシャープに伝授しよう。リレーショナル脳のままでは絶対に書けない、堅牢で美しい論理スキーマの設計論に入っていく。
—
1. なぜ「論理データベース記述」が必要なのか？
現代のエンジニアは、SQLの `JOIN` や ORマッパーの遅延ローディングに毒されている。「必要なデータは、後からどうとでも結合して取得すればいい」という甘えが、クエリの肥大化とパフォーマンス劣化を生む。
しかし、階層型DBMS（IBM IMS等）の思想は根本から異なる。
物理データベース（DBD: Database Descriptor）は、レコードがポインタチェーンによって物理的に硬直したツリー構造として配置されている。もしアプリケーションがこの物理構造を直接意識してプログラミングしたらどうなるか？
- 物理的なセグメントの追加・削除・並び替えが、直ちに全アプリケーションのコード書き換え（爆発的な影響範囲）を誘発する。
- アクセス経路が固定化され、異なる切り口でのデータ参照が不可能になる。
この「物理構造の呪縛」からアプリケーションを解放する防壁こそが、PCB（Program Communication Block） である。アプリケーションは物理DBDを直接見ない。PCBが定義する「自分専用の切り取られた世界（論理ビュー）」だけを頼りに動作するのだ。
—
2. アーキテクチャの核心：PSB と PCB の関係
設計に入る前に、構造を整理しておこう。
- PSB (Program Specification Block)
- 特定のプログラムが使用するすべての論理データベース（PCB）の集合体。プログラムの実行要件を定義するマニフェストである。
- PCB (Program Communication Block)
- アプリケーションから見た「1つの論理データベースのビュー」。
- 物理DB（DBD）のツリー構造から、どのセグメントを、どの階層順序で、どのような権限（Read/Insert/Update/Delete）で見せるかを定義する。
概念的アーキテクチャ
[物理層] 物理データベース (DBD)
└─ 顧客(Root) ─┬─ 口座(Child) ─ 伝票(Grandchild)
└─ 住所(Child)
↓ [論理抽象化 (PCB定義)] ↓
[論理層] アプリケーションから見たビュー (PCB)
├─ 視点A (入出金管理バッチ): 顧客 ── 口座 ── 伝票 (住所は見せない)
└─ 視点B (CRMバッチ) : 顧客 ── 住所 (口座は見せない)
この分離により、DBAが物理ストレージの最適化やセグメントの再配置（DBDの変更）を行っても、PCBの定義と射影が維持されている限り、アプリケーションのコードは1行も修正する必要がない。これこそが真の「データ独立性」である。
—
3. 実践：PCB/PSBの定義とコードレビューの視点
では、具体的な定義例を見ながら、レビューの現場で私がどこを見るのかを解説しよう。
例：口座管理システムのPCB定義（概念的記述言語）
—————————————————
- PCB定義: 顧客と口座情報のみに絞った論理ビュー
—————————————————
PCB DBDNAME=CUSTDB, 参照する物理DBD名
PROCOPT=G, 処理オプション (G=Get/参照のみ)
NAME=CUSTPCB アプリケーションから見たPCB名
- セグメント論理構造の定義（SENSEG = Sensitive Segment）
SENSEG NAME=CUSTOMER, ルートセグメント（顧客）
PARENT=0,
PROCOPT=G
SENSEG NAME=ACCOUNT, 子セグメント（口座）
PARENT=CUSTOMER, 親はCUSTOMER
PROCOPT=G 読み取り専用
チーフアーキテクトのコードレビュー視点：
1. 最小権限の原則（PROCOPTの厳格化）
- 「とりあえず更新もできるように `PROCOPT=A` にしておこう」という甘えを見つけたら即座にリジェクトしろ。このバッチが参照しかしないのであれば、厳格に `G`（Get）を指定するべきだ。誤った更新系権限は、バグによるデータ破損の最大のリスク源となる。
2. 不要なセグメントの排除
- 物理DBDに存在する `ADDRESS` や `MEMO` といったセグメントは、このPCB定義にはあえて記述（SENSEG）していない。アプリケーションからは「存在しないもの」として扱われるため、意図しない機密情報の露出や、不要なバッファ消費を防げる。
—
4. 堅牢な設計パターン：論理データ構造（Logical Database）の活用
実務で最も差がつくのが、「物理的に別々のDBDを、PCB上でいかに結合（Logical Relationship）して見せるか」という点だ。
リレーショナルDBであれば結合はSQLの `JOIN` の仕事だが、階層型DBでは「あらかじめ結合された論理DBD（LDBD）」を定義し、それをPCB経由でアタッチする。
設計パターン：顧客DBDと契約DBDの統合ビュー
物理的には「顧客ツリー」と「契約ツリー」が別個に存在するとする。しかし、契約管理バッチからは「ある顧客の配下に、その顧客の契約リストが直接ぶら下がっている」ように見せたい。
[物理DBD-A] 顧客(CUSTOMER)
[物理DBD-B] 契約(CONTRACT) ── (ポインタで物理DBD-AのCUSTOMERに論理接続)
[論理PCBの視点]
CUSTOMER (ルート)
└── LOG_CONTRACT (論理セグメントとして結合された契約)
設計上の注意点（パフォーマンスの罠）
論理リレーションを多用すると、ポインタを辿るためのI/Oオーバーヘッドが増大する。
- 双方向論理ポインタのコスト: 更新時の整合性維持（カスケード削除やポインタの張り替え）において、ロック競合や処理コストが跳ね上がる。
- 設計の鉄則: オンライントランザクション系のPCBでは、極力「単一物理DBD内で完結するツリー」を設計し、複雑な論理リレーション（LDBD）はバッチ処理用の専用PCBに限定すべきである。
—
5. パフォーマンス・チューニング：PCB位置づけと「位置の保持」
階層型DBMSの最大の武器であり、同時に諸刃の剣であるのが 「ポジション（カレント・ポジショニング）」 の概念だ。
リレーショナルDBは「集合指向（Set-oriented）」であり、結果セットは抽象的なテーブルだ。一方、階層型DBは「レコード志向（Record-oriented、ナビゲーショナル）」であり、DBMSは常にツリー内の「現在位置（Current of PCB）」を記憶している。
匠のチューニングテクニック：
大量のセグメントをシーケンシャルに処理するバッチプログラムにおいて、PCBの切り出し方と呼出順序（GU, GNPなど）がパフォーマンスの生死を分ける。
[処理フローのイメージ]
1. GU (Get Unique) : 条件に合致するルートセグメントを特定 (高コストなランダムI/O)
2. GNP(Get Next Parent): 親を維持したまま子セグメントを高速にシーケンシャル走査 (低コスト)
- アンチパターン: 毎回 `GU` を発行して子セグメントをルートから手繰り寄せるコード。論理ビュー（PCB）の階層構造を無視して不必要な親を再検索すると、インデックスの無駄撃ちが発生し、CPU時間を浪費する。
- 正しい設計: PCBの定義順序とアプリケーションのアクセスパスを完全に一致させ、`GNP（Get Next within Parent）` を最大限活用できる論理ビュー設計を行うこと。
—
結びにかえて
階層型DBMSにおけるPSB/PCBの設計は、単なる「設定ファイルの記述」ではない。
それは、「システム全体というカオスな物理的現実から、個々のプログラムのために美しく安全な秩序（論理的現実）を切り出す建築行為」である。
現代のマイクロサービスやドメイン駆動設計（DDD）における「境界づられたコンテキスト（Bounded Context）」や「データモデリングの隠蔽」の思想は、何十年も前の階層型DBMSのPCB設計思想にその源流を持っている。
もし君が今、レガシーシステムのモダナイゼーションや、極限のパフォーマンスが要求される基幹系の設計に挑んでいるなら、思い出してほしい。
「データをどう隠すか」「アプリケーションに何を見せないか」。
その境界線を引き締めることこそが、システムを半永久的に堅牢に保つ唯一の鍵なのだ。
コメント