【実務・中級編】論理関係のタイプ – 階層型DBMS

物理の檻を超えよ：階層型DBMSにおける「論理関係」の極限設計と実装パターン

こんにちは。チーフアーキテクトの私だ。
今日のコードレビューで、また「物理階層に縛られた硬直したスキーマ設計」を見かけた。親セグメントの下に子セグメント、その下に孫セグメント……。確かに階層型DBMS（IMS等）の基本はツリー構造だが、現実世界のデータが綺麗な単一ツリーに収まると本気で思っているのか？

顧客（Customer）の傘下に注文（Order）があり、注文の傘下に商品（Product）がある。ここまではいい。では、「ある商品が、どの顧客から過去に注文されたかを高速に引きたい」「異なる部門間でマスタデータを共有したい」となったとき、物理的な親子関係だけでこれを解決しようとすれば、データの冗長化という悪夢か、あるいは迷宮のようなポインタ辿りのコードが出来上がる。

今回は、物理的な制約を軽やかに突破し、保守性とパフォーマンスを極限まで高める「論理関係（Logical Relationship）」の設計と実装パターンを叩き込む。実務で明日から使えるレベルまで解像度を上げて解説する。

—

1. なぜ「物理階層」だけでは生き残れないのか

階層型DBMSの根本思想は、物理的なストレージ上の隣接性（ポインタの鎖）による爆速のアクセス性能だ。しかし、これは諸刃の剣である。

1つのセグメントは、物理的に1つの親しか持てない（標準的な階層モデルの制約）。
現実のビジネス要件は 多対多（M:N） や グラフ構造 に満ちている。

このジレンマを解決するために、DBMSのベンダーたちは「論理関係（Logical Relationship）」という脱獄ルートを用意した。物理的な格納場所を変えずに、仮想的なポインタでセグメント同士を結びつける機能だ。これを使いこなせないようでは、階層型DBMSを触る資格はない。

—

2. 単方向論理関係 vs 双方向論理関係

論理関係には大きく分けて2つのタイプがある。それぞれの構造と、どのような地雷が潜んでいるかをコード（疑似DDL/FML）ベースで見ていこう。

① 単方向論理関係（Unidirectional Logical Relationship）

「見ることはできるが、逆からは辿れない」関係だ。
例えば、「部品（Part）」セグメントから、それが使用される「製品（Product）」の情報を参照したいケースを考える。部品は多くの製品に使われるが、物理的には製品のツリー構造とは別に管理したい。

[ 物理DB: 製品ツリー ]
Product (Root)
└── Bill-of-Materials (Child)

[ 物理DB: 部品マスタ ]
Part (Root) ──(論理ポインタ)──> [Product側へ接続]

設計の急所:
単方向は、参照の方向が決まっている場合にオーバーヘッドが最も少ない。しかし、「この部品を使っている製品を一覧表示し、さらにその製品の別の属性を更新したい」といった要件が出た瞬間、メンテナンス性が破綻する。読み取り専用の参照にとどめるべきだ。

② 双方向論理関係（Bidirectional Logical Relationship）

実務で圧倒的に多いのがこれだ。論理親（Logical Parent）と論理子（Logical Child）を結び、両方向からお互いを実体として（あるいは仮想的に）ナビゲートできるようにする。

双方向関係を定義する場合、DBMS内部では「論理子（LC）」セグメントに対して、物理親へのポインタと論理親へのポインタ（LPtr）の両方が維持される。

—

3. 実務で使う設計パターンとDDL実装

百聞は一見にしかず。IMS DBを想定したDBD（Database Description）定義のイメージを見てみよう。ここでは、「社員（Employee）」が所属部門（物理親）とは別に、プロジェクト（Logical Parent）にアサインされている双方向論理関係の例を示す。

実装パターン：部門ツリーとプロジェクトの論理結合

— DBD定義のイメージ —

DBD NAME=DEPTDB 部門物理データベース
SEGM NAME=DEPT, …
SEGM NAME=EMP, PARENT=DEPT, … 物理的な社員セグメント
LCHILD NAME=(PROJEMP,PROJDB) プロジェクトDBへの論理子ポインタ

DBD NAME=PROJDB プロジェクト物理データベース
SEGM NAME=PROJ, … 論理親となるプロジェクト
SEGM NAME=PROJEMP, PARENT=PROJ,
LCHILD NAME=(EMP,DEPTDB) 社員セグメントとの双方向論理関係

この設計における極限の知見を授ける。

1. 論理子（Logical Child: `PROJEMP`）の実体配置
プロジェクト側から見た「アサインされた社員」を保持するセグメントをどこに置くか。これを誤ると、更新時のトランザクション整合性が崩壊する。基本は「変動が少ない側の親」に実体を置き、もう一方からは論理ポインタで引く形に正規化せよ。
2. カスケードルールの厳守（RULESパラメータ）
論理親（プロジェクト）が削除された時、論理子（社員のアサイン情報）をどう扱うか。

`RULES=(VIRTUAL)` （仮想）：実体は片方にしか持たず、もう片方は完全なポインタ参照。
`RULES=(PHYSICAL)` （物理）：双方向に実体データを同期させる（アンチパターンだ。整合性維持のコストでバッチが死ぬ。基本はVIRTUALを使え）。

—

4. パフォーマンス上の注意点：ポインタ追跡の罠

「論理関係を使えば何でも綺麗に結合できる」と喜んだジュニアエンジニアが、本番環境の性能テストで絶望する顔を私は何度も見てきた。

罠1：論理パスの深さとチェインの肥大化

論理関係を辿るということは、DBMS内部で異なるストレージ領域（または同一DB内の離れたセグメント）をポインタ経由でジャンプすることを意味する。

物理アクセス：ダイレクトあるいは同一シリンダー内の順次アクセス（高速）
論理アクセス：ポインタを辿るためのディスクI/O発生（場合によってはランダムI/Oの嵐）

対策:
論理関係を介した結合（Logical Join）をオンラインのトランザクションパスの深部で多用するな。どうしても必要な場合は、あらかじめ参照頻度の高いデータを非正規化（サマリー化）して持たせるか、高速パス用の二次インデックス（Secondary Index）を併用せよ。

罠2：デッドロックの温床

双方向論理関係のデータを更新（INSERT / REPLACE / DELETE）する際、物理親のロックと論理親のロックを同時に取得しに行くことになる。
アプリケーション側でアクセスの順序（ロック順序）を統一していないと、見事にデッドロックを踏み抜く。

鉄則:
論理関係を持つセグメントを更新するプログラムでは、必ず「物理親 $\rightarrow$ 論理親」またはその逆のロック順序を全社標準としてドキュメント化し、コードレビューで強制せよ。

—

5. チーフアーキテクトからの提言

階層型DBMSの論理関係は、リレーショナルデータベース（RDBMS）における「外部キー制約とJOIN」の先祖にあたる機能だ。しかし、RDBMSのようにオプティマイザが勝手に最適なJOIN経路を考えてはくれない。「どのポインタをどう張り、どちらの方向からアクセスさせるか」の全責任は、設計者である君たちにある。

美しいスキーマとは、コードの行数を減らすものではなく、「将来の変更に対する耐性を持ち、かつI/Oコストの物理法則に逆らわないもの」だ。

次回の設計レビューでは、ただ「論理関係が繋がっています」ではなく、「なぜこの方向の単方向/双方向なのか」「論理親削除時のカスケードでデッドロックが起きない証明はあるか」を私に説明できるようにしておきたまえ。

健闘を祈る。