The 6 dimensions of data quality, explained

Completeness, uniqueness, validity, consistency, accuracy and timeliness — what each dimension means, an example violation, and the check that catches it.

2026-09-10 · 8 min read

The six dimensions of data quality are completeness, uniqueness, validity, consistency, accuracy and timeliness. Each names a distinct way data can be wrong, and together they form the standard framework for describing, measuring and reporting the health of a dataset. A dimension is not a check — it is a category of checks, which is what makes it useful: a single failing rule tells you one column is broken, while coverage by dimension tells you whether you are watching for the right kinds of failure at all.

The framework comes out of the data management literature (DAMA-DMBOK and the DAMA UK dimensions paper are the usual references) and is conventional enough that a coverage report means roughly the same thing across teams and tools. Some taxonomies rename a dimension — conformity for validity, freshness for timeliness — but the six below are the working set.

Summary

1. Completeness

Definition. Completeness measures whether all the data that should be present is present — at the value level (no nulls in required fields), the record level (no missing rows) and the dataset level (no missing partitions).

Example violation. An overnight load fails halfway through. Every row that landed is individually perfect, but customer_id is null on 4% of orders because the join ran against a customer table that had not yet refreshed. No error was raised; the rows simply carry nulls.

The check. Count nulls in each required column, and count rows against an expected floor:

SELECT
    count(*)                                      AS row_count,
    count(*) FILTER (WHERE customer_id IS NULL)   AS missing_customer,
    count(*) FILTER (WHERE order_id IS NULL)      AS missing_order_id
FROM sales.orders
WHERE created_at >= current_date - 1;

Row-count checks are the underrated half of completeness: a null check on a table that received no rows at all passes with flying colours.

2. Uniqueness

Definition. Uniqueness measures whether each real-world entity is represented exactly once. It covers both exact duplicates of a key and near-duplicates that represent the same entity under different values.

Example violation. A backfill is re-run without truncating first, and every order from the last seven days now exists twice. Nothing is null, no value is out of range, and every downstream aggregate is wrong.

The check. Count key values that appear more than once:

SELECT count(*) AS violations
FROM (
    SELECT order_id
    FROM sales.orders
    WHERE order_id IS NOT NULL
    GROUP BY order_id
    HAVING count(*) > 1
) dupes;

A unique index would prevent this at write time, but analytics tables rarely have one: CREATE TABLE AS SELECT carries no constraints, so a rebuilt dbt model has nothing enforcing its key. The duplicate check is the only thing standing in.

3. Validity

Definition. Validity — also called conformity — measures whether each value conforms to the format, type, range or allowed set defined for its field. It is a syntactic property: a valid value is well-formed, which does not mean it is correct.

Example violation. A new upstream integration starts writing "COMPLETE" into a status column whose consumers switch on 'pending', 'paid', 'shipped' and 'refunded'. Every downstream CASE falls through to its ELSE branch, and the orders quietly vanish from the funnel report.

The check. Test membership, pattern and range:

SELECT count(*) AS violations
FROM sales.orders
WHERE status IS NOT NULL
  AND status NOT IN ('pending', 'paid', 'shipped', 'refunded');

The IS NOT NULL guard is not decoration. SQL's three-valued logic resolves NULL NOT IN (...) to NULL rather than true, so a null status never satisfies the WHERE clause and never reaches the count. Drop the guard and a column that has stopped being populated altogether scores as perfectly valid — which is why validity and completeness have to be measured as separate rules rather than folded into one query.

4. Consistency

Definition. Consistency measures whether related values agree — across columns in a row, across tables in a database, or across systems. It covers referential integrity, cross-field logic and cross-system reconciliation.

Example violation. A partial reload leaves 12,000 orders whose customer_id does not exist in the customer table. Each row is complete, unique and valid in isolation, and invisible until a dashboard's inner join silently drops them and revenue appears to fall 3%.

The check. Orphaned foreign keys, and impossible field combinations:

SELECT count(*) AS orphans
FROM sales.orders o
LEFT JOIN sales.customers c ON o.customer_id = c.id
WHERE o.customer_id IS NOT NULL
  AND c.id IS NULL;

Cross-field consistency is the same idea inside one table: shipped_at >= ordered_at, a refund never exceeding its payment, line items summing to the invoice total. These encode domain invariants, and they are the checks that catch genuine business errors rather than plumbing errors.

5. Accuracy

Definition. Accuracy measures whether the values correctly describe the real-world thing they refer to. It is the hardest dimension, because verifying it requires a source of truth outside the dataset.

Example violation. A customer's address is well-formed, complete, unique and internally consistent — and belongs to the building they moved out of two years ago. Every syntactic check passes; the parcel goes to the wrong place.

The check. Three approaches, in descending order of rigour:

• Reconciliation. Compare against an authoritative system — warehouse revenue against the finance ledger, customer counts against the CRM. The only check that measures accuracy directly, and worth the effort for the handful of numbers the business reports.
• Reference data. Validate against an external list: postcodes that exist, ISO 4217 currency codes, VAT numbers that resolve.
• Plausibility bounds. Range checks as a proxy. An order total of -40 or 4,000,000 is not provably wrong, but it is wrong often enough to catch:

SELECT count(*) AS violations
FROM sales.orders
WHERE total_amount IS NOT NULL
  AND (total_amount < 0 OR total_amount > 100000);

Be honest about the distinction: plausibility bounds are a validity check wearing an accuracy hat. They catch outliers, not errors.

6. Timeliness

Definition. Timeliness — often called freshness — measures whether the data is recent enough for the decision it supports. It has two halves: latency (how long between an event happening and it being queryable) and currency (how stale the newest row is now).

Example violation. A pipeline stops on Friday evening. The Monday dashboard renders perfectly, every check passes, and every number is from Friday. No rule about the contents of the data can detect this, because the contents are fine.

The check. Compare the newest timestamp against a threshold:

SELECT count(*) AS violations
FROM sales.orders
WHERE created_at < now() - interval '24 hours';

Prefer a timezone-aware timestamp type — a bare timestamp compares against whatever the session's zone happens to be, so the same check gives two clients different answers. And set the threshold from the decision, not the schedule: a table loading hourly that only feeds a weekly report needs no hourly alert.

Using dimensions rather than just naming them

The framework earns its keep once you have a hundred rules. Individually they are a list; grouped by dimension they become a coverage matrix, and the gaps in that matrix are usually more informative than any single failing check.

The characteristic gap: heavy coverage on completeness and validity, because those checks are easy to write, and almost nothing on consistency or timeliness, because those require thinking about relationships and schedules. The team ends up well defended against the failures that are cheap to detect and undefended against the ones that take down a dashboard. Two practices follow:

1. Tag every rule with its dimension and report coverage per dataset. A critical table with zero timeliness rules is a finding even when every check is green.
2. Weight by criticality, not table count. Full six-dimension coverage on your ten most-consumed datasets beats partial coverage on four hundred.

The Open Data Contract Standard makes the dimension a first-class field on every quality rule, which is what allows coverage to be computed rather than estimated. Catalyst models the same six dimensions directly: every rule carries one, and results roll up into a per-dataset coverage view alongside the pass/fail detail.

See also: what data validation is, what a data contract is, and the guide to validating data for the SQL and scheduling.

Frequently asked questions

What are the 6 dimensions of data quality?

Completeness (is the expected data present), uniqueness (does each entity appear exactly once), validity (does each value conform to its allowed format or set), consistency (do related values agree with each other), accuracy (do the values correctly describe the real world) and timeliness (is the data recent enough to be useful).

Are there only six data quality dimensions?

Six is the common working set, but taxonomies vary. DAMA UK's paper lists six; other frameworks add integrity, precision, relevance or accessibility. The exact count matters far less than picking one set and using it consistently, so coverage reports mean the same thing across teams.

What is the difference between validity and accuracy?

Validity is syntactic: the value is well-formed and belongs to the allowed set or range. Accuracy is semantic: the value correctly describes the real-world thing. A valid but inaccurate value is the classic hard case — a properly formatted street address for the building the customer moved out of two years ago passes every validity check and is still wrong.

Which data quality dimension is most important?

It depends on the decision the data supports, but timeliness and completeness cause the most incidents in practice: a stopped pipeline or a partial load breaks everything downstream at once while leaving every value individually correct. Accuracy matters most for numbers reported externally, and it is the only dimension requiring a source of truth outside the dataset.

How do you measure data quality dimensions?

Attach each rule to a dimension, express it as a query returning a violation count, and report both the pass rate per rule and the coverage per dimension. Coverage is the part teams skip: knowing that ninety-eight of a hundred checks passed is much less useful than knowing that none of the hundred were timeliness checks.