| Oracle Warehouse Builderユーザーズ・ガイド 10gリリース2（10.2） B31258-02 |
|
 戻る |
 次へ |
今日、組織では、これまで以上にデータ品質の重要性が認識されています。データ・ウェアハウスまたはビジネス・インテリジェンス・アプリケーションに高品質のデータを格納することは、依存するアプリケーションや分析用の情報の品質を確保することにつながります。
Oracle Warehouse Builderには、高品質な情報をビジネス・ユーザーに提供するデータ・システムの作成を支援する一連の機能が用意されています。品質を評価、設計、変換および監視する品質プロセスを実装できます。各フェーズ内では、Warehouse Builderの特定の機能を使用して、向上した品質情報を作成します。
この章の内容は次のとおりです。
高品質なデータは、意思決定や計画の際に重要です。データ・ウェアハウスを構築する目的は、ビジネス上の決定を下すときに役立つ、統合かつ一元化されたデータを確保することです。通常、データは複数の異なるシステムから取得されるため、データ・ウェアハウスにロードされる前にデータが標準化および整備されていることが重要です。
Warehouse Builderは、データを評価、変換および監視することによってデータ品質を効率的に管理できる機能を備えています。Warehouse Builderを使用してデータを管理する利点は次のとおりです。
エンドツーエンドのデータ品質ソリューションを提供できます。
データ統合プロセスの構成部分として、データ品質およびデータ・プロファイリングを含めることができます。
データの品質に関係なく、データとともにメタデータを格納できます。データとメタデータは両方とも、デザイン・リポジトリに格納されます。
データ修正に使用できるマッピングが自動生成されます。このマッピングは、データに適用するビジネス・ルール、およびデータの修正方法に関する決定に基づいています。
データ品質の確保には、次のフェーズが含まれます。
図10-1に、ビジネス・ユーザーへの高品質の情報の提供に関連するフェーズを示します。
品質評価フェーズでは、ソース・データの品質を判断します。このフェーズの最初のステップは、ソース・データ（複数の異なるソースに格納されている場合もあります）をWarehouse Builderにロードすることです。メタデータとデータは、OracleおよびOracle以外のソースからインポートできます。
ソース・データをロードした後に、データ・プロファイリングを使用してデータの品質を評価します。データ・プロファイリングとは、データ内の内容、構造および関係を分析して、データの変則、非一貫性および冗長性を検出するプロセスです。この分析とデータ検出の技術は、データ監視の基礎になります。データ・プロファイリングの詳細は、「データ・プロファイリングについて」を参照してください。
品質設計フェーズでは、品質プロセスを設計します。データ・ルールを使用して、データ・オブジェクト内の正当なデータ、またはデータ・オブジェクト間の正当な関係を指定できます。データ・ルールの詳細は、「データ・ルールについて」を参照してください。
また、データを修正および改良します。データを修正および改良するには、データ品質演算子を使用できます。詳細は、「データ品質について」を参照してください。
品質設計フェーズの一部として、データ品質を確保するための変換も設計します。この変換は、データ・プロファイリングの結果としてWarehouse Builderで生成されたマッピング、またはユーザーが作成したマッピングの場合があります。
品質変換フェーズでは、ソース・データの修正に使用する修正マッピングを実行します。
データ監視は、一定期間にわたってデータを検査し、設定されたビジネス・ルールにデータが違反したときに警告するプロセスです。データ監視の詳細は、「品質監視について」を参照してください。
データ・プロファイリングは、組織が情報の品質を改善し、より適切な決定を下すための最初のステップです。これは、Warehouse Builderで使用できる堅牢なデータ分析方法で、データを使用する前にデータの欠陥を検出して測定するために使用できます。データ・プロファイリングは、Warehouse BuilderのETL機能、および他のデータ品質機能（データ・ルール、組込みの整備アルゴリズムなど）と統合されているため、データ整備およびスキーマ修正も生成できます。これによって、データおよびメタデータの非一貫性、冗長性および不正確さを自動的に修正できます。
データ・プロファイリングを使用すると、データに関する重要な内容を検出できます。次に、一般的な検出内容を示します。
有効な製品コードのドメイン
製品割引の範囲
電子メール・アドレスのパターンを保持している列
列間の1対多関係
列内の変則および異常
表間の関係（関係がデータベースに記述されていない場合も含む）
このトピックには、次の項目が含まれます。
Warehouse Builderのデータ・プロファイリング機能を使用して、次の作業を実行できます。
Warehouse Builderがアクセス可能なソースまたはソースの組合せからのデータをプロファイリングできます。
データ・プロファイリング結果を表形式またはグラフ形式で確認できます。
プロファイリング結果に関連する実際のデータにドリルダウンできます。
データ・プロファイリング結果に基づいて、データ・ルールを手動または自動で導出できます。
データ・ルールをターゲット・オブジェクトにアタッチし、ルールが失敗した場合に実行するアクションを選択できます。
データ・ルールからデータ監査を作成して、オブジェクトにロードされるデータの品質を継続して監視できます。
シックスシグマ評価などの品質指数を導出できます。
導入前に検証が必要なデータ・ルールをプロファイリングまたはテストできます。
データ・オブジェクトの選択に続いて、プロファイルおよび分析の対象とするデータの側面を判断します。図10-2に示すように、データ・プロファイリングには、属性分析、関数従属性および参照分析の3タイプの分析が用意されています。また、データ・ルールを使用してカスタム・プロファイリング・プロセスを作成できるため、実際のデータに対してカスタム・ルールを検証し、その正確性のスコアを取得できます。
属性分析では、特定の列または属性内に格納されたデータの構造と内容に関して、一般情報と詳細情報の両方を調べます。属性分析によって、パターン、ドメイン、データ型および一意の値に関する情報が検出されます。
パターン分析では、属性内に格納されたデータの文字列を分析して、レコードのパターンと共通タイプを検出します。この分析では、属性内に存在する特定の正規表現の形式パターンに準拠するデータのパーセントを識別します。このパターン結果を使用して、現在のデータに関する問題をクリーン・アップするのに役立つデータ・ルールと制約を作成できます。一般的に識別されるパターンには、日付、電子メール・アドレス、電話番号、社会保障番号などがあります。
表10-1に、パターン分析で使用できるサンプル属性「ジョブ・コード」を示します。
表10-2は、このパターン分析の結果を示しています。ここで、Dは数値を表し、Xは文字を表します。この結果から、すべてのジョブ・コードをDDD-X-DDの形式にすることが会社の方針であることが判明し、この属性のすべての値がこのパターンに準拠することを要求するデータ・ルールを導出できます。
ドメイン分析では、最も頻繁に発生する値を調べることによって、ドメイン、つまり属性内で共通して使用されている値を識別します。たとえば、顧客表の「婚姻」列をプロファイリングした結果、90%の値が「MARRIED」、「SINGLE」または「DIVORCED」のいずれかであることが判明したとします。さらに分析を進めてデータにドリルダウンしたところ、残りの10%は、わずかな例外を除いて、これらの語のスペルの間違いであることが判明しました。プロファイリングの構成によってドメインとして適格となる対象が決まるため、ドメイン値を受け入れる前に、構成を確認してください。その後、Warehouse Builderで、この属性に格納されるデータがドメインとして適格とされた3つの値のいずれかであることを要求するルールを導出できます。
データ型分析では、属性内のデータ型に関する情報を検出できます。このタイプの分析では、スケールや精度とともに文字長の最大値と最小値などのメトリックが判明します。たとえば、データベース列のデータ型はVARCHAR2ですが、この列の値がすべて数値である場合があります。この場合、ロード対象が数値のみであることを確認する必要があるとします。データ型分析を使用すると、Warehouse Builderで、属性内に格納されたすべてのデータが同じデータ型であることを要求するルールを導出できます。
一意キー分析では、属性が一意キーであるかどうかを判断するための情報が提供されます。そのために、この分析では、属性内で発生する個別値のパーセントを調べます。70%以上の個別値を持つ属性を一意キー分析の対象としてフラグを付けることもできます。たとえば、一意キー分析を使用して、EMP_ID列の95%の値が一意であることが判明したとします。さらに分析を進めると、残り5%のほとんどの値は重複かNULL値であることが判明しました。このことから、EMP_ID列に入力するすべてのエントリは一意の値でNULL値でないことを要求するルールを導出できます。
関数従属性分析では、列の関係に関する情報を調べます。この分析によって、オブジェクト内のある属性によって別の属性が決定される関係などを検出できます。
表10-3に、属性「部門所在地」が属性「部門番号」に依存する従業員表の内容を示します。属性「部門番号」は属性「部門所在地」に依存していないことに注意してください。
参照分析では、他のオブジェクトを参照するデータ・オブジェクトの状態を調べます。このタイプの分析の目的は、プロファイリング対象のオブジェクトが他のオブジェクトとどのように関連または結合しているかを調べることです。このタイプの分析では2つのオブジェクトを比較するため、多くの場合、1つのオブジェクトを親オブジェクト、もう1つを子オブジェクトと呼びます。この分析で検出される一般的な状態には、親なしの子、子なしオブジェクト、冗長なオブジェクトおよび結合があります。親なしの子とは、子オブジェクトにあるが、親オブジェクトにない値です。子なしオブジェクトとは、親オブジェクトにあるが、子オブジェクトにない値です。冗長な属性とは、親オブジェクトと子オブジェクトの両方に存在する値です。
表10-4および表10-5に、参照分析の候補である2つの表の内容を示します。表10-4は子オブジェクトで、表10-5は親オブジェクトです。
これら2つのオブジェクトの参照分析によって、従業員表の部門番号15は親なしの子で、部門表の部門番号18、20および55は子なしであることが判明します。また、部門番号列の結合も判明します。
これらの結果に基づいて、2つの表の間のカーディナリティを判断する参照ルールを導出できます。
Warehouse Builderには、属性分析、関数従属性および参照分析に加えて、データ・ルール・プロファイリングが用意されています。データ・ルール・プロファイリングを使用すると、オブジェクト内またはオブジェクト間のプロファイル・パラメータを検出するルールを作成できます。
これは強力な機能で、ビジネス・ユーザーが定義した、明らかに存在するルールを検証できます。データ・ルールを作成し、このルールでプロファイリングすることによって、データが実際にルールに準拠しているかどうか、ルールの修正やデータの整備が必要かどうかを確認できます。
たとえば、表10-6に示す従業員表に対して、「収入=給与+ボーナス」というルールを作成したとします。これによって、従業員Alisonに見られるようなエラーを検出できます。
データ・プロファイリングは、定義上、見通しと計画を必要とするリソース集中型のプロセスです。データ・プロファイリングによってデータおよび列を分析し、多くの反復操作を実行してデータの欠陥や変則を検出します。これにより、見通しと計画ができるかぎり効率的であるように保証されます。
データ・プロファイリングを開始する前に、対象となるデータ・オブジェクトを識別する必要があります。すべてのオブジェクトをプロファイリングするのではなく、重要とみなされるオブジェクトを選択してください。同時に、プロファイリングの対象としてソース・システム全体を選択する必要はありません。それは、リソースを無駄に使用するだけでなく、多くの場合、不必要であるからです。品質が重要で会計上の影響が最も大きいデータ範囲を選択してください。
たとえば、顧客、地域、受注、製品および販促の5つの表を含むデータ・ソースがあるとします。データ品質の観点から、最も重要な表は顧客と受注であると判断しました。顧客表には多くの重複や誤ったエントリが含まれているため、マーケティング業務に支障が生じて会社の経費がかさんでいることが判明しています。受注表には、受注に関するデータが不正確な形式で格納されていることが判明しています。このため、データ・プロファイリングの対象として、これら2つの表を選択します。
プロファイリングするオブジェクトを選択した後は、次のステップに従ってプロファイリング・プロセスを実行します。
データ・プロファイリング・プロセスは、ステップ4で終了します。ステップ5から7はオプションで、データ・プロファイリングの後にデータ修正を行う場合に実行できます。
データ・プロファイリングでは、データ・プロファイリングを実行するプロジェクトにプロファイリング対象のオブジェクトが存在する必要があります。プロファイリング対象のオブジェクトがプロジェクトにインポートされているか、プロジェクト内に作成されていることを確認してください。また、データがオブジェクトにロードされていることも確認してください。データ・プロファイリングでは、データがロードされている必要があります。
データ・プロファイリングでは、マッピングを使用してプロファイリングを実行するため、使用するすべてのロケーションが登録されていることを確認してください。データ・プロファイリングでは、ロケーションの登録を試みます。なんらかの理由でデータ・プロファイリングでロケーションを登録できない場合は、プロファイリングを開始する前に、ロケーションを明示的に登録する必要があります。
|
注意: デフォルト構成のデータのみプロファイリングできます。 |
システムの設定後にデータ・プロファイルを作成できます。データ・プロファイルとは、Warehouse Builderリポジトリ内のメタデータ・オブジェクトで、ナビゲーション・ツリーに作成します。データ・プロファイルには、オブジェクトのプロファイリングに必要な定義と設定が格納されます。また、データ・プロファイルには、プロファイリング対象のデータ・オブジェクトのセット、プロファイリング・プロセスを制御する設定、データのプロファイリング後に戻される結果、および修正情報（修正を使用する場合）が含まれます。データ・プロファイルの作成方法の詳細は、「データ・プロファイルの使用」を参照してください。
データ・プロファイルを作成した後は、データ・プロファイル・エディタで開いてデータをプロファイリングしたり、直前に実行したプロファイルの結果を確認できます。データ・プロファイルの目的は、選択したオブジェクトを精査することです。このため、オブジェクト数や実行するプロファイリングのタイプに応じて、時間がかかる場合があります。ただし、プロファイリングは非同期ジョブとして実行されるため、プロファイリング・プロセス中はクライアントを閉じることができます。ジョブ・モニターでジョブの進捗を確認でき、ジョブが完了するとメッセージが表示されます。
結果が生成されて使用可能になると、データ・プロファイル・エディタで表示できます。データのプロファイリング方法の詳細は、「データのプロファイリング」を参照してください。
特定のタイプの分析がある場合は（実行の有無に関係なく）、プロファイルの実行前に構成する必要があります。プロファイルとそのオブジェクトは、次のレベルで構成可能です。
プロファイル全体（含まれるすべてのオブジェクト）
個別のオブジェクト（例: 表）
1つの表内の単一列
たとえば、表内で問題があるのは1列のみで、ほとんどのレコードは特定のドメイン内の値に準拠する必要があることが判明している場合は、プロファイリング・リソースをドメインの検出と分析に集中できます。必要なプロファイリングのタイプを絞り込むことによって、使用するリソースが減り、結果をより速く取得できます。データ・プロファイルの構成方法の詳細は、「プロパティ・インスペクタ」を参照してください。
プロファイリング結果には、プロファイリングされたデータに関する様々な分析情報や統計情報が含まれます。異常が発生している箇所にすぐにドリルダウンしてそのデータを表示できます。さらに、修正が必要なデータを特定できます。プロファイリング結果の表示方法の詳細は、「結果の表示」を参照してください。
データ・ルールは、意思決定に基づいて導出できます。データ・ルールは、データ・ルールに準拠する値のみをデータ・オブジェクト内で許容する場合に使用します。データの整備が必要と判断した場合は、データ・ルールがデータの修正または削除の基礎となります。また、データ・ルールを使用して、ルールに準拠していないデータをレポートすることもできます。データ・ルールの導出方法の詳細は、「データ・ルールの導出」を参照してください。
プロファイリング結果からデータ・ルールを導出した後は、スキーマおよびマッピングの修正を作成できます。スキーマの修正ではスクリプトが作成され、そのスクリプトを使用して、導出済データ・ルールが適用された修正済のソース・データ・オブジェクトのセットを作成できます。
マッピングの修正では、ソース・オブジェクトからデータを取得して新しいオブジェクトにロードするための新しい修正マッピングが作成されます。スキーマおよびマッピングの修正を作成する方法の詳細は、「スキーマの修正とデータの整備」を参照してください。
データ・ルールは、導出することも手動で作成することもできます。修正を作成した前後に、追加のデータ・ルールを手動で定義できます。データ・ルールを手動で定義および編集する方法の詳細は、「データ・ルール・フォルダの作成」を参照してください。
最後に、修正マッピングとデータ・ルールを生成、配布および実行できます。修正マッピングをデータ・ルールとともに実行すると、データが修正されます。導出されたデータ・ルールは修正済スキーマのオブジェクトにアタッチされたままであるため、データ・モニターで使用することもできます。
Warehouse Builderには、データ品質に対する標準化された手法として、別のデータ・プロファイリング結果内に埋め込まれたシックスシグマ結果が用意されています。
シックスシグマとは、ビジネス・プロセスにおける品質の概念を標準化するための方法です。この方法では、ビジネス・プロセスのパフォーマンスを統計的に分析します。シックスシグマの目的は、欠陥を識別して把握し、欠陥の発生要因を排除することによって、ビジネス・プロセスのパフォーマンスを向上させることです。
シックスシグマ・メトリックによって、1,000,000機会当たりの欠陥数が量的な数値として示されます。「機会」という用語は、レコード数と解釈できます。満点のスコアは6.0です。6.0というスコアは、1,000,000機会当たりの欠陥数が3.4の場合のみ達成できます。スコアは、次の計算式を使用して計算されます。
1,000,000機会当たりの欠陥数（DPMO）= (合計欠陥数 / 合計機会数) * 1,000,000
欠陥率（%）= (合計欠陥数 / 合計機会数)* 100%
歩留まり（%）= 100 - 欠陥率
シグマの生成= NORMSINV(1-(合計欠陥数 / 合計機会数)) + 1.5
NORMSINVは、標準正規累積分布の逆数です。
Warehouse Builderには、データ・プロファイリングのためにシックスシグマ・メトリックも用意されています。データ・プロファイリングを実行すると、検出された欠陥および変則の数がシックスシグマ・メトリックとして示されます。たとえば、データ・プロファイリングを実行して、最初の表と2番目の表の間に行関係があることが検出されたとします。この場合、最初の表でこの行関係に準拠しないレコードの数をシックスシグマ・メトリックを使用して示すことができます。
シックスシグマ・メトリックは、データ・プロファイル・エディタで次の方法で計算されます。
集計: 各列について、表内の合計行数（機会）に対するNULL値（欠陥）の数。
データ型: 各列について、表内の合計行数（機会）に対する、文書化されたデータ型に準拠しない値（欠陥）の数。
データ型: 各列について、表内の合計行数（機会）に対する、文書化された長さに準拠しない値（欠陥）の数。
データ型: 各列について、表内の合計行数（機会）に対する、文書化されたスケールに準拠しない値（欠陥）の数。
データ型: 各列について、表内の合計行数（機会）に対する、文書化された精度に準拠しない値（欠陥）の数。
パターン: 各列について、表内の合計行数（機会）に対する、共通形式に準拠しない値（欠陥）の数。
ドメイン: 各列について、表内の合計行数（機会）に対する、文書化されたドメインに準拠しない値（欠陥）の数。
参照: 各関係について、表内の合計行数（機会）に対する、文書化された外部キーに準拠しない値（欠陥）の数。
参照: 各列について、表内の合計行数（機会）に対する、冗長な値（欠陥）の数。
一意キー: 各一意キーについて、表内の合計行数（機会）に対する、文書化された一意キーに準拠しない値（欠陥）の数。
一意キー: 各外部キーについて、表内の合計行数（機会）に対する、子なしの行（欠陥）の数。
データ・ルール: データ・プロファイルに適用された各データ・ルールについて、表内の行数に対する、データ・ルールが失敗した行数。
Warehouse Builderでは、データ・プロファイリングの結果に基づいて、修正マッピングを自動的に作成できます。データ品質のためにWarehouse Builderの基礎となるアーキテクチャを利用する自動化された修正に加えて、独自のデータ品質マッピングも作成できます。
Warehouse Builderは、データ品質を確保するための機能を備えています。ソース・データの変換時に、次の演算子を使用してデータ品質を確保できます。
Match-Merge演算子
「Match-Merge演算子について」を参照してください。
Name and Address演算子
「Name and Address演算子について」を参照してください。
Match-Merge演算子は、一致するレコードを識別して単一のレコードにマージするデータ品質演算子です。この演算子は、レコードを作成してマスター・レコードと照合する、様々なシステムのマスター・データ管理作業で使用できます。
Match-Merge演算子を使用して同じデータを参照するレコードを識別する、ビジネス・ルールを定義できます。この演算子は、一致したレコードを識別した後に、そのレコードを一元化された単一のレコードにマージします。
Match-Merge演算子を使用する際には、次のオプションがあります。
新しいMatch-Merge演算子の定義: パレットからマッピングにMatch-Merge演算子をドラッグ・アンド・ドロップします。マッピング・エディタでMatch-Mergeウィザードが起動します。
既存のMatch-Merge演算子の編集: 演算子を右クリックして「詳細をオープン」を選択します。マッピング・エディタでMatch-Mergeエディタが開きます。
Warehouse Builderでは、Name and Address演算子を使用して、データに対して名前とアドレス整備を実行できます。
Name and Address演算子では、サード・パーティの名前とアドレス整備ソフトウェア・ベンダーから供給されたデータ・ライブラリと入力データを比較し、名前とアドレスのソース・データにあるエラーや非一貫性を識別して修正します。データ・ライブラリは、ベンダーから直接購入できます。
|
注意 : Name and Address演算子を使用するには、別途ライセンスが必要で、サード・パーティの名前とアドレス整備ソフトウェアをインストールする必要があります。詳細は、Oracle Warehouse Builderインストレーションおよび管理ガイドを参照してください。 |
Name and Address演算子を使用する際には、次のオプションがあります。
新しいName and Address演算子の定義: ツールボックスの演算子をマッピングにドラッグ・アンド・ドロップします。マッピング・エディタでName and Addressウィザードが起動します。
既存のName and Address演算子の編集: 演算子を右クリックして「詳細をオープン」を選択します。マッピング・エディタでName and Addressエディタが開きます。
Name and Address演算子によって修正されるエラーや非一貫性には、アドレス形式の相違、略語の使用、スペルの間違い、古くなった情報、一貫性のないデータ、名前の順序変更などがあります。この演算子は、これらのエラーと非一貫性を次のように修正します。
名前とアドレスの入力データを個々の要素に解析します。
名前とアドレスのデータを標準化します。これには、一般的なニックネームやビジネス名、および各国の郵政公社で承認されているアドレス・コンポーネントの標準的な略称が使用されます。名前やアドレスを標準化すると、照合やハウスホールディングが容易になり、顧客を単一のビューで表示するのに非常に役立ちます。
番地名や市区町村名などのアドレス情報を修正します。不適切なアドレスや郵送不可能なアドレスをフィルタリングすると、マーケティング・キャンペーンのコストの削減につながります。
性別、ZIP+4、国コード、区画ID、ビジネスIDと顧客IDなどの追加データを名前とアドレスに追加します。この情報以外に調査ジオコーディングなどのアドレス情報を加えると、地理的な場所に基づくマーケティング・キャンペーンに使用できます。
アドレスに地理的情報を追加しておくと、地域特有のマーケティング活動が容易になります。たとえば、大都市圏内の顧客（都市圏から半径nマイル以内）に限定したマーケティングや、会社の店舗が対象とする顧客（店舗から半径xマイル以内）に限定したマーケティングなどがあります。Oracle DatabaseのオプションであるOracle Spatial、およびOracle Databaseに同梱されているOracle Locatorは、この機能とともに使用できる製品です。
また、Name and Address演算子を使用すると、アドレス修正と郵便照合がサポートされている国の郵便レポートを生成できます。郵便レポートによって、郵便割引を受けられる場合もあります。詳細は、「郵便レポートについて」を参照してください。
この例では、Name and Address演算子を使用するマッピングによってレコードを操作する方法を説明します。このマッピングでは、データ品質のエラーを処理する推奨方法を説明するためにスプリッタ演算子も使用しています。
この例では、ソース・データには表10-7に示すデータ行のある顧客表が含まれます。
表10-7 Name and Address演算子へのサンプル入力
| アドレス列 | アドレス・コンポーネント |
|---|---|
|
名前 |
Joe Smith |
|
番地 |
8500 Normandale Lake Suite 710 |
|
市区町村 |
Bloomington |
|
郵便番号 |
55437 |
このデータにはニックネーム、姓、および郵送先アドレスの一部が含まれますが、顧客のフル・ネーム、完全な番地および州がありません。また、このデータには、トラック輸送の距離計算に使用できる、緯度や経度などの地理的な情報も含まれていません。
この例のマッピングでは、Name and Address演算子を使用して名前とアドレスのレコードを整備した後に、スプリッタ演算子を使用して、レコードの解析が成功したかどうかに応じてレコードを別々のターゲットにロードします。この項では、このようなマッピングの設計に必要な一般的な手順を説明します。
サンプル・レコードを変更する手順は、次のとおりです。
マッピング・エディタで、次の演算子をキャンバスに追加します。
レコードの抽出元のCUSTOMERS表。これは、データ・ソースです。このソースには、「入力例」のデータが含まれています。
Name and Address演算子。この演算子をキャンバスに追加すると、Name and Addressウィザードが起動します。ウィザードの手順に従ってください。
スプリッタ演算子。この演算子の使用方法は、「スプリッタ演算子」を参照してください。
解析に成功したレコード、解析エラーが発生したレコード、およびアドレスは解析されたが郵便照合ソフトウェアに存在しなかったレコードをロードする3つのターゲット演算子。
CUSTOMERS表の属性をName and Address演算子のIngroupにマッピングします。Name and Address演算子のOutgroupの属性をスプリッタ演算子のIngroupにマッピングします。
スプリッタ演算子の使用は必須ではありませんが、この演算子は、適切なレコードと問題が発生したレコードを分割する重要な機能を果します。
スプリッタ演算子の各Outgroupの分割条件を定義し、Outgroupをターゲットにマッピングします。
図10-4に、この例で設計するマッピングを示します。データは、ソース表からName and Address演算子にマッピングされ、次にスプリッタ演算子にマッピングされます。スプリッタ演算子によって、解析に成功したレコードと、解析時にエラーが発生したレコードが分割されます。OUTGRP1の出力は、CUSTOMERS_GOODターゲットにマッピングされます。OUTGRP2の分割条件は、たとえば、Is ParsedフラグがFalseのレコードはNOT_PARSEDターゲットにロードされるように設定されます。この場合、OUTGRP2の「分割条件」はINGRP1.ISPARSED='F'と設定されます。REMAINING_RECORDSグループのレコードは、解析に成功していますが、そのアドレスは郵便照合ソフトウェア内で検出されません。これらのレコードは、PARSED_NOT_FOUNDターゲットにロードされます。
図10-4 Name and Address演算子とともにスプリッタ演算子を使用したマッピング
この例で設計したマッピングを実行すると、Name and Address演算子によって、ソース表にあるアドレス・データが標準化および修正され、完全なデータになります。この例では、ターゲット表に、表10-8に示すアドレス・データが含まれています。表10-7の入力レコードと比較してください。
表10-8 Name and Address演算子の出力サンプル
| アドレス列 | アドレス・コンポーネント |
|---|---|
|
標準化された名前 |
JOSEPH |
|
姓 |
SMITH |
|
第1アドレス |
8500 NORMANDALE LAKE BLVD |
|
第2アドレス |
STE 710 |
|
市区町村 |
BLOOMINGTON |
|
都道府県 |
MN |
|
郵便番号 |
55437-3813 |
|
緯度 |
44.849194 |
|
経度 |
-093.356352 |
|
解析済 |
TrueまたはFalse。レコードが個々の要素に分割できるかどうかを示します。 |
|
適切な名前 |
TrueまたはFalse。名前が郵便データベースで見つかったかどうかを示します。 |
|
適切なアドレス |
TrueまたはFalse。アドレスが郵便データベースで見つかったか、または解析に成功したかを示します。 |
|
検出済 |
TrueまたはFalse。アドレスが郵便データベースで見つかったかどうかを示します。 |
|
名前警告 |
TrueまたはFalse。名前の解析時に問題が発生したかどうかを示します。 |
|
番地警告 |
TrueまたはFalse。アドレスの解析時に問題が発生したかどうかを示します。 |
|
市区町村警告 |
TrueまたはFalse。市区町村名の解析時に問題が発生したかどうかを示します。 |
この例では、入力データが次のように変更されています。
Joe SmithがFirst_Name_Standardized（標準化された名前）とLast_Name（姓）の2列に分割されています。
JoeがJOSEPHに標準化され、SuiteがSTEに標準化されています。
Normandale LakeがNORMANDALE LAKE BLVDに修正されています。
郵便番号の最初の部分である55437にZIP+4コードが追加され、55437-3813になっています。
緯度および経度が追加されています。
レコードが様々な方法でテストされ、適切なレコードは、問題が発生したレコードとは別のターゲットにロードされます。
他の種類の解析と同様に、Name and Address解析は、キーワードとそのキーワードを含むパターンの識別に依存します。自由形式の名前とアドレスのデータは、キーワード・セットが大きく100%完全であることがないため、解析が困難です。キーワード・セットは何百万ものレコードを分析することで構築されますが、新しいデータ・セットに、未定義のキーワードが含まれることもあります。
自由形式の名前とアドレスのレコードの大半には、数字、文字および英数字文字列の共通パターンが含まれるため、多くの場合、解析は英数字のパターンのみに基づいて実行できます。ただし、英数字のパターンが曖昧であったり、特定のパターンがみつからない場合があります。Name and Addressの解析エラーによって、データ・マッピングの制御に使用できる解析ステータス・コードが設定されます。
品質の基準はアプリケーションによって異なるため、特定のレコードの品質を判断するのに役立つフラグが数多く用意されています。郵便照合がサポートされる国の場合は、Is Good Groupフラグを使用してください。このフラグによって、アドレスが郵便データベース内の有効なエントリであることが確認されます。また、米国のCoding Accuracy Support System（CASS）認証およびカナダのSoftware Evaluation and Recognition Program（SERP）認証の郵便でも、Is Good Groupフラグを使用してください。
郵便レポートを指定しないかぎり、アドレスは郵便データベースで見つからなくても使用できます。たとえば、交差点のアドレスやビル名が郵便データベースで見つからない場合がありますが、配達には問題ありません。Is Good Groupフラグが失敗を示す場合は、別のエラー・フラグによって解析ステータスを判断できます。
Is Parsedフラグは、解析プロセスの成功または失敗を示します。Is Parsedが解析の成功を示す場合でも、特異なデータを示す解析警告フラグをチェックする必要があります。このレコードは手動でチェックできます。
Is Parsedが解析の失敗を示す場合は、元のデータを保存して、データの損失を防ぐ必要があります。
スプリッタ演算子を使用して、解析に成功したレコードと解析に失敗したレコードを別々のターゲットにマッピングします。
割引が適用されるオートメーション郵便料金の郵便物の生成に使用されるアドレス一覧はすべて、郵便レポート認証ソフトウェアで照合される必要があります。認証は、サード・パーティ・ベンダーの名前とアドレスのソフトウェアおよびデータによって異なります。次のような認証があります。
米国郵政公社: Coding Accuracy Support System（CASS）
カナダ郵便局: Software Evaluation and Recognition Program（SERP）
オーストラリア郵便局: Address Matching Approval System（AMAS）
Coding Accuracy Support System（CASS）は、米国郵政公社（USPS）と郵便業界の協力によって開発されました。このシステムは、郵便利用者にとって、アドレス照合ソフトウェアの品質を測定する共通プラットフォームとなり、特に、すべての郵便に適用される5桁の郵便番号、ZIP+4番号、配布ポイント・コードおよび配達ルート・コードの正確さを検証します。オートメーション料金の郵便物の生成に使用されるアドレス一覧はすべて、CASS認定ソフトウェアで照合される必要があります。
USPS要件を満たすには、郵便利用者はCASSレポートを原本のフォームでUSPSに送信する必要があります。
カナダ郵便局は、ソフトウェア・パッケージを評価するSoftware Evaluation and Recognition Program（SERP）というテスト・プログラムを開発しました。このプログラムでは、カナダ郵便局の要件に対して、メーリング・リストを検証する機能、または検証して修正する機能が評価されます。SERP要件を満たす郵便プログラムは、カナダ郵便局のWebサイトにリストされています。
カナダのインセンティブ・レターメール、広告付きアドメールおよび刊行物メールを利用する顧客は、アドレス照合プログラムの要件を満たしている必要があります。顧客は、使用しているデータベースとカナダ郵便局のアドレス・データを比較することで、Statement of Accuracyを取得できます。
Address Matching Approval System（AMAS）は、アドレス指定の品質を向上させるためにオーストラリア郵便局によって開発されました。このシステムは、アドレス照合ソフトウェアの次の機能をテストおよび測定する基準を提供します。
郵便アドレス・ファイル（PAF）に対するアドレスの照合および修正。
各アドレス・レコードへの一意の配布ポイントID（DPID）の追加。これは、メールのバーコード化への手順の1つです。
AMASによって、企業は次の機能を持つアドレス照合ソフトウェアを開発できます。
バーコード作成用アドレスの準備
高品質なアドレス指定
郵便物の事前区分け申請による割引資格の適用
事前区分けサービス料金は、利用者が、最新バージョンのPAFで有効な配布ポイントID（DPID）を持つAMAS承認ソフトウェアを使用していることが条件です。
郵便局で入手可能な事前区分け申請書を使用する場合は、郵便物が適切に準備されていることを宣言する必要があります。
データ・ルールは、Warehouse Builderで作成できる有効なデータ値と関係の定義です。データ・ルールによって、表内の正当なデータ、または表間の正当な関係が判断されます。データ・ルールを使用すると、データ品質の確保に役立ちます。データ・ルールは、表、ビュー、ディメンション、キューブ、マテリアライズド・ビューおよび外部表に適用できます。また、データ・ルールは、データ・プロファイリング、データやスキーマのクレンジング、データ監査など多くの場合に使用されます。
データ・ルールのメタデータは、リポジトリに格納されます。データ・ルールを使用するには、データ・ルールをデータ・オブジェクトに適用します。たとえば、有効値が'M'と'F'であることを指定するgender_ruleというデータ・ルールを作成したとします。このデータ・ルールは、Employees表のemp_gender列に適用できます。データ・ルールを適用することによって、emp_gender列に格納される値が'M'または'F'のいずれかであることが保証されます。データ・ルール・バインディングの詳細は、Employees表のデータ・オブジェクト・エディタの「データ・ルール」タブで表示できます。
データ・ルールを作成する方法は2通りあります。1つは、データ・ルールをデータ・プロファイリングの結果から導出する方法で、もう1つは、データ・ルール・ウィザードを使用して作成する方法です。データ・ルールの詳細は、「データ・ルールの使用」を参照してください。
品質監視は、最初のデータ・プロファイリングとデータ品質の方針に基づきます。品質監視によって、データの品質を一定期間にわたって監視できます。また、データが準拠するビジネス・ルールを定義できます。
Warehouse Builderを使用してデータを監視するには、データ監査を作成する必要があります。データ監査によって、定義したビジネス・ルールにデータが準拠していることを確認できます。データ・ルールという機能を使用して、データが準拠するビジネス・ルールを定義できます。
データ監査は、一連のデータ・ルールに対してデータを検証し、レコードがルールに準拠しているかどうかを判断するプロセスです。データ監査では、システム内のデータがルールに準拠しているかどうかの統計メトリックが収集され、欠陥データを監査表およびエラー表に抽出できます。
データ監査では、しきい値を使用します。これによって、ルールに準拠しないレコードが大量に発生するとプロセス・フローが正常に進行せず、エラーや通知が多数発生するという事実に基づくロジックを作成できます。プロセスでは、このしきい値に基づいてアクションを選択できます。また、監査結果を取得して、分析目的で保存できます。
データ監査は、配布して随時実行できますが、通常は、データ・ウェアハウスやERPシステムなどの運用環境において、データの品質を監視するために実行します。したがって、データ監査は、プロセス・フローに追加したりスケジュールすることができます。
データ監査には、実行時の出力値がいくつか設定されています。監査結果は出力値の1つです。監査結果が0の場合、エラーはありません。監査結果が1の場合は、少なくとも1つのエラーが発生しています。監査結果が2の場合は、少なくとも1つのデータ・ルールが指定のエラーしきい値に達して失敗しています。また、データ監査には、エラー率やシックスシグマなどの実測値も設定されています。データ監査の使用方法の詳細は、「データ監査の使用」を参照してください。
データ監査は、システムのユーザーが設定した標準以上のデータ品質レベルを確保するための非常に重要なツールです。また、データ監査は異常なデータの急激な増加を判断するのに役立ち、イベントを急激な増加に結び付けることができます。
メタデータ・ローダー（MDL）ユーティリティを使用すると、データ監査に関連するメタデータをインポートまたはエクスポートできます。MDLユーティリティの使用方法の詳細は、第33章「メタデータ・ローダー（MDL）によるインポートおよびエクスポート」を参照してください。
