【入門編】ペアセグメント – 階層型DBMS

こんにちは！階層型データベース（DBMS）の世界へようこそ。

「階層型DBMSって、会社組織図や家系図みたいな『キレイな木構造（ツリー構造）』しか扱えないんじゃないの？」と思っていませんか？

実は、その疑問こそが階層型データベースを学ぶ上で最初にぶつかる大きな壁であり、同時に一番面白く、奥が深い部分なんです。現実の世界は、木構造のように「親が1人で子がたくさん」という単純な関係（1対多）ばかりではありませんよね。「多対多」の複雑な関係がたくさん存在します。

今回は、その限界を鮮やかに突破するための秘密兵器「ペアセグメント」についてお話しします。ここをクリアすれば、階層型DBMSの基本とデータ設計の勘どころはバッチリマスターできますよ！リラックスしてついてきてくださいね。

—

1. 日常の例えで見る「多対多」のジレンマ

まずは、私たちがよく知っている「大学の履修登録」を例に考えてみましょう。

学生さんは、複数の「講義」を受けますよね（英語、数学、プログラミング……）。
一方で、講義から見ても、複数の「学生さん」が受講しています。

【現実世界の多対多】
［学生：佐藤くん］──┬──［英語］
［学生：鈴木さん］──┼──［数学］
［学生：高橋くん］──┴──［プログラミング］

これを階層型DBMSでそのまま作ろうとすると、大問題が発生します。
階層型DBMSの大原則は「子は、必ずたった1つの親しか持てない」というルールだからです。

パターンA（学生が親）： 学生の下に講義をぶら下げると、「英語の講義に誰が出席しているか」を一覧で見たいときに、大学中の全学生データを上から下まで全部探す羽目になります。
パターンB（講義が親）： 講義の下に学生をぶら下げると、今度は「佐藤くんが今学期何を取っているか」を見たいときに、すべての講義をひっくり返して佐藤くんを探さなければなりません。

どちらか一方を立てれば、もう一方が地獄のような非効率に陥ってしまう……。
「両方の視点から、サクサクと一瞬でデータを取り出したい！」
そんなエンジニアの願いを叶えるために生まれたのが、「論理関係」と、それを支える「ペアセグメント」なんです。

—

2. 「ペアセグメント」は手を取り合う分身（ペア）

解決策はとてもエレガントです。
「学生ツリー」と「講義ツリー」を物理的に別々に作っておき、その間に「お互いを指し示す専用の窓口セグメント（ペア）」を配置するのです。

【物理ツリー1：学生DB】【物理ツリー2：講義DB】
［学生：佐藤］［講義：数学］
│ │
▼ ▼
［履修セグメント A］ <═══════════> ［受講生セグメント B］
（数学へのポインタを持つ）（佐藤へのポインタを持つ）

この図にある [履修セグメント A] と [受講生セグメント B] のコンビこそが、今回主役の「ペアセグメント」です！

学生ツリー側から見ると、「履修セグメント A」を通じて、講義（数学）へワープできます。
講義ツリー側から見ると、「受講生セグメント B」を通じて、学生（佐藤）へワープできます。

物理的な格納場所は別々のツリーなのに、システム的には「対（ペア）」としてガッチリ手を結んでいるため、どちら側からアクセスしても矛盾なく相手の情報を手に入れることができます。

—

3. スキーマ定義（DBD）をのぞいてみよう

では、実際にこのペアセグメントがスキーマ定義（DBD: Data Base Description）でどのように表現されるのか、エッセンスを見てみましょう。専門用語が並んでいますが、コメントを読めば「なるほど、ここで手を結んでいるんだな」と直感的に分かりますよ。

学生側データベースの定義（抜粋）

————————————————————-

学生ツリーの定義

————————————————————-
DBD NAME=STUDENT,ACCESS=HDAM
DATASET DD1=STUDDAT

親セグメント：学生（実体）

SEGM NAME=STUDENT,BYTES=50,PARENT=0
FIELD NAME=(STUDID,SEQ,U),BYTES=6,START=1

子セグメント：履修（これがペアセグメントの片割れ！）
PARENTで「物理的な親(STUDENT)」と「論理的な親(COURSE)」を両方指定します

SEGM NAME=STUCOUR,BYTES=20, X
PARENT=((STUDENT,DBLE), X
(COURSE,P,COURDB))

★ここがポイント！相手側のペアセグメント名を指定してリンクさせます

SOURCE=((COURSTU,,COURDB))
FIELD NAME=(COURID,SEQ,U),BYTES=6,START=1

講義側データベースの定義（抜粋）

————————————————————-

講義ツリーの定義

————————————————————-
DBD NAME=COURDB,ACCESS=HDAM
DATASET DD1=COURDAT

親セグメント：講義（実体）

SEGM NAME=COURSE,BYTES=60,PARENT=0
FIELD NAME=(COURID,SEQ,U),BYTES=6,START=1

子セグメント：受講生（ペアセグメントのもう一方の片割れ）

SEGM NAME=COURSTU,BYTES=20, X
PARENT=((COURSE,DBLE), X
(STUDENT,P,STUDENT))

★相手（学生側）のペアセグメント「STUCOUR」とペアリング！

PAIRED=YES, X
SOURCE=((STUCOUR,,STUDENT))
FIELD NAME=(STUDID,SEQ,U),BYTES=6,START=1

定義の中で `PAIRED` や `SOURCE` というキーワードを使って、「私のペアは、あっちのツリーにいるあのセグメントですよ」とお互いに自己紹介し合っています。これによって、DBMSが裏側で自動的にポインタ（アドレスの糸）を張り巡らせてくれるわけです。

—

4. 2種類のペアリング：「物理」と「仮想」

先輩として、もう一歩だけ深い「本質の知識」をプレゼントしておきますね。
ペアセグメントには、実は2つの実現方法があります。

1. 物理ペアリング（Physical Pairing）：

学生側にも講義側にも、実際にディスク上に両方のセグメントを書き込む方式。
メリット： どちらから読んでも物理データがすぐそこにあるので、検索がとにかく高速！
注意点： ディスク容量を2倍食います。また、佐藤くんが履修を取り消した時は、両方のセグメントをDBMSが同時に消し込みにいくため、更新のコストが少し高くなります。

2. 仮想ペアリング（Virtual Pairing）：

ディスク上には片方（例えば学生側）だけ実体を置き、もう片方は「実体はないけれど、論理的に存在するように見せかける（仮想）」方式。
メリット： ディスクの節約になり、更新時の整合性管理もシンプル！
注意点： 仮想側からたどるときは、ポインタの糸を何度もたぐり寄せるため、ほんの少しだけマシンのCPUパワーを使います。

「スピード命の大規模トランザクションなら物理ペアリング」「容量と整合性のシンプルさを取るなら仮想ペアリング」というように、当時のアーキテクトたちはミリ秒単位・バイト単位で頭を悩ませながら使い分けていたんですよ。ロマンを感じませんか？

—

5. まとめ：日常の感覚で理解するペアセグメント

最後に、今日の内容をギュッと整理しておきましょう！

なぜ必要？： 階層型DBMSは基本「1対多」だが、現実世界の「多対多」をスマートに扱うため。
ペアセグメントとは？： 2つの異なるツリー構造の間に立ち、お互いを繋ぐ「対（ペア）となる窓口セグメント」。
効果： 学生側からも、講義側からも、どちらからでも最速ルートで相手のデータにたどり着ける！

ペアセグメントの役割がイメージできるようになると、「階層型データベースって、ただの古い木構造ではなく、ポインタを駆使して自由自在にネットワーク網を張り巡らせる超高速エンジンなんだ！」ということが見えてきます。

ここさえしっかり押さえれば、階層型DBMSの基本設計はバッチリです。自信を持って次のステップへ進んでくださいね！