View source for Data validation

{{Short description|Process of ensuring computer data is both correct and useful}}
{{redirect|Input validation||Improper input validation}}
In [[Computing|computing]], '''data validation''' or '''input validation''' is the process of ensuring [[Data|data]] has undergone [[Data cleansing|data cleansing]] to confirm it has [[Data quality|data quality]], that is, that it is both correct and useful. It uses routines, often called "validation rules", "validation constraints", or "check routines", that check for correctness, meaningfulness, and security of data that are input to the system. The rules may be implemented through the automated facilities of a ]], or by the inclusion of explicit application program validation logic of the computer and its application.

This is distinct from [[Formal verification|formal verification]], which attempts to prove or disprove the correctness of algorithms for implementing a specification or property.

==Overview ==
Data validation is intended to provide certain well-defined guarantees for fitness and [[Data consistency|consistency of data]] in an application or automated system. Data validation rules can be defined and designed using various methodologies, and be deployed in various contexts.<ref>[https://ec.europa.eu/eurostat/cros/system/files/methodology_for_data_validation_v1.0_rev-2016-06_final.pdf Methodology for data validation 1.0]</ref> Their implementation can use [[Declarative programming|declarative]] [[Data integrity|data integrity]] rules, or [[Imperative programming|procedure-based]] business rules.<ref>[http://msdn.microsoft.com/en-us/library/aa291820(VS.71).aspx Data Validation, Data Integrity, Designing Distributed Applications with Visual Studio .NET]</ref>

The guarantees of data validation do not necessarily include accuracy, and it is possible for [[Data entry|data entry]] errors such as misspellings to be accepted as valid. Other clerical and/or computer controls may be applied to reduce inaccuracy within a system.

==Different kinds==
In evaluating the basics of data validation, generalizations can be made regarding the different kinds of validation according to their scope, complexity, and purpose.

For example:
* Data type validation;
* Range and constraint validation;
* Code and cross-reference validation;
* [[Biology:Structure validation|Structured validation]]; and
* Consistency validation

===Data-type check===
Data type validation is customarily carried out on one or more simple data fields.

The simplest kind of data type validation verifies that the individual characters provided through user input are consistent with the expected characters of one or more known [[Primitive data type|primitive data types]] as defined in a programming language or data storage and retrieval mechanism.

For example, an integer field may require input to use only characters 0 through 9.

===Simple range and constraint check===
Simple range and constraint validation may examine input for consistency with a minimum/maximum range, or consistency with a test for evaluating a sequence of characters, such as one or more tests against regular expressions. For example, a counter value may be required to be a non-negative integer, and a password may be required to meet a minimum length and contain characters from multiple categories.

===Code and cross-reference check===
Code and cross-reference validation includes operations to verify that data is consistent with one or more possibly-external rules, requirements, or collections relevant to a particular organization, context or set of underlying assumptions. These additional validity constraints may involve cross-referencing supplied data with a known look-up table or directory information service such as LDAP.

For example, a user-provided country code might be required to identify a current geopolitical region.

===Structured check===
Structured validation allows for the combination of other kinds of validation, along with more complex processing. Such complex processing may include the testing of conditional constraints for an entire complex data object or set of process operations within a system.

===Consistency check===
Consistency validation ensures that data is logical. For example, the delivery date of an order can be prohibited from preceding its shipment date.

===Example===
Multiple kinds of data validation are relevant to 10-digit pre-2007 [[ISBN]]s (the 2005 edition of ISO 2108 required ISBNs to have 13 digits from 2007 onwards<ref>[http://www.lac-bac.gc.ca/iso/tc46sc9/isbn.htm ''Frequently Asked Questions about the new ISBN standard''] {{Webarchive|url=https://web.archive.org/web/20070610160919/http://www.lac-bac.gc.ca/iso/tc46sc9/isbn.htm |date=2007-06-10 }} [[Organization:International Organization for Standardization|ISO]].</ref>).

* Size. A pre-2007 ISBN must consist of 10 digits, with optional hyphens or spaces separating its four parts.
* Format checks. Each of the first 9 digits must be 0 through 9, and the 10th must be either 0 through 9 or an ''X''.
* [[Check digit]]. To detect transcription errors in which digits have been altered or transposed, the last digit of a pre-2007 ISBN must match the result of a mathematical formula incorporating the other 9 digits ([[International Standard Book Number#ISBN-10 check digits|ISBN-10 check digits]]).

==Validation types==
;Allowed character checks
:Checks to ascertain that only expected characters are present in a field. For example a numeric field may only allow the digits 0–9, the decimal point and perhaps a minus sign or commas. A text field such as a personal name might disallow characters used for [[Markup language|markup]]. An e-mail address might require at least one @ sign and various other structural details. [[Regular expression]]s can be effective ways to implement such checks.

;Batch totals
:Checks for missing records. Numerical fields may be added together for all records in a batch. The batch total is entered and the computer checks that the total is correct, e.g., add the 'Total Cost' field of a number of transactions together.

;Cardinality check
:Checks that record has a valid number of related records. For example, if a contact record is classified as "customer" then it must have at least one associated order (cardinality > 0). This type of rule can be complicated by additional conditions. For example, if a contact record in a payroll database is classified as "former employee" then it must not have any associated salary payments after the separation date (cardinality = 0).

;Check digits
:Used for numerical data. To support error detection, an extra digit is added to a number which is calculated from the other digits.

;Consistency checks
:Checks fields to ensure data in these fields correspond, e.g., if expiration date is in the past then status is not "active".

;Cross-system consistency checks
:Compares data in different systems to ensure it is consistent. Systems may represent the same data differently, in which case comparison requires transformation (e.g., one system may store customer name in a single Name field as 'Doe, John Q', while another uses First_Name 'John' and Last_Name 'Doe' and Middle_Name 'Quality').

;Data type checks
:Checks input conformance with typed data. For example, an input box accepting numeric data may reject the letter 'O'.

;File existence check
:Checks that a file with a specified name exists. This check is essential for programs that use file handling.

;Format check
:Checks that the data is in a specified format (template), e.g., dates have to be in the format YYYY-MM-DD. Regular expressions may be used for this kind of validation.

;Presence check
:Checks that data is present, e.g., customers may be required to have an email address.

;Range check
:Checks that the data is within a specified range of values, e.g., a probability must be between 0 and 1.

;Referential integrity
:Values in two relational [[Database|database]] tables can be linked through foreign key and primary key. If values in the foreign key field are not constrained by internal mechanisms, then they should be validated to ensure that the referencing table always refers to a row in the referenced table.

;Spelling and grammar check
:Looks for spelling and grammatical errors.

;Uniqueness check
:Checks that each value is unique. This can be applied to several fields (i.e. Address, First Name, Last Name).

;Table look up check
:A table look up check compares data to a collection of allowed values.

===Post-validation actions===
;Enforcement Action
:Enforcement action typically rejects the data entry request and requires the input actor to make a change that brings the data into compliance. This is most suitable for interactive use, where a real person is sitting on the computer and making entry. It also works well for batch upload, where a file input may be rejected and a set of messages sent back to the input source for why the data is rejected.
:Another form of enforcement action involves automatically changing the data and saving a conformant version instead of the original version. This is most suitable for cosmetic change. For example, converting an [all-caps] entry to a [Pascal case] entry does not need user input. An inappropriate use of automatic enforcement would be in situations where the enforcement leads to loss of business information. For example, saving a truncated comment if the length is longer than expected. This is not typically a good thing since it may result in loss of significant data.

;Advisory Action
:Advisory actions typically allow data to be entered unchanged but sends a message to the source actor indicating those validation issues that were encountered. This is most suitable for non-interactive system, for systems where the change is not business critical, for cleansing steps of existing data and for verification steps of an entry process.

;Verification Action
:Verification actions are special cases of advisory actions. In this case, the source actor is asked to verify that this data is what they would really want to enter, in the light of a suggestion to the contrary. Here, the check step suggests an alternative (e.g., a check of a mailing address returns a different way of formatting that address or suggests a different address altogether). You would want in this case, to give the user the option of accepting the recommendation or keeping their version. This is not a strict validation process, by design and is useful for capturing addresses to a new location or to a location that is not yet supported by the validation databases.

;Log of validation
:Even in cases where data validation did not find any issues, providing a log of validations that were conducted and their results is important. This is helpful to identify any missing data validation checks in light of data issues and in improving

==Validation and security==
Failures or omissions in data validation can lead to [[Data corruption|data corruption]] or a security vulnerability.<ref>[http://www.cgisecurity.com/owasp/html/ch10.html Chapter10. Data Validation]</ref> Data validation checks that data are fit for purpose,<ref>[https://web.archive.org/web/20171201042621/https://spotlessdata.com/blog/more-efficient-data-validation-spotless More Efficient Data Validation with Spotless]</ref> valid, sensible, reasonable and secure before they are processed.

== See also ==
* {{anl|Data processing}}
* {{anl|Data verification}}
* {{anl|Triangulation (social science)}}
* {{anl|Verification and validation}}
* {{anl|Data quality}}

==References==
{{Reflist}}

== External links ==
* [https://www.owasp.org/index.php/Data_Validation Data Validation], [[Organization:OWASP|OWASP]]
* [https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Input_Validation_Cheat_Sheet.md Input Validation], OWASP Cheat Sheet Series, github.com

{{Data}}

{{DEFAULTSORT:Data Validation}}
[[Category:Data processing]]
[[Category:Data security]]
[[Category:Data quality]]

{{Sourceattribution|Data validation}}