ddadminandClaude Fable 5
4a04a2caf6
Одна диаграмма отвечает на один вопрос: db_schema.md перестроен в лесенку из четырёх схем (слои, звезда, сборка факта, витрины), полная lineage-карта перенесена в конец как справочная. Новые документы: reading_the_pipeline.md (метод чтения FROM/JOIN load-скрипта, разбор fact_src) и dq_taxonomy.md (три класса DQ-проверок на реальных скриптах, семантика NULL). Точки входа: корневой README, docs/README.md, assignment/README.md, qa-plan.md. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
64 lines
4.6 KiB
Markdown
64 lines
4.6 KiB
Markdown
# Классы DQ-проверок
|
||
|
||
DQ-проверка должна отвечать на конкретный вопрос. В этом проекте есть три
|
||
класса. Один `*_dq.sql` может содержать проверки нескольких классов.
|
||
|
||
## 1. Универсальные структурные проверки
|
||
|
||
Они проверяют форму таблицы: обязательные ключи заполнены, ключ уникален, а
|
||
таблица не пуста там, где по контракту ожидаются строки. Так можно быстро поймать
|
||
сломанное зерно или незавершённую загрузку без знания бизнес-смысла данных.
|
||
|
||
Реальные примеры:
|
||
|
||
- [`sql/dds/dim_airports_dq.sql`](../../sql/dds/dim_airports_dq.sql) требует
|
||
непустую таблицу, проверяет уникальность `airport_sk` и `airport_bk`, а также
|
||
обязательные поля.
|
||
- [`sql/ods/bookings_dq.sql`](../../sql/ods/bookings_dq.sql) ищет дубли
|
||
`book_ref` и `NULL` или пустые значения в обязательных полях. Пустой
|
||
инкрементальный батч здесь допустим.
|
||
- [`sql/ods/tickets_dq.sql`](../../sql/ods/tickets_dq.sql) проверяет уникальность
|
||
`ticket_no`, обязательные поля и отсутствие билетов без `bookings.book_ref`.
|
||
|
||
## 2. Проверки бизнес-правил
|
||
|
||
Они проверяют ограничения предметной области, которых не видно из структуры
|
||
таблицы. Такая проверка нужна, чтобы заметить правдоподобную по типам, но
|
||
невозможную по смыслу строку.
|
||
|
||
В [`sql/dm/sales_report_dq.sql`](../../sql/dm/sales_report_dq.sql) для дат
|
||
текущего запуска проверяется, что `tickets_sold >= passengers_boarded`,
|
||
`boarding_rate` лежит между `0` и `1`, а `total_revenue` неотрицательна.
|
||
|
||
## 3. Межслойные сверки
|
||
|
||
Они отвечают на вопрос: согласован ли слой N+1 со слоем N для нужного батча?
|
||
Сверка находит потерянные или лишние строки на границе загрузки.
|
||
|
||
Реальные примеры используют разные способы сверки:
|
||
|
||
- [`sql/ods/airports_dq.sql`](../../sql/ods/airports_dq.sql) сравнивает множества
|
||
`airport_code`: ищет пропущенные и лишние ключи относительно текущего STG-батча.
|
||
Это сверка ключей, а не простое сравнение числа строк.
|
||
- [`sql/stg/airplanes_dq.sql`](../../sql/stg/airplanes_dq.sql) сравнивает число
|
||
строк во внешней `stg.airplanes_ext` и в текущем батче `stg.airplanes`.
|
||
- [`sql/dds/fact_flight_sales_dq.sql`](../../sql/dds/fact_flight_sales_dq.sql)
|
||
требует равенства числа строк факта и `ods.segments`, потому что зерно факта —
|
||
один сегмент билета.
|
||
|
||
## `NULL` — не всегда ошибка
|
||
|
||
В [`fact_flight_sales_load.sql`](../../sql/dds/fact_flight_sales_load.sql)
|
||
измерения присоединяются через `LEFT JOIN`. Факт может прийти раньше измерения,
|
||
поэтому `route_sk`, `airplane_sk` или `passenger_sk` временно бывают `NULL`. На
|
||
ветке `main` это также ожидаемо, пока студент не реализовал эти измерения. Такой
|
||
`NULL` сохраняет строку факта и не должен сам по себе останавливать пайплайн.
|
||
|
||
`seat_no` тоже может быть `NULL`: у билета уже есть сегмент, но записи
|
||
`boarding_passes` ещё нет. Обязательный ключ, напротив, должен быть заполнен.
|
||
Например, `NULL` в `airport_sk` измерения или в `(ticket_no, flight_id)` факта
|
||
нарушает контракт таблицы.
|
||
|
||
Архитектурное решение о том, где живут DQ-проверки, зафиксировано в разделе
|
||
[«Ключевые договорённости»](../design/db_schema.md#ключевые-договорённости).
|