docs: лесенка схем, метод чтения пайплайна и таксономия DQ

Одна диаграмма отвечает на один вопрос: 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>

docs/reference/dq_taxonomy.md

@@ -0,0 +1,63 @@
+# Классы 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#ключевые-договорённости).

docs/reference/qa-plan.md

@@ -14,6 +14,7 @@
 >
 > Зависимость: перед запуском этого плана нужно починить bookings-db
 > (см. `docs/reference/bookings_db_issues.md`).
+> Классы проверок для разбора ошибок: [`dq_taxonomy.md`](dq_taxonomy.md).
 
 ---