“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 consumersThe 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:
- the intended use;
- the fields and population in scope;
- the rules or metrics applied;
- known exceptions and missing coverage;
- 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.