Skip to content
Expert O'clock

Data Quality

Data quality dimensions with practical checks

A practical guide to the six data quality dimensions, the checks that test each one, and how to decide which failures should stop a report.

Talha Ansari··5 min read

Key takeaways

  • Dimensions turn a vague concern about quality into a testable question.
  • Completeness, uniqueness, validity, consistency, timeliness, and accuracy cover most checks.
  • A check needs a threshold and a defined response.
  • Measure quality over time instead of relying on a one-off clean-up.
On this page

Dimensions make quality testable

Data quality is easy to discuss in general and hard to act on. Dimensions give the discussion structure. Instead of asking whether the data is good, ask whether it is complete, unique, valid, consistent, timely, and accurate for a specific use.

No dataset scores well on every dimension at all times. The purpose of the dimensions is to make the trade-offs explicit. A daily operations report may accept a short delay; a statutory return may not.

Completeness and timeliness

Completeness checks whether the expected records and fields are present. That includes rows, periods, and mandatory attributes. A missing week or a missing region can change a trend without producing an error.

Timeliness checks whether the data arrived when the process needed it. A complete dataset delivered after the report deadline is still late. Record the expected arrival time and the actual load time, and alert when the gap exceeds the agreed limit.

  • Row counts by day and by source file.
  • Null counts for mandatory fields.
  • Missing periods compared with a calendar.
  • Load time against the agreed deadline.

Uniqueness and validity

Uniqueness checks for duplicate keys and duplicate business records. Duplicate invoices inflate revenue; duplicate customers distort counts and segmentation. Test the key you expect to be unique, then test the business identifier people actually use.

Validity checks whether values fall within an allowed domain. Dates should be real dates, statuses should come from an approved list, and amounts should respect sign and range rules. A value can be present and still be wrong.

Check for duplicate invoice keysSQL
SELECT
  COUNT(*) AS total_rows,
  COUNT(DISTINCT invoice_id) AS distinct_invoices,
  COUNT(*) - COUNT(DISTINCT invoice_id) AS duplicate_rows
FROM invoices;

Consistency and accuracy

Consistency checks whether the same fact agrees across datasets. An order total should match the sum of its lines. A customer's country should match the country on their invoices. Consistency failures often point to a broken join or a late update rather than a data entry error.

Accuracy checks whether the value matches reality. It is the hardest dimension to test automatically because it requires an independent source: a bank statement, a physical stock count, or a signed contract. Sample-based review is often the practical approach.

Dimensions, questions, and example checks
DimensionQuestionExample check
CompletenessAre the expected rows and fields present?Daily row count against the source file
UniquenessIs each entity recorded once?Duplicate count on the business key
ValidityDo values fit the allowed domain?Status outside the approved list
ConsistencyDo related datasets agree?Order header total versus sum of lines
TimelinessDid the data arrive on time?Load timestamp against the deadline
AccuracyDoes the value match reality?Sample compared with a bank statement

Turn dimensions into checks

A useful check has four parts: the rule, the threshold, the scope, and the response. The rule is the query or comparison. The threshold says what counts as a failure. The scope says which rows or periods are tested. The response says who is notified and whether the report is blocked.

Set thresholds from the business impact, not from a wish for zero defects. A small number of missing optional phone numbers may be acceptable. A single missing invoice in a financial total may not be. Write the decision down so the check does not depend on who is on duty.

Triage failures without hiding them

When a check fails, record the failure, the affected period, and the action taken. Publish the report with a visible caveat if the issue is known and bounded. Do not silently exclude bad rows to make the total look clean.

Review failures monthly. A check that fails every run is either badly calibrated or pointing at a process that needs fixing. Both are useful findings. A check that never fails may not be testing anything important.

  • Block the report for financial or statutory totals.
  • Flag and annotate for operational reports with a known gap.
  • Route data entry issues to the source owner.
  • Retire or recalibrate checks that no longer match the process.

Frequently asked questions

How many data quality dimensions are there?+

Six are commonly used: completeness, uniqueness, validity, consistency, timeliness, and accuracy. Some frameworks add others, but these cover most reporting checks.

Which dimension matters most?+

It depends on the decision. Accuracy matters most for financial reporting; timeliness may matter more for daily operations. Agree the priority with the report owner.

Is a tool needed to run these checks?+

No. SQL queries and a scheduled script can cover the basics. A tool helps when there are many datasets, owners, and alerts to manage.

What should happen when a check fails?+

Follow the documented response: block, flag, or notify. Record the failure and review it, rather than deleting the rows and moving on.

Need help applying this?

Improve your data cleanup & pipelines.

Review the service scope or tell us what you are trying to improve. We will reply with a clear next step.

Discuss this serviceView service
Free KPI definition template

Related reading