The Six Dimensions of Data Quality
Name the defect before you fix it
Completeness, uniqueness, timeliness, validity, accuracy and consistency — a shared vocabulary for describing exactly how data is broken before you fix it.
What you will learn
- Distinguish the six canonical data quality dimensions
- Translate a vague complaint ('data is messy') into a named dimension with a metric
- Pick which dimensions to enforce per dataset instead of enforcing everything forever
What is this?
Data quality dimensions are a standard way to classify defects: completeness (are values present?), uniqueness (one record per entity?), timeliness (is data fresh enough?), validity (does data conform to its schema and ranges?), accuracy (does it reflect the real world?) and consistency (is it the same — across columns, tables and systems?). Most 'dirty data' is a mix of several dimensions, and each needs its own check and its own owner.
Why do you need it?
- A shared vocabulary stops arguments: 'this column is wrong' becomes 'validity failed in the source feed'.
- Each dimension maps to a concrete, automatable check with a pass/fail threshold.
- Prioritization becomes possible — 100% accuracy everywhere is unaffordable, so teams pick the dimensions that matter per dataset.
- Regulators and auditors ask for dimension-based quality reporting (e.g. completeness of PII fields).
Mental model
A restaurant's food-quality checklist
Data quality dimensions
A kitchen checks that dishes are complete (all components present), unique (correct per order), served on time (timeliness), within recipe spec (validity), tasting right (accuracy) and matching across orders (consistency). Data is graded the same way.
How it works
- Completeness: fraction of rows where a field is non-null; also row-level completeness versus expected volume.
- Uniqueness: fraction of rows that are eligible duplicates within a defined entity key.
- Timeliness: age of data relative to source event time and the agreed SLA.
- Validity: conformance to schema, domain, ranges, format and reference lists.
- Accuracy: agreement with a trusted ground-truth source (often sampled and reconciled).
- Consistency: identical representation across copies, systems and time.
The six dimensions and the check they each suggest.
In production
- A payments team measures uniqueness of the transaction key daily; a drift above 0.01% blocks the batch.
- A marketing warehouse tracks completeness of the customer_id field per source and pages the source owner when it drops below 99.5%.
- A weather data vendor reports timeliness as minutes between observation and landing, with an SLA of 5 minutes.
Best practices
- Score a handful of dimensions per dataset, not all six — enforce what consumers actually rely on.
- Write a one-line metric definition per dimension so the number is interpreted identically by everyone.
- Trend quality over time; a single '98%' snapshot says nothing about whether things are improving.
- Exclude expected-null cases from 'completeness' so legitimate absence isn't flagged as a defect.
Common mistakes
- Treating validity and accuracy as the same thing — a well-formatted number can still be wrong.
- Enforcing every dimension on every table and drowning engineers in false positives.
- Scoring completeness without a baseline expectation, so empty tables look '100% complete'.
- Fixing symptoms in the warehouse instead of the upstream system that creates the dirt.
Debugging tips
- Calculate all six metrics on one day of data before building checks — let the data tell you which dimensions are polluted.
- Bucket rows by dimension failure: a row can fail multiple checks at once.
- Use the dimension that fails most to guide root-cause: validity points to source mapping, uniqueness to key design.
- When in doubt, verify against the raw landing copy before the transform stage.
Interview checkpoint
Quick quiz
A date column contains '2026-13-45'. Which dimension is violated?
Two tables storing the same revenue figure disagree. That is an accuracy problem.