階層型DBMSの核心：なぜ私たちは今、親セグメント（P）と子セグメント（C）の「論理的リンク」に立ち返るべきなのか
こんにちは。チーフアーキテクトの私だ。
今日のコードレビュー、あるいは基本設計レビューで、また君たちは「リレーショナルに毒された脳」で複雑なJOIN地獄のスキーマを持ち込んできたな。
「何でもかんでもRDBの第3正規形にすれば正義」という妄信は、そろそろ捨てたまえ。
現代の超高速トランザクション処理、あるいは特定のドメイン駆動設計（DDD）における集約（Aggregate）の物理的局所性を突き詰めていくと、私たちは奇しくも階層型DBMS（Hierarchical DBMS）が何十年も前に到達した「真理」に回帰することになる。
今回は、階層型DBMSの根幹をなす「親子関係（Parent-Child関係：P-C関係）」のデータ構造と、それを定義するDDLの極意を叩き込む。
「古臭い技術」などと侮るなかれ。ポインタチェインによる物理的近接性と階層整合性の強制こそが、極限のパフォーマンスを生む唯一の解なのだから。
—
1. P-C関係の本質：ポインタが紡ぐ「運命共同体」
RDBの外部キー制約（Foreign Key）は、いわば「論理的な約束事」に過ぎない。結合（JOIN）を行わじには親子の顔も見えないし、オプティマイザの機嫌次第でフルスキャンという地獄が待っている。
しかし、階層型DBMSにおけるP-C関係は違う。
親セグメント（Parent Segment）と子セグメント（Child Segment）は、物理的なアドレスポインタ（あるいはそれに準ずるダイレクト・リンク）によって直接結ばれている。
[ 親セグメント (Segment P) ]
│
├───(論理ポインタ)───> [ 子セグメント (Segment C1) ]
│ │
│ └───(双方向リング)───> [ 子セグメント (Segment C2) ]
│
└───(物理隣接/オーファン防止)
この構造が意味するのは、「親がいなければ子は存在し得ない（カスケードの物理的強制）」ということだ。
コードレビューで「親を消した後に子が宙ぶらりんになる（孤児レコードの発生）」というバグを見かけるたびに私は頭を抱えるが、階層型DBMSのP-C関係の設計においては、物理レベルでその悲劇が排除されている。
—
2. 厳格なスキーマ定義（DDL）の作法
では、概念を実際のコードに落とし込もう。
階層型DBMSのDDL（Data Definition Language）において、P-C関係の定義は「どの親の、どの下位に、どのセグメントがぶら下がるか」を極めて厳密に宣言する。
以下に、架空の標準的階層型DDL構文を用いて、堅牢なスキーマ定義の例を示す。
— =====================================================================
— スキーマ定義: 企業・組織階層システム (Enterprise & Department Hierarchy)
— =====================================================================
— 1. ルートセグメント（最上位親）の定義
— すべての階層の起点となる。DBMSはこのセグメントの物理配置をベースに最適化を行う。
DEFINE SEGMENT COMPANY_ROOT {
FIELD company_id CHAR(8) PRIMARY KEY, — 企業コード
FIELD company_name VARCHAR(64) NOT NULL, — 企業名
— アクセスパスのヒント（ハッシュ方式によるルート直接アクセス）
ACCESS_METHOD IS DIRECT_HASH(company_id)
};
— 2. 第1階層の子セグメント（部門セグメント）の定義
— COMPANY_ROOT の直下に位置する。P-C関係の明示的なバインド。
DEFINE SEGMENT DEPARTMENT_SEGMENT
PARENT IS COMPANY_ROOT { — ★ここで物理的・論理的親をバインド
FIELD dept_code CHAR(4) NOT NULL, — 部門コード
FIELD dept_name VARCHAR(32) NOT NULL, — 部門名
— 兄弟セグメント（同一親を持つ子同士）の物理的並び順の定義
— キー値昇順でポインタチェーンを構築し、検索コストをO(1)に近づける
ORDER BY dept_code ASC,
— 領域管理のポリシー
STORAGE (
INITIAL_EXTENT 64K,
NEXT_EXTENT 32K,
CLUSTER_RATIO HIGH — 親と同一シリンダ/ブロックへの近接配置を強く推奨
)
};
— 3. 第2階層の子セグメント（従業員セグメント）の定義
— DEPARTMENT_SEGMENT を親とする多重階層構造
DEFINE SEGMENT EMPLOYEE_SEGMENT
PARENT IS DEPARTMENT_SEGMENT {
FIELD emp_id CHAR(6) PRIMARY KEY, — 社員番号
FIELD emp_name VARCHAR(45) NOT NULL, — 氏名
FIELD joined_date DATE NOT NULL, — 入社年月日
ORDER BY emp_id ASC
};
チーフアーキテクトからの設計レビュー指摘事項
1. `PARENT IS` の明示性
どの親の傘下に属するかを曖昧にしてはならない。結合の方向性は一方向に限定され、循環参照（Cycles）はデータ構造レベルで完全に禁止される。これを破る設計を持ってきた者は、私のレビューを通過できない。
2. `ORDER BY` によるポインタチェーンの制御
子セグメントが複数存在する場合、それらは「双方向リングポインタ」等で連結されることが多い。検索時にどの順序で走査されるべきか（キー順か、挿入順か）をDDLで定義することは、インデックス戦略と同等の価値を持つ。
—
3. 実務における堅牢な設計パターン
階層型DBMSを実務で扱う際、P-C関係の設計で生死を分けるポイントは以下の2点だ。
パターンA：極端な深さ（Deep Hierarchy）の回避
「現実世界の組織図をそのまま10段階の階層にしました」――こういう設計をするジュニアが後を絶たない。
階層が深くなりすぎると、子セグメントへのアクセス時に辿るべきポインタのホップ数が増え、かえってオーバーヘッドになる。
【対策】 階層は原則として3〜4階層以内に収めよ。もしそれ以上の深さが必要なグラフ構造であれば、それは階層型のドメインではなく、ネットワーク型あるいはグラフDBの領域だ。
パターンB：物理的局所性（Clustering）の最大化
階層型DBMS最大の武器は、「親セグメントの物理的近傍に、子セグメントが連続して格納される」という点にある。
ディスクI/Oの観点から、親をフェッチした時点で子データ群も同一のページ／ブロック内にロードされていなければ意味がない。
上記のDDL例にある `CLUSTER_RATIO HIGH` のような指定を使いこなし、ストレージ層のキャッシュ効率を極限まで高めろ。
—
4. パフォーマンス上の注意点：子セグメントの「爆発（Explosion）」
忘れてはならない罠がある。「ファンアウト（分岐数）の制御」だ。
例えば、1つの親セグメント（例：倉庫）に対して、子セグメント（例：在庫品目）が 100万件 ぶら下がっているスキーマを想像してほしい。
階層型DBMSの走査は、親からポインタを辿って子を線形（あるいはツリー）にスキャンする。もし特定の親に子が集中しすぎると、その親レコードに紐づく子チェーンの走査だけでCPUとメモリ帯域が枯渇する。これを業界では「子セグメントの爆発（Child Explosion）」と呼ぶ。
対策：バケツ分かち（Virtual Partitioning）の導入
もし1つの親に対する子数が数万件を超えることが予見される場合、そのままP-C関係を結んではならない。
間に「ハッシュバケツ用擬似セグメント」を挟むか、あるいは親を論理的に分割（シャード化）する設計上の工夫が必要だ。
— 悪い例：1つの親に全従業員がぶら下がる
COMPANY_ROOT -> DEPARTMENT (全社一括の1部門) -> EMPLOYEE (100万人) [破綻する]
— 良い例：地域や部署コードのプレフィックスでセグメントを分割
COMPANY_ROOT -> REGION_SEGMENT -> DEPARTMENT_SEGMENT -> EMPLOYEE_SEGMENT
—
5. 結びにかえて
階層型DBMSのP-C関係の定義は、単なる「データの入れ子構造の表現」ではない。
それは、「アプリケーションが直面するアクセスパターンを、物理メモリおよびストレージのレイアウトに1対1でマッピングする」という、極めてハードウェア寄りの高次元なエンジニアリングなのだ。
次にデータベースのスキーマを設計するとき、自問したまえ。
「この関連は、本当にただのルーズな外部キーでいいのか？ それとも、運命を共にする強固なP-C関係として、物理レベルで縛るべきなのか？」
その問いに向き合った瞬間から、君たちの書くコードのパフォーマンスは次元が変わる。
設計の妥協は許さない。次のレビューを楽しみにしている。
コメント