【入門編】 PHDAM/PHIDAM (Partitioned HDAM/HIDAM) の定義 – 階層型DBMS

こんにちは！データベースの世界へようこそ。
今日は、世界中の基幹システムを裏で支え続ける、ちょっと硬派で、でも知れば知るほどよくできた仕組みを持つ「階層型DBMS」の、さらに一歩進んだ世界にご案内しますね。

テーマは 「PHDAM / PHIDAM（Partitioned HDAM / HIDAM）」 です。
名前を聞くだけで「うっ……難しそう」と窓を閉めたくなるかもしれませんが、大丈夫。私が普段、現場で後輩に教えるときの目線で、身近な例えを交えながらスッキリと紐解いていきます。

ここをクリアすれば、大規模データをあやつるDBMSの基本はバッチリマスターできますよ。肩の力を抜いて、一緒に見ていきましょう！

—

1. なぜ「PHDAM / PHIDAM」が必要なのか？（日常の例えで理解する）

想像してください。あなたが、日本中のすべての住所と住民のデータを管理する「超巨大な巨大図書館」の館長だとします。

もし、この図書館の本がすべてたった1つの巨大な棚に詰め込まれていたらどうなるでしょう？
新しい人が引っ越してきて住民票を登録するにも、誰かが住所を探すにも、その巨大な棚の前には大渋滞が起きてしまいますよね。職員もヘトヘトになってしまいます。

そこで、「関東エリア」「関西エリア」「九州エリア」といった具合に、図書館を物理的にいくつかの「分館（パーティション）」に分割することにしました。これが Partitioned（パーティショニング） の考え方です。

データがどれだけ巨大になっても、エリアごとにスリムに分割しておけば、並行して作業ができるし、管理もラクになりますよね。これがPHDAMやPHIDAMの根本にある思想です。

—

2. PHDAM と PHIDAM の正体

では、頭文字のアルファベットを一つずつ分解して、その正体を暴いていきましょう。

P (Partitioned): 先ほどお話しした「分割（パーティション）」のこと。
HDAM (Hierarchical Direct Access Method): キーワード（ハッシュ値）を使って、データの置き場所を計算ですぐに導き出し、直接アクセスする方式。
HIDAM (Hierarchical Indexed Direct Access Method): 「索引（インデックス：索引簿）」を使って、目的のデータがどこにあるか調べてからアクセスする方式。

つまり、

PHDAM ＝「エリアごとに分けたうえで、計算でダイレクトにデータを見つける職人技タイプ」
PHIDAM ＝「エリアごとに分けたうえで、分厚い索引簿（目次）を引いて確実にデータを見つける優等生タイプ」

となります。

—

3. 物理スキーマ定義（DDL風）のイメージを覗いてみる

実際に、こうした巨大なパーティションデータベースを定義するスキーマ（設計図）の世界を少しだけ覗いてみましょう。実務ではJCL（ジョブ制御言語）やユーティリティ制御ステートメントを使って定義しますが、ここではイメージしやすいように、そのエッセンスをお伝えします。

— 【仮想的なPHIDAM定義のイメージ】
DATABASE DEFINITION
DB_NAME = WORLD_DB
ACCESS_METHOD = PHIDAM — 索引付き分割アクセス方式を採用

— パーティション1: 東日本エリアの定義
PARTITION
PART_ID = EAST_01
DATA_SET = “DSN.WORLD.EAST.DATA”
INDEX_SET = “DSN.WORLD.EAST.INDEX”
HIGH_KEY = “TOKYO_ZZZ” — この値までのデータをこの分館に収める

— パーティション2: 西日本エリアの定義
PARTITION
PART_ID = WEST_02
DATA_SET = “DSN.WORLD.WEST.DATA”
INDEX_SET = “DSN.WORLD.WEST.INDEX”
HIGH_KEY = “OSAKA_ZZZ” — この値までのデータをこの分館に収める

ここがポイント：
コードの中にある `HIGH_KEY`（境界値）というのがミソです。「どこまでのデータをどの分館（パーティション）に置くか」の境界線をここでスパッと引いています。これにより、DBMSは「あ、大阪のデータだな」と分かれば、迷わず西日本の分館の扉をノックできるようになるのです。

—

4. チーフアーキテクトからの実務アドバイス

現場でこれらの物理スキーマを設計・運用する際、私たちプロが最も頭を悩ませ、かつ腕の見せどころとするのが「パーティションの切り方（境界線の設計）」です。

もし特定のエリア（例えば東京周辺）にばかりデータが集中してしまうと、そのパーティションの担当分館だけが大混雑してしまい、分割した意味が薄れてしまいます（これを「データ skewed（偏り）」と呼びます）。
均等に美しくデータを散らせるか、あるいはアクセスの負荷を分散できるか。このバランス感覚こそが、優れたエンジニアの証です。

—

おわりに

いかがでしたでしょうか？
PHDAM / PHIDAMは、一見すると呪文のような難解な名前をしていますが、その本質は「巨大になりすぎたデータを、上手にエリア分けして、迷わず素早くアクセスするための知恵の結晶」に他なりません。

この基本マインドさえ掴んでおけば、どんなに大規模な階層型DBMSのドキュメントや物理設計書に出会っても、怖気づくことはもうありません。

あなたのエンジニアとしての引き出しに、また一つ強力な武器が加わりましたね。
それでは、次のステップでも一緒に楽しく学んでいきましょう！