やあ。システムアーキテクチャの荒波を渡り歩いてきた者として、今日は少し「古くて新しい」話をしよう。
君たちが普段当たり前のように使っているデータベース（RDB）。でも、その歴史を遡ると、かつて世界を支配していた「階層型DBMS」という巨人に行き着くんだ。今日は、この巨人の正体と、なぜ現代のRDBへ移行するときに多くのエンジニアが頭を抱えるのか、その「痛みの本質」を紐解いていこう。
—
1. 階層型DBMSって、結局何者？
階層型DBMSを理解するための最も簡単な例え話がある。それは「Windowsのフォルダ（ディレクトリ）構造」だ。
親フォルダの中に子フォルダがあり、その中にファイルがある。この「ツリー構造」そのものだよ。
- 親（親セグメント）： 会社
- 子（子セグメント）： 部署
- 孫（孫セグメント）： 社員
データを取り出すときは、「会社→部署→社員」というように、必ず一番上のルートから順番に辿っていかなければならない。これが階層型DBMSの基本ルールだ。
階層型のここがスゴい！
実は、この仕組みは「読み込み速度」においては今でも最強クラスなんだ。データの場所が最初から物理的な「住所」として決まっているから、迷う必要がない。まさに、整理整頓された巨大な書類棚のようなものさ。
—
2. なぜ「移行」で苦しむのか？
さて、ここからが本題だ。なぜ階層型から現代的なRDBへ移行するとき、エンジニアは地獄を見るのか。
一番の理由は「親子関係の『縛り』が強すぎるから」だ。
階層型の「物理的な絆」
階層型では、子データは「親がいなければ存在できない」という絶対的な依存関係にある。さらに、データ同士は「ポインタ（次のデータの場所を指し示す矢印）」で物理的に繋がっている。
[会社A] ───> [部署X] ───> [社員T]
│
└─────────> [社員S]
この矢印を辿るのが、階層型のアイデンティティなんだ。
RDBの「自由な関係」
一方、RDBはテーブルという「平らな表」にデータを並べる。データ同士の繋がりは「外部キー」という、言わば「名札」で表現する。
- 階層型： 「親の直属の配下」という物理的な制約で繋がっている。
- RDB： 「IDが同じなら関連していると見なす」という論理的な約束事で繋がっている。
この「物理的な支配関係」を「論理的な対等関係」に解体する作業が、非常に厄介なんだ。
—
3. 移行の現場で直面する「3つの壁」
君たちが移行プロジェクトに関わるなら、きっとこの3つの壁にぶつかるはずだ。
1. 「多対多」の地獄
階層型は基本的に「1対多」しか表現できない。例えば「社員が複数のプロジェクトを兼務する」という構造を階層型でやろうとすると、物理的にデータを複製したり、ポインタを無理やり飛ばしたりして設計が崩壊する。これをRDBの「中間テーブル」という綺麗な形へ整えるのは、職人芸が必要なんだ。
2. 「ルートからの検索」という呪縛
階層型は「ツリーの頂点」からしか検索できない設計になっていることが多い。これをRDBへ移行すると、「特定の社員IDだけから、その人が所属する会社を逆引きしたい」という要求が出てくる。RDBなら一瞬だが、階層型で染み付いた思考を捨てないと、SQLのパフォーマンスを著しく落とすことになる。
3. 「ポインタ」の消失
階層型はデータの物理的な位置に依存する。RDBへ移す際、その「ポインタ（住所）」をすべて「論理的なID」に変換しなければならない。このマッピング作業をミスすると、データが宇宙の彼方に消えてしまうような感覚に陥るよ。
—
まとめ：階層型を理解することは「データの骨格」を知ること
階層型DBMSは、決して過去の遺物じゃない。君たちが普段書いているSQLの裏側で、データベースエンジンがどうやってツリー構造を検索しているか、その「根源的な知恵」がここに詰まっているんだ。
ここをクリアするためのアドバイス：
「階層」を「物理的な支配」と捉えるのをやめて、「データの持ち主と属性」という関係性に分解してみよう。そうすれば、RDBへの移行設計はパズルを解くように楽しくなるはずだよ。
階層型を制する者は、データの構造を制する。
さあ、恐れずに巨人の背中に乗ってみよう。きっと、今のシステムをより深く理解できるはずだ。
応援しているよ。何か詰まったら、いつでも聞きに来るといい。
コメント