| Oracle® Fusion Middleware Oracle Data Integratorスタート・ガイド 11g リリース1(11.1.1) B65041-01 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Data Integratorスタート・ガイド 11g リリース1(11.1.1) B65041-01 |
|
前 |
次 |
この章では、データ品質管理の実装方法について説明します。データ整合性制御の概要を示します。
この章の内容は、次のとおりです。
データ整合性制御は、情報システムのアプリケーションにおいて、データの全体的な整合性を維持する際に欠かせません。
情報システムによって課された制約および宣言的ルールに対して、アプリケーション・データが常に有効とはかぎりません。たとえば、発注書で顧客が空白になっている場合や、発注の明細で製品が空白になっている場合などが考えられます。
Oracle Data Integratorには、これらの制約違反を検出してリサイクルまたはレポート目的で格納するための作業環境が用意されています。
静的制御とフロー制御の2つのタイプがあります。この2つのタイプの相違について説明します。
静的制御
静的制御は、アプリケーション・データの整合性を検証するために使用するルールが存在することを意味します。これらのルール(制約とも呼ばれます)の一部は、データ・サーバーに(主キー、参照制約などを使用して)すでに実装されている可能性があります。
Oracle Data Integratorでは、追加の制約を定義してチェックすることでデータの品質を高めることができます。追加の制約をサーバーに直接宣言する必要はありません。この手順は、既存(静的)データのチェックを直接実行できるため、静的制御と呼ばれます。
フロー制御
変換プロセスおよび統合プロセスに対応する情報システムでは、通常、独自の宣言的ルールが実装されています。フロー制御機能は、データを対応する情報システムにロードする前に、それらの制約に基づいてアプリケーションの着信データを検証するために使用します。フロー制御の手順は、インタフェースの章で説明されています。
利点
データ整合性チェックを実行する主な利点は、次のとおりです。
ライフサイクル全体でターゲット・データベースを使用することによる生産性の向上。データ内のビジネス・ルール違反によって、ターゲット・データベースのライフサイクルを通してアプリケーション・プログラミングが遅くなります。したがって、転送されたデータのクリーニングによってアプリケーション・プログラミング時間を減少させることができます。
ターゲット・データベースのモデルの検証。ルール違反が検出されることは、ソースのデータ整合性が不十分なことを必ずしも意味しません。ターゲット・モデルの不備を示す場合があります。アプリケーションが再記述される前にデータを移行すると、現状に則したテスト・データベースを提供しつつ、新規データ・モデルを検証できます。
エンドユーザーに対するサービスの品質の向上。
データの整合性を保証することは、複雑なタスクになる場合があります。実際は、宣言的ルールに違反するデータを分離し、リサイクルする必要があります。ターゲット・データベースに整合性制約を検証するメカニズムが組み込まれている場合は特に、複雑なプログラミングの開発が必要です。操作制約に関しては、(ソース、ターゲットまたはリサイクルされたフローの)誤ったデータを修正する方法を実装し、その方法を企業全体で再利用することが最も効率的です。
この例では、データ整合性の監査プロセス(静的制御)について順を追って説明します。
Orders Application - HSQLアプリケーションには、様々なレベルでビジネス・ルール制約を満たさないデータが含まれています。目的は、このアプリケーションのデータのうち、情報システムで設定された制約を満たさないものを特定することです。
この項の内容は、次のとおりです。
ソースには、矛盾するデータが含まれている可能性があります。ソース表に実装されていない制約がターゲット表にある場合や追加の規則が必要な場合があります。この例では、SRC_CUSTOMER表に設定する制約が2つあります。
顧客は21歳より上である必要があります。ただし、それより若い顧客に対応するレコードが入力表に含まれている可能性があります。
CITY_ID列はSRC_CITY表のエントリを参照する必要があります。ただし、市区町村表に存在しない値がある可能性があります。
これらの2つの制約を満たさない行を特定し、対応する無効なレコードを分析用にエラー表に自動的にコピーします。
これらのタイプのルールを強制するには、チェック制約(条件とも呼ばれる)およびSRC_CITY表とSRC_CUSTOMER表の間の参照制約を使用する必要があります。
この項では、次の制約の作成方法について説明します。
年齢制約を作成することは、列にデータの検証条件を追加することです。
年齢制約を作成するには:
デザイナ・ナビゲータの「モデル」アコーディオンで「Orders Application - HSQL」モデルを展開します。
「SRC_CUSTOMER」データストアを展開します。
「制約」ノードを右クリックし、図5-1に示すように「新規条件」を選択します。
条件エディタの「定義」タブで次のようにします。
「名前」フィールドに条件の名前を入力します。たとえば、AGE > 21です。
「タイプ」リストで「Oracle Data Integrator条件」を選択します。
Where句フィールドに次のSQLコードを入力します。
SRC_CUSTOMER.AGE > 21
|
注意:
|
「メッセージ」フィールドに、エラー表に表示されるエラー・メッセージを指定します。
Customer age is not over 21!
図5-2に条件エディタを示します。
「ファイル」メイン・メニューから「保存」を選択し、条件を保存します。
この項では、CITY_ID列に基づいた、SRC_CUSTOMER表とSRC_CITY表の間の参照制約を作成する方法について説明します。
この制約では、顧客の市区町村がSRC_CITY表に存在することをチェックできます。
参照制約を作成するには:
デザイナ・ナビゲータの「モデル」アコーディオンで「Orders Application - HSQL」モデルを展開します。
「SRC_CUSTOMER」データストアを展開します。
「制約」ノードを右クリックし、図5-3に示すように「新規の参照」を選択します。
参照エディタの「定義」タブで次のようにします。
「タイプ」リストから「ユーザー参照」を選択します。
「親モデル/表」セクションの「モデル」リストで「Orders Application - HSQL」を選択します。これは、リンク先の表を含むデータ・モデルです。
「表」リストから、「SRC_CITY」を選択します。これは、リンク先の表です。
図5-4に参照エディタを示します。
参照エディタで「列」タブに移動します。
「列」タブで、図5-5に示すように「追加」をクリックします。
新しい行が列表に挿入されます。
このステップでは、対照させる列を定義します。
表示される行をクリックします。これによって、適切な表のすべての列を含むドロップダウン・リストが表示されます。
「列(外部表)」リストから、「CITY_ID」を選択します。
「列(プライマリ表)」リストから、「CITY_ID」を選択します。
図5-6に、選択した、対照させる列が含まれた参照エディタの「列」タブを示します。
この例では、外部表はSRC_CUSTOMERで、プライマリ表はSRC_CITYであることに注意してください。外部キーでは、外部表とプライマリ表の列名が一致する必要はないことにも注意してください。この例ではたまたまそうであるだけです。
「ファイル」→「保存」の順に選択し、この参照を保存します。
|
ヒント: かわりに、[Ctrl]+[S]ショートカットを使用して現在のエディタを保存することもできます。 |
静的制御の実行では、データベースに定義されている制約が検証されます。SRC_CUSTOMERデータストアのデータを、第5.2.3項「制約の作成」で定義した制約に対して検証できます。
静的制御を実行するには:
デザイナ・ナビゲータの「モデル」アコーディオンで、「SRC_CUSTOMER」データストアを右クリックします。
「制御」→「チェック」の順に選択します。
図5-7に示すような「実行」ダイアログが表示されます。
「実行」ダイアログで「OK」をクリックします。
図5-8に示すような「情報」ダイアログが表示されます。
「情報」ダイアログで「OK」をクリックします。
Oracle Data Integratorでデータのチェックに必要なコードがすべて自動的に生成され、実行セッションが開始されます。
オペレータ・ナビゲータを使用すると、実行結果を表示でき、セッションでの開発物の実行を管理できます。
制御の実行結果を表示するには:
オペレータ・ナビゲータの「セッション・リスト」アコーディオンで「すべての実行」ノードを展開します。
セッション・リストには、日付、物理エージェント、ステータス、キーワードなどの単位で編成されたすべてのセッションが表示されます。
オペレータ・ナビゲータのツールバーで「リフレッシュ」をクリックして、表示されている情報をリフレッシュします。
実行セッションのログの表示は、図5-9のようになります。
ログは3つのレベルで構成されます。
セッション(実行エージェントによって起動されるシナリオ、インタフェース、パッケージまたはプロシージャなどの実行に対応)
ステップ(パッケージまたはシナリオ内のチェック対象のデータストア、インタフェース、プロシージャまたはステップに対応)
タスク(インタフェース、プロセスまたはチェックの基本タスクに対応)
この項では、無効なレコードの特定方法について説明します。これらは、制約を満たさず、静的制御によって拒否されたレコードです。
この項の内容は、次のとおりです。
無効なレコードの数を特定するには:
オペレータ・ナビゲータの「セッション・リスト」アコーディオンで「すべての実行」ノードおよび「SRC_CUSTOMER」セッションを展開します。
「SRC_CUSTOMER」ステップをダブルクリックし、セッション・ステップ・エディタを開きます。
「レコード統計」セクションに、静的制御で行われた変更の詳細が表示されます。これらの変更には、挿入、更新、削除およびエラーの数やこのステップで処理された行の数などがあります。
図5-10に、SRC_CUSTOMERステップのセッション・ステップ・エディタを示します。
無効なレコードの数は、「エラー数」フィールドに表示されます。SRC_CUSTOMER表の静的制御では、9個の無効なレコードが検出されたことに注意してください。これらのレコードは、エラー表に分離されます。詳細は、第5.2.6.2項「無効なレコードの確認」を参照してください。
モデルの表で右クリックし、「制御」→「エラー」の順に選択すると、無効なレコードにアクセスできます。
SRC_CUSTOMER表の静的制御のエラー表を確認するには:
デザイナ・ナビゲータで、「Orders Application - HSQL」モデルを展開します。
「SRC_CUSTOMER」データストアを右クリックします。
「制御」→「エラー」の順に選択します。
表5-11に示すようなエラー表エディタが表示されます。
チェック・プロセスで拒否されたレコードは次のとおりです。
AGE > 21制約に違反する8レコード(顧客の実年齢は21歳以下。詳細はAGE列を参照してください)。
FK_CITY_CUSTOMER制約に違反する1レコード(CITY_ID値はSRC_CITY表に存在しません)。
このエディタでレコード全体を確認できます。つまり、正しくない値(最初のレコードの無効なCITY_ID値など)をすぐに確認できます。
表示されるエラー・メッセージは、第5.2.3.1項「年齢制約」でAGE > 21制約を設定したときに定義したものであることに注意してください。
静的制御がソース・データで実行されたため、統合インタフェースの実装に進む準備ができました。
