【入門編】論理親連結キー（LPCK） – 階層型DBMS

みなさん、こんにちは！日々の開発や勉強、お疲れ様です。

突然ですが、みなさんは「データベース」と聞くと、どのような形を思い浮かべますか？
おそらく、多くの人がエクセルのような行と列で表される「関係データベース（RDB）」を思い浮かべるでしょう。

しかし、世界の金融システムや交通インフラなど、1秒間に数万件もの超巨大なトランザクションを50年以上もノーミスで支え続けている、「階層型DBMS」という偉大な大先輩がいます。

一見すると「古くて難しいもの」に思えるかもしれませんが、その設計思想は洗練の極み。今モダンなシステムで使われている技術の「原点」がここに詰まっています。

今日は、階層型DBMSを理解する上で避けては通れない、だけど一度理解すれば「なるほど、だからこの仕組みはこんなに強いのか！」と目からウロコが落ちる重要キーワード、「論理親連結キー（LPCK：Logical Parent Concatenated Key）」について、どこよりも優しく、本質を突いたお話をします。

ここをクリアすれば、階層型DBMSの基本はバッチリマスターできますよ。一緒に楽しく学んでいきましょう！

—

1. 階層型DBMSの「親子関係」をおさらいしよう

階層型DBMSは、データを「親と子」のツリー構造（家系図のような形）で管理します。
これを専門用語で「セグメント」と呼びますが、今はシンプルに「データの箱」だと思ってください。

【会社（親）】
│
└───【社員（子）】

このように、「会社」の下に「社員」がぶら下がっているのが、物理的な親子関係です。
しかし、現実のビジネスはもっと複雑ですよね。例えば、「プロジェクト」という別のツリーがあるとします。

【プロジェクト（親）】
│
└───【参画メンバー（子）】

ここで問題が発生します。
ある「社員」は、「会社」の子どもであると同時に、「プロジェクト」のメンバー（子ども）でもあります。
でも、階層型DBMSのルールでは「子どもは、たった一つの物理的な親しか持てない」という大原則があります。人間のように、2つの家系図に同時に所属することはできないのです。

そこで編み出されたのが、「論理的な親子関係」というウルトラCの解決策です。

—

2. 日常の例え：図書館の「本」と「貸出カード」

この仕組みを、日常の「図書館」に例えてみましょう。

物理的な親：図書館の「本棚（場所）」
物理的な子：本棚に並んでいる「本」
論理的な親：本を借りる「利用者（会員）」

本は必ずどこか一つの「本棚」に置いてあります（物理的な親子関係）。
しかし、その本が「誰に貸し出されているか」を表すために、本の中に「貸出カード」を挟んでおきます。この貸出カードが「論理的な子」です。

この貸出カードには、何が書かれているでしょうか？
そう、本を借りている「利用者の会員番号」です。

【本棚（物理親）】
│
└───【本（物理子）】
│
└───【貸出カード（論理子）】 ─── (指し示す) ───> 【利用者（論理親）】
★ここに「会員番号」が書かれている！

この「貸出カード（論理子）」に書かれた「会員番号」こそが、今回テーマである「論理親連結キー（LPCK）」の正体です！

—

3. 「論理親連結キー（LPCK）」とは何か？

正式な定義を少しだけ専門的に言うと、LPCKとは「論理的な親セグメントを特定するために、ルート（一番上の親）からその親にたどり着くまでのキー情報をすべて繋ぎ合わせたもの」です。

先ほどの図書館の例で、利用者が「東京支部」の「一般部門」の「会員番号12345番」だとしましょう。
このとき、LPCKはこれらをガッチャンコと繋げた値になります。

LPCKの値：`TOKYO-IPPAN-12345`

このキーが、貸出カード（論理子）のデータの中に直接書き込まれているのです。

「えっ、ポインタ（住所）があるなら、キーはいらないんじゃない？」

ここで鋭い方はこう思うかもしれません。
「階層型DBMSって、データ同士を高速な『ポインタ（メモリ上の住所）』で直接繋いでいるんでしょ？住所がわかっているなら、わざわざ『会員番号（LPCK）』なんてデータを持たせる必要はないのでは？」

実は、ここが伝説のアーキテクトたちが知恵を絞った「極限の安全設計」なのです。

もし、データベースの引越し（データの再編成やリカバリ）が発生して、データの「住所（物理ポインタ）」が変わってしまったらどうなるでしょう？
ポインタだけに頼っていると、すべての繋がりが切れて迷子になってしまいます。

しかし、データの中に「不変のキー情報（LPCK）」が物理的に書き残されていれば、万が一住所が変わって迷子になっても、「君の親は `TOKYO-IPPAN-12345` だね！」と、正しい親子関係を100%復元することができるのです。

ポインタという「超高速な近道」と、LPCKという「絶対に迷わない地図」。この2つが揃うことで、階層型DBMSは他の追随を許さない圧倒的な堅牢性を実現しています。

—

4. 実際のデータ構造を見てみよう！

では、このLPCKがどのようにデータベース内に定義され、格納されるのかを、具体的なイメージで見てみましょう。

まずは、スキーマ定義（DBD：データベース定義）の雰囲気を、初心者向けに超シンプルにしたコードで表現してみます。

/ データベースの定義（イメージ） /

DATABASE NAME=COMPANY_AND_PROJECT

/ 1. 論理的な親：プロジェクト情報 /
SEGMENT NAME=PROJECT, BYTES=100
FIELD NAME=(PROJID,SEQ), BYTES=10, START=1 / プロジェクトID（キー） /
FIELD NAME=PROJNAME, BYTES=90, START=11

/ 2. 物理的な親：社員情報 /
SEGMENT NAME=EMPLOYEE, BYTES=150
FIELD NAME=(EMPID,SEQ), BYTES=8, START=1 / 社員ID（キー） /
FIELD NAME=EMPNAME, BYTES=42, START=9

/ 3. 論理的な子：プロジェクト参画メンバー /
/ ここで「社員」と「プロジェクト」を繋ぐ！ /
SEGMENT NAME=MEMBER, PARENT=((EMPLOYEE), (PROJECT, DB2))
/
★ここがポイント！
MEMBERセグメントの先頭には、自動的に論理親（PROJECT）のキーである
「PROJID（10バイト）」が【LPCK】として格納されます。
/
FIELD NAME=LPCK, BYTES=10, START=1 / これが論理親連結キー！ /
FIELD NAME=ROLE, BYTES=20, START=11 / 役割（プログラマ、PLなど） /

実際のデータの中身（セグメントレイアウト）

このとき、`MEMBER` セグメント（貸出カードにあたる部分）の実データは、メモリやディスク上で次のように並んでいます。

システムがこの `MEMBER` データを見たとき、先頭の10バイトを読み取るだけで、「あ、このメンバーは `PROJ-A999` というプロジェクトに参加しているんだな」ということが一瞬で分かります。

そして、裏側にあるポインタを使って、`PROJ-A999` の詳細データ（プロジェクト名など）へワープするのです。

—

5. RDBの「外部キー」と何が違うの？

RDBを少し勉強したことがある方なら、「それってRDBの外部キー（Foreign Key）と同じじゃない？」と思うかもしれません。

確かに「別のテーブルのデータを指し示す」という目的は似ています。しかし、そのアプローチの思想が決定的に異なります。

| 特徴 | 階層型DBMSのLPCK | RDBの外部キー |
| :— | :— | :— |
| 繋ぎ方 | 物理ポインタ（住所）が主役。LPCKはそれを補完・保証する「命綱」。 | キー（値）の完全な一致だけで繋ぐ。ポインタは存在しない。 |
| 速度 | ポインタで直接飛ぶため、極限まで高速。 | テーブル同士を合体（JOIN）する計算が必要なため、データ量が増えると重くなる。 |
| 堅牢性 | データの再配置や復旧時、LPCKのおかげで自動的にポインタが再構築される。 | 自分でインデックスや制約を管理する必要がある。 |

LPCKは、単なる「マーク」ではなく、「超高速なポインタアクセスを裏で支える、究極のアンカー（錨）」としての役割を担っているのです。

—

まとめ：LPCKは「超高速」と「超安全」を両立する架け橋

最後に、今日学んだ大切なポイントをまとめましょう。

1. 階層型DBMSでは、1つの子どもが複数の親を持つために「論理的な親子関係」を使う。
2. その論理的な親子を繋ぐために、子ども側に格納される親のキー情報が「論理親連結キー（LPCK）」。
3. LPCKは、高速な「ポインタ」が何らかの理由で使えなくなった時のための「命綱」であり、データの安全性を100%に高めるための知恵。

「ポインタによる圧倒的なスピード」と、「LPCKによる揺るぎないデータ保証」。
この両輪があるからこそ、階層型DBMSは誕生から半世紀を経た今でも、世界のインフラの奥深くで現役最強のデータベースとして君臨し続けています。

一見難しそうな言葉も、こうして紐解いてみると、先人たちの素晴らしいアイデアが詰まっていることが分かりますね。

この基本をマスターしたあなたなら、もう階層型のデータモデルを見ても戸惑うことはありません。自信を持って、さらに深い技術の世界へ進んでくださいね。

いつでもあなたの挑戦を応援しています。また次のテーマでお会いしましょう！