階層型DBMSの深層：論理レコード連結における設計の極意
こんにちは。チーフアーキテクトの私だ。
今日のコードレビューで、また「論理親・論理子」の結合設計で迷走しているプルリクエストを見かけた。リレーショナルデータベース（RDB）のJOIN句に毒された脳のまま、IMSやIDMSといった階層型DBMS（Hierarchical DBMS）の領域に踏み込むと、必ず致命的な設計ミスを犯す。
階層型DBMSにおける「論理レコードの連結」は、単なるポインタの貼り合わせではない。ストレージの物理配置、アクセスパスのコスト、そしてデータ整合性のライフサイクルそのものを定義する極めて高度なエンジニアリング領域だ。
今日は、実務の現場で「お前、本当にわかって設計しているのか？」と問われたときに、自信を持ってコードとスキーマを見せられるよう、論理レコード連結の構造定義とマッピングルールの極意を伝授しよう。
—
1. 階層型DBMSにおける「連結」の本質
RDBのJOINは「遅延評価」だ。クエリが走った瞬間に、インデックスと一時領域を使って結合を解決する。
しかし、階層型DBMSの論理レコード連結（Logical Relationship）は「構造の事前固定（Pre-structured Binding）」である。
論理親（Logical Parent）と論理子（Logical Child）が異なる物理データベース（または同一DB内の異なるセグメント）に存在する場合、システムはポインタ（Logical Child Pointer）を用いて両者を結びつける。
[論理親セグメント (DB: A)] <---(論理子ポインタ)-- [論理子セグメント (DB: B)] この構造を定義するDDLにおいて、我々が意識すべきは「アクセスの非対称性」だ。論理親から論理子へのアクセスと、論理子から論理親へのアクセスでは、コストも定義の複雑性もまったく異なる。ここを理解していないと、バッチ処理でCPUとI/Oが爆発する。
—
2. スキーマ定義（DDL）の実際とマッピングルール
百聞は一見に如かず。具体的なDBD（Database Description）およびSEGM（Segment）定義の擬似コードを見てみよう。ここでは、顧客（論理親）と、別管理されている契約詳細（論理子）を論理連結するケースを考える。
実務レベルのDDL定義例
— ==========================================
— 1. 物理親データベース: 顧客マスタ (CUSTDB)
— ==========================================
DBD NAME=CustMasterDB, ACCESS=HIDAM
SEGM NAME=CUSTSEG, BYTES=250, PTR=TWIN
— 顧客IDをルートキーとする
FIELD NAME=CUSTID_F, START=1, BYTES=10, TYPE=C, KEY
— ==========================================
— 2. 物理子データベース兼 論理子を含むデータベース (CONTRACTDB)
— ==========================================
DBD NAME=ContractDB, ACCESS=HIDAM
SEGM NAME=CONTRSEG, BYTES=120, PTR=TWIN
— 契約IDをルートキーとする
FIELD NAME=CONTRID_F, START=1, BYTES=10, TYPE=C, KEY
— 【重要】論理子セグメントの定義
— 論理親（CustMasterDBのCUSTSEG）へのポインタを持つ
SEGM NAME=LOGICAL_CHILD_SEG, PARENT=CONTRSEG, BYTES=40, — 論理親へのポインタ領域を含むため物理セグメント内に配置
PTR=(LPARNT, TWIN), — LPARNT: 論理親ポインタの指定
LCHILD=(CUSTSEG, CustMasterDB) — どのDBのどのセグメントと結ぶか
FIELD NAME=L_CUSTID_F, START=1, BYTES=10, TYPE=C — 論理親のキーを保持する領域
チーフアーキテクトのコードレビュー視点
1. `PTR=(LPARNT, TWIN)` の指定:
論理子から論理親を辿るための `LPARNT` ポインタが確実に確保されているか確認しろ。これが抜けていると、論理子から親の属性を参照するたびにフルスキャン地獄が待っている。
2. 外部キーの冗長性（`L_CUSTID_F`）:
RDBであれば正規化して外部キー制約を張るだけで済むが、階層型では論理親のキーを物理的にどこに保持させるかのマッピングルール（VIRTUALかPHYSICALか）を明示する必要がある。ここでは検索性を考慮し物理保持（PHYSICAL）の設計としている。
—
3. 堅牢な設計パターン：双方向リンクと削除ルールの罠
論理レコード連結を設計する際、最もエンジニアが頭を悩ませるのが「データ整合性（Anomalies）」と「削除ルール（Delete Rules）」だ。
論理親が削除されたとき、論理子はどうなるべきか？
階層型DBMSでは、以下の3つのルールをスキーマ定義で厳格にコントロールできる。
- VIRTUAL（仮想）: 論理親側には実データを持たせず、ポインタのみで結合。
- RESTRICT（制限）: 論理子が存在する場合、論理親の削除を拒否する。
- CASCADE（連鎖）: 論理親が消えれば、論理子も自動的に消滅する。
推奨する堅牢な設計パターン
金融系や基幹系システムにおいて、マスターデータ（論理親）とトランザクション（論理子）を論理連結する場合、安易な `CASCADE` は厳禁だ。誤ったマスター削除が連鎖し、数百万件の契約トランザクションが一瞬で消失する障害を私は何度も見てきた。
実務では、`RESTRICT`（または論理削除フラグの併用）をデフォルトとし、次のような方針でスキーマを固めろ。
[設計方針: 孤児レコード（Orphaned Record）の防止]
論理親削除時 ──> 論理子の存在チェック ──> 存在する場合はABORT（RESTRICT）
DDLの `RMDIR`（Remove Directive）パラメータ等で、論理削除時の挙動を必ず明示的に定義せよ。「デフォルト任せ」にした瞬間に、運用フェーズでデータ不整合の爆弾を抱えることになる。
—
4. パフォーマンス上の注意点：ポインタ・チェインの劣化を防ぐ
RDBのインデックスはB+Treeだが、階層型DBMSの論理連結はポインタ・チェイン（双方向リスト等）に強く依存する。
ここで発生するのが、「チェインの肥大化とI/Oスキュー」だ。
1つの論理親に対して、何万件もの論理子が論理連結されている構造（1対多の「多」が極端に多い場合）を考えてみてほしい。
[論理親] <---> [論理子1] <---> [論理子2] <---> … <---> [論理子N (数万件)]
この状態のとき、最後の論理子にアクセスするためには、DBMSはポインタを数万回たどる（あるいはセグメント間を物理的にジャンプする）必要がある。これはCPUバウンドかつI/Oバウンドの最悪なボトルネックを生む。
パフォーマンスチューニングの極意
1. 論理連結の深さを制限する: 論理親から論理子、さらにその下の論理子孫（Logical Grandchild）へとチェインを伸ばすな。構造が複雑化するほど、ポインタのメンテナンスコスト（挿入・更新時のオーバヘッド）が跳ね上がる。
2. ハッシュアクセスや二次索引（HIDAM/PHDAM）の併用: 論理子側のアクセスパスにおいて、ポインタ・チェインの全探索を回避するため、論理子セグメント自体に適切なルートキーや二次索引を張り、ダイレクトアクセスを狙え。
—
5. まとめ
階層型DBMSにおける論理レコードの連結は、単なる「データの関連付け機能」ではない。それは、システム全体のデータ構造の骨格であり、パフォーマンスの生命線だ。
- スキーマ定義: `LPARNT` や `LCHILD` のマッピングを正確に行い、アクセスの非対称性を意識せよ。
- 削除ルール: 安易なカスケードを避け、`RESTRICT` を基本として整合性を担保せよ。
- パフォーマンス: ポインタ・チェインの肥大化を防ぐため、1親あたりの子レコード数とアクセスの深さを常に監視・制限せよ。
この領域の設計を妥協する者は、やがて巨大な技術的負債という名のモンスターに足元をすくわれる。
今日のレビューから、君たちの手でその甘い設計をすべて叩き直してくれ。期待している。
コメント