【第4回】階層型DBMSの深層：GNP (Get Next Within Parent) の極意とスコープ制御の美学
こんにちは。チーフアーキテクトの私だ。
今日のコードレビュー、あるいは基本設計レビューで、また「なんとなくGU（Get Unique）やGN（Get Next）を乱発して、バッチ処理の暴走やロジック破綻を引き起こしているコード」を見かけた。
リレーショナルデータベース（RDBMS）全盛の現代において、IMS（Information Management System）に代表される階層型DBMSの作法は、多くのエンジニアにとって「レガシーの遺物」に見えるかもしれない。しかし、その根底にある「ポインタによるナビゲーション」と「スコープの厳密な制御」の概念は、大規模分散ストレージやグラフDBのクエリ最適化においてもそのまま通用する普遍的なアーキテクチャだ。
今回は、階層型ナビゲーションの真髄である GNP (Get Next Within Parent) に真っ向から焦点を当てる。
この呼び出しがなぜ実務で不可欠なのか、そしてどう設計に組み込むべきか。私の知見のすべてをここに叩き込む。
—
1. GNPとは何か？ ― なぜGNではダメなのか
階層型DBMSの基本操作である GN (Get Next) は、物理的なストレージの階層構造（Pre-order / 先序走査）に従い、レコードの境界を無視してデータベース全体を次々とスキャンする。
ここで、以下の顧客（`CUSTOMER`）と注文（`ORDER`）の階層ツリーを想像してほしい。
[CUSTOMER: 顧客A]
├── [ORDER: 注文001]
└── [ORDER: 注文002]
[CUSTOMER: 顧客B]
├── [ORDER: 注文003]
└── [ORDER: 注文004]
もし、あなたが「顧客Aの配下の注文だけをすべて処理したい」という要件を GN で実装した場合、どうなるか？
顧客Aの最後の注文（`注文002`）を処理した後に再度 GN を発行すると、ポインタはツリーの境界を越え、顧客Bの最初の注文（`注文003`）へと突入してしまう。
この制御ミスを防ぐために、アプリケーション側で「今処理している顧客IDが変わっていないか」を毎回チェックするスパゲッティコードを書いたとしたら……それはアーキテクトとして失格だ。
GNPの定義とスコープの概念
GNP (Get Next Within Parent) は、その名の通り、「現在位置の親セグメントの配下（Within Parent）」という厳格な境界（スコープ）をシステム側で強制するナビゲーション命令である。
- 親のコンテキスト維持: GNPを発行すると、データベース管理システム（DBMS）は、現在位置の親セグメントが何であるかを内部的に保持し続ける。
- 境界防壁（Boundary Guard）: スキャンが親セグメントの配下を超えようとした瞬間（顧客Aから顧客Bへ移ろうとした時）、DBMSは `GB`（End of Data within Parent）ステータスを返し、安全にループを停止させる。
—
2. 実務コードに見る GNP の美しい制御パターン
実際のホスト言語（COBOLやPL/I、あるいはモダンなバッチ系ラッパー）を想定した擬似コードで、GNPを使った堅牢なループ処理を見てみよう。
- ====================================================================
- ルーチン名: 顧客A配下の注文明細処理
- アーキテクチャノート:
- GNで親を位置づけた後、GNPで子セグメントを安全にイテレートする。
- ====================================================================
01 PROCESS-CUSTOMER-ORDERS.
- 1. まず親（CUSTOMER）を特定して位置づける（GU呼び出し）
MOVE ‘CUST001’ TO CUST-ID.
CALL ‘CBLTDLI’ USING DB-GU,
CUSTOMER-SEGMENT,
CUST-SEARCH-ARG.
IF DLI-STATUS NOT = ‘ ‘
PERFORM HANDLE-ERROR
EXIT.
- 2. 親の配下に対するGNPループの開始
PERFORM UNLESS DLI-STATUS = ‘GB’
- 子セグメント（ORDER）の取得
CALL ‘CBLTDLI’ USING DB-GNP,
ORDER-SEGMENT
EVALUATE DLI-STATUS
WHEN ‘ ‘
- 正常取得時のビジネスロジック
PERFORM PROCESS-ORDER-DETAIL
WHEN ‘GB’
- 【重要】親の配下スキャンが完了（EndOfData Within Parent）
CONTINUE
WHEN OTHER
- 予期せぬシステムエラー
PERFORM HANDLE-FATAL-ERROR
END-EVALUATE
END-PERFORM.
このコードの美しさは、「子を読み出すループの中に、親のブレイクチェック（コントロールブレイク）を書く必要が一切ない」という点にある。親が変わった瞬間の判定はDBMSのストレージエンジン層が担保するため、アプリケーション層のロジックは極めて純粋に保たれる。
—
3. パフォーマンス上の注意点と物理ストレージの罠
チーフアーキテクトとして、綺麗事だけでなく実務上のダークパターンについても言及しておかなければならない。GNPを使う際、以下のハードウェア・ストレージ特性を理解していないと、バッチ処理の夜間バッチ枠が容易に炎上する。
① 仮想親ポインタ（Hierarchic Pointers）の欠落による性能劣化
IMSなどの階層型DBMSでは、セグメント間の物理的結合にポインタ（双方向ポインタ、あるいは子・親ポインタ）を使用する。
もし、子セグメントから親セグメントへ遡るためのポインタ（Parent Pointer）がスキーマ定義（DBD）で明示されていない場合、DBMSは親の境界を判定するために親セグメントまで物理的に逆流（Traverse）するコストを支払うことになる。
- 対策: GNPを多用するスキーマ設計では、DBD定義において `PTR=PA`（Parent）や `PTR=TWIN` が適切に張られているかを必ずストレージ管理者（DBA）と共に物理DUMPで確認しろ。ここをケチると、O(N)のスキャンがO(NM)のデッドロック温床に化ける。
② 修飾GNP（Qualified GNP）の誤用
GNPには、単に次のセグメントを取る「非修飾GNP」のほかに、条件を指定して次を取る「修飾GNP」が存在する。
しかし、大量の子セグメントが存在するツリー構造の中で、修飾GNPをループの頭で何度も発行すると、DBMSはツリーの線形探索（Sequential Search）を強いられる。
- 設計指針: 子の数が数千件を超えるような高密度セグメントに対して、GNPによる力技のフィルタリングを行ってはならない。そういう要件の場合は、セグメントの順序づけ（`SEQ` 指定）を見直すか、あるいは二次インデックス（Secondary Index）を組み合わせたアクセスパスへ設計を直せ。
—
4. チーフアーキテクトからの提言：現代のアーキテクチャへの示唆
「なぜ今さら階層型DBMSなのか」と思うかもしれない。
しかし、JSONやXML、さらにはProtocol Buffersなどの「階層構造を持つドキュメントデータ」を扱う現代のマイクロサービスやNoSQL（MongoDBやDynamoDBなど）の設計においても、この「スコープを限定した走査」の概念は全く古びていない。
RDBMSのJOIN地獄から逃れるためにドキュメント指向DBを採用した結果、アプリケーション側で「親ドキュメントの配列を舐めるときに境界を見失うバグ」をやらかす開発者を私は何度も見てきた。
- 親のコンテキストを明確にする
- 走査のスコープ（境界）をミドルウェア層に強制させる
- 物理的なポインタ構造とアクセスパターンを一致させる
GNPという古典的な仕組みの裏側にあるこの哲学を理解しているエンジニアこそが、どんなパラダイムのデータベースを扱おうとも、美しく堅牢なデータアクセス層を設計できる本物のプロフェッショナルだ。
次の設計レビューでは、ただ動くだけのコードではなく、こうした「スコープの美学」が宿ったコードを見せてほしい。期待している。
コメント