Crystal Reports Administration: Data Validation and the Crystal Reports Administrator

Crystal Reports Administration: Data Validation

The subject of data validation is extensive and no article is going to provide complete coverage of the topic. The purpose of this article is to point out some key factors you should consider so your Crystal Reports tend to reflect accurate data.

While there is a definite line between Crystal Reports administration and database administration, the CR administrator may be the first one blamed if a report isn't accurate. In many situations, the two functions are occupied by one person. Where this is not the case, the people occupying the two functions benefit from working together. For one thing, when users stop trusting your Crystal Reports, there will be a decreased need for your services. So, you have a vested interest in database accuracy.

Your database is only as good as the information provided to it. Various database programs offer various data input validation functions for the designer to implement in an input screen. Examples include:

Field length

Minimum number of characters

Data type

Letter case

Comparison to another field

While these tools are good, they are basically concerned with the format of the data. The reason for that focus is the limitation of automation. To accomplish a higher level of data validation, you must use education rather than automation. People can still enter poor or inaccurate data, while meeting format requirements.

Rather than try to exhaust this subject (and you) in the space of an article, let's look at a case history you can draw lessons from.

Steve was a supervisor in the research department of a magazine company. One day, he happened on the Website of one of the magazines his company put out. He noticed a link called "Reader Response," so he clicked on it. This showed some nice pie charts of what readers allegedly thought of the usefulness the articles in each issue.

Steve contacted the editor, and asked about this. The survey methods violated several principles of survey design. For example:

The surveyed population was very small. Some articles had responses from only 5 readers out of 120,000.

The population was self-selecting, and the bias was toward a particular type of reader rather than a representative spectrum of readers.

The readers were to rate the articles as Excellent, Good, Fair, Average, or Poor. Only "Poor" is negative, so the bias in this survey was atrocious.

Some range of responses for each article in each issue ranged from a few hundred to only 5--thus, the response density was inconsistent and comparison was meaningless.

Steve asked the editor if these results were every surprising or inconsistent with the staff's expectations, and the editor responded that they were. Steve then pointed out the invalidity of the survey.

The lesson here is you, as a Crystal Reports administrator, should not rely on automation to ensure the database contains accurate information. You must question the means of data collection. If you are not responsible for the entire database process, take heart--you have an opportunity to build a mutually beneficial working relationship with everyone involved in the process. Not only will that improve the usefulness and reliability of the Crystal Reports you are responsible for, but it will improve your personal network of contacts in an age of disappearing IT jobs.

Some thoughts on data accuracy

In recent years, there have been several high profile scandals involving advocacy groups that have published false statistics or other false data. In many cases, this was deliberate. In other cases, the problem was those using the data simply did not vet the data because what they were looking at supported their existing notions and agenda.

The first thing to consider is the source. Are the data from a reliable source? An accurate historical book, for example, will draw mostly on primary sources--original correspondence, for example. An inaccurate one will draw on newspaper accounts (notoriously inaccurate), which are tertiary sources at best.

In your own organization, where are your data coming from? If the sources have a vested interest in a particular outcome, your data are probably biased. So look at who is providing your data and how your data are collected. You want to eliminate bias and error at the source and also eliminate dubious sources.

Next, look at the data collection method. Consider the case of the typical hotel survey that asks, "How are we doing?" You get a few multiple choice questions, with the answers being "Outstanding, excellent, very good, good, average, poor." Do you see the problem there? How can you graph the results in any meaningful way? You can't; it will be skewed beyond any reliability and thus any value.

A third aspect to consider is whether you are getting the relevant data and the right data. Avoid the situation that's analogous to the guy who's looking for his lost nickel under the street lamp because the light's better there than 50 feet away where he actually dropped the coin. Adding irrelevant data leads to drawing irrelevant conclusions.

Finally, ensure you aren't asking for too much data. A common problem in plant maintenance organizations is the techs are burdened with filling out huge reports while doing preventive maintenance. They just check everything off as OK and then look at the equipment based on their experience and without regard to the checklist. This defeats the purpose of data collection. It's better to get a small but reliable sample of data than a huge but unreliable sample. You may have to focus on the top few things that matter, rather than everything that could possibly matter.