物理配置を制する者が、階層型DBMSを制する
おい、設計レビューを始めるぞ。
今回のテーマは「階層型DBMSにおけるレコードの物理配置戦略」だ。
現代のWeb系エンジニアの多くは、リレーショナルデータベース（RDBMS）やNoSQLのドキュメントストア、あるいはグラフDBの感覚でスキーマを定義しがちだ。しかし、IMS（Information Management System）に代表される階層型DBMS（Hierarchical DBMS）の領域に足を踏み入れた瞬間、その甘い認識はシステム全体の致命傷となる。
RDBMSのように「論理設計を綺麗にしておけば、物理配置やオプティマイザが勝手によくしてくれる」なんて幻想は今すぐ捨てろ。階層型DBMSにおいて、論理的な親子関係の定義は、そのままストレージ上の物理的なクラスタリング配置に直結する。
今回は、ルートセグメントを起点としたレコードの物理配置メカニズムを解剖し、アクセス局所性を極限まで高めるための設計パターンと、現場で踏みがちな地雷について徹底的に伝授する。
—
1. 階層型DBMSの物理配置のメカニズム：なぜ「ポインタ」がすべてなのか
階層型DBMSのデータ構造は、根（Root）から枝（Segment）へと伸びる「木構造（Tree）」だ。だが、これを単なる抽象概念だと思ってはいけない。ストレージ（DASDなど）の上で、この木がどう配置されているか。それがパフォーマンスの生死を分ける。
物理的隣接性（Physical Contiguity）の幻想と現実
階層型DBMSの根幹をなす物理配置の基本思想は、「親子関係にあるレコードを、ストレージ上で物理的に可能な限り隣接させて配置する（Hierarchical Sequence）」ことにある。
[ルートセグメント: 顧客ID=001]
└─ [子セグメント: 注文ID=101]
└─ [孫セグメント: 明細ID=9001]
└─ [孫セグメント: 明細ID=9002]
└─ [子セグメント: 注文ID=102]
OSやストレージのブロックI/Oの観点から考えてみろ。
親レコードを読み込んだそのヘッドのまま、あるいは同一シリンダー・同一トラック内で子レコードを読み込めるか？ ここが命運を分ける。
リレーショナルデータベースであれば、JOINを行うために複数テーブルのインデックススキャンとランダムI/Oが発生する。しかし、階層型DBMSでは、セグメント間が物理的なメモリポインタ（ダイレクトアドレスまたは相対アドレッシング）で直結されている。
アクセスパスの固定化
階層型DBMSのDDL（あるいはそれに相当する生成言語）で定義されるセグメント階層は、そのままアクセスパスの物理構造を決定する。
— 【概念的なDDL例：顧客をルートとした階層定義】
DATABASE CUST_DB
SEGMENT ROOT CUSTOMER
IDENTIFIED BY CUST_ID (CHAR(8))
— 顧客情報セグメント
SEGMENT CHILD ORDER
DEPENDENT ON CUSTOMER
IDENTIFIED BY ORDER_ID (CHAR(10))
— 注文情報セグメント（CUSTOMERの直下に物理配置される）
SEGMENT GRANDCHILD ITEM
DEPENDENT ON ORDER
IDENTIFIED BY ITEM_ID (CHAR(6))
— 明細情報セグメント（ORDERの直下に物理配置される）
この定義により、DBMSのストレージエンジンは `CUSTOMER` -> `ORDER` -> `ITEM` の順序で連続した物理領域（あるいはポインタチェーン）を構築する。
ルートセグメント（`CUSTOMER`）にアクセスさえできれば、子である `ORDER` へのアクセスは、追加のインデックス探索コストをほぼゼロにし、ポインタを辿るだけで完了する。これがアクセス局所性（Locality of Reference）の極限だ。
—
2. 実務で使う設計パターン：物理配置を最適化する「3つの鉄則」
コードレビューの現場で、俺が若手によく言う「物理配置デザインの3大原則」を授けよう。これを外したら、どんなにハードウェアを盛ってもバッチ処理は終わらない。
鉄則1：アクセス頻度（ホットスポット）をルートに近づけろ
階層の深さ（Depth）が増すほど、物理的なポインタチェーンを辿るオーバーヘッドが増加する。
頻繁に参照・更新するトランザクションのターゲットデータは、可能な限り浅い階層、欲を言えばルートセグメント、あるいはルートの直下のセグメントに配置すべきだ。
- アンチパターン:
`COMPANY` (Root) -> `DEPARTMENT` -> `TEAM` -> `EMPLOYEE` -> `SKILL` (Deep)
個人のスキルを参照するたびに5階層分のポインタを辿るハメになる。
- 正しい設計:
アクセス頻度の高い「社員の直近ステータス」を上位セグメントに昇格させる、あるいは別ツリーとして独立させ、論理キー（外部キー的な参照）で結ぶ割り切りを持つこと。
鉄則2：可変長セグメントとオーバーフローの制御
階層型DBMSの物理配置において最も恐ろしいのは、セグメントの挿入・更新による断片化（Fragmentation）だ。
RDBMSのページ分割に近い現象だが、階層型では「子セグメントが追加された結果、同一物理ブロックに収まりきらなくなった場合」に深刻な影響が出る。オーバーフローエリアへの退避が発生した瞬間、物理的隣接性による高速アクセスという最大のメリットが霧散する。
【対策】
- 初期ロード時（Initial Load）に、将来的な拡張を見込んだ十分なスペース（Free Space / Padding）を各セグメントに確保するサイジング設計を行う。
- 高頻度で更新・可変長化する属性は、固定長の親セグメントから切り離し、別の子セグメントとして垂直方向に逃がす。
鉄則3：物理シーケンスと論理順序の調停（物理キーの選定）
兄弟セグメント（同一親を持つ複数の子）の物理的な並び順（Physical Sequence）は、ルートからのトラバーサル性能に直結する。
例えば、`ORDER` セグメントが `CUSTOMER` の下に複数ぶら下がる場合、これらを「注文日時の昇順」で物理配置するのか、「注文ID順」にするのか。
— 物理配置の順序を規定するキー定義の例
SEGMENT CHILD ORDER
DEPENDENT ON CUSTOMER
— 物理的にソートされて配置されるキーを指定
SEQUENCE FIELD = ORDER_DATE, ASCENDING
検索クエリやバッチ処理が「最新の注文」を常に必要とするのであれば、`ORDER_DATE` の降順（DESCENDING）で物理配置をソートさせておくべきだ。これにより、DBMSは最初のレコードにアクセスしただけで、ソート処理をスキップして最新データを取得できる。「足で稼ぐ」のではなく「物理配置で稼ぐ」のだ。
—
3. パフォーマンス上の注意点：この設計はシステムを殺す
最後に、実際の障害現場や性能チューニング案件で見てきた「最悪のアンチパターン」を警告しておく。
1. 「深すぎる階層（Deep Hierarchy）」の罠
「現実世界の組織図や部品表（BOM）をそのまま忠実にデータベースに表現したい」という美しい理想を持つエンジニアがいる。
階層が10階層、20階層と深くなった瞬間、ツリーのメンテナンストレードオフとポインタチェーンの維持コストがシステムを押しつぶす。1つのルートをロックした際の排他制御（Latching）の範囲も広がり、並行性（Concurrency）が劇的に低下する。
実務上の限界値は、通常「4階層〜5階層以内」に収めることだ。
2. ルートセグメントの肥大化（Fat Root Antipattern）
「子セグメントへのポインタチェーンを辿るのが面倒だから」という理由で、あらゆる属性をルートセグメントに詰め込む馬鹿がいる。
ルートが肥大化すると、1つのブロックに収まるルートレコード数が減り、インデックススキャン効率が悪化するだけでなく、バッファプール（Buffer Pool）のヒット率が急降下する。
「ルートは最小限の識別子とキー属性に絞り、実体データは子セグメントへ分散配置する」という、階層型本来の美しさを忘れるな。
—
チーフアーキテクトからの総括
階層型DBMSの物理配置設計は、ハードウェアの制約とデータ構造の特性をダイレクトに結びつける、極めてエンジニアリング主導の作業だ。
「とりあえず正規化しておく」といったRDBMS的な思考停止は通用しない。
- このデータは、ストレージのどこに置かれるべきか？
- 次のレコードへ移るとき、ヘッドやメモリは最短距離で動いているか？
この問いを常に自分に投げかけ、ポインタの挙動と物理ブロックの配置を頭の中で3D描画できるようになれ。それができて初めて、お前は真の「階層型DBMSを使いこなすエンジニア」と名乗る資格を得る。
次の設計レビューでは、この原則に則っていないスキーマは一切通さない。出直して来い。
コメント