Напиши SQL-проверку качества данных (data quality test) для таблицы fact_orders: убедись, что у каждого заказа есть существующий customer_id в dim_customer (referential integrity), и что amount не отрицательный?

Короткий ответ

Нужны два отдельных запроса-проверки: LEFT JOIN с фильтром на отсутствие соответствия в dim_customer для ссылочной целостности и простой фильтр amount < 0 для проверки диапазона значений; в обоих случаях результат должен возвращать ноль строк.

Как это работает подробнее

Такие проверки обычно оформляют как автоматические тесты в оркестраторе/dbt (тест «relationships» и «custom SQL test»), которые запускаются после каждой загрузки и падают (fail), если запрос вернул хотя бы одну «плохую» строку.

Пример кода

example.sqlКопировать

-- Проверка 1: ссылочная целостность
SELECT o.order_id
FROM fact_orders o
LEFT JOIN dim_customer c ON o.customer_id = c.customer_id
WHERE c.customer_id IS NULL;
-- Проверка 2: amount не может быть отрицательным
SELECT order_id, amount FROM fact_orders WHERE amount < 0;

Что использовать на практике

• На практике. Проверки качества данных встраивают в сам пайплайн, а не выполняют вручную постфактум — это позволяет остановить загрузку или хотя бы оповестить команду до того, как сломанные данные дойдут до дашбордов бизнеса.
• Проверка. оба запроса в здоровом пайплайне должны возвращать 0 строк; если проверка 1 вернула строки — где-то в источнике создаются заказы без клиента или dim_customer не успела обновиться до загрузки fact_orders.

Подводные камни

• Частые ошибки. Делают проверки «для галочки» без алертинга — тест падает, но об этом никто не узнаёт; либо пишут слишком строгие проверки без допуска на редкие легитимные случаи (например, тестовые заказы с amount = 0), что приводит к постоянным ложным срабатываниям и игнорированию алертов командой.