階層型DBMSの深層：削除フラグ（プレフィックス・ビット）が握る物理整合性と極限パフォーマンスの設計哲学
こんにちは。チーフアーキテクトの私だ。
今日のコードレビューで、あるジュニアエンジニアが書いたスキーマ定義を見て、私は思わず赤ペンを止めた。
「先生、論理削除（Soft Delete）なので、セグメントの先頭に `DELETE_FLG` というVARCHAR(1)のフラグを持たせ、UPDATEで’1’に更新するようにしました」
……おいおい、ここはリレーショナルデータベースの緩い世界ではない。現代においても金融・航空・基幹系インフラの足回りで現役稼働する階層型DBMS（Hierarchical DBMS: IMS/DB等）の世界だ。
ツリー構造のポインタを辿り、物理的なシーケンシャルアクセスとダイレクトアドレッシングの極限で性能を絞り出すこの領域において、VARCHARでフラグを持たせるなどという愚行は、システム全体の寿命を縮める致命傷になり得る。
今日は、階層型DBMSにおける「削除フラグ（プレフィックス内のビットによる物理再利用制御）」の真実について、アーキテクトの視点から徹底的に叩き込んでやろう。
—
1. 階層型DBMSにおける「削除」のパラダイムシフト
RDBであれば、論理削除は単なるカラムのUPDATEだ。しかし、階層型DBMSのセグメント（Segment）において、削除とは「ツリー構造からの切り離しと、ポインタチェーンの再配線」を意味する。
ここで問題になるのが「物理空間の再利用（Space Reclamation）」だ。
動的に変動する可変長セグメント（Variable-length Segment）において、レコードを物理的に即座に削除（詰める）すると、ディスクI/Oのオーバーヘッドと断片化（Fragmentation）が爆発する。そのため、階層型DBMSでは、セグメントの物理的先頭プレフィックス（Prefix）領域に「削除ビット（Deletion Flag Bit）」を埋め込み、物理位置を維持したまま「論理的に無効化」するアーキテクトが標準採用されている。
[ 制御プレフィックス領域 ] [ ユーザーデータ領域 ]
+————–+——————+———-+————————+
| 削除ビット(1b)| セグメントコード(7b)| ポインタ | 顧客名 | 住所 | 属性… |
+————–+——————+———-+————————+
↑
ここの1ビットがミリ秒単位のI/O生死を分ける
この「プレフィックス内の1ビット」をどう制御するかで、バッチ処理のスループットが桁違いに変わる。
—
2. スキーm定義（DBD）とプレフィックスビットの構造
階層型DBMSの定義言語（DBD: Database Definition）において、この削除制御はセグメント記述子の低レイヤーで定義される。以下に、実務で耐えうる堅牢なDBDの例を示す。
———————————————————————-
- データベース記述 (DBD) サンプル
- 対象: 顧客ツリー構造 (ROOT: 顧客 -> CHILD: 契約)
———————————————————————-
DBD NAME=CUSTDB,ACCESS=HDAM,RMNAME=(DFSHDC40,200,500)
- 根セグメント (Root Segment)
SEGM NAME=CUSTSEG,
PARENT=0,
BYTES=(120),
PTR=(LL,TWIN),
RULES=(IVL,VAL,VAL)
- プレフィックス領域の論理削除を有効化 (REUSE=YES)
- ※物理削除を行わず、プレフィックスの削除ビットをONにする指定
LCHILD NAME=(DELXIDX,CUSTDB),POINTER=SNI
- 子セグメント (Child Segment) – 契約情報
SEGM NAME=CONTSEG,
PARENT=CUSTSEG,
BYTES=(80),
PTR=(LL,LPARNT,TWIN)
END
設計上の急所：`RULES=(IVL,VAL,VAL)` の意味
- `IVL` (Insertions/Updates/Deletions): 削除されたセグメント領域への「挿入（Insert）時の物理空間再利用（Insert-Vial-Logical）」を許可する設定。
- ここを適切に設定しないと、削除フラグが立っている（論理削除済みの）セグメント領域に、新しい子セグメントを上書き（再利用）できず、データベースが不毛な肥大化（Space Bloat）を起こす。
—
3. 堅牢な設計パターン：削除ビットと物理再利用のライフサイクル
実務の現場では、単にフラグを立てるだけでは不十分だ。以下のライフサイクルをコード（アプリケーション側のアクセスモジュール）およびDBMSの制御ブロックで厳密にハンドリングする必要がある。
パターンA：ソフトデリート（論理削除）フェーズ
アプリケーションが削除リクエストを発行すると、DBMSのアクセス・メソッド（DL/I等）は以下の処理をアトミックに実行する。
1. プレフィックス走査: 該当セグメントの物理アドレスを特定。
2. ビット反転: プレフィックスの最上位ビット（または専用の1バイトフラグ）を `0`（有効）から `1`（削除済み）へアトミックに変更。
3. ツリー整合性維持: 子セグメントが存在する場合、カスケード削除のポリシーに従い、配下のプレフィックスも連鎖的にビットを立てるか、あるいは「孤児（Orphan）」として切り離す。
パターンB：スペースリサイクル（再利用）フェーズ
新規セグメントの挿入時、DBMSはHDAM（Hash Direct Access Method）のシリンダーバッファ内を走査する際、この「削除ビット＝1」のセグメントを空き領域（Free Space）として即座に認識する。
[物理ブロック内]
+——————+——————+——————+
| Seg A (Active) | Seg B (Deleted) | Seg C (Active) |
| [Bit: 0] | [Bit: 1] | [Bit: 0] |
+——————+——————+——————+
↑
新規挿入時、この領域のバイト長(BYTES)が
収まれば、物理位置を変えずに上書き再利用！
この「物理位置を変えない上書き再利用」こそが、ディスクシークを最小化し、階層型DBMSのパフォーマンスを極限まで高める最大の秘訣だ。
—
4. パフォーマンス上の注意点：アンチパターンとチーフからの戒め
最後に、コードレビューで私が必ずチェックする「やってはいけないアンチパターン」を挙げておく。これらを犯した者は、容赦なく差し戻すので覚悟してほしい。
❌ アンチパターン1: ユーザーデータ領域に「削除フラグ」を定義する
- 愚行: プレフィックスのシステム制御領域を使わず、わざわざ業務データ領域に `DELETE-FLG PIC X(1)` を持たせ、アプリケーション側でUPDATE文（REPLコール）を発行する。
- 弊害: DBMSはそれを「通常のデータ更新」とみなすため、ポインタの再配線もスペースリサイクルも行われない。単にゴミデータが物理ブロックを圧迫し続け、I/Oコストが跳ね上がる。
- 正解: 必ずDBMSの標準機能であるプレフィックス領域の削除ビットを使用せよ。
❌ アンチパターン2: 削除後の再利用（Reorganization）の怠慢
- 弊害: 論理削除と上書き再利用を繰り返すと、セグメント内のフラグメント（断片化）が進行し、シーケンシャルスキャン時のヒット率が低下する。
- 対策: 定期的なデータベース再編成ユーティリティ（IBM IMSであれば `DFSURBO0` など）を夜間バッチに組み込み、削除ビットが立ったまま放置されているデッドスペースを物理的に回収・圧縮するフローを必ずアーキテクチャに組み込め。
—
結言
階層型DBMSにおける「削除フラグ」は、単なる真偽値の保管場所ではない。それは、物理メモリとディスクI/Oの限界に挑む先人たちが残した、空間効率化のための芸術的なハードウェア制御インターフェースである。
次に君たちがスキーマを定義し、あるいは古いシステムのモダナイゼーションを任されたとき、「たかが1ビット」と侮るなかれ。その1ビットの裏側にある物理再利用のメカニズムを完璧に支配できて初めて、一人前のアーキテクトと名乗る資格が生まれるのだ。
さて、それでは設計書の修正に戻るとしよう。レビューを期待している。
コメント