【入門編】仮想論理子（VLC） – 階層型DBMS

こんにちは！いつもブログを読んでくれてありがとうございます。頼れる先輩エンジニアの「タカさん」です。

突然ですが、皆さんは「データの二重持ち（重複）」で困ったことはありませんか？
例えば、Excelで「社員名簿」と「プロジェクトメンバー表」の2つを作っていて、ある社員が引っ越したときに両方のファイルを更新し忘れて、データがバラバラになってしまった……なんて経験、きっと一度はありますよね。

実は、今から半世紀以上前に生まれた、データベースの元祖である「階層型DBMS」の世界でも、まったく同じ問題がありました。

今回は、この問題をスマートに解決するために生み出された、階層型DBMSの超重要テクニック『仮想論理子（かそうろんりし / Virtual Logical Child: VLC）』について、どこよりも分かりやすく、日常の例えを交えて解説します。

「ここをクリアすれば、階層型DBMSの基本はバッチリマスターできますよ」

リラックスして、お茶でも飲みながら読んでみてくださいね！

—

1. そもそも「階層型DBMS」ってどんなもの？

まずは、基礎の基礎をおさらいしておきましょう。

階層型DBMSは、データを「会社組織図」や「パソコンのフォルダ構造」のようなツリー状（親子関係）で整理するシステムです。

【会社】（親）
│
├──【開発部】（子）
│ ├──【プロジェクトA】（孫）
│ └──【プロジェクトB】（孫）
│
└──【営業部】（子）

このように、「親から子、子から孫」へと一方通行でデータをたどるのが基本です。この仕組みは、データの場所がはっきりしていて検索がとにかく爆速という強力なメリットを持っています。

しかし、ここで一つの大きな壁にぶつかります。
「もし、1つのデータが複数の親を持ちたくなったらどうするの？」という問題です。

—

2. 日常の例え：部活動と生徒の「二重持ち」問題

学校のデータベースを例に考えてみましょう。

ここにある「部活動データベース」と「クラス名簿データベース」があります。

物理ツリーA（部活動が親）： 「サッカー部」の下に「鈴木くん」がいる。
物理ツリーB（クラスが親）： 「1年A組」の下に「鈴木くん」がいる。

もし、鈴木くんの連絡先が「090-XXXX」から「080-YYYY」に変わったらどうなるでしょうか？
部活動のデータと、クラス名簿のデータの両方を書き直さなければなりません。もし片方を忘れたら、システムの中で「2人の鈴木くん」が存在することになり、データがめちゃくちゃになってしまいます（これを出発点とするデータの矛盾を「不整合」と呼びます）。

かといって、鈴木くんのデータを片方にしか置かないと、もう片方のツリーから鈴木くんの情報が見えなくなってしまいます。

ここで登場するのが、今回の主役「仮想論理子（VLC）」です！

—

3. 「仮想論理子（VLC）」は、データの魔法のショートカット

この問題を解決するために、階層型DBMSの設計士たちは素晴らしいアイデアを思いつきました。

「実体（本物のデータ）は1箇所だけに置いて、もう片方には『本物はあっちにあるよ』というリンク（ポインタ）だけを置こう！」

図にすると、このようなイメージです。

【物理ツリーB：クラス名簿】（本物のデータを持つ）
└── [1年A組]
└── [鈴木くん] （※ここに本物の電話番号がある：実論理子）
▲
│（裏でつながる魔法の糸 = ポインタ）
│
【物理ツリーA：部活動】
└── [サッカー部]
└── [鈴木くん(仮)] （※「本物はクラス名簿の鈴木くんだよ」と指さすだけ：仮想論理子）

実論理子（RLC）： 本物のデータを保持している子セグメント。
仮想論理子（VLC）： 自分自身はデータを持たず、本物の場所を指し示している（ポインタのみを持つ）「透明な」子セグメント。

サッカー部から鈴木くんのデータを見ようとすると、システムが自動的にこの「魔法の糸（ポインタ）」をたどって、クラス名簿にいる鈴木くんのデータを引っ張ってきてくれます。

これなら、鈴木くんの電話番号が変わっても、クラス名簿のデータだけを直せば、サッカー部側も自動的に最新の電話番号になります。
データの重複がなくなり、更新のミスも絶対に起きません。素晴らしい解決策だと思いませんか？

—

4. 実際のスキーマ定義（DBD）を覗いてみよう！

「仕組みはわかったけど、システムにはどうやって教えるの？」と思いますよね。
階層型DBMS（例えば、IBMの代表的なDBMSである「IMS」）では、DBD（Database Description）という言語を使って、この親子関係やリンクを定義します。

初心者の方でもイメージしやすいように、大切なポイントにコメントをつけたコード例を用意しました。

=============================================================
1. 本物のデータを持つ「クラス名簿データベース」の定義
=============================================================

DBD NAME=CLASSDB

親セグメント（クラス）

SEGM NAME=CLASS,BYTES=50

子セグメント（生徒：これが「実論理子」になります）
LCHILD（論理的な子）として、部活動DB（CLUBDB）と双方向でつながるように定義します

SEGM NAME=STUDENT,PARENT=CLASS,BYTES=100
LCHILD NAME=(MEMBER,CLUBDB),PAIR=VSTUDENT,PTR=DBLE

=============================================================
2. リンクだけを持つ「部活動データベース」の定義
=============================================================

DBD NAME=CLUBDB

親セグメント（部活動）

SEGM NAME=CLUB,BYTES=30

子セグメント（部活動メンバー：これが「仮想論理子(VLC)」です！）
SOURCEで「本物のデータはCLASSDBのSTUDENTだよ」と指定しています。
これにより、このセグメントは物理的なデータを持たない「仮想」の存在になります。

SEGM NAME=VSTUDENT,PARENT=CLUB,SOURCE=((STUDENT,KEY,CLASSDB))

ここがポイント！
最後の行の `SOURCE=((STUDENT,KEY,CLASSDB))` という記述が、「私は中身を持ちません。本物は `CLASSDB` の `STUDENT` です」という宣言です。
これにより、データベースの中に無駄なコピーを作ることなく、2つのツリーを自由に行き来できるようになります。

—

5. 先輩からのワンポイント：なぜこれが「極限の知見」なのか？

現代の主流であるRDB（リレーショナルデータベース）に慣れている方なら、「それって、テーブル同士を `JOIN`（結合）するのと何が違うの？」と思うかもしれません。

実は、決定的な違いがあります。

RDBのJOINは、検索するときに「ええと、クラス名簿の鈴木くんと、サッカー部の鈴木くんを合体させて……」と、その都度コンピュータが頭を使って探します（インデックスを使っても、それなりの計算コストがかかります）。

一方、階層型DBMSの「仮想論理子」は、データが書き込まれた瞬間に、メモリ上の物理的な住所（ポインタ）を直接つなぎます。
つまり、データをたどるスピードが「最初からそこに道がある」状態なので、文字通り桁違いに速いのです。

この「物理ポインタによる超高速なデータアクセス」と「データの重複排除」を両立させるために、この仮想論理子という美しい知恵が生み出されました。

—

まとめ

お疲れ様でした！
今回学んだことを、3行でまとめてみましょう。

1. 階層型DBMSでは、複数のツリーで同じデータを扱おうとすると「データの二重持ち（重複）」が発生してしまう。
2. 「仮想論理子（VLC）」は、実データを置かずに「本物の場所を示すポインタ」だけを置く仕組み。
3. これにより、データの整合性（更新漏れがない状態）を保ちつつ、超高速にデータを検索できる。

この「実体は一つ、アクセス経路は複数」という考え方は、現代の最先端のシステム設計や、クラウドのファイルシステム、さらにはプログラミングの「参照（Reference）」の概念にも深く息づいています。

ここをクリアできれば、階層型DBMSの基本はバッチリマスターできましたよ！自信を持って進んでくださいね。

また次回の記事でお会いしましょう。質問があればいつでもコメントにどうぞ！