【DBDの極意】物理データベース記述で抉る、階層型DBMSの肉体と魂
おい、コードレビューの手を止めろ。
今、お前たちが画面に向かって叩き込んでいるリレーショナルな正規化の常識、一度その脳みそからキレイさっぱり消去しろ。今日は、現代のクラウドネイティブな脳には少し刺激が強すぎるかもしれない、しかし極限のパフォーマンスを叩き出すための古くて新しい要塞――階層型DBMS（Hierarchical DBMS）の「物理データベース記述（DBD：Database Description）」について徹底的に解剖する。
俺たちが扱うのは、ふわっとしたオブジェクト指向の抽象レイヤーでもなければ、気まぐれなオプティマイザが支配するRDBMSの世界じゃない。ベアメタルに近いストレージの物理配置、ポインタチェーン、そしてミリ秒単位のオーバーヘッドすら許されない極限の世界だ。
心して聞け。これからお前たちに、実務で絶対に生き残るためのDBD設計の真髄を伝授する。
—
1. 物理データベース記述（DBD）とは何か？
DBDとは、階層型DBMS（IBMのIMSなどをイメージしろ）において、データの物理的な格納構造、セグメントの配置、ポインタの種別、そしてアクセスのための物理パスを完全に規定する「ストレージの遺伝子コード」だ。
RDBMSのDDL（`CREATE TABLE`など）が「論理的なスキーマ」を定義し、その物理配置をDBMSのエンジンに丸投げするのに対し、DBDは違う。「ディスクのこのセクタに、このセグメントをどう並べ、親子間をどのポインタで結ぶか」を人間（＝シニアアーキテクト）が物理レベルで支配する。ここを誤れば、システム全体の命運が絶たれる。
DBDの全体像（イメージ）
階層型DBMSのデータ構造は、根本的に「木構造（Tree Structure）」だ。
ルートから始まり、子、孫へとポインタで物理的に直結されている。この物理構造を定義するのがDBDのマクロ言語だ。
[DBD: 顧客管理システム]
└── [SEGM: 顧客 (Root)]
├── [SEGM: 契約 (Child)]
│ └── [SEGM: 明細 (Grandchild)]
└── [SEGM: 連絡先 (Child)]
—
2. 実務におけるDBD定義の具体例とコードレビュー
百聞は一見にしかずだ。典型的なDBDの定義コードを見てみこう。
以下のコードは、ある超高スループットが要求される金融系勘定系システムの顧客・口座・取引履歴をモデル化したDBDの模擬コードだ。
- =====================================================================
- 顧客管理システム物理データベース記述 (DBD)
- =====================================================================
DBD NAME=CUSTDB,ACCESS=HDAM,RMBN=CUSTRNG,Lrecl=4096
- — ルートセグメント：顧客基本情報 —
SEGM NAME=CUSTSEG,PARENT=0,BYTES=(256,128),
PTR=(TWIN,NOTINCL)
LCHILD NAME=(ACCNTSEG,ACCTDB),POINTER=DBD
FIELD NAME=(CUSTID,SEQ,U),BYTES=10,START=1
FIELD NAME=CUSTNAME,BYTES=40,START=11
- — 子セグメント：口座情報（顧客に属する） —
SEGM NAME=ACCNTSEG,PARENT=CUSTSEG,BYTES=(128,64),
PTR=(TWINBWD,LOGICAL)
FIELD NAME=(ACCTNO,SEQ,U),BYTES=12,START=1
FIELD NAME=BALANCE,BYTES=8,START=13
- — 孫セグメント：取引履歴（口座に属する） —
SEGM NAME=TRANSSEG,PARENT=ACCNTSEG,BYTES=(64,32),
PTR=TWIN
FIELD NAME=(TRANSDATE,SEQ,U),BYTES=8,START=1
FIELD NAME=AMOUNT,BYTES=8,START=9
DBDGEN
FINISH
END
チーフアーキテクトのコードレビュー眼：ここを見抜け！
お前らが書いたこのコード、レビューに回ってきたら俺はこう突っ込む。「おい、ポインタの指定とアクセス方式の選択に根拠はあるのか？」と。
1. アクセス方式の選定 (`ACCESS=HDAM`)
- ルートセグメントへのアクセスに `HDAM`（Hierarchical Direct Access Method）のハッシュアクセスを採用している。ランダムアクセスが多発する基幹系では、インデックスをいちいち辿る `HIDAM` よりも、ハッシュ関数によるダイレクトアクセスが命綱になる。ただし、ハッシュ衝突（Overflow）のチューニングを怠ると、一瞬でパフォーマンスが崩壊するぞ。
2. ポインタの物理指定 (`PTR=(TWINBWD,LOGICAL)`)
- 子セグメントの `ACCNTSEG` では、双方向ポインタ (`TWINBWD`) を指定している。片方向ポインタに比べて容量を喰うが、削除・挿入時のコストをO(1)に抑えるためのトレードオフだ。ここをケチると、バッチ処理の時間が倍に跳ね上がる。
3. 可変長セグメントの定義 (`BYTES=(128,64)`)
- 最大128バイト、平均64バイトの設計だ。物理ストレージのフラグメンテーション（断片化）を防ぐため、プレフィックス領域のサイズ計算は厳密に行う必要がある。
—
3. 堅牢なDBD設計パターン：実務の現場から
現場で生き残るための、DBD設計における2大原則を授けよう。
パターンA：「深さ」の制限とフラット化の判断
階層型DBMSの最大の罠は、「階層を深くしすぎること」だ。
「現行の業務フローがこうだから」と、親-子-孫-ひ孫-玄孫（5階層以上）と深く設計するバカがいるが、今すぐやめろ。階層が深くなると、物理的に離れたディスクブロック間をポインタで辿ることになり、I/Oの嵐を引き起こす。
- 鉄則: 階層は原則として3階層（Root-Child-Grandchild）以内に収めよ。それ以上の関係性が必要な場合は、論理関係（Logical Relationship）を張って別DBDへ逃がすか、非正規化をためらうな。
パターンB：接頭辞（Prefix）領域のサイズ最適化
セグメントの先頭には、必ずDBMSが管理するポインタや削除フラグ、論理長さが入る「プレフィックス領域」が存在する。
- 鉄則: フィールド定義の `START` 位置や `BYTES` は、必ず4バイトまたは8バイトパディング（境界整列）を意識して設計しろ。ハードウェアのメモリアクセス効率を無視したDBDは、高負荷時に確実にバスネックを引き起こす。
—
4. パフォーマンス上の注意点：破滅を回避するために
最後に、実運用で障害アラートを鳴らさないための致命的な注意点を挙げておく。
- フリースペース（FSPC）の枯渇に怯えろ
HDAMやHIDAMを定義する際、`FSPC=(blocks,bytes)` であらかじめ空き領域を確保する。これをサボると、データの挿入（INSERT）が発生した瞬間にストレージの断片化が進行し、オーバフローチェーンが爆発する。定期的なデータベース再編成（Reorganization）のスケジュールとセットでDBDを設計しろ。
- 物理ロギングとバッファプール（Buffer Pool）のチューニング
階層型DBMSの更新処理は、物理ポインタの書き換えを伴うため、RDBMS以上にトランザクションログの整合性がシビアだ。DBDで定義したセグメントサイズと、OS/DBMS側のバッファプール（BFPS）のページサイズがミスマッチを起こしている現場を見かけたら、即座に差し戻せ。ページ境界を跨ぐセグメント配置は、I/O効率をドブに捨てるようなものだ。
—
結びにかえて
階層型DBMSのDBD設計は、まるで古い建築物の耐震設計に似ている。
目に見えないポインタの糸、ディスク上の物理的な隣接性、そしてハードウェアの限界。これらすべてを完全に手中に収めた者だけが、RDBMSでは絶対に到達できない「圧倒的なスループット」という果実を手にすることができる。
「古い技術だから」と侮るなかれ。根底にあるデータ構造と物理レイアウトへの執念は、現代の分散ストレージやNoSQLの内部設計にも脈々と生きている。
お前たちの次の設計レビュー、このレベルの視座で書かれたDBDが出てくることを期待している。
手を動かせ。妥協するな。以上だ。
コメント