Data validation guarantees to your application that every data value is correct and accurate. You can design data validation into your application with several differing approaches: user interface code, application code, database constraints, or business rules.
There are several types of data validation.
One of the simplest forms of data validation is verifying the data type. Data type validation answers such simple questions as "Is the string alphabetic?" and "Is the number numeric?" Usually you can handle such simple validations with your application's user interface.
As an extension of simple type validation, range checking ensures that the provided value is within allowable minimums and maximums. For example, a character data type service code may only allow the alphabetic letters A through Z. All other characters would not be valid. As with data type validation, your application's interface can typically provide the necessary range validation, although as a design alternative you could create a business rule to handle range validations.
Code checking is a bit more complicated, typically requiring a lookup table. For example, maybe your application calculates sales tax for only certain state codes. You would need to create a validation table to hold the authorized, taxable state codes. This validation table could be part of a business rule, or it could be implemented directly in the database for query lookup.
Simple field and lookup validation is sometimes not enough. Consider a health care claim which has a billed amount of $123.57, but the allowable amount may depend on a year-to-date rolling accumulation that is capped at $1,500 (not to exceed the lifetime policy maximum of $100,000). In this situation, data validity extends beyond the immediate data entry screen to one of careful evaluation of how to pay this claim based on the policy limits and year-to-date accruals. This kind of complex data validation is best handled with business rules.
It's an unfortunate artifact of older file structures that the data is often corrupted (such as numeric fields that are blank or contain alphabetics). As you build your enterprise application, you may want to build a testing utility to verify the correctness of every single field in every record of the files your application uses. If you don't, your application may provide unpredictable results.