【実務・中級編】論理子・論理親 (Logical Child/Parent) – 階層型DBMS

階層型DBMSの「禁断の果実」：論理関係（Logical Relationship）を極める

いいか、よく聞け。今の若いエンジニアたちは、RDBの正規化やNoSQLの柔軟性に毒されすぎて、データの「物理配置」という概念を忘れかけている。だが、我々が扱う階層型DBMS（IMSがその筆頭だ）において、データの物理的な局所性と論理的な関連性を分離し、ポインタで繋ぐという設計思想は、現代の分散システムにおいても極めて重要な示唆を与えてくれる。

今日は、階層型DBMSの真髄である「論理子（Logical Child）」と「論理親（Logical Parent）」について語る。これは単なるポインタ操作ではない。物理的な制約を超えてデータに「意味の橋」を架ける、最もエレガントかつ危険な技法だ。

—

1. なぜ「論理関係」が必要なのか？

物理的な階層構造（Physical Database: PDB）は、常に「主従関係」を強制する。例えば、「顧客」を親とし、「注文」を子とする物理DBを作ったとしよう。では、「商品」という別の物理DBにあるデータを「注文」から参照したいときはどうする？

単純に「注文」の下に「商品」を物理的に埋め込むと、商品のデータが各注文レコードごとに重複し、地獄のようなデータ不整合が待っている。

そこで登場するのが論理関係だ。
物理的には分離された二つのDB（顧客DBと商品DB）に対し、「注文」を媒介にして論理的な紐付けを行う。これが階層型DBMSにおける「多対多」を実現する唯一の解だ。

2. 論理子・論理親の構造を読み解く

論理関係を設計する際、以下の3つの役割を正確に理解しろ。

論理親（Logical Parent）: 参照される側のデータ（例：商品マスター）。
物理親（Physical Parent）: 論理子を保持している物理的な主（例：注文）。
論理子（Logical Child）: 二つの世界を繋ぐ「架け橋」となるセグメント。物理親の下に配置され、論理親へのポインタを持つ。

設計パターン：交差セグメントの配置

[物理DB: 注文DB] [物理DB: 商品DB]
顧客セグメント商品セグメント (論理親)
└─ 注文セグメント (物理親) ▲
└─ 注文明細 (論理子) ─────┘ (論理子ポインタ)

この構造により、注文明細セグメントは「注文」という文脈（Context）と、「商品」という実体（Entity）の双方に同時に属することができる。

3. エンジニアが陥る「パフォーマンスの罠」

理論は美しい。しかし、実務でこれを実装すると、必ずパフォーマンスの壁に突き当たる。以下の警告を刻んでおけ。

① ポインタの「追いかけっこ」によるI/O増大

論理子から論理親へアクセスする際、システムは論理親の物理アドレスを解決するために、内部的にポインタを辿る必要がある。これを頻発させると、ディスクI/Oが爆発する。

対策: 論理親が頻繁にアクセスされるなら、論理子側に必要な属性を「冗長」であっても保持させる（論理親のキー情報や、ごく一部の参照用属性など）。これを恐れるな。メモリをケチってI/Oで死ぬのが一番の愚策だ。

② データベースの再編成（Reorganization）

物理DB同士をポインタで結合しているため、一方の物理DBを再編成して物理アドレスが変わると、もう一方のポインタが腐る。

対策: `Symbolic Pointer`（物理アドレスではなく、論理親のキー値で保持する）を採用すべきか、`Direct Pointer`（高速だがアドレス依存）を採用すべきか。可用性と速度のトレードオフを、プロジェクトのフェーズに応じて決断しろ。

4. 実践的な運用の極意

論理関係を設計する際は、常に「参照の整合性」を誰が担保するのかを明確にしろ。

論理親の削除ルール: 論理親を消すとき、論理子はどうなる？物理DBをまたぐため、カスケード削除の設計は非常に複雑だ。安易に「物理親が消えるまで論理子は残す」という実装にすると、ゴミデータ（デッドポインタ）が累積する。
論理的キーの設計: 論理親のキーは不変であるべきだ。物理的なキー変更を許容すると、全論理子側のポインタ更新という「悪夢のバッチ処理」が待っている。

結びに：伝説のアーキテクトからの助言

論理子・論理親の設計は、RDBの「外部キー制約」よりも遥かに強力で、同時に遥かに脆い。
現代のマイクロサービスにおける「分散トランザクション」や「疎結合なデータ参照」に通じる概念が、ここには詰まっている。

「ポインタを貼ればいい」という安易な考えで設計するな。物理配置と論理アクセスのパスを頭の中で重ね合わせ、ディスクヘッドがどう動き、メモリ上でどうマッピングされるかを想像しろ。それが見えたとき、君は本当の意味で階層型DBMSを支配できるはずだ。

技術は変われど、データの本質は変わらない。さあ、設計書を書き直せ。もっと深く、もっと鋭く。