データ検証

ウィキペディアから、無料の百科事典
ナビゲーションにジャンプ 検索にジャンプ

コンピュータサイエンスデータの検証が保証するプロセスであるデータが施されたデータクレンジング、彼らが持っていることを確認するために、データの品質、彼らは両方とも正しいと有用であること、です。これは、「検証ルール」、「検証制約」、または「チェックルーチン」と呼ばれることが多いルーチンを使用して、システムに入力されるデータの正確性、意味、およびセキュリティをチェックします。ルールは、データディクショナリの自動化された機能を介して、またはコンピューターとそのアプリケーションの明示的なアプリケーションプログラム検証ロジックを含めることによって実装できます。

これは、仕様またはプロパティを実装するためのアルゴリズムの正当性を証明または反証しようとするフォーマル検証とは異なります。

概要

データ検証は、アプリケーションまたは自動システム内のデータの適合性と一貫性について、明確に定義された特定の保証を提供することを目的としています。データ検証ルールは、さまざまな方法論を使用して定義および設計でき、さまざまなコンテキストで展開できます。[1]それらの実装では、宣言型の データ整合性ルールまたは手順ベースの ビジネスルールを使用できます[2]

データ検証の保証には必ずしも正確性が含まれているわけではなく、スペルミスなどのデータ入力エラーが有効であると認められる可能性があることに注意してください。システム内の不正確さを減らすために、他の事務および/またはコンピュータ制御が適用される場合があります。

さまざまな種類

データ検証の基本を評価する際に、範囲、複雑さ、および目的に応じて、さまざまな種類の検証に関して一般化を行うことができます。

例えば:

  • データ型の検証;
  • 範囲と制約の検証。
  • コードと相互参照の検証。
  • 構造化された検証;
  • 一貫性の検証

データ型チェック

データ型の検証は、通常、1つ以上の単純なデータフィールドで実行されます。

最も単純な種類のデータ型検証では、ユーザー入力を通じて提供される個々の文字が、プログラミング言語またはデータの保存および取得メカニズムで定義されている1つ以上の既知のプリミティブデータ型の予想される文字と一致していることを確認します。

たとえば、整数フィールドでは、0から9までの文字のみを使用するための入力が必要になる場合があります。

単純な範囲と制約のチェック

単純な範囲と制約の検証では、入力の最小/最大範囲との整合性、または正規表現に対する1つ以上のテストなどの文字シーケンスを評価するためのテストとの整合性を調べることができます。たとえば、カウンター値は負でない整数である必要があり、パスワードは最小の長さを満たし、複数のカテゴリーの文字を含む必要がある場合があります。

コードと相互参照チェック

コードと相互参照の検証には、データが1つ以上の可能性のある外部ルール、要件、または特定の組織、コンテキスト、または基礎となる仮定のセットに関連するコレクションと一致していることを確認する操作が含まれます。これらの追加の有効性制約には、提供されたデータを既知のルックアップテーブルまたはLDAPなどのディレクトリ情報サービスと相互参照することが含まれる場合があります

たとえば、現在の地政学的地域を識別するために、ユーザー提供の国コードが必要になる場合があります。

構造化チェック

構造化された検証では、より複雑な処理とともに、他の種類の検証を組み合わせることができます。このような複雑な処理には、システム内の複雑なデータオブジェクト全体または一連のプロセス操作に対する条件付き制約のテストが含まれる場合があります。

整合性チェック

整合性検証により、データが論理的であることが保証されます。たとえば、注文の配達日が出荷日より前になることを禁止できます。

複数の種類のデータ検証は2007年以前の10桁のISBNに関連しています(ISO 2108の2005年版では、2007年以降のISBNは13桁である必要がありました[3])。

  • サイズ。2007年以前のISBNは、10桁で構成され、オプションのハイフンまたはスペースで4つの部分を区切る必要があります。
  • フォーマットチェック。最初の9桁はそれぞれ0から9でなければならず、10番目は0から9またはXのいずれかでなければなりません
  • チェックディジット数字が変更または転置された転記エラーを検出するには、2007年より前のISBNの最後の数字が、他の9桁(ISBN-10チェックディジット)を組み込んだ数式の結果と一致する必要があります。

検証タイプ

許可された文字チェック
予期された文字のみがフィールドに存在することを確認するためにチェックします。たとえば、数値フィールドでは、0〜9の数字、小数点、およびマイナス記号またはコンマのみを使用できます。個人名などのテキストフィールドでは、マークアップに使用される文字が許可されない場合があります。電子メールアドレスには、少なくとも1つの@記号とその他のさまざまな構造の詳細が必要な場合があります。正規表現は、このようなチェックを実装するための効果的な方法です。
バッチ合計
欠落しているレコードをチェックします。数値フィールドは、バッチ内のすべてのレコードに対して一緒に追加できます。バッチ合計が入力され、コンピューターは合計が正しいことを確認します。たとえば、複数のトランザクションの「合計コスト」フィールドを合計します。
カーディナリティチェック
レコードに有効な数の関連レコードがあることを確認します。たとえば、連絡先レコードが「顧客」として分類されている場合、少なくとも1つの注文が関連付けられている必要があります(カーディナリティ> 0)。このタイプのルールは、追加の条件によって複雑になる可能性があります。たとえば、給与データベースの連絡先レコードが「元従業員」として分類されている場合、分離日(カーディナリティ= 0)以降は給与の支払いが関連付けられていない必要があります。
チェックディジット
数値データに使用されます。エラー検出をサポートするために、他の桁から計算される数値に1桁が追加されます。
整合性チェック
フィールドをチェックして、これらのフィールドのデータが対応していることを確認します。たとえば、有効期限が過去の場合、ステータスは「アクティブ」ではありません。
システム間の整合性チェック
異なるシステムのデータを比較して、一貫性があることを確認します。システムは同じデータを異なる方法で表す場合があります。その場合、比較には変換が必要です(たとえば、あるシステムでは顧客名を「Doe、John Q」として単一の名前フィールドに格納し、別のシステムではFirst_Name「John」とLast_Name「Doe」とMiddle_Nameを使用します。 '品質')。
データ型チェック
入力されたデータとの入力の適合性をチェックします。たとえば、数値データを受け入れる入力ボックスは、文字「O」を拒否する場合があります。
ファイル存在チェック
指定された名前のファイルが存在することを確認します。このチェックは、ファイル処理を使用するプログラムにとって不可欠です。
フォーマットチェック
データが指定された形式(テンプレート)であることを確認します。たとえば、日付はYYYY-MM-DDの形式である必要があります。この種の検証には正規表現を使用できます。
プレゼンスチェック
データが存在することを確認します。たとえば、顧客は電子メールアドレスを持っている必要がある場合があります。
範囲チェック
データが指定された値の範囲内にあることを確認します。たとえば、確率は0から1の間でなければなりません。
参照整合性
2つのリレーショナルデータベーステーブルの値は、外部キーと主キーを介してリンクできます。外部キーフィールドの値が内部メカニズムによって制約されていない場合は、それらを検証して、参照テーブルが常に参照テーブルの行を参照していることを確認する必要があります。
スペルチェックと文法チェック
スペルと文法の誤りを探します。
一意性チェック
各値が一意であることを確認します。これは、いくつかのフィールド(つまり、住所、名、姓)に適用できます。
テーブルルックアップチェック
テーブルルックアップチェックは、データを許可された値のコレクションと比較します。

検証後のアクション

施行措置
強制アクションは通常、データ入力要求を拒否し、入力アクターがデータをコンプライアンスに準拠させるための変更を行うことを要求します。これは、実際の人がコンピューターに座って入力するインタラクティブな使用に最適です。また、ファイル入力が拒否され、データが拒否された理由について一連のメッセージが入力ソースに返送されるバッチアップロードにも適しています。
別の形式の強制アクションでは、データを自動的に変更し、元のバージョンではなく準拠バージョンを保存します。これは化粧品の変更に最適です。たとえば、[all-caps]エントリを[Pascal case]エントリに変換する場合、ユーザー入力は必要ありません。自動施行の不適切な使用は、施行がビジネス情報の損失につながる状況になります。たとえば、長さが予想よりも長い場合、切り捨てられたコメントを保存します。これは、重要なデータが失われる可能性があるため、通常は適切ではありません。
アドバイザリーアクション
アドバイザリアクションでは通常、データを変更せずに入力できますが、発生した検証の問題を示すメッセージをソースアクターに送信します。これは、非対話型システム、変更がビジネス上重要ではないシステム、既存のデータのクレンジングステップ、および入力プロセスの検証ステップに最適です。
検証アクション
検証アクションは、アドバイザリアクションの特殊なケースです。この場合、ソースアクターは、反対の提案に照らして、このデータが実際に入力したいものであることを確認するように求められます。ここで、チェックステップは代替案を提案します(たとえば、郵送先住所のチェックは、そのアドレスをフォーマットする別の方法を返すか、まったく別のアドレスを提案します)。この場合、推奨事項を受け入れるか、バージョンを保持するかをユーザーに選択できるようにする必要があります。これは、設計上、厳密な検証プロセスではなく、新しい場所または検証データベースでまだサポートされていない場所へのアドレスをキャプチャするのに役立ちます。
検証のログ
データ検証で問題が見つからなかった場合でも、実施された検証とその結果のログを提供することが重要です。これは、データの問題に照らして欠落しているデータ検証チェックを特定し、検証を改善するのに役立ちます。

検証とセキュリティ

データ検証の失敗または脱落は、データの破損またはセキュリティの脆弱性につながる可能性があります[4]データ検証は、データが処理される前に、データが目的に適合していること、[5]有効で、賢明で、合理的で、安全であることを確認します。

も参照してください

参考文献

外部リンク