Data Quality Starts With the Question, Not the Dataset

“Clean data” is not an absolute state. A dataset can be accurate enough for a national trend and unusable for street-level routing. CS 513’s most important starting point is therefore fitness for use: data quality is judged against the decision, operation, or question the data must support.

Turn an analysis question into a quality contract

Suppose we want to ask:

How did the number of restaurant menus vary by city and decade?

That sentence already implies requirements:

Required field	Quality condition	Why it matters
City	Same city maps to one canonical value	Otherwise groups fragment
Date	Parseable and within the collection’s time range	Needed to derive decade
Record identity	No accidental duplicate menus	Otherwise counts inflate
Provenance	Inferred cities are marked	Needed to interpret uncertainty

Price, page count, or dish description may be messy without blocking this question. Cleaning them first spends effort without increasing the fitness of this use.

In plain terms: do not polish every room before deciding which room you need to use.

Quality has several dimensions

Common dimensions describe different failure modes:

• Accuracy: does the value agree with reality?
• Completeness: is the required value present?
• Consistency: do related values obey the same rules?
• Validity: does the value conform to its format or domain?
• Uniqueness: is one real entity represented once?
• Timeliness: is the value current enough for the decision?

These dimensions can conflict. Replacing every missing value increases apparent completeness but may reduce accuracy. Rejecting every uncertain row improves validity among survivors but may make the dataset unrepresentative.

Measure the cost on both sides

Low-quality data creates search, rework, incorrect decisions, lost trust, and maintenance cost. Cleaning also costs engineering time, review effort, compute, and sometimes information loss.

A practical priority score can be informal:

priority ≈ probability of defect
         × impact on the intended use
         × number of affected consumers

The formula is not a universal metric. Its purpose is to expose why one issue deserves attention before another.

Prevention, detection, and repair are different investments

Stage	Example	Typical advantage
Prevent	Database constraint or controlled input	Stops bad states early
Detect	Profile, validation query, anomaly report	Reveals existing problems
Repair	Canonical mapping or reviewed correction	Makes data usable again

If you control data entry, prevention is usually cheaper than repeated repair. If you inherit historical data, detection and traceable repair become unavoidable.

“Good enough” needs evidence

A quality statement should name:

1. the intended use;
2. the fields and population in scope;
3. the rules or metrics applied;
4. known exceptions and missing coverage;
5. the version and time of assessment.

“The dataset is 96% accurate” is weak without saying which values were tested, how truth was established, and whether the sample resembles the rows that needed repair.

Review card

• Data quality is fitness for a stated use.
• Convert the intended query into field-level quality requirements.
• Accuracy, completeness, consistency, validity, uniqueness, and timeliness are different dimensions.
• Cleaning can trade one dimension for another.
• Prioritize defects by likelihood, impact, and reach.
• A quality claim needs scope, method, exceptions, and provenance.

priority ≈ defect probability
         × impact on intended use
         × affected consumers