【実務・中級編】参照整合性制約（ルール） – 階層型DBMS

階層型DBMSの深淵：参照整合性とポインタ同期の極意

テックリードの私だ。コードレビューや設計レビューで、若手から「なぜこのツリー構造の削除ルールでエラーが出るのか」「INSERT時のポインタチェーンの挙動がイメージできない」という質問をよく受ける。

現代のエンジニアの多くは、関係型データベース（RDB）やドキュメント指向DBのフラット、あるいは緩やかなJSON構造に毒されている。そのため、階層型DBMS（IMS等に代表される構造）における厳格な親子関係、物理・論理・仮想のポインタが織りなす「死の同期処理」に直面した途端、手足が凍りつく。

今回は、階層型DBMSのデータ構造とスキーマ定義（DDL）、そして最もクリティカルな「削除・挿入・置換時における参照整合性制約（ルール）」について、実務の現場で生き抜くための極限の知見を授けよう。

—

1. 階層型DBMSにおけるポインタペアリングの前提

まず、現代のRDBの外部キー制約（`FOREIGN KEY … ON DELETE CASCADE`など）という甘いお伽話は頭から捨ててくれ。

階層型DBMSのスキーマ定義（DDL）において、セグメント（RDBで言うテーブルに相当）間の結合は、ポインタによってハードコードに近い形で物理的・論理的に結ばれている。ここで重要なのが、ペアリングされるポインタの種別だ。

PHYSICAL（物理ペア）: 同一データベース内における、物理的なアドレス（RBA: Relative Byte Address等）による直接結合。最速だが、構造変更のコストが極めて高い。
LOGICAL（論理ペア）: 異なるデータベース間や、同一DB内の離れたセグメント間を、論理的なキー値の索引やセグメント・ポインタで結ぶ方式。
VIRTUAL（仮想ペア）: 論理ペアの変種であり、ポインタの実体を待たず、参照先のセグメントを「あたかも自セグメントの子孫であるかのように」見せかける省スペース設計。

これらが複雑に絡み合うツリー構造において、データを挿入（INSERT）・削除（DELETE）・置換（REPLACE）する際、DBMSのエンジンは背後で凄まじい整合性維持の演算を行っている。これを理解せずして、大規模バッチの設計など到底できない。

—

2. 削除（DELETE）時：カスケードの連鎖とポインタ切断の罠

セグメント削除における整合性ルールは、データ構造の存続を左右する最も危険な領域だ。

制御ルールの3パターン

階層型DBMSのDDL（あるいはそれに準ずるセグメント定義）では、親セグメント削除時の挙動を以下のルールで厳格に縛る。

1. CASCADE（連鎖削除）: 親を消せば、配下の子・孫セグメント、およびそれに紐づくすべてのポインタチェーンが物理的・論理的に消滅する。
2. RESTRICT（制限）: 子セグメントが存在する親セグメントの削除を完全拒否する。
3. NULLIFY（無効化）: 削除は許可するが、参照していた論理ポインタや仮想ポインタをヌル（無効アドレス）に置き換える。

PHYSICAL/LOGICAL/VIRTUAL ペアリングにおける挙動の違い

PHYSICALペアの場合:

物理的に直結しているため、親の `DELETE` に対する `CASCADE` は、データ領域の連続したパージ（ガベージコレクション）を引き起こす。ここで問題になるのが LOGICALペア との混在だ。親セグメントが別のデータベースから LOGICAL親 として参照されている場合、単純な `PHYSICAL` 削除を行うと、参照側の論理ポインタがダングリングポインタ（迷子のアドレス）と化し、システム全体をクラッシュさせる。

LOGICAL / VIRTUALペアの場合:

仮想ペア（VIRTUAL）で他ツリーから参照されているセグメントを物理削除しようとすると、DBMSは必ずエラー（あるいは例外割り込み）を発生させる。実務では、あらかじめ参照側（VIRTUAL子）を明示的に切断（Disconnection）してから親を消すという、厳格なトランザクション順序が強制される。

— 【設計レビューのチェックポイント：NGパターン】
— 仮想ペアで結ばれた参照先を、依存関係を無視して一括削除しようとするDDL/DML
DELETE SEGMENT Root_Customer WHERE CID = ‘C001’;
— ⚠️ 警告: VIRTUALペアリングされたOrder_Historyセグメントが存在するため、
— DBMSの整合性チェックにより異常終了（ABEND）します。

正しくは、アプリケーション側、あるいはプロシージャ内で「逆順のポインタ切断」を担保しなければならない。

—

3. 挿入（INSERT）時：親の存在証明とポインタチェーンの歪み

新しいセグメントを挿入する際、階層型DBMSは「どこに物理的/論理的コンテキストをつなぐか」の厳密な検証を行う。

挿入時の整合性ルール

Mandatory Parent（必須親）: 子セグメントを挿入するためには、必ず実在する親セグメントがツリー上に存在しなければならない。
Optional Parent（任意親）: 親が不在でも挿入を許可する（主に論理ペアや仮想ペアのルーツにおいて発生）。

ポインタ同期のメカニズム

例えば、既存の双方向チェーン（Forward/Backward Pointer）を持つセグメントの間に、新しい子セグメントを `INSERT` する場合を想像してほしい。

1. 物理配置の決定: フリースペース・マネージャ（FSM）が空き領域を探す。
2. ポインタの付け替え:

直前のセグメントの「次のポインタ（Forward Pointer）」を、新規セグメントのアドレスに向ける。
新規セグメントの「前のポインタ（Backward Pointer）」を直前のセグメントに向け、「次のポインタ」を直後のセグメントに向ける。

3. ペアリングの解決: もしこの新規セグメントが他のツリーから LOGICAL または VIRTUAL で参照される場合、索引セグメント（Intersection Data）へのエントリー追加が不可欠となる。

この挿入処理中に障害（電源断やデッドロック）が発生した場合、ポインタチェーンが途切れるため、データベース全体がセマンティックな破損状態（Corrupted）に陥る。実務では、このインサート時のコストを最小化するため、大量挿入時は一時的に制約のレベルを落とす（あるいは一括ロードユーティリティを用いる）のが鉄則だ。

—

4. 置換（REPLACE/UPDATE）時：キー値の変更とインデックスの破綻

「データの更新なんて、RDBの `UPDATE` と同じだろう」と思ったら大間違いだ。階層型DBMSにおいて、セグメント内のデータを置換（`REPLACE`）する行為、特にシーケンスキー（Sequence Key）やポインタのキーとなるフィールドを書き換える行為は、地雷原を歩くようなものだ。

置換時の制約ルール

1. シーケンスフィールドの変更禁止（Immutable Key Rule）:
ツリー内の順序を決めるキー値（例：顧客IDや受注日など）を `REPLACE` しようとすると、DBMSは即座にエラーを返す。なぜなら、キーが変わるということは、ツリー内の物理的・論理的なソート順序が変わり、バイナリサーチやポインタの順序が完全に破綻するからだ。
2. 論理ペアのキー変更時のカスケード同期:
LOGICALペアで結ばれた親のキーが変更された場合、参照している側（子側）の論理ポインタが保持している「ターゲットキー」も同時に更新されなければならない。これを怠ると、参照整合性が一瞬で崩壊する。

—

5. 堅牢な設計パターンとパフォーマンス上の注意点

この泥臭くも厳格な階層型DBMSの制約を逆手に取り、堅牢で高パフォーマンスなシステムを構築するための設計指針を授けよう。

パターン1：仮想ペア（VIRTUAL）を活用した非正規化の模倣

RDBであれば、多対多（M:N）の関係を解消するために交差テーブル（中間テーブル）を切る。しかし階層型DBMSでそれをやると、ポインタの迷宮に迷い込む。

解決策: マスターデータへのアクセスには VIRTUALペア を用いる。実体を二重に持たせず、ポインタだけで参照することで、データ更新時の不整合リスクを排除しつつ、ツリーの深さを浅く保つ。

パターン2：削除は「論理削除（フラグ方式）」への逃げ込みを検討せよ

物理・論理ペアが入り組んだ巨大な階層型DBにおいて、`CASCADE` による物理削除をオンライン処理で行うのは、排他制御（ロックの競合）の観点から自殺行為だ。

解決策: セグメントのD主要的削除は避け、ステータスフラグによる「論理削除（Logical Deletion via Flag）」を採用する。バッチ処理の夜間ウィンドウ等で、整合性を検証しながら一括パージ（Physical Purge）を行うアーキテクチャに設計すべきだ。

パターン3：ポインタチェインの深さ制限（Max Depth）

ツリー構造が深くなりすぎると、挿入・削除時のポインタトラバーサル（走査）コストが爆発的に跳ね上がる。

解決策: スキーマ定義の段階で「最大深度（通常は5〜7階層以内）」を厳守する。それを超えるリレーションが必要な場合は、あえて階層を切り離し、LOGICALペアによる疎結合な別データベースとして設計し直せ。

—

チーフアーキテクトからの総括

階層型DBMSの参照整合性制約は、単なる「ルールの集まり」ではない。それは、物理メモリやディスク上のポインタという剥き出しの現実と、データの論理的秩序を無理やり一致させるための防壁だ。

現代の抽象化されたフレームワークやDBに慣れきったエンジニアにとって、この厳格さは窮屈に映るかもしれない。だが、このポインタとルールの挙動を骨肉にした者だけが、どんなに複雑なスケールや障害に直面してもビクともしない、真に堅牢なデータアーキテクチャを組み上げることができる。

設計レビューでこの領域に踏み込むときは、コードの行数ではなく、「ポインタの向こう側で何が起きているか」を想像させろ。それができれば、君も一流のアーキテクトだ。