【実務・中級編】階層・リレーショナル変換モデル – 階層型DBMS

階層型からRDBへ：先祖のDNAを読み解き、現代の設計に昇華させる

諸君、設計レビューを始める。

今さら「階層型DBMS（IMSなど）」の話をするのは、レガシーを懐かしむためではない。基幹システムのモダナイゼーション、あるいは複雑なツリー構造を持つドメインモデルを扱う際、「階層型の本質」を知らずにRDBを設計するのは、地図を持たずに未開の地へ突撃するようなものだからだ。

今回は、階層型DBMSのセグメント（Segment）構造を、現代のRDBへいかに論理的かつ堅牢にマッピングするか。その「極意」を伝授する。

—

1. 階層の正体：ポインタの鎖と物理的制約

階層型DBMSにおける「セグメント」と「親・子関係」の本質は、物理アドレス（あるいはレコードID）による直接リンクにある。

階層型: 物理的にデータが近接しているか、ポインタで直結されている。探索コストは極めて低い。
RDB: 集合論的アプローチ。データは論理的に独立しており、結合（JOIN）によって関係を再構築する。

この「物理的な繋がり」を「外部キー（FK）という論理的な繋がり」に変換する際、多くのエンジニアが「単にFKを置くだけ」という浅い思考に陥る。だが、それだけでは階層型が持っていた「データの整合性という強力な足枷」を捨て去ることになる。

—

2. 実践的変換パターン：セグメントからテーブルへ

階層構造をRDBに落とし込む際、以下の3つのパターンを使い分けろ。

パターンA：単純な1対多（Parent-Child）

最も基本的だが、最もミスが多い。

変換ルール: 親テーブルの主キー（PK）を子テーブルの外部キー（FK）として保持する。
設計の要諦: 階層型DBMSには「親が消えれば子も消える」という物理的な強制力があった。RDBではこれを`ON DELETE CASCADE`で再現せよ。

— 子テーブルには必ずNOT NULLかつCASCADE制約をつける
CREATE TABLE orders (
order_id UUID PRIMARY KEY
);

CREATE TABLE order_items (
item_id UUID PRIMARY KEY,
order_id UUID NOT NULL, — 物理的な「親子」を論理的に強制
CONSTRAINT fk_order FOREIGN KEY (order_id)
REFERENCES orders(order_id) ON DELETE CASCADE
);

パターンB：多階層の再帰（Recursive Relationship）

組織図や部品表（BOM）のような、階層が深くなる構造だ。

設計の要諦: 「隣接リストモデル」が定石だが、SQLの再帰クエリ（CTE）なしでは爆死する。パフォーマンスがボトルネックになる場合は、「閉包テーブル（Closure Table）」を採用せよ。階層の深さを問わず、全祖先・全子孫を別テーブルで管理する手法だ。

—

3. パフォーマンスの落とし穴：N+1問題を超えて

階層型DBMSでは、ポインタを辿るだけで済んだ処理が、RDBでは膨大なインデックススキャンに化ける。これが「RDBは階層データに弱い」と言われる所以だ。

堅牢な設計のためのチェックリスト

1. インデックスの貼る位置: FK列には必ずインデックスを貼れ。これは議論の余地がない。
2. 結合コストの予測: 階層が深い場合、JOINを繰り返すとプランナが迷走する。必要に応じて、「パス（Path）列」を文字列として保持する（例: `/root/node1/node2/`）デノマライズ（非正規化）を検討せよ。
3. 整合性の担保: 物理的なポインタを失った代償として、アプリケーション層で「孤立した子レコード」を作らせない設計を徹底しろ。

—

4. チーフアーキテクトからの助言

私が設計レビューで最も厳しく見るのは、「なぜその階層構造が必要なのか」というドメインの本質への理解だ。

階層型DBMSの設計者は、常に「親・子・兄弟」という関係性の中でデータの生存期間を定義していた。RDBへ移行する際、その「生存期間の連動（ライフサイクル）」をアプリケーションコードにまで引き継いでいるか？

データモデルはドメインの写像である。
RDBのテーブル定義は、単なる保存箱ではなく、ビジネスルールそのものである。

階層からリレーショナルへの変換は、単なるデータの置き換えではない。「物理的な制約」から「宣言的な整合性」への昇華である。

もし君が「とりあえずFKを貼ったから動く」というレベルで止まっているなら、今すぐ設計をやり直せ。階層型の設計思想が持っていた「厳格さ」を、現代のRDBの柔軟性の中に再実装してこそ、真のエンジニアだ。

—

次回のレビューでは、実際に稼働している大規模なBOMモデルの変換事例を紐解こう。準備はいいか？妥協なき設計を期待している。