こんにちは！データベースの世界へようこそ。
今日は、少しレトロだけど、現代のデータ管理の基礎が詰まった「階層型DBMS（データベース管理システム）」についてお話ししますね。
「階層型」と聞くと難しく聞こえるかもしれませんが、安心してください。ここをしっかりクリアすれば、データベースの根本的な仕組みが手に取るようにわかるようになりますよ。
今日のテーマは「データベースのレコードサイズ、そして物理配置の制約」です。
なんだか難しそうな言葉が並びましたが、身近な例えを交えて優しく解きほぐしていきますので、リラックスしてついてきてくださいね。
—
1. 階層型DBMSって、なにに例えられる？
現代の主流であるリレーショナルデータベース（RDBMS）が「エクセルシートの表をたくさん組み合わせる」イメージだとすれば、階層型DBMSは「会社の組織図」や「引き出しの整理整頓」そっくりです。
一番上に「親（ルート）」がいて、その下に「子ども（従属セグメント）」がぶら下がる、綺麗なピラミッド構造をしています。
例えば、「学校」を管理するデータベースを考えてみましょう。
- ルートセグメント（一番上の親）: 学校情報（学校名、所在地）
- 従属セグメント（子どもたち）: 学年 ＞ クラス ＞ 生徒
このように、親子関係がガッチリと決まっているのが階層型の最大の特徴です。
—
2. 今回の主役：「レコードサイズと物理配置の制約」の正体
さて、ここからが本題です。
階層型DBMSでは、この「親と子、さらにその孫」といった家族全員（レコード）のデータの合計サイズが、ディスク（ハードディスクなど）の物理的な配置にもの凄く大きな影響を与えます。
日常の例えで考えてみましょう。あなたは今、「家族全員分の荷物を、一つの大きなカバンに詰め込んで、ロッカーに収納する」という作業をしています。
- ルートセグメント ＝ お父さんの荷物（財布や鍵）
- 従属セグメント ＝ お母さんや子供たちの荷物（教科書や着替え）
階層型DBMSの物理的なルールはこうです。
「家族全員の荷物は、できる限りディスク上の同じエリア（連続した場所）にひとまとめにして詰め込まなければならない」
ここがポイントです。もし、家族全員の荷物（合計サイズ）が大きすぎると、どうなるでしょうか？
—
3. なぜ「合計サイズ」が制約になるのか？
もし、一人ひとりの荷物は小さくても、子どもが100人いて、その全員分の従属セグメントがぶら下がっているとどうでしょう。「家族全員の合計サイズ」はもの凄く巨大になります。
これが物理配置において、以下のような問題を引き起こします。
1. ディスクの「お引越し（断片化）」が大変
- データベースの世界では、データが更新されて大きくなると、入りきらなくなって別の空きスペースに引っ越す必要があります。
- この時、リレーショナルデータベースなら「子どもだけ別の場所へお引越し」が簡単にできますが、階層型は「家族全員（親も子も孫も）」がセットでひとつの塊として扱われがちです。そのため、巨大なサイズになったレコードを綺麗に収める場所を探すのが、ディスクにとって一苦労なのです。
2. 読み込みの効率（パフォーマンス）のジレンマ
- 「お父さんの情報（学校名）」だけをちょっと見たいだけなのに、その下にある巨大な家族の荷物（全生徒のデータなど）まで一緒にメモリに読み込まざるを得ないケースが出てきます。
- サイズが大きすぎると、ディスクからデータを読み取るスピードがガクッと落ちてしまう原因になります。
つまり、「ルートから一番下の末端までの合計サイズがどれくらいになるか」を計算に入れないと、ディスクのパフォーマンスがすぐに限界を迎えてしまうという物理的な制約があるのです。
—
4. スキーマ定義（DDL）でどう表現する？
では、実際にこのような階層構造を定義するイメージを見てみましょう。
階層型DBMSの世界では、スキーマ（設計図）を書くときも、この「親と子」の関係を意識して記述します。
— 概念的なスキーマ定義のイメージ
DATABASE SchoolDB
— ① ルートセグメント（一番上の親）
SEGMENT SCHOOL_SEG
FIELD school_name CHAR(50);
FIELD location CHAR(100);
— ② 従属セグメント（学校の下にある「学年」）
SEGMENT GRADE_SEG DEPENDENT ON SCHOOL_SEG
FIELD grade_level INT;
— ③ さらにその下の従属セグメント（学年の下にある「生徒」）
SEGMENT STUDENT_SEG DEPENDENT ON GRADE_SEG
FIELD student_id CHAR(10);
FIELD student_name CHAR(50);
— ※実際のDBMSの方言によって構文は異なりますが、構造的な親子関係がこうして定義されます。
この定義を見たとき、優秀なエンジニアはこう考えます。
「ひとつのSCHOOL（学校）の下に、何人のSTUDENT（生徒）がぶら下がる想定だろう？ もし全校生徒が3,000人だとしたら、この一つのツリー構造の『合計サイズ』は何メガバイトになるかな？」と。
このサイズの見積もりこそが、階層型DBMSを使いこなす上での最大のキモなのです。
—
まとめ：ここをクリアすればバッチリです！
いかがでしたでしょうか？
今日のポイントをギュッと凝縮して振り返ってみましょう。
- 階層型DBMSは「家族（親子関係）」のデータ構造。
- 「ルートと全従属セグメントの合計サイズ」が、そのまま物理的なディスク上の専有サイズになりやすい。
- 合計サイズが大きすぎると、ディスクの配置やデータの引っ越し（更新・管理）でパフォーマンスのボトルネックになる。
この「全体でどれくらいの大きさになるか」という物理的な感覚を持っていれば、たとえ古いアーキテクチャのシステムであっても、設計の意図が手に取るようにわかるようになります。
ここをクリアできれば、あなたもう階層型DBMSの基本はバッチリマスターです！
現代のデータベースを学ぶ上でも、「データが物理的にどう並んでいるか」を想像するこの視点は必ず役に立ちますよ。それでは、次のステップへ進みましょう！
コメント