Validation rules generally start with a description of what the data should look like.
Some common things:
Which variables should never have missing values? Relatively easy to check: Proc freq Nlevels will tell if there are missing values for variables.
Data ranges: Variable X should have values of <some list goes here> examples: survey question category answers, product types or departments for categorical data. Numeric may have "natural range" such as Sales should be >= 0 (though I have seen some idiots use - values for sales as a return); data collection instruments may a theoretically unlimited range but practical limits: air temperature values of < -100F or > 150F are highly suspect anywhere and geography likely provides better limits.
Expected membership in a category is easily checked with custom informats and using the _error_ option. The following will only allow values of F and M to be accepted for the variable. Note that it complains about lowercase. So this is an exact comparison.
Proc format library=work;
invalue $gender
'F','M' = _same_
other = _error_
;
run;
data example;
input gender $gender.;
datalines;
F
M
a
f
.
m
;
run;
numeric ranges can be tested similarly when read if you know a range. If missing is acceptable you would provide a line in the informat code for that so the Other doesn't catch it.
If you have values that you expect in a range but sometimes go out, do not make the values from the informat as errors but you might provide data checking code to report low or high values.
The next set of relatively easy checks are referential test based on two or more variables in the data. Can a persons Date of Birth be later than the date of a hospital visit for instance. It is easy to code things such as: If varb > vara then put "WARNING: Measure a exceeds b for " <id variables>;
Proper informat choices for date, time and datetime values can provide a lot of help when the data source gets fubarred. I have some dates from project that looked like: 12020121 If that date was supposed to be YYYYMMDD then the year was 1202, if the data was supposed to be MMDDYYYY then the year was 121. In either case highly improbable for an STD test.
Other forms of referential data depend on your knowledge of the subject and you data. Is the sale amount for this month much larger or smaller than seems "right" for that store/company/department/product. Snow shovel sales in the US tend to peak with the first regional major snowstorm. If a store sells a bunch of then in July (or December for the folks in the southern hemisphere) that might be an indicator.
Another referential might be you expect at least one record per time interval. So you have to examine the actual intervals. Or only one record per time interval, more than one would be an issue.
If there is a data layout or agreement document you may have some of the expected values, and possibly even edits performed before you see the data. If you have agreement or content documents that is the first place to look to Know Thy Data.
