こんにちは！データベースの世界へようこそ。
今日は、少しレトロでありながら、データベースの「家族の絆」とも言える面白い仕組み——「階層型DBMS（データベース管理システム）」における、データの整合性と、親が消えたときのドラマについてお話ししますね。
ここをクリアすれば、階層型DBMSの基本はバッチリマスターできますよ！肩の力を抜いて、一緒に見ていきましょう。
—
1. 階層型DBMSって、身近な何に似ている？
難しい専門用語はちょっと置いておいて、まずは日常の例えから始めましょう。
会社組織や、パソコンのフォルダ（ディレクトリ）構造を思い浮かべてみてください。
「総務部」という親フォルダの下に、「人事課」「庶務課」という子フォルダがあり、さらにその下に社員のデータが入っていますよね。
階層型DBMSは、まさにこの「ツリー構造（木構造）」でデータを管理する仕組みです。
特徴はシンプルで強力。「すべてのデータ（子）には、必ずたった一人の親がいる」という絶対のルールがあります。
—
2. 「親が消えた！」そのとき、子どもたちはどうなる？
さて、ここからが今回の本題です。
もし、組織改編などで「親」にあたるデータ（例：総務部）を削除しなければならなくなったとき、その下でぶら下がっている「子どもたち（人事課や社員データ）」はどうなってしまうでしょうか？
現実の世界なら、部署がなくなったら社員は他の部署に異動したり、別の道を探したりできますよね。
しかし、昔のシステムである階層型DBMSの世界は、もう少しドライ（というか厳格）です。
崩壊の危機：ポインタの不整合
階層型DBMSの内部では、親と子は「ポインタ（矢印のような目印）」でガッチリ結ばれています。
もし、親のデータだけをスパッと消してしまうと、どうなるでしょう？
子どものデータから親をたどろうとしたとき、「あれ？ 親がいない……！？」というパニックが起きます。
これが、システムの世界でいう「ポインタの不整合」です。行き場を失った迷子のデータ（孤児レコード）がデータベースの海をさまよい、システム全体の故障や誤作動を引き起こす原因になります。
—
3. システムはどうやってこの危機を防ぐのか？（論理データベースの整合性）
この「親の消滅による迷子問題」を防ぐため、階層型DBMSにはシステム管理機能（ルール）がしっかりと用意されています。
親を削除しようとしたとき、DBMSは自動的に次のいずれかの対応をとります。
1. 連鎖削除（Cascade Delete）
- 「親が消えるなら、その下の子も孫も、すべて一緒にきれいに削除する」というドラスティックな方法です。
- 例：会社が完全に解散したら、そこに属するすべての部署と社員のデータも一緒に整理するイメージです。中途半端な迷子を作らないため、一番安全です。
2. 削除の拒否（Restrict / Deny）
- 「子どもが1人でも残っているうちは、親の削除を絶対に許可しない」という門番のようなルールです。
- 例：社員がまだ所属しているのに、勝手に部署を消そうとすると、パソコン画面に「エラー：子データが存在するため削除できません」と怒られる仕組みです。
—
4. スキーマ定義（DDL）のイメージをのぞいてみよう
言葉だけだと少し抽象的なので、スキーマ定義言語（DDL）の雰囲気をコード風に見てみましょう。（※実際の構文はシステムによって異なりますが、概念は同じです）
— 【親の定義】総務部テーブル
DEFINE SEGMENT DEPARTMENT (
DEPT_ID CHAR(4),
DEPT_NAME CHAR(30)
);
— 【子の定義】社員テーブル
— ここで「DEPARTMENT（部署）」が親であることが定義されています
DEFINE SEGMENT EMPLOYEE (
EMP_ID CHAR(5),
EMP_NAME CHAR(20)
)
— 親が削除されたときのルール（連鎖削除を指定）
PARENT IS DEPARTMENT
ON DELETE CASCADE; — ★ここがポイント！親が消えたら子も一緒に消す設定
このように、スキーマを定義する段階で「親が消えたときにどうするか」をあらかじめシステムに教えておくことで、データの秩序（整合性）が綺麗に保たれるのです。
—
5. 先輩エンジニアからのまとめ
いかがでしたか？
階層型DBMSにおける「論理データベースの整合性」とは、言い換えれば「親子の絆が切れたときに、データベースが壊れないようにするための防衛策」です。
- すべてのデータは親子関係で結ばれている。
- 親が消えたとき、ポインタの不整合（迷子）が起きないようにルール（連鎖削除や拒否）が働く。
この基本さえ押さえておけば、どんなに古いアーキテクチャのシステムに出会っても、データの裏側で何が起きているのかが手に取るようにわかるはずです。
データベースの構造をデザインするときは、いつも「家族の絆と、そのお片付け」まで想像できるエンジニアを目指していきましょう。
ここまで読んでくれたあなたなら、もうバッチリです！次のステップも一緒に楽しみましょうね。
コメント