こんにちは！データベースの世界へようこそ。
今日は、少しレトロでありながら、現代のデータ管理の「源流」でもある「階層型DBMS（データベース管理システム）」の核心についてお話しします。
「階層型」と聞くと難しく聞こえるかもしれませんが、安心してください。ここをクリアすれば、データベース全体の仕組みに対する見方がガラリと変わり、基本はバッチリマスターできますよ。
今日はその中でも、データの秩序を守るための心臓部「論理データベースの制約（挿入・削除・置換ルール）」について、日常の例えを交えながら優しく紐解いていきましょう。
—
1. 階層型DBMSって、なに？（身近な例えで理解する）
現代の主流であるリレーショナルデータベース（表形式のやつです）と違い、階層型DBMSは「家族の家系図」や「会社の組織図」のように、親と子の関係（親子関係）がガッチリと一本の樹木のように繋がっているのが特徴です。
例えば、あなたの大好きな「スマホのフォルダ構造」を思い出してください。
- 「写真」フォルダを開くと、その中に「旅行」「ペット」という子フォルダがある。
- 「旅行」フォルダを消せば、中に入っている写真も一緒に消える。
階層型DBMSの基本もまさにこれです。データ同士が「親」と「子」の上下関係を持ってピラミッド状に並んでいます。この構造を維持するために、データの追加や削除には厳格なルール（制約）が設けられています。
—
2. 親子の絆を定義する「3つのルール」
階層型データベースでは、新しいデータをどう入れるか（挿入）、いらなくなったデータをどう消すか（削除）、データをどう入れ替えるか（置換）というルールを、スキーマ定義（DDL：データの設計図）であらかじめ決めておきます。
先輩エンジニアとして、このルールを分かりやすく3つに分けて解説しますね。
① 挿入ルール（Insert Rule）：親がいないと、子は生まれない
現実の世界でも、親がいないところに子供だけがポツンと存在することはできませんよね。階層型DBMSでも同じです。
- ルール： 子のデータ（セグメント）を新しく挿入するには、必ず「親のデータ」がすでに存在していなければならない。
- 日常の例え： 「社員証（子）」を発行するためには、その人が所属する「部署（親）」が会社に存在していなければならないのと同じです。部署がないのに社員だけを登録しようとしても、システムに「そんな親はいません！」と怒られてしまいます。
② 削除ルール（Delete Rule）：親を失った子は、どう生きるか？
これが一番ドラマチックで、実務でも重要なルールです。親のデータを削除したとき、その下にある子や孫のデータどう扱うかを決めます。だいたい次の3つのパターンが用意されています。
1. 連鎖削除（Cascade）： 親を消したら、子も孫も一網打尽に消す。（例：フォルダごとゴミ箱に入れたら中身のファイルも全部消える）
2. 孤立禁止（Denial）： 子がいるうちは、親の削除を絶対に許さない。（例：まだ部員が残っているのに、部活そのものを廃部にはできない）
3. 独立（Nullify / Disconnect）： 親を消しても、子は別の親にぶら下がるか、あるいは浮いた状態で残る。（例：クラスが解散しても、生徒のデータ自体は学校に残る）
設計図（DDL）を書くときは、「この親を消したら子はどうなるべきか？」をビジネスロジックに合わせて慎重に選ぶ必要があります。
③ 置換ルール（Replace Rule）：身分証の書き換え
データの「中身のアップデート」に関するルールです。
- ルール： データの値を書き換えるとき、そのデータの「アイデンティティ（キー項目）」勝手に変えてはいけない、といった制約です。
- 日常の例え： 戸籍の名前やマイナンバーの根本は簡単に変えられませんが、住所や連絡先ならいつでも変更できますよね。それと同じで、データベース上の「親子の繋がりを証明する重要な鍵」を勝手に置き換えてしまわないように制限をかけます。
—
3. スキーマ定義（DDL）のイメージを見てみよう
百聞は一見にしかず。階層型データベースでこれらのルールがどう定義されるのか、疑似的なコード（DDL）で雰囲気を感じてみましょう。
— 【階層型データベースのスキーマ定義のイメージ】
— 親セグメント：部署 (DEPARTMENT)
SEGMENT DESCRIPTION DEPARTMENT
KEY IS DEPT_ID; — 部署IDが親の目印（キー）
— 子セグメント：従業員 (EMPLOYEE)
SEGMENT DESCRIPTION EMPLOYEE
PARENT IS DEPARTMENT — 「部署」の子供であると宣言
KEY IS EMP_ID;
— 削除ルールの指定例
DELETE RULE IS CASCADE; — 親（部署）が消えたら子（従業員）も連鎖して削除する！
> 💡 先輩からのワンポイントコメント
> コード内の `DELETE RULE IS CASCADE` という部分に注目してください。ここを指定することで、「部署が消滅した瞬間に、所属する社員データも自動的に整理される」という整合性（データの矛盾がない状態）がシステムによって強制されます。人間の手でいちいち子データを消して回る必要がないため、データのゴミ（ゾンビデータ）が残らない美しい設計が実現できるのです。
—
4. まとめ：なぜこのルールが重要なのか？
私たちがなぜ、わざわざこのような厳格なルールを学ぶのか？
それは、「現実世界の複雑な関係性を、矛盾なくコンピュータの中に再現するため」に他なりません。
現実のビジネスや社会は、組織図、部品の組み立て表（BOM）、電車の路線図など、綺麗に整った「階層構造」で満ちあふれています。
その中で、
- 親のない子が勝手に暴走しないように（挿入ルール）
- 親がいなくなった残骸が放置されないように（削除ルール）
- データの正当性が歪められないように（置換ルール）
これらのルールがデータベースの土台でしっかりと見守ってくれているからこそ、私たちは安心してデータを預けることができるのです。
ここをしっかりと押さえておけば、どんなに古いレガシーなシステムであっても、あるいは最先端のグラフデータベースやドキュメントDBに触れるときであっても、「データの依存関係とライフサイクルをどう管理すべきか」という本質的な視点にブレがなくなります。
階層型DBMSの基本、見事にクリアです！お疲れ様でした！
コメント