階層型DBMSの呪縛：なぜ「多対多」は我々を狂わせるのか
君たちが今、RDBMSやNoSQLの恩恵を当たり前のように受けているのは、先人たちが「木構造」という名の檻の中でどれほど血を流してきたかを知らないからだ。
階層型DBMS。IBMのIMS（Information Management System）に代表される、この古き良きアーキテクチャ。物理的なストレージ効率とポインタの追跡による高速なレコードアクセスは、現代の疎結合なデータモデルにはない凄みがある。
だが、一度「多対多（M:N）」の現実を突きつけられた瞬間、階層型は牙を剥く。今日は、この構造的弱点と、それをどうハックするかについて語ろう。
—
1. 階層の檻：多対多が突きつける「物理的制約」
階層型モデルにおいて、データは「親」と「子」のペアレント・チャイルド関係（PCR）で表現される。これはシンプルで強力だ。しかし、この「1つの親に複数の子」という制約は、実世界を記述するにはあまりにも脆い。
例として、「学生」と「科目」の多対多関係を考えてみてほしい。
- 学生 A は「数学」と「物理」を履修している。
- 学生 B も「数学」を履修している。
これを階層型で素直に組むとこうなる。
[学生A] –+–> [数学]
+–> [物理]
[学生B] –+–> [数学]
ここで「数学」のデータが物理的に重複していることに気づくか？
もし「数学」の教室番号が変更になったらどうする？ すべてのツリーを走査して、重複している「数学」ノードを一つ一つ書き換えなければならない。 これがデータの冗長性が引き起こす「更新時不整合（Update Anomaly）」の悪夢だ。
2. 賢明なエンジニアが取るべき「ポインタ・ハック」
この冗長性を回避するために、かつてのアーキテクトたちは「論理的親子関係」を導入した。物理的なデータは1箇所に置き、他の場所からはポインタ（論理リンク）で参照する手法だ。
推奨される設計パターン：物理的な分離と論理的結合
// 物理構造（データの実体）
[科目マスター]
|– [数学レコード] (物理ID: 101)
|– [物理レコード] (物理ID: 102)
// 階層構造（リンクによる多対多の実現）
[学生レコード]
|– [履修ポインタ] -> [科目マスター: 101]
この設計の肝は、「実体」と「関係性」を物理的に分離することにある。階層型DBMSのポインタ実装は、現代のJOIN演算よりも遙かに低コスト（ポインタを追うだけ）だ。だが、その代わり、データの整合性保証はアプリケーション層の責務となる。
3. パフォーマンスと整合性の均衡点
階層型DBMSでシステムを組む際、私がレビューで必ずチェックするのは「再帰的なデータ参照の深さ」だ。
- 物理ポインタの多用は諸刃の剣:
ポインタを多用すれば冗長性は排除できるが、ポインタの整合性を失った瞬間、システムは死ぬ。バックアップからのリストア時、論理リンクが切断されていないかを確認する「ポインタ整合性チェック」は、夜間バッチの鬼門だ。
- 読み取り速度の極限化:
もし読み取りが主体のシステムなら、あえて冗長性を許容し、データを非正規化してツリーに埋め込むべきだ。CPUサイクルを削ってポインタを追うより、物理的な連続読み込みの方が速いケースは多い。
4. 総括：システムを支配するな、構造に従え
君たちがこれから階層型DBMSを扱う、あるいはその思想を現代のシステム設計に応用しようとするなら、次の格言を刻んでおけ。
> 「物理的な冗長性を許容するか、論理的なポインタ管理の複雑性を許容するか。それ以外の選択肢はない」
階層型DBMSは、現代の汎用的なDBのように「何でもうまくやってくれる」わけではない。しかし、データへのアクセスパスが完全に固定されているような高トラフィックな領域では、依然として最強のツールになり得る。
冗長性を単なる悪と見なすな。それは、特定の条件下では「整合性を保つためのコスト」を「読み取り速度」に換金した結果に過ぎない。
設計において重要なのは、そのトレードオフを言語化できるかだ。コードレビューで「なぜ冗長にしたのか？」「なぜポインタを使わなかったのか？」と問われたとき、即座に論理的な回答ができるようであれ。それが、エンジニアとしての価値だ。
—
次回の講義では、階層型DBMSにおける物理的再編成（Reorganization）がいかに物理ストレージのフラグメンテーションを解決するか、その深淵に触れる。
コメント