データベースレコード型：階層型DBMSの論理スキーマ設計における極意
こんにちは。チーフアーキテクトの私だ。
今日のコードレビュー、あるいは新規システムの設計レビューで、また「リレーショナル脳」のまま階層型DBMS（Hierarchical DBMS）に挑み、見事に玉砕した設計書を見かけ申した。
「なぜリレーショナルデータベース（RDB）のように、とりあえずテーブルをフラットに切り、後からJOINすればいいと考えないのか？」
――もし君がそう思っているなら、今すぐその思考をアンインストールしてほしい。
階層型DBMSにおける「データベースレコード型（Record Type）」とは、単なるデータの入れ物ではない。それは、システムが表現すべき現実世界の「主従関係」そのものを物理・論理の境界で定義する、極めて厳格な契約なのだ。
今回は、この「データベースレコード型」の本質と、実務の現場で生き残るための堅牢なスキーマ設計、そしてパフォーマンスの急所について、一切の妥協を排して伝授する。
—
1. データベースレコード型とは何か？（本質的理解）
リレーショナルモデルが「集合論と述語論理」をベースにするのに対し、階層型モデルは「木構造（Tree Structure）」をベースにする。この世界において、データベースレコード型は、論理スキーマを構成する最小にして最強の単位である。
ここで重要なのは、「論理的なレコード型」と「物理的な格納形式」が完全に分離されているという点だ。
[論理スキーマ (Schema Definition)]
COMPANY (レコード型A)
├── DEPARTMENT (レコード型B)
│ └── EMPLOYEE (レコード型C)
└── PRODUCT (レコード型D)
開発者が定義すべきは、このツリー構造における「親レコード型」と「子レコード型」の親子関係（Parent-Child Relationship: PCR）の定義そのものである。
リレーショナル脳からの脱却
RDBでは、外部キー（Foreign Key）を張ることで、データ投入後にいくらでも動的に関係性を構築・変更できる。しかし、階層型DBMSのレコード型設計において、この動的結合の概念は存在しない。
レコード型の定義こそが、ディスク上のアクセスパスのハードコードであり、システムの実行計画（Access Path）をあらかじめ決定づける静的な構造なのだ。
—
2. 実務におけるスキーマ定義（DDL）とコードレビューの視点
では、実際のスキーマ定義言語（DDL）に近い概念で、堅牢なレコード型の設計を見ていこう。
ここでは、グローバル製造業のサプライチェーンを模した、極めてシリアスな例を挙げる。
【アンチパターン】すべてをフラットに並べた悲劇
— 【悪手】階層構造を無視し、IDだけで結びつけようとした設計
RECORD COMPANY {
company_id CHAR(10);
name VARCHAR(50);
};
RECORD FACTORY {
factory_id CHAR(10);
company_id CHAR(10); — 外部キーのつもり
location VARCHAR(50);
};
【チーフアーキテクトの指摘】
論外だ。これではRDBのシミュレーションを階層型でやっているだけであり、階層型DBMSの恩恵（ポインタによる高速な直接ナビゲーション）を完全にドブに捨てている。
【正しい設計パターン】親子レコード型による厳格なツリー構造
— 1. ルート（根）となる親レコード型
DATABASE RECORD COMPANY {
— 論理的な属性定義
SECURITY_CODE CHAR(4) NOT NULL, — 証券コード
COMPANY_NAME VARCHAR(100) NOT NULL, — 企業名
ESTABLISHED_DATE DATE NOT NULL — 設立年月日
— 格納方針の指定（物理独立性の確保）
STORAGE AREA IS CORP_MASTER_AREA
ACCESS VIA DIRECT
};
— 2. 子レコード型（DEPARTMENT: 部門）
DATABASE RECORD DEPARTMENT {
DEPT_CODE CHAR(6) NOT NULL,
DEPT_NAME VARCHAR(50) NOT NULL
— 【最重要】親レコード型との親子関係（PCR）の明示的定義
OWNED BY COMPANY
— 子データの物理的なクラスタリング指定（ポインタチェインの効率化）
CLUSTER
STORAGE AREA IS DEPT_DATA_AREA
};
— 3. 孫レコード型（EMPLOYEE: 従業員）
DATABASE RECORD EMPLOYEE {
EMP_ID CHAR(8) NOT NULL,
EMP_NAME VARCHAR(50) NOT NULL,
SKILL_LEVEL SMALLINT NOT NULL
OWNED BY DEPARTMENT
STORAGE AREA IS EMP_DATA_AREA
};
設計レビュー時のチェックポイント：
1. 親の存在なしに子は存在しうるか？（依存関係の確認）
従業員（EMPLOYEE）は必ず部門（DEPARTMENT）に属し、部門は必ず企業（COMPANY）に属する。この「生命の依存関係」がレコード型の階層と完全に一致しているか。
2. 多対多（M:N）の罠を回避しているか？
階層型は純粋なツリー（1:N）しか表現できない。もし「1人の従業員が複数のプロジェクトに所属する」といったM:N関係が必要な場合、レコード型を直接つないではならない。必ず「交差レコード型（Intersection Record Type）」を間に挟む設計になっているか確認しろ。
—
3. パフォーマンスとアクセスパスの極意
階層型DBMSの真価は、データアクセスにおいて「JOIN（結合）のコストが理論上ゼロである」という点にある。
RDBでは、10万件の企業から特定の従業員を探す場合、インデックススキャンとJOIN、あるいはハッシュ結合のコストが発生する。しかし、階層型DBMSでは、データベースレコード型同士が物理的なメモリ・ポインタ（チェイン）で直接結ばれている。
[COMPANY レコード]
│ (物理ポインタ: First Child)
▼
[DEPARTMENT レコード] ──(Next Twin)──> [DEPARTMENT レコード]
│ (物理ポインタ: First Child)
▼
[EMPLOYEE レコード]
実装上の注意点：ポインタ・チェインの枯渇と偏り
パフォーマンスチューニングにおいて、開発者が最も留意すべきは「扇形（Fan-out）のバランス」だ。
1. 極端なデブ・ツリー（Fat Tree）の回避
1つの親レコード型に対して、子レコード型が100万件ぶら下がるような設計（例: COMPANY直下に100万人のEMPLOYEE）をしてはならない。
ポインタ・チェインをたどる線形探索（Next Twinの走査）が発生した瞬間、階層型であっても性能はO(N)で劣化する。
対策: 必ず適切な中間レコード型（DEPARTMENTなど）を挟み、ツリーの深度（Depth）を適切に保ちつつ、分岐係数（Branching Factor）を均等化せよ。
2. 更新処理（INSERT/DELETE）時のポインタメンテナンス
レコード型定義において、子レコードの挿入順序（`FIRST`, `LAST`, `SORTED`）の指定を誤ると、頻繁なポインタ書き換えによるデッドロックやページ分割の嵐を招く。
特に理由がない限り、シーケンシャルな追加で済む `LAST` を選択し、ソートが必要な場合はアプリケーション側か、論理的なインデックスレコード型を別途設計すべし。
—
4. チーフアーキテクトからのメッセージ
階層型DBMSのデータベースレコード型設計は、単なる「データモデリング」ではない。それは「システムの寿命を決める骨格の彫刻」だ。
RDBのような「あとから何とでも直せる柔軟性」はない代わりに、設計さえ正しければ、現代のクラウド環境であっても、超高スループットかつ予測可能な低レイテンシを叩き出すことができる。
君たちが次に書くスキーマ定義書は、ただの「表の定義」になっていないか？
親子の絆を定義し、ポインタの流れる音に耳を澄ませる――その気概を持って、最高のシステムを作り上げてくれ。期待している。
コメント