DBD生成（DBDGEN）の極意：物理と論理の境界線を支配せよ
こんにちは。チーフアーキテクトの私だ。
今日のコードレビューで、また「なんとなく動く」だけの場当たり的なDBD（Database Description）定義を見かけた。
「なぜこのセグメント長にしたのか？」「なぜこのポインタ構造を選んだのか？」と問うと、返ってくるのは「前任者の踏襲です」というお決戒めの言葉だ。
レガシーシステムと呼ばれる領域、特にIMS（Information Management System）などの階層型DBMSにおいて、DBDGEN（Database Definition Generation）の出来栄えは、システム全体の寿命とスループットを決定づける。リ relational DBのように「後からインデックスを追加してチューニングすればいい」という甘えは、階層型モデルの前では一切通用しない。物理構造がそのまま論理構造を規定し、I/Oの効率のすべてを握っているからだ。
今回は、実務の現場で若手エンジニアが必ず直面する「DBDGENの設計と実装の急所」について、私の知見を余すところなく伝授しよう。
—
1. 階層型DBMSにおけるDBDGENの本質
DBDGENとは、データベースの物理的構造（Physical Structure）および論理的関係を定義するためのマクロアセンブラソースをコンパイルし、IMSコントロールブロック（DBDライブラリ）を生成するプロセスである。
ここで重要なのは、「物理的なストレージ配置の最適化」と「アプリケーションから見える階層ビュー」が、この数行のマクロ定義によって不可分のものとしてバインドされるという点だ。
リレーショナルデータベースがテーブルと外部キーで関係性を「抽象化」するのに対し、階層型DBMSはポインタと物理的近接性（Contiguity）で関係性を「具現化」する。したがって、DBDGENの設計を誤るということは、最初から歪んだ骨組みのビルを建て続けることに等しい。
—
2. 実践：堅牢なDBD定義の解剖
百聞は一見にしかずだ。まずは、実務で耐えうる堅牢なDBD定義のサンプルを見てほしい。
対象は、ECプラットフォームを想定した「顧客（CUSTOMER）をルートとし、その下に注文（ORDER）、さらにその下に注文明細（ITEM）」がぶら下がる階層構造だ。
- DBDGEN SAMPLE: ECプラットフォーム用顧客・注文管理データベース
——————————————————-
PRINT NOGEN
- 1. データベース全体の定義 (ACCESS手法の選定)
DBD NAME=CUSTDB,ACCESS=(HDAM,DFHIDX00),RMNAME=(DFHrc001,10,500,2048)
- 2. ルートセグメント: 顧客セグメント (CUSTSEG)
SEGM NAME=CUSTSEG,PARENT=0,BYTES=(150,50),
PTR=(TWIN,NOTWIN),
RULES=(IV,IV)
- ルートのシーケンスフィールド（顧客ID）定義
FIELD NAME=(CUSTID,SEQ,U),BYTES=10,START=1
- 3. 2階層目セグメント: 注文セグメント (ORDSEG)
SEGM NAME=ORDSEG,PARENT=CUSTSEG,BYTES=(80,20),
PTR=(TWIN,LPARNT),
RULES=(L,R)
- 注文セグメントのシーケンスフィールド（注文日時＋注文ID）定義
FIELD NAME=(ORDID,SEQ,U),BYTES=16,START=1
- 4. 3階層目セグメント: 明細セグメント (ITEMSEG)
SEGM NAME=ITEMSEG,PARENT=ORDSEG,BYTES=(40,10),
PTR=TWIN,
RULES=(L,R)
FIELD NAME=(ITEMID,SEQ,U),BYTES=8,START=1
DBDGEN
FINISH
END
このコードのどこが「プロの仕事」なのか、ポイントを絞って解説しよう。
—
3. 設計レビュー：コードに隠された3つの急所
① アクセス手法の選択（`ACCESS=` と `RMNAME=`）
今回のサンプルでは、ルートセグメントへのアクセスに HDAM（Hierarchical Direct Access Method） を採用し、ランダムライザー（`DFHIDX00`）を指定している。
- なぜHIDAM（索引付き）ではなくHDAMなのか？
- 顧客IDのような一意なキーで直叩きするトランザクション処理が全体の90%を占める場合、B+木構造の索引を辿るHIDAMよりも、ハッシュアルゴリズムでダイレクトにブロックをヒットさせるHDAMの方がI/Oコストが圧倒的に低い。
- `RMNAME=(DFHrc001,10,500,2048)` は、ルートアンチプロット（RAP）数と最大バイト数を制御する極めて重要なパラメータだ。ここを適当に決めると、ハッシュ衝突（Overflow）が多発し、一瞬でパフォーマンスが崩壊する。
② セグメント長とプレフィックスの妙（`BYTES=`）
`BYTES=(150,50)` の記述に注目してほしい。
- 第11パラメータ（150）は最大長、第2パラメータ（50）は平均長（可変長セグメントの場合）を意味する。
- 固定長であれば `BYTES=150` でよいが、可変長（Variable）を定義する場合、この平均長の見積もりが狂うと、ストレージのフラグメンテーション（断片化）を引き起こし、DBAから強烈な差し戻し食らうことになる。リアルな業務データを統計的に分析し、この数値を叩き出すのがシニアの仕事だ。
③ ポインタオプションの最適化（`PTR=`）
ポインタの指定は、更新処理のオーバーヘッドと密接に関係している。
- `CUSTSEG`（ルート）：`PTR=(TWIN,NOTWIN)`。ルートの双方向ポインタ（TWIN）は不要（HDAMのハッシュ管理のため）であり、無駄なポインタ維持コストを削る。
- `ORDSEG`（子）：`PTR=(TWIN,LPARNT)`。親セグメントへのポインタ（LPARNT）を持たせることで、子から親へ遡る際のI/Oを劇的に削減している。ただし、ポインタ数が増えればレコード更新時のプレフィックス領域の書き込みコストが増える。トレードオフを常に意識しろ。
—
4. パフォーマンス上の注意点：アンチパターンを踏み抜くな
現場でよくある失敗を挙げておく。設計時に以下の罠に落ちていないか、今すぐ自分のDBDを確認したまえ。
1. 階層の深さ（Hierarchy Depth）の暴走
階層型だからといって、4階層、5階層と深くするのは悪手だ。物理的な親子関係が深くなると、ルートから最下層までのパス（Path）をたどる際のホップ数が増え、結果的にゲッター（GU/GNコール）のCPUコストが跳ね上がる。原則として3階層以内に収めるのがモデリングの鉄則だ。
2. 不適切なシーケンスフィールド（`SEQ`）の定義
`FIELD NAME=(…,SEQ,U)` の `U`（Unique：一意性）をサボって重複を許容（M：Multiple）にすると、アプリケーション側のハンドリングが複雑化し、データ整合性バグの温床になる。どうしても重複が必要な場合を除き、原則は `U` を強制せよ。
3. フリースペース（FSPACE）の軽視
HDAMやHIDAMの定義において、データセットグループ（DSG）のフリースペースをケチると、挿入（ISRT）処理が頻発した瞬間にストレージがオーバーフローを起こし、チェイン（Chain）が伸びきってバッチ処理が夜間バッチの枠から溢れ出す。
—
5. チーフアーキテクトからのメッセージ
「レガシー」という言葉の裏に隠れて、構造の本質を理解することを放棄していないか？
リレーショナルだろうが、階層型だろうが、グラフDBだろうが、「ハードウェアの物理特性とデータのアクセスパターンをいかにアライメントさせるか」というアーキテクチャの根本原理は1ミリも変わらない。
DBDGENのコード1行1行には、システムの血肉が通っている。
明日のレビューでは、「なぜこのセグメント長なのか」「なぜこのポインタなのか」を淀みなく説明できるコードを持ってきなさい。
期待している。
コメント