階層型DBMSの深淵：物理ポインタが支配する整合性の極致
リレーショナルモデルが「集合論」という抽象的な美学に逃避する一方で、我々が対峙する階層型DBMS（IMS等）は、物理的なアドレスという「冷徹な現実」そのものを管理する。
多くのエンジニアが階層型を「古臭いツリー構造」と誤解しているが、それは大きな過ちだ。階層型DBMSの真髄は、レコード間の関係性を、抽象的なキーの照合ではなく、物理的な隣接性（Adjacency）と直接アドレス指定（Direct Addressing）という、計算コストゼロのリンクで解決している点にある。
今日は、その中でも最も過酷で、かつアーキテクトの腕が試される「削除ルール（Deletion Rules）」の深層について語ろう。
—
1. 物理的制約としての「削除ルール」
階層型DBMSにおける削除ルールは、単なる論理的な整合性の話ではない。「ポインタの書き換え」という物理的操作を、いかにして無矛盾にトランザクション内で完結させるかという低レイヤの戦いそのものである。
削除ルールには主に以下の3つが存在する。
- PHYSICAL (P): 親を削除すれば、直下の子セグメントは強制的に道連れになる。
- LOGICAL (L): 親を削除しても、子への論理関係（ポインタ）が有効であれば削除を拒否する。
- VIRTUAL (V): 論理関係を優先し、物理的な階層構造を突き抜けて参照整合性を維持する。
なぜこれが「極限」なのか
もし君が大規模な物理データベースを設計するなら、このルールがディスクI/Oに与える衝撃を考慮しなければならない。例えば、親セグメントの削除時に大量の子セグメントが連鎖的に削除される場合、DBエンジン内部では「ポインタの連鎖追跡」によるランダムアクセスの嵐が発生する。
このとき、ページバッファのキャッシュヒット率を維持するための「順序的削除」や「ポインタの事前キャッシュ」といった低レイヤの最適化が、システムの生死を分ける。
—
2. 内部メカニズム：ポインタの不整合をどう防ぐか
階層型DBMSの核は「セグメント接頭部（Segment Prefix）」にある。ここに格納されたポインタ（親、子、兄弟、論理関係）こそが、整合性を担保する唯一の防波堤だ。
削除ルールが発動した瞬間、DBMSエンジン内では以下のような「ポインタ再構築」のシーケンスが走る。
/
- 概念的な疑似コード：親削除時の子連鎖削除処理
- 実際のエンジンでは、この処理はページロックを保持したままアトミックに行われる
/
void delete_parent_segment(Segment parent) {
// 1. 子ポインタをトレースし、物理的に隣接する子を順次探索
for (Child c = get_first_child(parent); c != NULL; c = get_next_sibling(c)) {
// 2. 削除ルールがPHYSICALであれば、再帰的に子を削除
if (rule == RULE_PHYSICAL) {
delete_parent_segment(c); // 再帰的破壊：物理整合性の担保
} else {
// 3. LOGICALの場合、ポインタの生存確認を行い、生存なら異常終了
if (check_logical_link(c)) {
abort_transaction(ERR_INTEGRITY_VIOLATION);
}
}
}
// 4. 親の物理領域を解放（フリースペース・マップの更新）
deallocate_page_space(parent);
}
ここで重要なのは、「削除」が物理的に何を意味するかだ。セグメントを消すということは、そのセグメントが占有していた物理アドレスを解放し、空き領域リスト（Free Space List）に組み込む必要がある。断片化を恐れて即座に圧縮を行えば、CPUコストが跳ね上がる。
—
3. アーキテクチャの極意：メモリと物理ストレージの狭間で
伝説的なシステムを設計する際、私は常に「ポインタの無効化」というコストを最小化することに腐心してきた。
- 遅延削除（Lazy Deletion）:
削除フラグを立てるだけで物理的なポインタ操作を後回しにする手法。バッチ処理で夜間にポインタの再リンクと領域圧縮を行うことで、オンライン時のI/O競合を劇的に抑える。
- 階層的ロック（Hierarchical Locking）:
削除ルールを適用する際、親から子へ向けてXロック（排他ロック）を伝播させるが、このとき「ロックの粒度」がボトルネックになる。セグメント単位ではなく、ページ単位でロックを最適化しつつ、論理的な整合性を維持する技術こそが、熟練アーキテクトの領域だ。
—
結論：階層型は「過去」ではない
現在、グラフデータベースやドキュメントストアが注目されているが、それらは皆、階層型DBMSが数十年前に到達していた「物理リンクの最適化」という課題を再発見しているに過ぎない。
階層型DBMSの整合性規則を理解することは、コンピュータがメモリ上のアドレスをいかにして「意味」に変換しているかという本質に触れることと同義だ。
君たちがもし、次世代のストレージエンジンを構築しようとしているなら、まずはこの「連鎖的な削除」のコストを、CPUクロック単位で計算するところから始めてみてほしい。そこにこそ、アーキテクトとしての真の知性が宿る。
—
「データベースを制する者は、物理メモリの断片化を友とする。」
—— 某所にて、伝説のアーキテクトより
コメント