SENSEGステートメントの深層：PCB設計における権限管理とパフォーマンスの境界線
こんにちは。チーフアーキテクトの私だ。
今日のコードレビューで、また「なんとなくコピペで作った」ようなPCB（Program Communication Block）の定義を見かけた。特に、`SENSEG`（Sensitive Segment）ステートメントの扱いについて、根本的な理解が欠落しているケースがあまりにも多い。
リレーショナルデータベース（RDBMS）に慣りきった脳みそで階層型DBMS（IMS DBなど）のスキーマを触ると、必ずと言っていいほど設計の地雷を踏む。RDBMSの「ビュー（View）」や「GRANT構文」の感覚で`SENSEG`を捉えているなら、今すぐその認識を改めなさい。
`SENSEG`は単なるアクセス許可のリストではない。アプリケーションが航行するデータ空間の物理的・論理的境界を定義し、エンジン自体のI/Oコストを左右する極めて重要なチューニングポイントなのだ。
今回は、この`SENSEG`ステートメントの本質と、実務で絶対に外してはならない堅牢な設計パターンを叩き込む。
—
1. SENSEGステートメントの本質：何が定義されているのか？
`SENSEG`ステートメントは、一つのPCB内において、アプリケーションプログラムがどのセグメントにアクセス可能かを定義する。
ここで思い出してほしい。階層型DBMSのデータ構造は、親から子へという一本道のツリー構造（あるいはネットワーク構造）をとる。アプリケーションが特定のセグメント（例えば、最下層の「口座明細」セグメント）に到達するためには、原則としてその親、さらに祖父母にあたるセグメントを経由しなければならない。
`SENSEG`の定義において最も重要な鉄則を言う。
> 「子セグメントを`SENSEG`で定義する場合、その経路上のすべての親セグメントも漏れなく`SENSEG`で定義されていなければならない」
これを怠ると、DBD（Database Description）の物理階層がどうなっていようと、アプリケーションからはデータが見えない、あるいはPSB（Program Specification Block）の生成時に容赦なくエラーが返される。
基本構文の解剖
一般的な`SENSEG`の定義を見てみよう。
- — PSB生成マクロの例 —
PCB TYPE=DB, DBDName=CUSTDB, PROCSEQ=0
- 顧客セグメント（ルート）へのアクセス定義
SENSEG NAME=CUSTSEG, PARENT=0, PROT=(G,U)
- 注文セグメント（顧客の子）へのアクセス定義
SENSEG NAME=ORDSEG, PARENT=CUSTSEG, PROT=(G,I,R,D)
この数行に、システムの生死を分ける情報が凝縮されている。
—
2. 権限（PROTパラメータ）の厳密なコントロール
`SENSEG`の `PROT`（または `FUNCT`）パラメータは、セキュリティとデータ整合性の最後の砦だ。RDBMSの `GRANT SELECT, INSERT…` と同等に考えてはいけない。これはセグメント単位の物理的オペレーションの制限に直結する。
実務でよく使われる権限の組み合わせと、その危険性を整理しておこう。
| パラメータ | 意味 | チーフアーキテクトからの警鐘 |
| :— | :— | :— |
| G (Get) | 読み取り | 参照系プログラムには必須。これがないと `GU`, `GN` コールは即座に異常終了（GBステータス）する。 |
| I (Insert)| 挿入 | 新規作成権限。親がロックされている文脈での不適切なI権限は、論理整合性を破壊する。 |
| R (Replace)| 更新 | 既存データの書き換え。項目単位ではなくセグメント全体の置換になる点に注意せよ。 |
| D (Delete)| 削除 | 子孫セグメントの連鎖削除（Cascade Delete）を引き起こす可能性があり、最も慎重な設計が求められる。 |
【アンチパターン】「念のため全部入り」のSENSEG
新人によくあるのが、「どのプログラムからでもデータを直せるように」と、すべての`SENSEG`に `PROT=(G,I,R,D)` を付与してしまう設計だ。
即刻、その設計を差し戻せ。
バッチ処理や参照用のオンライン画面のPCBに `D`（削除）や `R`（更新）権限を与えてはならない。最小権限の原則（Principle of Least Privilege）は階層型DBMSにおいても絶対の真理だ。万が一のバグや不正アクセス時、余計な更新権限を持つPCBが存在するだけで、データベース全体がロストするリスクが跳ね上がる。
—
3. パフォーマンスに直結する設計パターン
さて、ここからがエンジニアとしての腕の見せ所だ。`SENSEG`の定義の仕方いかんで、データベースアクセスのパフォーマンスが劇的に変わる。
パターンA：不要なセグメントの「隠蔽」（ビューとしての活用）
階層型DBでは、アプリケーションは原則としてツリーを上から順に舐めるようにアクセスする。しかし、親セグメントの膨大な属性データ（例：顧客のメタデータ）をアプリケーション側が一切必要としていない場合、どうすべきか？
答えは、「ルートセグメントであっても、処理に不要ならSENSEGから外す（あるいは限定する）」 だ。
- [悪例] すべてのセグメントを定義してしまっている
SENSEG NAME=ROOTSEG, PARENT=0, PROT=G
SENSEG NAME=METASEG, PARENT=ROOTSEG, PROT=G <-- 使わないのに！
SENSEG NAME=DATASEG, PARENT=METASEG, PROT=G
- [推奨] アプリケーションが関心のない中間セグメントをスキップ（※論理関係の活用時など）
- または、アクセスパスを最短化するプロシージャルな配慮
※注：物理的な親子関係を完全に無視して親を飛ばすことはできないが、「不要なセグメントへのポインタ辿りをDBMSに意識させない設計」や、感度（Sensitivity）を絞ることで、DBMS内部のバッファ管理やセグメント走査のオーバーヘッドを最適化できるケースがある。
パターンB：依存関係を考慮したデッドロック回避設計
複数のオンライン・トランザクションが同時に動くシステムでは、`SENSEG`の定義順序とアプリケーションのコール順序がデッドロックの温床になる。
- トランザクションA： `CUSTSEG` を掴んでから `ORDSEG` を更新
- トランザクションB： 別の経路から `ORDSEG` を掴んでから `CUSTSEG` を参照
このような競合を防ぐため、すべてのオンライン用PCBにおける`SENSEG`の定義順序、およびアプリケーションの処理シーケンスは、全社共通のコーディング規約で完全に統一していなければならない。
アーキテクトである私たちがレビューで見ているのは、まさにこの「システム全体でのロック順序の調和」なのだ。
—
4. チーフアーキテクトからの最終提言
階層型DBMSは古い技術だと言う者がいる。笑止千万。
根底にある「データの物理的・論理的配置の最適化」と「アクセスの厳密な制御」という概念は、現代の分散データベースやNoSQLのシャード設計、GraphQLのスキーマ設計にも脈々と生き続けている。
`SENSEG`ステートメントの記述は、単なるボイラープレート（お決まりのコード）ではない。
「このプログラムに、このデータのどこまでを触る権利を許すか」という、システム全体のセキュリティガバナンスとパフォーマンスの境界線を引く神聖な作業だ。
次に君たちがPSBを設計し、`SENSEG`を書くときには、その一行がDBMSのエンジン内部でどのようなI/Oを引き起こし、どのようなロックを生むのかを脳裏に思い浮かべたまえ。
妥協のない、美しいコードを期待する。
コメント