単一データベース内の複数の所有者

検証は常に本番管理データを使用

検証バッチ・プロセスがステージング・データに対して実行されると、ステージング・データは本番の管理表に対して検証され(エラーはステージング・エラー表に挿入され)ます。これは、エンティティに対してアクセス / 更新するSQL文はステージング所有者を使用する必要があり、管理表にアクセスするSQL文は本番所有者を使用する必要があることを意味します。しかし、これらの同じ検証バッチ・プロセスを本番に対して実行する場合、SQL文はステージング所有者にまったくアクセスしません。むしろ、すべて本番所有者を指し示しています。

これは、次のようにして実現されています。

• 所有者ごとに別個のアプリケーション・サーバーが存在する必要があります。各アプリケーション・サーバーは、固有のデータベース・ユーザーIDを指し示します。
  注意: クラウドのインストール環境では、アプリケーション・サーバーが特定のデータベース・ユーザーIDのみをいつでも指し示すことができます。所有者の切替えの詳細は、「クラウド実装のデータ変換サポート」を参照してください。
• ステージング所有者に関連付けられたデータベース・ユーザーIDは、CISSTGをマスター表およびトランザクション表の所有者として使用しますが、CISADMを本番管理表の所有者として使用します。
• 本番所有者に関連付けられたデータベース・ユーザーIDは、CISADMをすべての表の所有者として使用します。

この手数をかけることを疑問に思うかもしれません。これには、次のような理由があります。

• 本番データを検証するプログラムに存在する検証ロジックを再利用するため。これを実現するには、これらのプログラムは、ある時はステージング所有者を指し示し、ある時は本番所有者を指し示す必要があります(これはプログラムに対して透過的である必要がありますが、そうでない場合は2つのセットのSQLが必要になります)。
• アプリケーションを使用してステージング・データを調べて修正できるようにするため。これを実現するには、ステージング・データベースを指し示すアプリケーション・サーバーを前述の所有権特性を使用して作成します。
• 検証プログラムで(ステージング・データに加えて)本番データを検証できるようにするため。本番に追加できるのはクリーンなデータのみである場合に、本番データを検証する理由を考えます。次のようなシナリオについて考えてみます。
  • アップグレード後に、本番データを検証して、既存のユーザー終了ロジックが変らず動作することを確認する場合。
  • 検証ロジックの変更が与える影響の実験を実施する場合。そのためには、(本番の)ユーザー終了ロジックを一時的に変更し、ランダム・サンプル・ベースで検証ジョブを実行します。
  • 本番に移入する前に検証プログラムの実行を忘れ、その損害を確認する場合。このドキュメントの指示に従った場合、このようなことは発生しません。しかし、事故は発生します。事故が発生した場合、少なくとも影響を特定する方法はあります。

検証のみが両方の所有者で機能

所有者IDのリダイレクトは検証バッチ・プロセスに役立つ技法ですが、キー割当および本番挿入バッチ・プロセスに使用できません。なぜなら、これらのプロセスは所有者の異なる同じ表に同時にアクセスする必要があるためです。本番に存在しない変換固有の表を参照する必要もあります。たとえば、本番の表に行を挿入するバッチ・プロセスは、その表のステージング・バージョンから行を選択し、変換の旧キー / 新キー・マッピング表からキーを解決し、解決したレコードをその同じ表の本番バージョンに挿入する必要があります

これは、次のようにして実現されています。

• ステージングでは、変換表に適格なそれぞれについて本番へのビューが存在します。これらのビューは、本番を指し示すためにデータベース所有者がハードコードされています。たとえば、本番のパーソン表を指し示すCX_​PERというビューがあります。
• キー割当プログラムと挿入プログラムは、本番データへのアクセスが必要なときは必ずこれらのビューを使用します。