検証と検証：違いは何ですか？

素人の言葉では, データ検証とデータ検証は、同じことのように聞こえるかもしれません。 しかし、データ品質の複雑さを掘り下げると、パズルのこれら二つの重要な部分ははっきりと異なっています。 この区別を知ることで、データ品質の全体像をよりよく理解するのに役立ちます。

データ検証とは何ですか？

一言で言えば、データ検証は、特定の情報が特定のフィールドの許容可能な値の範囲内にあるかどうかを判断するプロセスです。

たとえば、米国では、すべての住所に州の個別のフィールドを含める必要があります。 NH、ND、AK、TXなどの特定の値は、米国郵政公社によって定義されている州の略語のリストに準拠しています。 ご存知のように、これらの略語は特定の状態を示します。

グアム（”GU”）や北マリアナ諸島（”MP”）など、米国の領土のための二文字の略語もあります。 Stateフィールドに「ZP」または「A7」と入力すると、そのようなstateまたはterritoryが存在しないため、本質的にアドレス全体を無効にすることになります。 データ検証では、データベース内の既存の値に対してチェックを実行して、有効なパラメータ内にあることを確認します。

米国外の国を含む住所のリストについては、state/province/territoryフィールドは、可能な値のかなり長いリストに対して検証する必要がありますが、基本的な前提は同じ （FYI、正確にはアドレス検証ソリューションを提供しています）

たとえば、前の例よりも精度が少し低いにもかかわらず、特定のフィールドの可能な数値 人の身長を記録している場合は、予想される範囲外の値を禁止することができます。 人があなたのデータベースに12フィート（約3メートル）の高さであるとリストされている場合、おそらくデータが間違っていると仮定することができます。 同様に、そのフィールドに負の数を許可したくないでしょう。

幸いなことに、これらの種類の検証チェックは、通常、アプリケーションレベルまたはデータベースレベルで実行されます。 たとえば、eコマースwebサイトに米国ベースの配送先住所を入力する場合、米国では無効な州コードを入力できる可能性は低いでしょう。

データ検証とは何ですか、そしてそれはどのように違いますか？

一方、データ検証は実際にはデータ検証とはかなり異なります。 検証は、現在のデータが正確で一貫性があり、意図された目的を反映していることを確認するために、現在のデータのチェックを実行します。

検証はいつでも行われる可能性があります。 言い換えると、検証は定期的なデータ品質プロセスの一部として行われますが、検証は通常、レコードが最初に作成または更新されたときに行われます。

検証は、外部のデータソースからデータを移行またはマージするときに特に重要な役割を果たします。 小さな競争相手を買収したばかりの会社の場合を考えてみましょう。 彼らは、取得した競合他社の顧客データを独自の課金システムにマージすることを決定しました。 移行プロセスの一環として、レコードがソースシステムから適切に送信されたことを確認することが重要です。

移行のためにデータを準備する際に小さなエラーが発生すると、大きな問題が発生することがあります。 得意先マスタレコードのキー項目が正しく割り当てられていない場合(たとえば、データの準備中にスプレッドシート内のセルの範囲が誤って上下に移動した場合)、配送先住所または未処理の請求書が誤った得意先に割り当てられる可能性があります。

したがって、移行先システムの情報が移行元システムの情報と一致することを確認することが重要です。 これは、ソースシステムと宛先システムの両方からデータをサンプリングして手動で精度を検証するか、インポートされたデータの完全な検証を実行し、すべてのレコードを照合し、例外にフラグを設定する自動化されたプロセスを含むことができます。

進行中のプロセスとしての検証

検証はデータ移行に限定されません。 また、時間の経過とともに企業データの正確性と一貫性を確保する上で重要な役割を果たします。

あなたの製品を購入した消費者の既存のデータベースがあり、その製品に新しいアクセサリーのプロモーションを郵送したいとします。 その顧客情報の一部が古くなっている可能性がありますので、あなたの郵送の前にデータを確認する価値があります。

郵便サービスからの住所データベースの変更に対して顧客の住所を確認することにより、古い住所を持つ顧客レコードを識別することができます。 多くの場合、そのプロセスの一部として顧客情報を更新することもできます。

重複するレコードの識別は、もう一つの重要なデータ検証活動です。 あなたの顧客データベースが同じ顧客を三、四回リストしている場合は、それらに重複した郵送物を送信する可能性があります。 これはあなたに多くのお金がかかるだけでなく、それはまた、負の顧客体験になります。

重複排除プロセスをより困難にするために、同じ顧客の複数のレコードが、人の名前にわずかに異なるバリエーションを使用して作成されている可能性 ファジィ論理を使用して可能性のある一致と可能性のある一致を識別するツールは、プロセスをより良く機能させることができます。

データ品質のマンデート

ますます多くのビジネスリーダーが、人工知能/機械学習と最新のビジネスインテリジェンスツールを使用してitから抽出できる洞察の中で、データの戦略的価値を理解するようになっています。

しかし残念ながら、昔の”ゴミ出し、ゴミ出し”という言葉は今まで以上に適用されています。 データ量が増加するにつれて、データ主導型の企業は、データ品質を定期的に監視および管理するための積極的な対策を講じることが不可欠です。 それ以外の場合は、欠陥のある情報に基づいた洞察に作用するリスクがあります。

詳細については、当社の電子ブックをお読みください：”十分に良い”品質がどのようにあなたのデータインサイトの信頼を侵食しています