情報サービスのパターン、第 3 回: データ・クレンジング・パターン
はじめに
情報はどんな組織にとっても最も戦略的な資産の 1 つですが、データの品質は、情報に基づき市場における真実を見抜いて優位に立つための重要な前提条件です。データの品質が悪ければ、非常に有益な情報が含まれていても、単なる価値のないバイト・ストリームになってしまいます。例えば、「相手」(クライアント、患者、顧客など) の住所が誤っている場合、戦略的な洞察は妨げられ、正確な実態も関連性のある実態も明らかになりません。この類のデータには、2 人の相手が同じかどうか、クライアントの合計数、そして顧客の全容に関する情報が含まれている場合があります。いい加減なデータは、顧客の満足度を下げ、意思の疎通を複雑にし、問題を回避しようとするときのコストを増大させ、そして別の問題の種となるだけです。
孤立した異なる種類のデータ･ストアに情報が分散されている場合、データ品質の問題は極めて深刻になります。このような環境が持つ、異種混合そして孤立しているという性質は、フォーマットがまちまちで値に整合性がないアーキテクチャーを伴う場合が多いからです。さらにデータが 1 つのデータベース内に保持されているとしても、適切なルールが施行されていなければ、品質が優れているとは限りません。データ品質がまったく守られていなかったり、あるいはアプリケーション・コードに組み込まれた一貫性のないルールを使って、別々のコンポーネントがデータ品質を管理したりしていることは珍しくないためです。これは、データ・ストア内に常駐する情報であろうが、アプリケーションによって適宜操作される情報であろうが同じことです。
情報から本質を見抜き、その多大な価値を利用するには、データ・クレンジングを継続的に行ってデータ品質に対処しなければなりません。つまり、データベース層だけでなく、アプリケーション層やプロセス層でも企業全体で一貫したクレンジング・ルールを使用しなければならないということです。
この記事では、データ・クレンジング・パターンの価値を簡単に説明してから、このパターンを適用すべきコンテキストについて説明します。続いて、データ・クレンジング・パターンで対処する問題、そしてソリューションの手法について取り上げます。そして記事の締めくくりとして、焦点とする対象とリスクのある対象、ならびにこのパターンの制約事項を要約します。
データ・クレンジング・パターンの価値命題
このパターンがもたらす主な価値は、以下の 3 つです。
- 整合性と品質の向上
- 開発費と保守費の削減
- 再利用性の向上
それぞれの価値について、以下に詳しく説明します。
整合性と品質の向上
データ・クレンジング・パターンを適用することによる最大のメリットは、情報がデータベース内で保持されるものか、アプリケーションによって処理されるものかに関わらず、情報の整合性と品質を向上させられるという点です。このパターンはデータの品質を向上させ、高品質であることを確実にします。
SOA コンテキストでデータ・クレンジング・パターンを適用すると、「データを最初に収集する時点で」ビジネス・プロセスがデータ品質を管理し、保証できるようになります。情報が保管される前にデータ・クレンジングを適用するようにすれば、データ入力ポータルなどでのエントリー・ポイントに、ビジネスが定義する検証メカニズムを組み込むことができます。
開発費と保守費の削減
データ・クレンジング・パターンは、クレンジング・ルールを指定する方法、そして永続データや一時データに最も効果的にクレンジング・ルールを適用する方法に関する推奨例を提供します。多くのデータ・クレンジング・パターンの実装では、クレンジング・ルールを開発、テスト、そしてデプロイするための高度なツールが提供されています。これらのツールを使用すれば、クレンジング・ルールが手作業で指定されるプロジェクトや、クレンジング・ルールの維持が困難なプロジェクトの多くでオーバーヘッドを減らすことができます。
再利用性の向上
データ・クレンジング・パターンの重要な側面は、これがエンタープライズ・レベルでの再利用性に重点を置いていることです。それぞれのデータベースとアプリケーションが独自のクレンジング・プロセスを実装したとすると、クレンジング・ルールの一貫性は損なわれてしまうでしょう。その場合、データ品質は向上したとしても、効果的な方法あるいは整合性を持った方法ではなく、品質が必要なレベルにまで達しない恐れがあります。そのため、データ・クレンジング・パターンは、同じクレンジング・ルールを広範なコンシューマーに対して一貫して適用する方法を規定します。
コンテキスト
データ・クレンジング・パターンの従来のコンテキストはデータベース層です。大抵はこの層にパターンが適用されますが、SOA への関心が高まっている今、データ・クレンジング・パターンを SOA コンテキストで適用する新たな機会を検討してみます。
SOA 以外の従来のコンテキスト
データ・クレンジング・パターンは、今まで、名前および住所情報のクレンジングに適用されてきましたが、例えば在庫システム内の製品説明などといったフリー・フォームのテキストに適用することも可能です。フリー・フォームのテキストとは一般的に、単一のフィールドに入力された完全な住所など、標準の選択リストから選択されたのではなく手入力されたデータやフォーマット設定なしで入力されたデータのことです。データ・クレンジング・パターンは、フリー・フォームのテキスト・フィールドに含まれるコンテンツに基づくレコードの標準化、クリーンアップ、そして詰まるところ、マッチング (あるいは重複の除去) として定義されます。
SOA 以外の従来からのコンテキストでのデータ・クレンジング・プロセスは、マスター･データ管理 (Master Data Management : MDM) の情報の完全性要件を満たし、複数の重要な企業体が一貫した 1 つの視野を持つためにバッチ機能として定期的に実行されるのが一般的です。従来から、データ・クレンジングは多くのデータ・ウェアハウジング・プロジェクトで適用されてきました。データ・ウェアハウジング・プロジェクトでは、顧客などのエンティティーの全体像の分析、報告、あるいは提供といったことをサポートするため、企業を取り巻くさまざまな情報貯蔵庫からデータが収集されます。このような情報の散在は、独立した部門、製品グループ、子会社、あるいは合併や買収などの後に続く一度きりのイベントに起因します。組織内に技術が存在しない場合や、ターゲット層やマーケティングについての詳細を加えてデータの価値をさらに高めることが望ましい場合、収集されたデータが社外に送られてクレンジングされることも珍しくありませんが、そうなると、重複が除去され品質が高められたデータが戻されるのは、おそらく数日後、あるいはそれよりも後になってしまいます。従来のデータ・クレンジング・パターンを社内で処理するとしたら、通常のデータ・クリーンアップ、またはデータ・ストア、レポート・システム、データ・ウェアハウスへのロードを行うために毎夜あるいは毎週実行される「定期的」機能とするのが一般的です。
使用事例
ある大手宝石小売店では、毎週データ・クレンジング・パターンを使用して、新規顧客アカウント、コンシューマー・ロイヤルティー、主要な世代、そして請求書発送を処理する一連のシステムからの顧客名を調整しています。それぞれのデータ入力ポイントが、顧客名の重複や、同じ場所に住んでいるかもしれない顧客の重複を発生させる原因として考えられます。重複を排除し、そのような情報の意味を理解する手法は、データ・クレンジング・パターンの適用例の 1 つです。
当初は送料といった単純なものを節約する方法として考えられていましたが、先見の明のある会社は現在、コンシューマーの注文パターンの詳細を見抜き、大口の購入者をさらに明確に特定し、そして販売問い合わせ、顧客サポート、請求書発送を 1 箇所に集約して顧客のエクスペリエンスを向上させる手段としてデータ・クレンジング・パターンを頼りにしています。
図 1 は、データ・クレンジング・パターンを従来のコンテキストで適用した場合のアーキテクチャー概要です。
図 1. データ・クレンジング・パターンの従来のコンテキスト
SOA のコンテキスト
データ・クレンジング・パターンの場合での SOA コンテキストは、高度な標準化とマッチングの手法を利用し、この 2 つの手法をほぼリアルタイムのアプリケーションの最前線にまで拡張します。SOA コンテキストで見た場合、データ・クレンジング・パターンを使用することで、企業はその検証能力とマッチング能力をデータ作成の時点にまで広げることができます。さらに、バッチ操作で使用される重複除去およびマッチングのロジックは、高度な検索方法を統合することも、情報や ID が不明または不完全な場合に顧客情報を特定する機能を拡張するために使用することもできます。
データ・クレンジングの場合の SOA コンテキストでは、個別の要求ストリングの標準化およびマッチングが可能です。単一の名前や住所は動的にクレンジングされた後、標準化フォーマットで返されます。あるいは検索の場合には、マッチング・プロセスで識別された一連の考えられる候補とともに返されます。データ入力ソリューションでは、これによってデータ表現 (通りの種類や州の一貫した省略法など) が改善され、データが保管される前に重複が検出される確率が高くなります。重複を起因とする問題を事前に回避するほうが、後になってから問題を修復しようとしたり、顧客の特定が不可能だったために発生する誤ったアカウントの処理の結果にわずらわされるより、はるかにコストが少なくて済みます。
使用事例
図 2 に示す例の左上にあるポータルによって表される店頭販売 (POS) アプリケーションは、共通顧客のプロファイルを管理するカスタマー・ロイヤルティー・モジュールに使用されると考えられます。前述した大手宝石店チェーンの場合、このアプリケーションのサブセットは、SOA コンテキストでデータ・クレンジング・パターンを適用することによって拡張されます。例えば、店舗を訪れたある顧客が、自分のカスタマー・ロイヤルティ・コードを忘れてしまったか、あるいはまったく知らなかったとします。適当に入力した (おそらくエラーが発生する) 顧客名はリアルタイムで動的に中央マスター・データ・ストアに照合され、顧客名の候補リストが返されます。この候補のなかから実際の顧客プロファイルを見つけたり、あるいは新規の顧客であることが確認できるというわけです。これで、店員は無料鑑定などのお得意様向けのサービスを提供することも、誕生日や記念日などのプロファイルに基づいて新しい贈答品の購入を勧めることもできます。特別な対応を受けた顧客は、自分が特別な人物として扱われていると感じるでしょう。このような潜在的な利益と顧客のエクスペリエンスは、データ・クレンジングをサービスとして採用することで実現されます。つまり、バッチ実行中に適用される同じ機能を利用して、マッチングおよび標準化ルールが再利用されるのです。
図 2. データ・クレンジング・パターンの SOA コンテキスト
問題の説明
データ・クレンジング・パターンは、メタデータ・レベルおよびデータ・レベル自体でデータ品質を改善し、データの整合性を確実にするという難題に対処します。不十分で品質の劣るデータを生み出す典型的な原因は、以下のとおりです。
- データ入力 (タイポ) エラー
- メタデータの定義 (データ・モデル) があまりにも大まかで、常に指定されているわけではない
- 完全性の制約が (適切に) 定義されていないか、実施されていない
例えば、郵便番号は有効な番号でなければならないという定義あるいは制約が欠如しているか、常に実施されているわけではないとします。その場合、アプリケーションを実行しても、番号が有効かどうか、あるいはそれが番号であるかどうかさえチェックし損ねてしまいます。実在する 1 つのエンティティーを表す複数のフォーマットが矛盾していることも考えられます (郵便番号を表すのに番号を文字列と比較するなど)。今さっき述べたように、矛盾はメタデータ・レベルとデータ・レベル自体で表面化するはずです。また、データ・モデルが適切かつ一貫して定義されているとしても、データ値に対する適切な完全性の制約がないために品質や整合性の問題につながることもあります。例えば、ある製品に対応するさまざまな部品番号があったり、重量測定の結果が異なっているなど、実在する 1 つのエンティティーがさまざまなデータ値で表されるといった具合です。最も一般的な問題としては、以下のものが挙げられます。
- 値が区分されていないこと (フリー・フォームのフィールドでの完全な住所に、通りがどこで終わって市がどこから始まるのかが示されていないなど)。
- データ・フォーマットおよび値に関する標準がないこと。これには以下のものが含まれます。
- データ型 (integer であるか、varchar であるかなど)
- テキストの書式 (「123-45-6789」、「123456780」、または「123 45 6789」)
- 省略形 (「IBM」または「I.B.M.」、「Int. Bus. Machines」または「International Business Machines」)
- 抽象化レベルと細分度 (「Massachusetts」または「Suffolk County」)
- 必須の属性 (個人の役職) または属性の部分 (組織名に含まれる組織の形式。例えば「IBM」または「IBM Corporation」)
- ID に対する値の一貫性の欠如
- 属性への誤った値の配置 (電話番号の属性に含まれる郵便番号の値)
- 誤ったデータ入力または失効した情報による誤った値 (「Somers, CT 10589」の郵便番号「10589」はコネチカット州ではなくニューヨーク州のもの)
- 1 つまたは複数の属性に含まれる値に一貫性がないために重複したレコード
ソリューションの説明
データ・クレンジング・パターン設計時の特性は、データ・ソースの変換とクレンジングに関する標準ルールの確立、重複の除去をサポートするためのマッチング基準の定義、そして最新または最も適確なデータを判断する方法の特定を軸としています。想像できると思いますが、設計は、データ・クレンジング・プロセスにおいて最も重要で最も複雑な段階です。この作業が完了すると、クレンジング、マッチング、サバイバーシップのルールがランタイム・プロセスに適用されます。
設計時の特性
データ・クレンジング・パターンを適用する設計者は、適切なツールでサポートされると考えられるクレンジング・ルールを指定しなければなりません。この作業は、以下の 4 つの主要なステップに分類できます。
- 入力データの解析、および標準要素と細分化された要素への関連付け
- データの標準化
- データ入力項目のマッチングと重複の除去
- 正しい情報のサバイバーシップ
「問題の説明」に記載したように、データ値はフリー・テキストまたは集約された複数のフィールド (street 属性には、番地、通りの方向ならびに通りの名前が取り込まれる場合があります) で表現されることが考えられます。フィールドに実際に取り込まれるデータが何であるかを理解した上で最初に行うのは、データ値を区分し、最適な基本属性に割り当てるためのアルゴリズムを決定することです。そのためには、ドメイン固有の知識が必要となります (例えば米国では「1007 North Main Street」といったように、通りに方向が示されますが、これはドイツでは一般的ではありません)。
データ値を属性に正しく割り当てた後、設計者は値の標準化方法を指定します。つまり設計者は、以下のような質問に対する回答を見つけなければなりません。
- テキストは大文字であるべきか、それとも大小混合文字であるべきか。
- 番号を適切なデータ型に変換するべきかどうか (「nineteen」を「19」に変換するなど)。
- 郵便番号フィールドの番号が正しい郵便番号を表すべきかどうか。
- 郵便番号が州 (および市) と一致するかどうか。
- 完全な住所 (街路番号、通り、市、州、郵便番号) が存在するかどうか。
名前の標準表現 (「Bob」など) は何になるか (このステップは、正しい名前を提案することではなく、重複を特定することが目的なので、「Robert」ではなく「Bob」となるはずです。)。
一部の標準化ルールは単純なもので、大小混合文字のデータを大文字に変換するなどといった大変な作業は必要になりません。一方、高度なルールもあり、その場合は郵便番号、市、米国国内の州の正しい関連付けなど、正しい値を保管するデータベースへのアクセスが必要となります。さらに、標準化ルールをコンテキストに応じて変えなければならない場合もあります。例えば、「St. Virginia St.」のような文字列は、通りの名前が「St. Virginia」で、通りのタイプが「street」であると判断されます (米国の住所であるという前提)。形の上では「St.」と「St.」は同じですが、理にかなったルール・セットで解釈すると、それぞれ意味が異なります。
多くの場合、設計者は重複の可能性があるレコードを特定しなければなりませんが、残念ながら標準化を行った後でもレコードのデータ値が同じでないことは珍しくありません。あるレコードでは個人の名前が「J. Smith」となっている一方、別のレコードでは「John Smith」となっているような場合です。一致を特定するときに難しいのは、「J. Smith」が「John Smith」と同じである可能性がどれほど高いのかを判断することです。これは明らかに、そのレコードに含まれている別の情報に依存します。住所がまったく同じであれば、一致する可能性が非常に高くなります。一方、どれだけの数の人が同じ名と姓を持っているかにも依存します。つまり、同じ市に二人の「April Back-Cunninghams」がいる可能性は、二人の「Robert Johnsons」がいる可能性に比べると低いというような具合です。フリー・フォームの名前と住所の構文解析および字句解析に適用するパターンは、在庫管理の強化を目的とした製品リストや部品の標準化および重複の除去にも適用できます。注意してもらいたいのは、ここでは米国の住所を主に取り上げましたが、この手法はどの国にも、そして住所以外のものにも当然、当てはまるということです。
マッチングに対処するには、決定的マッチングと確率的マッチングという 2 つの方法があります。決定的マッチングは、一致を定義するビジネス・ルールとアルゴリズムに基づきます。このマッチングのメリットは、2 つのレコードが一致する、あるいは一致しないといった明確な答をもたらすという点です。ただし、ルール・セットは一般的に、単純あるいは中程度の複雑度で分類されるルールとアルゴリズムに限られます。一方、確率的マッチングは、統計アルゴリズムとファジー・ロジックを利用して一致を示します。このマッチングでは一層強力なメカニズムを利用して一致を特定し、レコードが一致する可能性を確率 (93% など) で示します。一致の信用度は、対象とする情報の価値、そして一致を決定するコストとのバランスで考えなければなりません。
設計者はマッチング・ルールに基づいて、サバイバーシップ・ルールを指定します。サバイバーシップ・ルールとは、どのレコードとレコードの属性が正しい情報を反映しているかを判断し、存続させるレコードと破棄しなければならないレコードを決定するルールのことです。
以上でクレンジング・ルールの中核となる部分は完成したので、最終ステップとして入力データを収集する方法 (データベースの抽出/クエリー、サービス要求を使用)、そしてクレンジング・プロセスを出力する方法 (データベースに適用するか、サービス応答として提供するか) を指定します。
図 3 に、この作業の概要を示します。
図 3. データ・クレンジング・パターン設計時の側面
データ・クレンジング・パターンは、他のパターンと一緒に適用される場合が多いという点に注意することは重要です。図 3 の緑色のボックスがその一例です。開発者や設計者がクレンジング・ルールを指定するには、データ・クレンジング・パターンを適用するデータ･ソースを十分に理解していなければなりません。それには、構造情報だけでなく、データ・モデルの要素の意味など、情報セマンティクスを識別し、理解することも含まれます。基礎となるデータ・ソースからこのような知識を引き出すのに役立つのが、データ・プロファイルです。多くの場合、データ・クレンジング・パターンはデータ統合パターンとともに適用されますが、そのようなシナリオでは、データ要素間のソースからターゲットへのマッピングを指定する必要があります (図 3 では、これを統合モデリングと呼んでいます)。
実行時
データ・クレンジング・サービスは、データ品質のレベルが不確定なデータを入力として受け取ります。一般的にこのサービスは、この入力をサービス要求のパラメーター (値) として使って呼び出されるか、そうでなければサービスが 1 つ以上の指定ソース (参照) からデータを収集します (参照により)。するとサービスはクレンジング・ルールをソース・データに適用します。データ・クレンジング・ルールの複雑度によっては、このプロセスで、データベース内やディクショナリーを検索して情報の正確さ (郵便番号、市、州の組み合わせが正しいかどうかなど) を検証しなければなりません。処理が正常に完了すると、クレンジングされた情報がサービスの応答として戻されます。従来のコンテキストでは、出力はデータベースに適用されるか、データ統合プロセスでさらに処理されるのが一般的です (「参考文献」に記載したデータ統合に関する記事を参照)。
データ・クレンジング・サービスには、(並列処理を活用して高度なパフォーマンスとスケーラビリティーを提供する) データ・クレンジング・サーバーによる高度な実装が必要になることがよくあります。このようなサーバーは、リアルタイムで呼び出しを行う環境でそれぞれのレコードを処理およびクレンジングできるだけでなく、極めて大量のデータにもバッチ･モードで対応できます。大量のデータを処理するための要件を説明するのが、複数のレガシー・システムの完全なコンテンツを統合およびクレンジングしなければならないようなシナリオです。その一方、ポータル・アプリケーションが画面に入力された住所をチェックするために Web サービスを使ってデータ・クレンジング・サーバーを呼び出す場合もあります。この場合、サーバーは多数の同時要求にリアルタイムで応答しなければならない可能性があります。
検討事項
データ・クレンジング・パターンを適用するときには、以下の機能以外の要件にどのように影響するかを理解することが重要です。
トランザクションの実行頻度
クレンジング・サービスがデータ・クレンジング・トランザクションを高速で実行できるかどうかは、データ・クレンジング・サーバーが入力データにアクセスしてクレンジング・ルールを適用する速度によって決まります。クレンジング・ルールが複雑であればあるほど、必要な検索回数が増え、クレンジング・アクティビティーの実行時間も長くなります。
並列処理機能を活用できるデータ・クレンジング・サーバーには、他の手法に勝る大きなメリットがあります。そのようなデータ・クレンジング・サーバーの一例が、既製のサーバー、IBM® WebSphere® QualityStage (「参考文献」を参照) です。
パフォーマンス/トランザクションの応答時間
トランザクションの応答時間 (クレンジング・ルールを入力データに適用し、出力を返す時間) は、クレンジング・ルールの複雑さ、そしてクレンジング・サーバーによるデータ処理の効率性に依存します。ルールをコンパイルして並列処理機能を活用できるクレンジング・サーバーを実装すれば、他の実装よりパフォーマンスが向上します。
トランザクションごとのデータ量
データ・クレンジング・パターンが個別のレコードだけでなく、大量のデータ・セットに適用されるのは、かなり一般的なことです。そのため、データ・クレンジング・サーバーは大量のデータ処理にも対応できるようにスケーラブルである必要があります。
変換機能
データ・クレンジング・アクティビティー (値の解析または区分、標準化、マッチングおよびサバイバーシップ) は、クレンジング・ルールとして指定されます。クレンジング・ルールは最終的に、品質が低い可能性のある入力データを、整合性と品質の優れた出力に変換するために適用されます。このような変換ルールは数も膨大で複雑度も高くなる可能性があるので、多くのデータ・クレンジング・パターンの実装では、クレンジング・ルールをデータ・クレンジング・サーバーによる変換操作としてデプロイしています。
データ・クレンジング・パターンの変換機能は特殊化されています。特殊化の焦点はデータの標準化とマッチングによるデータの品質および完全性の改善です。これよりも一般的なデータ変換手法 (「Part 2: Data consolidation pattern」で説明した手法など) では、交換とデータの再フォーマット設定、分割、マージを焦点とするため、データ品質に対する高度なサポートはありません。
変換要件はデータ・ソースの多様性によって影響されることが最も多いため、複雑な変換の特性を定義できるかどうかが鍵となります。変換要件が複雑で変化に富んでいればいるほど、実行時の変換やデータ･クレンジング・サーバーは高度でなければなりません。
ソース・モデル、インターフェース、プロトコルのタイプ
データ・クレンジング・パターンの製品実装は、サポート可能な入力データのフォーマットによってさまざまに異なります。データ・クレンジング・パターンを完全かつ正確に適用することで、各種のソース・フォーマット、インターフェース、そしてプロトコルによる複雑さがなくなるため、開発者は 1 つのモデル、インターフェース、プロトコルに関心を向けるだけで済みます。
ソリューションの納期
データ・クレンジング・パターンの製品実装が、クレンジング・ルールを指定し、そして指定されたルールの入力データでの有効性を視覚化する非常に高度なツール・サポートを提供していることは珍しくありません。例えば、どのレコードを確率的マッチング・ルールに基づいて一致と判断するかについては、多くの実装に事前に定義された (クレンジング・ルール) 操作があり、すぐに使用できるものとして製品に付属しています。このフィーチャーにより、実装者は確率的マッチング・ルールを短期間で極めて効率的に適用できます。
データ・クレンジング・パターンは多くの場合、品質も整合性も極めて乏しいデータに適用されます。その結果、クレンジング・ルールを繰り返し改良する必要が出てくることもあります。改良に伴う作業は、パターンの手法ではなく目前の問題の特性に直接関係します。
スキル・セットと経験
データ・クレンジングには、2 つの主要なスキル・セットと経験が必要です。第一に重要なのは、フォーマット、値、範囲、そしてその他の特性に関して、データ・ソースとターゲットに関連付けられたニュアンスを理解し、定義するために必要な分析スキルです。また、ツールを使用してクレンジング・ルールを定義する場合は、分析者に製品固有の知識が必要となります。第二に、開発者はクレンジング・サービスの実装に必要な SOA の概念、標準、技術を理解していなければなりません。さらに、ランタイム・サーバーにツールによる方法が使われる場合、開発者とシステム・アーキテクトには、サーバーがスケーラブルであり、必要なサービス・レベル・アグリーメントを満たしていることを確信できるだけの知識と経験も必要です。
開発費
開発費は、データ・クレンジング・タスクの複雑さに大きく依存します。基本的な標準化ルールを適用すればいいだけの場合、開発費は非常に少なくて済みますが、クレンジング・ルールが複雑になればなるほど、実装の開発費は高くなります。開発費の増加は、データ分析、ならびに複雑性に対処するために繰り返し行う必要がある開発およびテスト・サイクルに関連します。
再利用性
データ・クレンジング・パターンにおける再利用性は、サービス全体を通してレコード・レベルで適用できるクレンジング・ルールを定義することによって実現され、データが大量にある場合は、バッチ・プロセスで適用可能なクレンジング・ルールを定義することによって実現されます。再利用の第 2 の機会は、クレンジング・ルールの実行に共通のサーバー・プロセスを使用することで生まれます。
まとめ
データ・クレンジング・パターンは、入力時または入力した後に永続データの品質を向上させる方法についての推奨基準を指定します。
データ・クレンジング・パターンを重点的に適用する対象
- 顧客の名前と住所など、必要不可欠な情報のニーズに合わせてデータの品質と整合性を改善してください。前述したように、データ・クレンジング・パターンによって、整合性のない (それ故に役に立たない) データが貴重な戦略的資産に生まれ変わります。
データ・クレンジング・パターンを適用するにはリスクがある対象
- 共通したコア・ビジネス・データの理解と定義の欠如。
- データ品質に対する安定したビジネス・ガイドラインと管理の欠如。データ・クレンジング・ルールの仕様は、ビジネス・エキスパートに承認され、概して安定したガイドラインに基づいていなければなりません。品質ガイドラインが頻繁に変わったり、承認されていなかったりすると、クレンジング・ルールの管理、そして新規ルールの恒常的な採用が多大なワークロードにつながる恐れがあります。
- 部門間のサポートの欠如。特に、複数の部門にまたがるアプリケーションが情報にアクセスして変更を行う場合。1 つの組織がその所有データの品質を改善できるとしても、組織の管理が及ばないところでアプリケーションがデータを変更してしまえば、品質の劣化につながる恐れがあります。
製品マッピング
以下は、データ・クレンジング・パターンを実装する IBM 製品です。
- WebSphere QualityStage は、データ・クレンジング技術を提供する製品群のコア・コンポーネントの 1 つです。WebSphere QualityStage はフリー・フォームのテキスト・データの標準化、品質向上、そしてマッチングをサポートします。Master Data Management ソリューションに不可欠の WebSphere QualityStage は、高度な構文解析ルールと統計的マッチング機能を適用することにより、データ・ソース間あるいはデータ・ソース内でのレコードのリンク、そして重複の排除を可能にします。また、このツールは複数システムに及ぶデータの単一の包括的ビューに対して、空白な、あるいは欠如した、あるいは不完全なエンティティー値を自動的に相互入力するため、ソース間で存続させるたった 1 つの「最適な」レコードを選択することができます。
- WebSphere Information Services Director (同じく IBM Information Server のコンポーネント) は、情報管理機能をサービスとして公開します。情報統合ロジック、クレンジング・ルール、情報アクセスはサービスとしてパッケージ化されるため、開発者はこの機能の基礎となるプロバイダーから隔離されます。とりわけ重要な点は、EJB (Enterprise JavaBean) コンポーネント、JMS (Java™ Message Service)、あるいは Web サービスなどのサービス指向インターフェースによって、データ・クレンジングを公開できることです。この製品は、情報サービスの基礎インフラストラクチャー (ロード・バランシングとフォールト・トレランスを含む) を提供します。図 2 の Information Service Enablement コンポーネントを実現しているのは、この製品です。WebSphere Information Services Director は、WebSphere QualityStage と同じ強力なメタデータ・インフラストラクチャーをベースにビルドされています。
謝辞
この記事の作成とデータ・クレンジング・パターンの開発をサポートしてくれた Jonathan Adams 氏と Lou Thomason 氏に感謝します。