いいか、よく聞け。リレーショナルデータベース（RDBMS）の「VIEW」と同じ感覚で階層型DBMSを語る奴がいるが、それは大きな間違いだ。
階層型DBMS、特にIMS（Information Management System）における「セグメント感度（Sensitivity）」は、単なるアクセス制御ではない。それは、物理的なデータ構造という「宇宙」から、特定のアプリケーションが必要な「銀河」だけを切り出す論理的な彫刻だ。
今日は、設計レビューで私がいつも若手に叩き込んでいる、セグメント感度の本質と「極限の設計論」を伝授する。
—
1. セグメント感度とは「アプリケーションが見る世界の境界線」である
階層型DBMSにおいて、データは物理データベース（DBD）として定義される。しかし、プログラムがその巨大なツリーのすべてを知る必要はないし、知るべきでもない。
ここで登場するのがPSB（Program Specification Block）であり、その中のPCB（Program Communication Block）で定義される`SENSEG`（Sensitive Segment）マクロだ。
- 物理DBD: データの「あるべき姿（全構造）」
- PCBのSENSEG: アプリケーションが「認識できる世界（論理構造）」
この設定により、特定のセグメントを隠蔽（Hide）し、プログラムからは最初から存在しないかのように振る舞わせることができる。これが「セグメント感度」だ。
—
2. DDL（PCB定義）における実戦的な記述
理屈を並べる前に、コード（マクロ）を見てみよう。これが、ある銀行システムの「顧客口座情報」の一部を切り出すPCBの定義例だ。
-asm
- ———————————————————
- 顧客情報DBのうち、口座残高(ACCOUNT)までは見せるが、
- 履歴(HISTORY)セグメントには感度を持たせない(隠蔽する)設計
- ———————————————————
PCB TYPE=DB,DBDNAME=CUSTDB,PROCOPT=G,KEYLEN=50
- 1. 顧客基本情報セグメント (感度あり: 参照のみ)
SENSEG NAME=CUSTOMER,PARENT=0,PROCOPT=G
- 2. 口座セグメント (感度あり: 参照および更新可能)
- 上位のCUSTOMERがG(参照)でも、ここはREPLACE可能にできる
SENSEG NAME=ACCOUNT,PARENT=CUSTOMER,PROCOPT=GR
- 3. [重要] ここにHISTORYセグメントを定義しなければ、
- プログラムはこのDBに履歴が存在することすら知ることができない。
ここでのポイント：`PROCOPT`（Processing Options）
`SENSEG`ごとに指定する`PROCOPT`こそが、設計者の意志だ。
- `G` (Get): 読み取り専用。
- `I` (Insert): 挿入。
- `R` (Replace): 更新。
- `D` (Delete): 削除。
- `K`: Key Sensitivity（キー感度）。これが重要だ。データの中身（データ部分）は見せず、下位セグメントへ辿るための「鍵」としてだけ利用させる場合に使う。
—
3. 極限の知見：設計で絶対に外せない「3つの鉄則」
現場の泥臭いトラブルを経験してきた私から言わせれば、セグメント感度の設計には以下の哲学が必要だ。
① 「最小権限の原則」を徹底せよ
「とりあえず全部見えるようにしておけば後で楽だ」という考えは、階層型DBMSの世界では死を意味する。
不要なセグメントに感度を持たせることは、バグによるデータの予期せぬ破壊を招くだけでなく、排他制御（ロッキング）の範囲を無駄に広げ、スループットを劇的に低下させる。 必要なパス以外は、たとえ親であっても「Key Sensitivity (`PROCOPT=K`)」で絞り込め。
② 階層の「飛び越し」は許されない
論理構造において、ある子セグメントにアクセスしたいなら、そのルートから子に至るまでのすべての親セグメントに対して感度（SENSEG）を持たせなければならない。
「親Aの情報はいらないが、孫Cの情報が欲しい」という場合、親Aを`PROCOPT=K`で定義し、物理的なパスだけを確保する。これが階層型の作法だ。これを無視した設計は、物理構造の変更に極めて脆弱になる。
③ パフォーマンス上の罠：セグメント・スキッピング
セグメント感度を絞りすぎると、階層走査において「物理的には存在するが、論理的には無視するセグメント」をスキップするオーバーヘッドが発生することがある。
特に、巨大なツリーの深層にあるセグメントだけに感度を持たせ、その間の広大な兄弟セグメントを無視するようなスキャンを行うと、I/O効率が極端に悪化する。「論理的な隠蔽」は「物理的なスキャンコストの消滅」を意味しないことを肝に銘じろ。
—
4. 堅牢な設計パターン：論理データベースによる抽象化
さらに高度な設計では、物理DBDを直接叩かせるのではなく、論理データベース（Logical Relationships）を介してセグメント感度を定義する。
物理的には「顧客」と「注文」が別々のDBに存在していても、PCB上でそれらを一つのツリーとして見せる。この際、セグメント感度を適切に設定することで、アプリケーション側には複雑なポインタ操作やDB間の結合を一切意識させない。
-asm
- 論理関係を用いたPCB例
SENSEG NAME=CUST,PARENT=0
SENSEG NAME=ORDER,PARENT=CUST 物理的には別DBだが、感度設定で結合して見せる
この「見せ方の制御」こそが、大規模レガシーシステムを数十年稼働させ続けるための秘訣だ。物理構造が変わっても、PSB/PCBのセグメント感度設定で吸収すれば、アプリケーション・ロジックを修正する必要はない。
—
最後に：チーフアーキテクトからの助言
セグメント感度の設定を見れば、その設計者が「データの寿命」と「アプリケーションの責任範囲」をどこまで理解しているかが一目でわかる。
適当な`PROCOPT=A`（All）で茶を濁すな。
どのセグメントが不可視であるべきか、どのパスが最小のI/Oで済むか、それをDDL（PCB）の一行一行に込めろ。
階層型DBMSは古い技術ではない。データの親子関係という「不変の真理」を最も厳格に、かつ高速に制御するための究極の道具だ。セグメント感度を支配する者は、システムの堅牢性を支配する。
わかったら、今すぐ自分の設計したPCBを見直してこい。話はそれからだ。
コメント