SQL Data Quality Checks — 10 LinkedIn Posts

SQL Data Quality Check #01

🧪 Null Check

SQL Data Quality Check #01: Null Check

Before trusting a report, check for missing critical values.

Business problem:
Some fields are too important to be empty.

Examples:
customer_id
order_date
invoice_number
employee_id
payment_amount

If these fields are NULL, your report may undercount, break relationships, or exclude important records.

Sample table:

order_id | customer_id | order_date  | amount
1001     | C001        | 2026-07-01  | 250
1002     | NULL        | 2026-07-01  | 180
1003     | C003        | NULL        | 320
1004     | C004        | 2026-07-02  | 95

SQL check:

SELECT *
FROM orders
WHERE customer_id IS NULL
   OR order_date IS NULL;

Expected result:

order_id | customer_id | order_date | amount
1002     | NULL        | 2026-07-01 | 180
1003     | C003        | NULL       | 320

Why it matters:
A missing customer_id can break joins.
A missing order_date can affect trend analysis.
A missing amount can distort revenue totals.

Common mistake:
Only checking if the table has rows, but not checking if the important fields are complete.

BI impact:
Dashboards can look correct visually while silently excluding incomplete records.

Key idea:
Data quality starts by asking:
“What fields must never be missing?”

More practical resources:
https://jobaqui.com
https://hialeahoficios.com
https://miamioficios.com

#SQL
#DataQuality
#BusinessIntelligence
#DataAnalytics
#DataCleaning
#DataValidation
#LearningByDoing

SQL Data Quality Check #02

📊 Volume Check

SQL Data Quality Check #02: Volume Check

A table can load successfully and still be wrong.

Business problem:
You need to detect sudden changes in record counts.

Maybe yesterday you received 50,000 rows.
Today you received only 2,000.

That may not be a business trend.
It may be a broken data load.

Sample table:

order_id | order_date  | amount
1001     | 2026-07-01  | 250
1002     | 2026-07-01  | 180
1003     | 2026-07-02  | 320
1004     | 2026-07-02  | 95

SQL check:

SELECT 
    order_date,
    COUNT(*) AS total_records
FROM orders
GROUP BY order_date
ORDER BY order_date;

Expected result:

order_date  | total_records
2026-07-01  | 2
2026-07-02  | 2

More advanced check:

SELECT COUNT(*) AS today_records
FROM orders
WHERE order_date = CURRENT_DATE;

Why it matters:
Volume changes can reveal:
• missing files
• failed ETL jobs
• duplicate loads
• source system issues
• incomplete daily refreshes

Common mistake:
Assuming that no error message means the data loaded correctly.

BI impact:
A dashboard can refresh successfully but still show incomplete business activity.

Key idea:
Always compare today’s volume against a normal baseline.

More practical resources:
https://jobaqui.com
https://hialeahoficios.com
https://miamioficios.com

#SQL
#DataQuality
#BusinessIntelligence
#DataAnalytics
#ETL
#DataValidation
#LearningByDoing

SQL Data Quality Check #03

🔑 Uniqueness Check

SQL Data Quality Check #03: Uniqueness Check

Some fields should be unique.

Business problem:
You need to confirm that IDs or business keys are not repeated.

Examples:
order_id
invoice_id
employee_id
customer_number
transaction_id

Sample table:

order_id | customer_id | amount
1001     | C001        | 250
1002     | C002        | 180
1002     | C002        | 180
1003     | C003        | 320

SQL check:

SELECT 
    order_id,
    COUNT(*) AS record_count
FROM orders
GROUP BY order_id
HAVING COUNT(*) > 1;

Expected result:

order_id | record_count
1002     | 2

Why it matters:
Duplicate keys can inflate totals.
Duplicate invoices can overstate revenue.
Duplicate employees can distort headcount.
Duplicate transactions can damage trust in reporting.

Common mistake:
Using SELECT DISTINCT to hide duplicates instead of investigating why they exist.

BI impact:
A duplicated fact row can make dashboards show inflated KPIs.

Key idea:
Do not just remove duplicates.
Understand why the duplicate exists.

More practical resources:
https://jobaqui.com
https://hialeahoficios.com
https://miamioficios.com

#SQL
#DataQuality
#BusinessIntelligence
#DataAnalytics
#DataCleaning
#DataValidation
#LearningByDoing

SQL Data Quality Check #04

🚨 Outlier Detection

SQL Data Quality Check #04: Outlier Detection

Not every unusual value is wrong.

But every unusual value deserves attention.

Business problem:
You need to detect values that are much higher or lower than expected.

Sample table:

sale_id | revenue
1       | 100
2       | 120
3       | 95
4       | 110
5       | 10000

The value 10000 may be:
• a real large transaction
• a data entry error
• a decimal issue
• a duplicate
• a system mapping problem

SQL check:

SELECT *
FROM sales
WHERE revenue > (
    SELECT AVG(revenue) * 10
    FROM sales
);

Expected result:

sale_id | revenue
5       | 10000

Why it matters:
Outliers can distort:
• averages
• forecasts
• dashboards
• performance metrics
• executive summaries

Common mistake:
Automatically deleting outliers without business review.

Better approach:
Flag outliers first.
Review them.
Then decide whether to keep, correct, exclude, or explain them.

BI impact:
One extreme value can change the story of a report.

Key idea:
Outliers are not always errors.
They are signals that require investigation.

More practical resources:
https://jobaqui.com
https://hialeahoficios.com
https://miamioficios.com

#SQL
#DataQuality
#BusinessIntelligence
#DataAnalytics
#Outliers
#DataValidation
#LearningByDoing

SQL Data Quality Check #05

🕒 Data Freshness Check

SQL Data Quality Check #05: Data Freshness Check

Old data can look clean and still be dangerous.

Business problem:
You need to confirm the latest records are being loaded.

Sample table:

event_id | event_date
1        | 2026-07-01
2        | 2026-07-02
3        | 2026-07-03

SQL check:

SELECT MAX(event_date) AS latest_event_date
FROM events;

Expected result:

latest_event_date
2026-07-03

Why it matters:
If today is 2026-07-09 and the latest data is from 2026-07-03, the dashboard may be stale.

The report may refresh.
The visuals may load.
The filters may work.

But the business is looking at old information.

Use this check for:
• daily transactions
• service requests
• payments
• attendance records
• sensor data
• incident data

Common mistake:
Assuming refresh date equals data date.

A Power BI report can refresh today using source data that stopped updating last week.

BI impact:
Decision-makers may act on outdated information.

Key idea:
Always check:
“When was the most recent business event loaded?”

More practical resources:
https://jobaqui.com
https://hialeahoficios.com
https://miamioficios.com

#SQL
#DataQuality
#BusinessIntelligence
#DataAnalytics
#ETL
#DataFreshness
#LearningByDoing

SQL Data Quality Check #06

🔗 Referential Integrity

SQL Data Quality Check #06: Referential Integrity

Tables do not live alone.

Business problem:
You need to validate that records in one table actually connect to valid records in another table.

Example:
Every order should belong to a valid customer.

Orders table:

order_id | customer_id | amount
1001     | C001        | 250
1002     | C002        | 180
1003     | C999        | 320

Customers table:

customer_id | customer_name
C001        | Ana
C002        | Luis

Problem:
Customer C999 does not exist in the customer table.

SQL check:

SELECT 
    o.order_id,
    o.customer_id
FROM orders o
LEFT JOIN customers c
    ON o.customer_id = c.customer_id
WHERE c.customer_id IS NULL;

Expected result:

order_id | customer_id
1003     | C999

Why it matters:
Broken relationships create orphan records.

Those records may not appear correctly by:
• customer
• region
• category
• department
• territory
• vendor

Common mistake:
Only checking row counts and not checking relationships.

BI impact:
A dashboard may show sales totals, but fail to explain where those sales belong.

Key idea:
A good data model depends on valid relationships.

More practical resources:
https://jobaqui.com
https://hialeahoficios.com
https://miamioficios.com

#SQL
#DataQuality
#BusinessIntelligence
#DataModeling
#DataAnalytics
#DataValidation
#LearningByDoing

SQL Data Quality Check #07

📏 Range Validation

SQL Data Quality Check #07: Range Validation

Some values may be valid technically but impossible in business reality.

Business problem:
You need to check whether numeric values stay within reasonable limits.

Sample table:

payment_id | amount
1          | 250
2          | 0
3          | -50
4          | 9999999

SQL check:

SELECT *
FROM payments
WHERE amount <= 0
   OR amount > 100000;

Expected result:

payment_id | amount
2          | 0
3          | -50
4          | 9999999

Why it matters:
A number can be stored correctly and still be wrong.

Examples:
• negative payment amount
• age greater than 120
• discount above 100%
• salary below zero
• quantity greater than realistic inventory
• tax rate outside expected range

Common mistake:
Only validating data types, but not validating business rules.

BI impact:
Invalid ranges can distort averages, totals, rankings, and exception reports.

Key idea:
Data quality is not only about format.
It is also about business plausibility.

More practical resources:
https://jobaqui.com
https://hialeahoficios.com
https://miamioficios.com

#SQL
#DataQuality
#BusinessIntelligence
#DataAnalytics
#DataValidation
#DataCleaning
#LearningByDoing

SQL Data Quality Check #08

🔢 Data Type Validation

SQL Data Quality Check #08: Data Type Validation

A column may look like a number but behave like text.

Business problem:
You need to confirm that values match the expected data format.

Sample table:

user_id | age
1       | 25
2       | 40
3       | unknown
4       | N/A

If age is expected to be numeric, values like “unknown” or “N/A” create problems.

SQL Server style check:

SELECT *
FROM users
WHERE TRY_CAST(age AS INT) IS NULL
  AND age IS NOT NULL;

Expected result:

user_id | age
3       | unknown
4       | N/A

Why it matters:
Bad data types can break:
• calculations
• filters
• joins
• sorting
• averages
• aggregations
• machine learning features

Common mistake:
Assuming a column is numeric because the field name says age, amount, quantity, or score.

BI impact:
Power BI may import the column as text, causing measures and visuals to behave incorrectly.

Key idea:
Do not trust column names.
Validate actual values.

More practical resources:
https://jobaqui.com
https://hialeahoficios.com
https://miamioficios.com

#SQL
#DataQuality
#BusinessIntelligence
#DataAnalytics
#DataValidation
#SQLServer
#LearningByDoing

SQL Data Quality Check #09

📅 Date Consistency Check

SQL Data Quality Check #09: Date Consistency Check

Dates must follow business logic.

Business problem:
You need to detect records where dates are out of sequence.

Sample table:

subscription_id | start_date  | end_date
1               | 2026-01-01  | 2026-12-31
2               | 2026-03-01  | 2026-02-15
3               | 2026-05-01  | NULL

Problem:
Subscription 2 ends before it starts.

SQL check:

SELECT *
FROM subscriptions
WHERE end_date < start_date;

Expected result:

subscription_id | start_date  | end_date
2               | 2026-03-01  | 2026-02-15

Why it matters:
Date errors affect:
• duration calculations
• active/inactive status
• aging reports
• churn analysis
• service timelines
• SLA reporting

Common mistake:
Checking whether dates are populated but not checking whether they make sense together.

BI impact:
Reports may show negative durations, incorrect active counts, or misleading trends.

Key idea:
Dates should be validated as relationships, not just individual fields.

More practical resources:
https://jobaqui.com
https://hialeahoficios.com
https://miamioficios.com

#SQL
#DataQuality
#BusinessIntelligence
#DataAnalytics
#DateValidation
#DataCleaning
#LearningByDoing

SQL Data Quality Check #10

✅ Accepted Values Check

SQL Data Quality Check #10: Accepted Values Check

Some columns should only contain approved categories.

Business problem:
You need to verify that values match allowed business rules.

Example:
Order status should only be:

CREATED
SHIPPED
DELIVERED
CANCELLED

Sample table:

order_id | status
1001     | CREATED
1002     | SHIPPED
1003     | DELIVERD
1004     | CLOSED

Problem:
DELIVERD is misspelled.
CLOSED is not an approved value.

SQL check:

SELECT *
FROM orders
WHERE status NOT IN (
    'CREATED',
    'SHIPPED',
    'DELIVERED',
    'CANCELLED'
);

Expected result:

order_id | status
1003     | DELIVERD
1004     | CLOSED

Why it matters:
Invalid categories can break:
• filters
• slicers
• status reports
• KPIs
• operational dashboards
• workflow analysis

Common mistake:
Letting free-text fields drive business reporting without standardizing them.

BI impact:
A dashboard may split the same business concept into multiple categories because of typos or inconsistent labels.

Example:
DELIVERED
Delivered
deliverd
DELIVERD

All may appear as different values.

Key idea:
Business categories need controlled values.

More practical resources:
https://jobaqui.com
https://hialeahoficios.com
https://miamioficios.com

#SQL
#DataQuality
#BusinessIntelligence
#DataAnalytics
#DataValidation
#DataCleaning
#LearningByDoing