さまざまな種類
データ検証の基本を評価する際には、検証の範囲、複雑さ、目的に応じて、さまざまな種類の検証について一般化することができる。
例えば：
- データ型の検証
- 範囲と制約の検証。
- コードと相互参照の検証。
- 構造化検証、および
- 一貫性検証
データ型チェック
データ型の検証は、通常、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)。
- チェックデジット
- 数値データに使用されます。エラー検出をサポートするため、他の桁から計算された数値に、追加の桁が加えられます。
- 一貫性チェック
- フィールドをチェックして、これらのフィールドのデータが一致していることを確認します。たとえば、有効期限が過去の日付の場合、ステータスは「アクティブ」ではありません。
- システム間の整合性チェック
- 異なるシステム間のデータを比較し、データの一貫性を確保します。システムによって同じデータが異なる表現で表示される場合があり、その場合は比較のために変換が必要になります（例えば、あるシステムでは顧客名を「Doe, John Q」のように単一の名前フィールドに格納する一方、別のシステムでは「First_Name 'John'」、「Last_Name 'Doe'」、「Middle_Name 'Quality'」のように複数の名前フィールドに格納する場合があります）。
- データ型チェック
- 入力されたデータが入力データと一致しているかを確認します。例えば、数値データのみを受け付ける入力ボックスでは、文字「O」は拒否される場合があります。
- ファイル存在チェック
- 指定された名前のファイルが存在するかどうかを確認します。このチェックは、ファイル処理を使用するプログラムにとって不可欠です。
- フォーマットチェック
- データが指定された形式（テンプレート）になっているかを確認します。例えば、日付はYYYY-MM-DD形式である必要があります。このような検証には正規表現を使用できます。
- 存在確認
- データが存在するかどうかを確認します。例えば、顧客にはメールアドレスの登録が求められる場合があります。
- レンジチェック
- データが指定された値の範囲内にあるかどうかを確認します。たとえば、確率は0から1の間である必要があります。
- 参照整合性
- 2つのリレーショナルデータベーステーブルの値は、外部キーと主キーによってリンクできます。外部キーフィールドの値が内部メカニズムによって制約されていない場合は、参照元のテーブルが常に参照先のテーブルの行を参照するように、値を検証する必要があります。
- スペルと文法のチェック
- スペルミスや文法ミスを探します。
- 一意性チェック
- 各値が一意であることを確認します。これは、複数のフィールド（例：住所、名、姓）に適用できます。
- テーブル参照チェック
- テーブル参照チェックは、データを許容値の集合と比較します。
検証後のアクション
- 執行措置
- 強制措置は通常、データ入力要求を拒否し、入力者にデータを準拠させるための変更を要求します。これは、実際に人がコンピュータの前に座って入力を行う対話型の使用に最適です。また、バッチアップロードにも適しており、ファイル入力が拒否された場合、データが拒否された理由を説明する一連のメッセージが入力元に返送されます。
- もう一つの強制措置の形態は、データを自動的に変更し、元のバージョンではなく準拠したバージョンを保存することです。これは、見た目の変更に最適です。たとえば、すべて大文字のエントリをパスカルケースのエントリに変換する場合、ユーザーの入力は必要ありません。自動強制措置の不適切な使用例としては、強制措置によって業務情報が失われる場合が挙げられます。たとえば、コメントの長さが想定よりも長い場合に、切り詰められたコメントを保存する場合などです。これは、重要なデータが失われる可能性があるため、通常は好ましいことではありません。
- 勧告措置
- アドバイザリアクションは通常、データの変更を許容しつつ、検出された検証上の問題点をソースアクターに通知するメッセージを送信します。これは、非対話型システム、変更が業務上重要でないシステム、既存データのクレンジング手順、および入力プロセスの検証手順に最適です。
- 検証アクション
- 検証アクションは、アドバイザリアクションの特殊なケースです。この場合、入力元のユーザーは、反対の提案を踏まえて、入力しようとしているデータが本当に自分が入力したいデータであるかどうかを確認するよう求められます。ここでは、チェックステップで代替案が提示されます（例えば、郵送先住所のチェックで、住所の書式が異なる形式になったり、全く別の住所が提案されたりします）。このような場合、ユーザーには、提案を受け入れるか、自分のバージョンを維持するかを選択できるようにする必要があります。これは、設計上、厳密な検証プロセスではなく、新しい場所への住所や、検証データベースでまだサポートされていない場所への住所を取得する際に役立ちます。
- 検証ログ
- データ検証で問題が見つからなかった場合でも、実施した検証とその結果のログを提供することは重要です。これは、データの問題を踏まえて、不足しているデータ検証チェックを特定し、改善するのに役立ちます。
外部リンク
- データ検証、OWASP
- 入力検証、OWASPチートシートシリーズ、github.com
