部門や取引先といったマスターデータの削除はやっかいだ。マスターデータは他のさまざまなデータから参照されるので、そうしたデータからの参照の有無をチェックして、削除してよいかどうか確認しなければならない。
リレーショナルデータベースの提供する参照整合性機能を用いればこうしたチェックを簡単に行うことができるが、いかんせん、この方法にも弱点がある。削除できない場合にはリレーショナルデータベースがエラーメッセージを返してくるが、このメッセージがユーザにとっては意味不明なのだ。しかも、削除しようとしているマスターデータを参照しているデータはどれかといった詳細情報を取得する手段が標準化されているわけでもない。
こうしたわけで、リレーショナルデータベースの参照整合性機能は「最後の砦」としておいて、それとは別にアプリケーションプログラムにて削除可否のチェックを行わなければならない場面がでてくる。この場合、「誰が」チェックを行うのかが問題になる。「誰が」と言っても「人」の話ではなく「システム」の話である。
例えば、一般会計システムが管理する「部門マスター」があるとしよう。このマスターを参照するデータは、経費管理システムと出張旅費精算システムにも存在することにする。だから、部門マスターからデータを削除する際には、その部門（の部門コード）が、経費管理システムと出張旅費精算システムのデータで使用されていないか、チェックする必要がある。
このチェックはどのシステムの責任だろうか。すなおに考えると、一般会計システムに含れる部門マスター削除処理のプログラムコードにおいてチェックを行うのが自然だ。だから一般会計システムの責任ということになる。
しかし、ちょっと待って欲しい。
部門マスターを参照するシステムは現在は３つだけかもしれない。しかし、４つ目のシステムが開発されたとき、それも部門マスターを参照することになる可能性は大きい。そうすると、部門マスター削除処理を修正しなければならない。すなわち、部門マスターを参照するシステムが増えるか修正される都度、一般会計システムの修正が必要になる訳だ。
なにか変ではないだろうか？
部門マスターの管理を一般会計システムに委ねたのが原因だろうか。マスター管理機能全般を「共通マスター管理システム」として切り出せばどうだろう。しかし、こうしてみても事態はあまり変わらない。影響を受けるシステムが一般会計システムから共通マスター管理システムに置き換わるだけだ。
いずれのシステム構成でも、マスターの管理を担当するシステムが、マスターを使用するシステムのデータを参照してしまうことが問題なのだ。
この事態を回避するには、マスター削除チェックに関する責任を管理側と利用側の二つに分割すればよい。
- 管理側： マスターの削除が要求されていることを利用側（複数）に通知して、削除可否を尋ねる責任を負う。
- 利用側： 管理側からの通知を受け、削除可否を回答する責任を負う。削除不可の場合はその理由を表すメッセージも返す。
「管理側」と「利用側」の間でやりとりを行う際のデータフォーマットや呼び出し手順はあらかじめプロトコルとして決めておく。
設計上のポイントは、「利用側」システムとして例えば経費管理システムと出張旅費精算システムがあるという知識を「管理側」システムが持たない、というようにすることである。つまり「利用側」がプロトコルに従っている限り、「管理側」としては自分が話しかけている相手が具体的にだれであるか関知しなくてもよいのである。(脚注①)
実際に存在する「利用側」システムの一覧は設定ファイルなどに列挙しておき、「管理側」システムの起動時に読み込むようにすればよい。システムの一覧の代りに、「利用側」システム内でじっさいに削除可否のチェックを担当するプログラムの名前（識別子）の一覧を記述しておくことにしてもよい。
このようにすれば、最初の例にもどって、部門マスターを使用するシステムが増えても、部門マスター削除処理は修正しなくてもよいことになる。設定ファイルにそのシステムを登録するだけだ。
上記の議論は、マスター削除処理というひとつのセッションの中（データベース処理の用語でいう『トランザクション』内）で処理が完結できることを暗黙の前提としていた。マスター利用側のデータベースの所在によってはこのような前提が置けないこともあるだろう。そうした場合は、削除可否の回答があるいは非同期で行われるということも想定して、上記の枠組みを修正することが必要だろう。
(脚注①)
オブジェクト指向設計にある程度慣れた方には、このメカニズムは「デザインパターン」でいうObserverパターンの変形である、と説明した方がわかりやすいかもしれない。
Observer パターンと共通なのは、不特定多数の（実体は不明な）相手に通知を行う点である。「管理側」が "Subject" 役で、「利用側」が "Observer"役である。異なるのは、Observer パターンでは、Subject から Observer に一方的に通知が行われるのに対して、ここで説明しているメカニズムは、通知に対する回答が Observer から Subject にもたらされる双方向の伝達のしくみであるという点だ。
