階層型DBMSの心臓部：「物理親」という呪縛と恩恵
多くの若手エンジニアは、RDBMSの柔軟なJOINに慣れきっている。だが、もし君がIMSのような「真の階層型DBMS」を扱う現場に立つなら、まず頭の中から「リレーション」という言葉を消し去る必要がある。
階層型DBMSにおいて、データはツリー構造という「物理的な実体」としてディスクに刻まれる。そして、その構造を支配する絶対的なポインタ、それが「物理親（Physical Parent）」だ。
今日は、この「物理親」という概念を、教科書的な定義ではなく、システムを設計・運用するプロの視点から解剖しよう。
—
1. 物理親とは何か：ポインタという名の「支配権」
階層型DBMSにおいて、セグメント（レコード）は親から子へとポインタで繋がれている。物理親とは、あるセグメントが従属する「直上のセグメント」を指す。
特筆すべきは、「子は物理親なしには存在し得ない」という制約だ。物理親が削除されれば、その配下の物理的な子セグメントは（論理的な整合性を保つために）自動的に断絶、あるいは削除される。この「親子関係の不可分性」こそが、階層型の最大の設計指針となる。
2. 実務設計における「物理親」の選定：運命の分かれ道
設計レビューでよくあるミスが、物理親の選び方だ。「論理的に関連があるから」という理由だけで親子関係を定義してはならない。
設計の鉄則：アクセスパスを「物理的」に最短化する
物理親を選ぶ基準は、「頻繁に行う検索の起点となるデータ」を親に据えることだ。
- 悪い例: 注文（Order）を親、顧客（Customer）を子にする（顧客単位の検索が困難になる）
- 良い例: 顧客（Customer）を親、注文（Order）を子にする（顧客IDをキーにすれば、その配下の注文履歴が物理的に隣接して配置される）
この設計を誤ると、I/Oは激増する。物理親へのアクセス後に子セグメントを探索する際、物理的な配置が「近接」しているかどうかが、スループットに直結するからだ。
3. パフォーマンスの深淵：ポインタ・チェイニングの罠
階層型DBMSのパフォーマンスを語る上で避けて通れないのが「ポインタ」だ。
[セグメントA: 物理親]
| (物理ポインタ)
[セグメントB: 子]
| (兄弟ポインタ: Twin Pointer)
[セグメントC: 子]
物理親から子へのアクセスには、ポインタを辿るコストが発生する。もし君が「子セグメントが膨大な数になる」ような設計をしているなら、物理親を介した子探索は地獄のようなI/O待ちを引き起こす。
エンジニアへのアドバイス:
親セグメントにすべてを詰め込む「デノーム（非正規化）」を恐れるな。階層型においては、物理親の配下に子をぶら下げすぎず、ある程度の深さで「冗長性」を持たせたほうが、検索性能は劇的に向上する。
4. 堅牢な運用パターン：物理親の再構成
運用において最も恐ろしいのは、物理親のキー値変更だ。物理親のキーが変わると、それに依存するすべての子セグメントのポインタ整合性を再構築しなければならない場合がある。
これを防ぐための実務上のパターンが「キーの不変性（Immutable Key）」の徹底だ。
- 物理親の識別子には、決してビジネスロジックが変更しうる値（名前や部署コードなど）を使ってはならない。
- 必ず「システム内部で生成したサロゲートキー（シーケンス番号等）」を物理親のキーとして固定せよ。
—
総括：階層型を支配する者は、物理配置を支配する
階層型DBMSは、現代のメモリリッチな環境ではレガシーに見えるかもしれない。しかし、その「物理的な位置関係を固定する」という思想は、超高負荷環境におけるデータ局所性の最適化という観点で、今なお最強の武器だ。
君が設計するシステムにおいて、「どのデータが物理親となり、どのデータをその配下に置くか」。この決定が、将来のシステムのレスポンスを決定づける。
設計書を書く前に、データが物理ディスク上でどう配置され、ポインタがどう走るかを頭の中でシミュレーションしろ。それができれば、君はもう階層型DBMSのマスターの一人だ。
さあ、次の設計レビューでは、ポインタの数まで語れるようになっていてくれ。期待している。
コメント