【実務・中級編】論理データベースの制約 – 階層型DBMS

階層型DBMSの論理データベース制約：Insert/Delete/Replace Rulesが織りなす「生と死」のガバナンス

こんにちは。チーフアーキテクトの私だ。
今日のコードレビュー、あるいは基本設計レビューで、また君たちは「リレーショナル脳」のまま階層型（Hierarchical）モデルのスキーマを定義し、私を絶望させようとしたな？

「とりあえず外部キー制約（FK）を貼って、カスケード削除にしておけば安全です」
――甘い。

現代のエンジニアリングにおいて、リ relational データベース（RDB）が覇権を握って久しい。しかし、大規模なエンタープライズ領域や、厳密な親子関係・部品表（BOM）のコンテキストにおいて、階層型DBMS（IBMのIMSなど）が持つポアインタ構造と決定論的な整合性維持のメカニズムは、今なお色褪せない「極限の高速性」と「鉄の統制」を我々にもたらす。

今回は、階層型DBMSの真髄である論理データベースの制約（Insert / Delete / Replace Rules）について、実務の現場で絶対に知っておくべき設計の哲学と実装パターンを叩き込む。

—

1. なぜリレーショナル脳のままでは設計を誤るのか？

RDBのスキーマ設計は「宣言的」だ。制約を定義し、オプティマイザが実行計画を解釈する。
対して、階層型DBMSの制約は、データ構造のトポロジー（樹形図）そのものに埋め込まれた「物理的・論理的生存ルール」である。

階層型データベースでは、セグメント（RDBでいうテーブルや行に相当）が親子関係（Parent-Child）の樹形構造を形成する。
ここで重要になるのが、「親なき子ティティ（Child）は存在し得ない」という大原則だ。この原則を維持するために、DBMSのエンジンレベルで強制されるのが Insert（挿入）、Delete（削除）、Replace（置換） の3大ルールである。

これらを適当に設計すると、本番稼働後にデータ不整合（孤児セグメントの発生）や、意図しないカスケード爆発によるデータ損失を引き起こす。テクニカルリードとして、このルールを完全に手懐けなければならない。

—

2. 3大ルールの解剖学：Insert / Delete / Replace

スキーマ定義言語（DL/Iやそれに類するDDL）において、各セグメントにはデータムのライフサイクルを規定するルールを付与する。それぞれの挙動を、実務の視点から徹底的に分解しよう。

① Insert Rules（挿入ルール）: 「生まれ落ちる資格」

親セグメントが存在しない状態で、子セグメントを単体で挿入できるか？という問いに対する答えだ。

System（システム管理）: アプリケーション側が明示的に親を特定して挿入する。基本形。
User（ユーザー管理）: アプリケーションが挿入時に親ポインタを解決する。
Depends（依存関係・強制）: 親が存在しなければ絶対に挿入を拒否する。

【設計の勘所】
実務では、トランザクションの整合性を保つため、実質的にすべての実業務データで `Depends`（またはそれに類する厳格な制約）を強制すべきだ。「親がいない子」が発生する余地を与えた瞬間、そのデータベースは腐り始める。

② Delete Rules（削除ルール）: 「死は連鎖するか、孤立するか」

階層型DBMSにおいて、最も事故りやすく、最も設計の腕が問われるのがこのDelete Ruleだ。親セグメントを削除したとき、その配下にある膨大な子孫セグメント（Sub-tree）に何が起きるのか。

定義される主なオプションは以下の3つだ。

1. CASCADE（カスケード削除）

挙動: 親を消せば、子、孫、ひ孫まで容赦なく物理消去される。
ユースケース: 契約データとその明細など、ライフサイクルが完全に同期している場合。
危険性: 1回のDELETE文（あるいはDL/Iの `DLAB` 呼び出し）で、数百万件のレコードが瞬時に消え去るポテンシャルを持つ。ログとバックアップの準備なしに使えば、翌朝には懲戒免職だ。

2. RESTRICT / DENY（制限・拒否）

挙動: 配下に1件でも子セグメントが存在する場合、親の削除をエラーとして即座にrejectする。
ユースケース: 組織マスター（親）に所属する社員（子）が1人でもいるうちは、組織を廃止できないようにする場合。
堅牢性: 最も安全。データロストを防ぐための防壁となる。

3. VIRTUAL / LOGICAL（論理・仮想リンクの切断）

挙動: 物理的な実体は残すが、他のパスからの参照を切断する。

③ Replace Rules（置換ルール）: 「不変性の担保」

セグメントの更新（Update）における制約だ。特にシーケンスキー（一意キー）フィールドの書き換えを許すかどうかが肝になる。

ReadOnly / Fixed: 主キーや論理順序を決定するフィールドの値は、一度挿入したら変更不可。変更したい場合は「一度削除して再挿入（Delete & Insert）」を強制する。
Variable: 制限付きで更新可能。

【設計の勘所】
階層型DBMSは、物理的なポインタチェーンや順序（Sequence）でデータを保持していることが多い。キー値をその場で書き換えさせると、ツリー内のソート順序が崩壊し、インデックス（ポインタ）の再構築コストや整合性破壊を招く。基本的には 「キー項目のReplaceは禁止（Fixed）」 が鉄則だ。

—

3. 実践：堅牢なスキーマ定義とコードレビューの視点

ここで、架空の物流システムを例に、階層型DBMSのスキーマ定義（概念的なDDL）と、そこに潜む設計のアンチパターンを見てみよう。

アンチパターンな設計（レビューNG例）

— 【NG】場当たり的で制約が緩い設計
SEGMENT WAREHOUSE — 倉庫（親）
RULE (INSERT=USER, DELETE=CASCADE, REPLACE=VARIABLE);

SEGMENT INVENTORY — 在庫（子）
RULE (INSERT=USER, DELETE=RESTRICT, REPLACE=VARIABLE);

チーフアーキテクトのツッコミ:
> 「おい、ちょっと待て。`INSERT=USER` にしている理由はなんだ？アプリケーションのバグで親（WAREHOUSE）のポインタを指し間違えたらどうする？さらに、`DELETE=CASCADE` なのに `REPLACE=VARIABLE` でキーを自由に変えられる？ツリーの構造がグチャグチャになってパニックを起こす未来しか見えないぞ。書き直せ。」

模範的な堅牢設計（Good例）

— 【OK】決定論的かつ堅牢な整合性ガバナンス
SEGMENT WAREHOUSE
— 物理的なルートセグメント
KEY (warehouse_id)
RULE (
INSERT = SYSTEM, — システム管理による厳格な生成
DELETE = RESTRICT, — 子（在庫）が存在するうちは倉庫マスタを消させない
REPLACE = FIXED — 倉庫IDの改ざんは厳禁
);

SEGMENT INVENTORY
— 倉庫に依存する子セグメント
PARENT WAREHOUSE
KEY (item_id)
RULE (
INSERT = DEPENDS, — 親（WAREHOUSE）の存在が絶対条件
DELETE = CASCADE, — 倉庫が閉鎖される特例ケースでは在庫データも運命を共にする（※要上位承認）
REPLACE = FIXED — 品目コードのインプレース更新は禁止。必ずD&Iで行う
);

この設計であれば、
1. 親のない在庫データが入り込む余地はない (`INSERT = DEPENDS`)。
2. 誤ってアクティブな倉庫を削除しようものなら、DBMSが即座に例外を吐いて止めてくれる (`DELETE = RESTRICT`)。
3. キーの改ざんによるポインタチェーンの破損を防げる (`REPLACE = FIXED`)。

システムとしての「頑健性（Resilience）」が段違いだ。

—

4. パフォーマンス上の注意点：制約とトレードオフ

最後に、パフォーマンスの観点に触れておこう。
「すべての制約を厳しくすればするほど安全だ」というのは、素人の発想だ。アーキテクトは常にコストを計算する。

`DELETE = CASCADE` の深さとロック競合
巨大なサブツリーに対してカスケード削除が走ると、DBMSは配下の全セグメントに対して排他ロック（Xロック）を取得し、物理的にポインタを辿って削除・チェーンのつなぎ替えを行う。
対策: バッチ処理などで大量削除を行う場合は、カスケードに頼るのではなく、アプリケーション側でボトムアップ（子から親へ）にトランザクションを分割して削除するか、メンテナンスウィンドウを厳密に確保すること。
ポインタチェーンのメンテナンスコスト
Insert/Delete/Replaceのルールが厳格（特にポインタの整合性をリアルタイム検証するもの）であるほど、更新系トランザクションのオーバーヘッドは増大する。
しかし、RDBで多用される「JOINと外部キー制約の動的解決（コストの高いハッシュ結合やソート）」に比べれば、階層型DBMSのポインタ追跡は圧倒的に高速だ。制約のコストを恐れて論理整合性を緩めるな。

—

5. 結びにかえて

階層型DBMSのInsert / Delete / Replace Rulesは、単なる「設定値」ではない。それは、システムが守るべきビジネスドメインの「秩序」そのものである。

リレーショナルデータベースの柔軟さに慣れきった頭脳では、この厳格なトポロジーの管理を窮屈に感じるかもしれない。だが、ミッションクリティカルな現場で「データが壊れないこと」「意図しない不整合が絶対に起きないこと」の価値を痛いほど知る者にとって、この制約群は最高の盾なのだ。

設計レビューでこのセクションのルールが曖昧になっているコードを見かけたら、私の言葉を思い出してほしい。
――「制約を制する者が、データアーキテクチャを制する」。

次のレビューまでに、君たちのスキーマを完璧に仕上げておくように。健闘を祈る。