データ・プロファイリングの実行

データ・プロファイリングでは、リソースが集中的に消費され、特にデータ量が大きい場合、実行時間が非常に長くなります。1つまたはすべてのソース・システムのコンテンツ全体をプロファイリングすることは、有効なプロファイリング結果を作成するための最も効率的な方法ではありません。プロファイリング対象のソースの量が大規模かつ複雑な場合、まず、限定的にデータ・プロファイリングを実行し、その結果を利用して次にプロファイリングする対象を決定する反復的な方法がより効率的です。

次のガイドラインに従うと、プロファイリングの所要時間や作業量が削減されるだけでなく、データ・プロファイリング結果の有効性が向上します。

• 大量のダウンストリーム・オブジェクトに影響を与えるソース、または影響を受けるオブジェクトがシステムの最も重要な出力である場合にそのソースをプロファイリングします。たとえば、大量のダウンストリーム・ビジネス・インテリジェンス・レポートの内容に影響を与えるデータがソース表に含まれる場合、この表のプロファイリングを検討します。特定の列のみがダウンストリーム・ターゲットで使用される場合、属性セットを使用して、特定の列に限定したプロファイリングを検討します。

  
  

  ヒント: システム全体に影響を与えるソースを特定するには、Warehouse Builderのデータ系統および影響分析の機能を使用します。詳細は、Oracle Warehouse Builderインストレーションおよび管理ガイドfor Microsoft Windows and UNIX Systemsを参照してください。

  
  

• 誤りのあるデータが含まれる可能性の高いソースをプロファイリングします。たとえば、手動で入力された顧客データおよび注文データは、サプライヤからダウンロードされた製品データよりもエラーが含まれる可能性は高くなります。

• 既存のシステムに統合する前に、新しいソース（特に初期データ品質が不明なソースなど）をプロファイリングします。

• ソースのドキュメントがある場合、このドキュメントに基づいてデータ・ルールを定義し、そのルールに準拠するデータに絞ってプロファイリングします。準拠するデータがない場合は、より全体的なプロファイリングを検討します。

• 重要な結果が得られないプロファイリング・タイプを無効化します。たとえば、ドメインの検出に限定した初期プロファイリング・パスを実行するか、機能依存の検出など、より詳細で計算集中型のプロファイリング・タイプの前に初期プロファイリングを実行します。

• まず、ソースのコンテンツ全体をプロファイリングするのではなく、データのランダム・サンプリングにプロファイリングを限定します。データ・ルールの初期セットを特定したら、そのルールに準拠するすべての行をプロファイリングできます。

たとえば、5つの表（CUSTOMERS、REGIONS、ORDERS、PRODUCTS、PROMOTIONS）を含むソースを検討するとします。次の情報を参考にできます。

• CUSTOMERS表は、重複し、かつ誤りのあるエントリが数多く含まれているとされ、マーケティング活動に使用されます。

• ORDERS表には、手書きのフォームおよび電話による注文から転記された注文データが含まれます。

• PRODUCTS表には、信頼できるサプライヤからダウンロードされたデータが含まれ、自由形式テキストを含むVARCHAR2（4000）列DESCRIPTIONがあります。

• ソース・システムのドキュメントには、ORDERS表とREGIONS表間に外部キー関係があると記載されていますが、このドキュメントは数年前のもので、ソース・システムが変更されている可能性があります。

この場合、初期プロファイリング・プロセスを次のように限定できます。

• CUSTOMERS表にはエラーが含まれている可能性があるため、他の表の前にCUSTOMERS表をプロファイリングします。

• すべてのプロファイリングからPRODUCTS.DESCRIPTION列を除外します。これは、自由形式テキストからは有効なプロファイリング情報を得られない場合が多いからです。

• ランダム・サンプリングを使用して、すべての表から限定された行数をプロファイリングします。

• ORDERS表とREGIONS表をまとめてプロファイリングし、外部キー関係をテストします。

その後、最初のパスでの検出結果に基づいて、さらにプロファイリングを実行します。