アーキテクチャ・ガイド
リリース11g R1 (11.1.1.7)
E51454-01(原本部品番号:E40036-02)
2013年10月
このドキュメントでは、Enterprise Data Quality (EDQ)のアーキテクチャについて説明します。
EDQは、複数のグラフィカル・ユーザー・インタフェース(GUI)、1つのデータ・リポジトリおよび1つのビジネス・レイヤーで構成されるクライアント/サーバー・アプリケーションです。以降の項では、これらのコンポーネントとそのデータ・ストレージの操作、データ・アクセスおよびI/O要件について、詳細に説明します。
EDQでは、システムを構成して操作するためのGUIが多数提供されています。そのほとんどはJava Web Startアプリケーションであり、それ以外は簡単なWebページです。次の表に、すべてのGUIを示します。
GUI名 | テクノロジ | 用途 |
---|---|---|
ディレクタ |
Web Start |
データ品質処理を設計し、テストします |
サーバー・コンソール |
Web Start |
ジョブを操作し、監視します |
一致レビュー |
Web Start |
一致結果をレビューして、手動で一致を決定します |
ダッシュボード |
ブラウザ |
DQのKPIおよび傾向を監視します |
ケース管理 |
Web Start |
構成可能なワークフローを通じてデータの問題を詳細に調査します |
ケース管理の管理 |
Web Start |
ケース管理のワークフローおよび権限を構成します |
Webサービス・テスター |
ブラウザ |
EDQ Webサービスをテストします |
構成分析 |
Web Start |
構成に関するレポートを作成し、複数のバージョンの構成の差分を取得します |
問題マネージャ |
Web Start |
DQの問題のリストを管理します |
管理 |
ブラウザ |
EDQサーバーを管理します(ユーザー、グループ、拡張機能、Launchpadの構成) |
パスワードの変更 |
ブラウザ |
パスワードを変更します |
構成分析 |
Web Start |
プロジェクトの構成を分析し、差分を報告します |
これらのGUIには、EDQサーバーのEDQ Launchpadからアクセスできます。クライアントがJava Web Startアプリケーションのいずれか(ディレクタなど)を起動すると、そのアプリケーションはクライアント・マシンにダウンロードされ、インストールされて実行されます。アプリケーションはサーバーと通信して、変更をインスタンス化し、サーバーからのメッセージを受信します(実行中のタスクに関する情報、他のユーザーによる変更など)。
EDQは拡張可能なシステムであるため、特定のユースケースに対応するために、インストール時にさらにユーザー・アプリケーションを追加して拡張することができます。たとえば、Oracle Watchlist ScreeningでEDQを拡張すると、監視リストに関してデータをスクリーニングする独自のユーザー・アプリケーションが追加されます。
注意: 多くのGUIがありますが、それらは単独で使用可能な場合(特定用途のため)と、別のGUIから使用可能な場合があります。たとえば、構成分析、一致レビューおよび問題マネージャのGUIは、ディレクタ内からでも使用できます。 |
EDQは、2つのデータベース・スキーマ(ConfigスキーマおよびResultsスキーマ)を含むリポジトリを使用します。
注意: 各EDQサーバーは、そのサーバー専用のConfigスキーマおよびResultsスキーマを持つ必要があります。複数のサーバーを高可用性アーキテクチャにデプロイする場合に、2つのサーバーが同一のスキーマをポイントするようにして構成を共有することはできません。 |
Configスキーマは、EDQの構成データを格納します。通常は、多くのWebアプリケーションに共通の一般的なトランザクション方式で使用されます(問合せを実行して少数のレコードにアクセスし、必要に応じて更新します)。
データ記憶域
通常、このスキーマには少量のデータのみが保持されます。簡単な実装の場合は、数MB程度であることがほとんどです。例外的に大規模なEDQシステムでは、特にケース管理の使用頻度が高い場合は、ストレージ要件が10GBに達する可能性があります。
データ・アクセス
Configスキーマで保持されるデータへのアクセスは、他のRDBMSアプリケーション内の構成データでもよく行われます。ほとんどのデータベース・アクセスは読取りリクエストの形式であり、それに比較的少量のデータ更新および挿入リクエストも付随します。
Resultsスキーマには、スナップショット・データ、ステージング済データおよび結果データが格納されます。これは高度に動的で、サーバーで動作中のプロセッサで処理されるデータを格納するために、必要に応じて表が作成および削除されます。プロセス実行中に、使用可能なメモリーに保持できない作業データを格納するために、一時的な作業表も作成および削除されます。
データ記憶域
Resultsスキーマに保持されるデータ量は時間とともに大幅に変化し、データのキャプチャおよび処理ではデータが数GBに及ぶ可能性があります。また、プロセスまたはジョブの実行中に、データが一時的に結果データベースに格納されることもあります。ジョブについては、処理中に複数のバージョンのデータがデータベースに書き込まれる場合があります。
データ・アクセス
Resultsスキーマは、Configスキーマとはまったく異なるデータ・アクセス・プロファイルを持ち、従来のWebベースのデータベース・アプリケーションとは大きく異なります。通常、Resultsスキーマの表は次の特徴を持ちます。
オンデマンドで作成されます。
一括JDBC APIを使用してデータを移入します。
プロセス実行をサポートするために、完全表スキャンを使用して問合せが実行されます。
索引が付けられます。
GUIでのユーザーの対話に応答して、複雑なSQL文を使用して問合せが実行されます。
関連付けられているプロセスまたはスナップショットが再度実行されると削除されます。
このような動的性質を持つため、このスキーマは慎重に取り扱う必要があります。たとえば、REDOログ・ファイルを別のディスクにマウントすることをお薦めします。
ビジネス・レイヤーでは、主に次の3つの機能があります。
GUIがシステムの他の部分とやり取りするためのAPIを提供します。
GUIに、GUIの更新が必要となる可能性のあるサーバー・イベントを通知します。
データをキャプチャして処理するプロセスを実行します。
GUIとの間でデータを受け渡す際、ビジネス・レイヤーはほとんどの従来のJava Webアプリケーションと共通の方法で動作します。ビジネス・レイヤーは小規模なデータベース・トランザクションを作成し、HTTP接続を使用してフロントエンドに少量の情報を送信します。このアプリケーション・フロントエンドの大部分がブラウザよりも豊富なGUIを持つという点において、これは幾分変わっています。そのため、このGUIに送信されるデータのほとんどは、従来のHTMLではなく、シリアライズJavaオブジェクトで構成されます。
ただし、プロセスの実行時およびスナップショットの作成時には、このビジネス・レイヤーの動作は従来のバッチ・アプリケーションに近づきます。デフォルト構成では、非常に大規模なデータ量でも処理できるように、複数のスレッドおよびデータベース接続を生成し、使用可能なCPUコアおよびデータベースI/O容量をすべて使用します。
使用可能なリソースの使用を制限するようにEDQを構成できますが、明らかにパフォーマンスに影響を与えます。詳細は、EDQインストレーション・ガイドおよびEDQパフォーマンス・チューニング・ガイドを参照してください。
EDQの最も重要な要素は次のとおりです。
要素 | 説明 |
---|---|
スナップショット |
スナップショットは、EDQリポジトリ内に格納されている、外部データのキャプチャ済コピーです。 |
プロセッサ |
プロセッサは、データに対してなんらかの処理を実行する論理要素です。プロセッサは、統計分析、監査チェック、変換、照合などの操作を実行できます。複数のプロセッサが連鎖することによって、プロセスを形成します。 |
プロセス |
プロセスは、特定のデータに対して実行するアクションのセットを示します。これは一連のプロセッサで構成され、プロセッサのそれぞれでデータの処理方法、および適用されるルールが指定されています。プロセスでは次のものが生成されることがあります。
|
ジョブ |
ジョブは、EDQまたは外部によって実行される可能性のある、構成され、順序付けられた一連のタスクです。タスクの例としては、ファイル・ダウンロード、スナップショット、プロセスおよびエクスポートの実行があります。 |
参照データ |
参照データは、プロセッサがチェック、照合、変換などの実行に使用できるリストおよびマップで構成されます。参照データは、EDQの一部として、またはサード・パーティによって提供されることも、ユーザーが定義することも可能です。 |
ステージング済データ |
ステージング済データは、データ・スナップショットおよびプロセスによって書き込まれたデータで構成され、Resultsスキーマ内に格納されます。 |
これらおよびその他のコンセプトの詳細は、EDQオンライン・ヘルプでコンセプトに関する項を参照してください。
この項では、EDQで実行される操作の中で、最も重要で大量にリソースを消費する操作として、データ・キャプチャ、一般的なデータ処理、照合処理およびリアルタイム・データ処理について説明します。
データ・キャプチャ・プロセスは、外部データ・ソースからキャプチャされるデータの取得で始まります。データは、データベース、テキスト・ファイル、XMLファイルなどからキャプチャできます。可能なデータ・ソース・タイプのすべてのリストについては、オンライン・ヘルプのコンセプトに関する項で、データ・ストアのトピックを参照してください。データ・ソースのタイプによっては、データ・キャプチャで次の操作が行われる場合があります。
ソース・システムでの単一のSQL問合せの実行。
区切り文字付きファイル、または固定形式ファイルの順次処理。
データのストリームを生成するための、XMLファイルの処理。
データが取得されると、単一のスレッドで処理されます。これには、次の処理が含まれます。
各入力レコードに内部的な順序番号が割り当てられます。通常、これは各行に対して単調に増分される番号です。
行を作業ユニットにバッチングします。作業ユニットが一杯になると、結果データベースの作業キューに渡されます。
データベースの作業キューは、データベースで実行される作業リクエストで構成され、そのほとんどはデータ挿入または索引付けリクエストです。キューはスレッドのプールによって処理されます(キューから作業ユニットが取得され、適切なデータベースへのデータベース接続が取得され、作業が実行されます)。スナップショットの場合、作業の内容は、レコードのグループを表にロードするためのJDBCバッチAPIを使用することです。
すべてのデータが1つの表に挿入されると、スナップショット・プロセスは1つ以上の索引付けリクエストを作成し、それらをデータベース作業キューに追加します。一意の行識別子に索引を付けるために、表ごとに1つ以上の索引付けリクエストが作成されますが、スナップショット内のデータ量およびスナップショット・プロセスの構成によっては、キャプチャされたデータ内の他の列もスナップショット・データへの索引生成に使用されます。
スナップショットでは、次のことが予想されます。
データの読取り中に、データ・ソースをホストするマシンでI/OおよびCPU負荷が生成される
スナップショット・プロセスがデータの読取りを行い、挿入用にそのデータのグループ化を行うことによって、Webアプリケーション・サーバーで、CPU負荷が生成される
データベース作業ユニットのエグゼキュータ・スレッドによって、Webアプリケーション・サーバーで、I/OおよびCPU負荷が生成される
データが新しい表に挿入されるときに、EDQ結果データベースをホストするマシンで、相当量のI/Oが生成される
データに索引付けされるときに、結果データベースをホストするマシンで、相当量のI/OとCPU負荷が生成される
たとえば、4コア・サーバーでのデフォルトのEDQインストールの場合に、10列にわたって10,000行のデータのスナップショットを作成する場合、次の形式のSQLが生成されます。
DROP TABLE DN_1; CREATE TABLE DN_1 (record-id, column1, column2, ..., column10);
100の一括挿入文は次のようになります。
INSERT INTO DN_1 (record_id, column1, column2, ..., column10) VALUES ( ?, ?, ..., ? )
それぞれ100個の一連のパラメータをとります。一括挿入は、4つのデータベース接続(CPUコアごとに1つ)でパラレルに実行されます。
ANALYZE TABLE DN_1 ESTIMATE STATISTICS SAMPLE 10 PERCENT
また、最後に、11個のCREATE INDEX...
文によって、新しい表の各列に索引付けされます(元の10個の列に追加のrecord_id列)。CREATE INDEX
文も、4つのデータベース接続でパラレルに実行されます。
データがキャプチャされると、処理の準備ができます。リーダー・プロセッサは、ダウンストリーム・プロセッサにデータへの管理されたアクセスを提供し、ダウンストリーム・プロセッサは結果データを生成します。ライター・プロセッサが存在する場合、処理の結果をステージング済データ・リポジトリに書き戻します。
プロセスを実行すると、Webアプリケーション・サーバーは多数のプロセス実行スレッドを開始します。EDQのデフォルト構成では、EDQアプリケーション・サーバー・マシンに存在するコア数と同数のスレッドを開始します。
スナップショット内のデータをキャプチャし、結果データベースに格納するかわりに(照合中の一時的なもの以外で)、ソースからプルして、ストリームとしてターゲットにプッシュできます。
各プロセスの実行スレッドには、処理するデータのサブセットが割り当てられます。プロセスの入力データが、スナップショット、ステージング済データなどの既知のサイズのデータ・セットの場合、各スレッドはデータのサブセットを取得する問合せを実行します(データのサブセットの識別は、スナップショット作成中に割り当てられた一意の行IDで行われます)。したがって、第3.1.1項の4コア・マシン上の10,000レコードのデータ処理を説明するサンプル・シナリオでは、Resultsスキーマに対して4つの問合せが発行されます。この問合せは、次の形式になります。
SELECT record_id, column1, column2, … , column10
FROM DN_1
WHERE record_id > 0 AND record_id <= 2500;
プロセスの実行対象が既知のサイズのデータ・セットではない場合(データ・ソースに対して直接実行するようにスケジュールされているジョブなど)、すべてのレコードを1つのキューに読み取ることでプロセス実行スレッド間でレコードが共有され、複数のプロセス実行スレッドによって消費されます。
各プロセス実行スレッドは、プロセスを構成するプロセッサのシーケンスを認識するようにもなっています。このプロセス実行スレッドは、それぞれの適切なプロセッサを通じてレコードを渡します。プロセッサが動作すると、Resultsスキーマに格納する必要がある結果を蓄積しますが、ライター・プロセッサの場合は、ステージング済データに書き込む必要があるデータも蓄積することがあります。このデータはすべて挿入グループに蓄積され、データベースの作業ユニットに追加され、第4.1項「データ・キャプチャ」の説明どおりに処理されます。
実行スレッドが割り当てられたすべてのレコードを処理すると、他のすべてのプロセス実行スレッドが完了するまで待機します。その後、プロセス実行スレッドは照合フェーズに入り、その間にプロセスの複数のコピーからのサマリー・データが蓄積され、データベースの作業キューによって結果データベースに書き込まれます。
バッチ処理中は、次の動作が予想されます。
キャプチャされたデータが読み取られる際に、Resultsスキーマでの読取り負荷。
データが処理される際に、Webアプリケーション・サーバーでのCPU負荷。
結果およびステージング済データがスキーマに書き込まれる際に、Resultsスキーマでの著しい書込み負荷。
照合フェーズに入った際のCPU負荷の減少。
未処理のデータベース作業ユニットが処理され、蓄積された結果が書き込まれた際の、それ以降の少量のデータベース作業。
必要に応じて、照合フェーズの最後でのResultsスキーマでのさらなる書込み負荷(結果およびステージング済データ表に索引を付けるためのリクエストの形式で)。索引付けリクエストのサイズと数は、データ量とシステム構成に応じて変わります。
クリーニングおよび検証操作を中心として重厚に構築されたプロセスは、データベースのI/O容量によって制限される傾向があります。一部のプロセッサは著しくCPUリソースを消費しますが、通常、処理速度を決めるのは、Resultsスキーマからのデータの提供速度、Resultsスキーマへの書込み速度です。
レコード重複プロファイラ・プロセッサや重複チェック・プロセッサなど、機能するためにはレコード・セット全体にアクセスする必要のあるプロセッサが多数あります。これらのプロセッサがデータのサブセットにしかアクセスできない場合、重複レコードを正確に検出することはできなくなります。これらのプロセスは、複数のスレッドを使用して入力レコードを取り込み、一時表を構築します。すべてのレコードの検証が完了すると、レコードを様々なプロセス実行スレッド間で配分することによって、再放出します。レコードを取り込んだときと同じプロセス実行スレッドで放出されるとはかぎりません。
プロジェクトの設計フェーズでは、通常、プロセスとジョブはディレクタを使用して対話的に実行されます。ジョブをディレクタ内で実行すると、通常は、ユーザーによる調査用に結果が書き込まれ、範囲内のデータで最適に動作するようにプロセスおよびジョブの構成を繰り返すことができるようになっています。書き込むデータ量は、ディレクタで制御できます。
ただし、ジョブを本番環境にデプロイした場合、通常はこのような詳細な結果は必要なく、ジョブは実行ラベル付きでサーバー・コンソールまたはコマンドラインから実行されます。実行ラベル付きで実行されると、ユーザーがジョブでステージングされるように構成したステージング済データと結果のビューのみがジョブによって書き込まれるため、パフォーマンス効率が向上します。
注意: ジョブは、データの特定のソースまたはターゲットとは独立して設計することができます。このようなジョブは、通常は、一連のコマンドライン・パラメータとともに、または同じパラメータを設定する格納済の実行プロファイルとともに実行されます(これによって、読み取るデータの物理ソース、主要な処理オプション、書き込むデータの物理ソースなど、主要な構成オプションが動的に変更されます)。このようなジョブは実行ラベル付きで実行して、書き込まれるデータおよび結果が、同じジョブを異なるデータで実行した場合とは明確に分離されるようにする必要があります。サーバー・コンソールでは、ユーザーが実行ラベル別に結果を調査できます。 |
オンライン・ヘルプの「拡張機能: 照合コンセプト・ガイド」(http://www.oracle.com/webfolder/technetwork/data-quality/edqhelp/index.htm)に記載されている内容をよく理解することをお薦めします。EDQ照合プロセスに関係する概念を理解することは、ここで説明する内容の把握に大きく役立ちます。
EDQ照合プロセッサは、これよりも単純なプロセッサとは大幅に異なる方法で処理されます。照合プロセッサで実行される作業の性質上、データを通して複数回のパスが必要になります。
照合プロセッサは、一連のサブプロセスとして取り扱うことで実行されます。たとえば、顧客のデータ・スナップショットを、禁止人物のリストと照合するように設計されたプロセスを考えます。このプロセスには、顧客参照番号と関連する禁止人物の識別子のリストを生成するように構成された照合プロセッサが含まれています。照合プロセッサに入力される(または出力される)各データ・ストリームは、照合プロセッサのサブプロセスとみなされます。そのため、この例には3つのサブプロセスがあります(顧客データ入力ストリーム、禁止人物入力ストリームおよび照合プロセッサの出力データ・ストリームを表します)。照合プロセッサ自体は4つ目のサブプロセスを形成し、効率的にデータの入力と出力を対にします。各サブプロセスにはプロセス実行スレッドの通常の割当て量が割り当てられるため、4コア・マシンでは、各サブプロセスが4つのプロセス実行スレッドを持つことになります。
照合プロセッサの実行が開始されると、入力データ・サブプロセッサが最初に実行され、入力データを処理します。この時点では、照合または照合出力サブプロセスの作業はなく、休止状態のままです。入力データ・サブプロセスはデータ・ストリームのクラスタ値を生成し、通常のデータベース作業ユニット・メカニズムを使用して、クラスタ値および受信レコードをResultsスキーマに格納します。
入力データ・サブプロセスがすべての使用可能なレコードを処理すると、そのサブプロセスは終了し、サブプロセスの結果の照合を開始します。その一方で、照合サブプロセスがアクティブになります。照合サブプロセスは一連のステージを通過し、各プロセス実行スレッドは、他のすべてのプロセス実行スレッドが各ステージを完了するまで待機してから、次に進みます。新しいステージが開始されるたびに、作業はそのステージに適した形でプロセッサ・エグゼキュータ・スレッド間でさらに分割されます。処理ステージは次のとおりです。
比較フェーズ |
顧客データと禁止人物データが取得され、クラスタ値で並べ替えられます。データは、クラスタ値が等しいグループに集められ、キューに入れられ、レコードを比較するための照合プロセス・スレッドに渡されます。レコード間に関係が検出された場合、その関係情報がResultsスキーマに書き込まれます。 |
暫定グループ化フェーズ |
比較フェーズで検出された関係情報は、チャンクで取得され、関連するレコードの暫定グループが形成されます。関係チャンクは、照合プロセッサ・スレッドによってパラレルに処理されます。これらの暫定グループは、結果データベースに書き戻されます。 |
最終グループ化フェーズ |
単一のスレッドが暫定グループ表を検査して、チャンクの境界によって人為的に分割されたグループを確認します。チャンクを横断するグループが検出された場合は、1つのグループにマージされます。 |
マージ済の出力フェーズ |
照合プロセッサ・スレッドのそれぞれが、照合グループの独立したサブセットを取得し、マージした出力を作成します(複数のレコードが1つの出力レコードにマージされます)。 |
これで照合サブプロセスは完了し、照合プロセッサ実行スレッドは照合フェーズへと移行します。
この時点で、照合データの出力に関連付けられるサブプロセスがアクティブになります。出力データは出力サブプロセスのプロセス実行スレッド間で分割され、照合プロセッサからのプロセッサ・ダウン・ストリームに渡されます。この後、データは通常のバッチ処理の方法で処理されます。
ベンチマークおよび本番での経験から、照合プロセッサの比較フェーズは、CPUバウンドになる可能性がある数少ないEDQ操作の1つであることがわかっています。非常に簡単な比較操作以外のものを実行した場合、CPUが比較負荷を処理する能力によって、プロセスが制限されます。比較操作の規模は適切に拡大縮小され、EDQ Webアプリケーション・サーバーで使用可能なすべてのCPUサイクルを完全に使用できます。
EDQは、メッセージをリアルタイムに処理できます。現在、EDQでサポートされているメッセージングの手段は次のとおりです。
Webサービス
JMS対応メッセージング・ソフトウェア
リアルタイム・メッセージ処理用に構成すると、サーバーはメッセージの受信時にメッセージを処理するために、複数のプロセス実行スレッドを開始します。受信メッセージは、空いているプロセス実行スレッドに渡されるか、キューに入れられて次のプロセス実行スレッドが空くのを待機します。メッセージが処理されるとステージング済データはすべて結果データベースに書き込まれ、プロセス実行スレッドは、キューから次のメッセージを取り出すか(存在する場合)、または次の受信メッセージに使用可能になります。
データをリアルタイムに処理する場合、プロセスは間隔モードで実行できます。間隔モードでは、プロセスが設定された間隔で結果を保存可能になり、その結果をユーザーが確認し、EDQダッシュボードに公開できるようになります。間隔は、処理されるレコード数、または時間制限によって決定できます。間隔の上限に達すると、EDQはそのプロセスに対して新しいプロセス実行スレッドのセットを開始します。新しいプロセス実行スレッドすべてが必要な初期化を完了すると、新しい受信メッセージはこの新しいスレッドに渡されます。古いプロセス実行スレッドのセットが未処理のメッセージの処理を完了すると、システムはこれらのスレッドに照合フェーズに移行して、すべての結果を保存するように指示します。その後に古いプロセス実行スレッドは終了され、データは参照可能になります。
アプリケーション・セキュリティは、アプリケーション・アーキテクチャの多くの側面に組み込まれています。
Webアプリケーション・サーバーとクライアント・アプリケーションの間の通信のセキュリティは、EDQをホストするJavaアプリケーション・サーバーの構成によって決まります。Javaアプリケーション・サーバーは、HTTPまたはHTTPSを使用するように構成できます。
EDQは、構成データベースに保持されている値、またはLightweight Directory Access Protocol (LDAP)が有効なユーザー管理サーバーに保持されている値に対してユーザー・パスワードを認証します。パスワードは、アプリケーションがリバースできないハッシュ済形式で保持されます。この構成は、次のものによって使用されます。
クライアント・ユーザー・アプリケーション
EDQ Webページ
クライアント・ユーザー・アプリケーションは、HTTPまたはHTTPS上で独自のプロトコルを使用してユーザーを認証します。パスワードは、暗号化されてからサーバーに送信されます。
Webページは、フォームベースの認証を使用して保護されます。これは、HTTPまたはHTTPS上でサーバーと通信します。
次の基準を含む、必須のパスワード強度の強制も構成できます。
最小文字数。
アルファベット以外の文字の最小数。
数字の最小数。
最近使用したパスワードの再利用防止。
パスワードへのユーザー名の使用防止。
次の条件を含むアカウント・セキュリティも構成できます。
パスワードの有効期限。
ログイン試行が失敗した後のアプリケーションの動作。
EDQは、情報の性質に応じて、セキュリティ情報を多くの場所に格納します。
EDQがスナップショットおよび動的な値のルックアップを実行するために接続するデータベースの接続情報は、Configスキーマに格納されます。これには、データベース接続に使用されるユーザー名、パスワード、ホスト名およびポート番号が含まれます。パスワードは暗号化されてConfigスキーマ(またはWebLogicプラットフォームのキーストア)に格納され、データベースへのログインが必要になるとEDQによって復号化されます。復号化されたパスワードが、EDQユーザーまたは管理者に表示されることはありません。パスワードの暗号化/復号化鍵は、EDQのインストール環境ごとにランダムに生成されます。WebLogicプラットフォームでは、鍵はキーストアに保持されます。その他のプラットフォームでは、EDQ構成ディレクトリ内のファイルに格納されます。インストール環境ごとにランダムにキーを生成することによって、暗号化されたパスワードを別のシステムにコピーしても役に立ちません。
WebLogicインストール環境、およびEDQがリポジトリ・データベースへの接続にJava Naming and Directory Interface (JNDI)接続を使用するようなその他のインストール環境では、データベースへの認証情報は、アプリケーション・サーバーに格納されます。EDQがこれを使用するには、EDQ構成ディレクトリ(oedq_home
)のファイル(director.properties
)でJNDI名を参照します。
EDQが複数のビジネス分野にまたがって使用される場合、または複数のビジネスで同じシステムを使用する場合、データへのユーザー・アクセスをセグメント化する能力が重要です。EDQでは、ユーザーおよびプロジェクトをグループに割り当て可能にすることによって、これを実現しています。ユーザーがプロジェクトにアクセスできるのは、ユーザーがそのプロジェクトと同じグループのメンバーである場合のみです。ディレクタ・ユーザー・アプリケーションは、特定のユーザーに対して、アクセス可能なプロジェクトのみを表示して、その他のすべてのプロジェクトは非表示にし、権限を持たないユーザーはどのコンテンツ(参照データ、Webサービスなど)も利用できないようにします。
注意: 管理ユーザーは、システムのすべてのプロジェクトを管理できる必要があるため、プロジェクトの作成権限を持つユーザーは、プロジェクトの設定に関係なく、システム内のすべてのプロジェクトを参照できます。 |
詳細は、ドキュメント・セットに含まれる次のドキュメントを参照してください。
『Oracle Enterprise Data Qualityインストレーション・ガイド』
次に示すOracle Enterprise Data QualityのドキュメントWebサイトで、このドキュメントおよびすべてのドキュメントの最新版を参照してください。
http://download.oracle.com/docs/cd/E48549_01/index.htm
また、EDQに付属のEDQオンライン・ヘルプの最新版も参照してください。
Oracleのアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWebサイト(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc
)を参照してください。
Oracle Supportへのアクセス
Oracleサポート・サービスでは、My Oracle Supportを通して電子支援サービスを提供しています。詳細情報は(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info
)か、聴覚に障害のあるお客様は(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs
)を参照してください。
Oracle Enterprise Data Qualityアーキテクチャ・ガイド, リリース11g R1 (11.1.1.7)
E51454-01
Copyright © 2006, 2013, Oracle and/or its affiliates. All rights reserved.
このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。
ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。
このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。
U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.
このソフトウェアまたはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアまたはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用する際、このソフトウェアまたはハードウェアを安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。
OracleおよびJavaはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。
Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。
このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。