docs: согласованы руководства загрузок и учебный маршрут

Руководства STG/ODS/DDS/DM сверены с действующими SQL и DAG,
ожидания учебных заглушек связаны с ТЗ. Самопроверка заданий
отделена от проверок разработки и исторических планов.

Для dim_routes закреплено обновление описательных полей только
у открытых версий. SQL, DAG, DDL и настройки стенда не менялись.

Проверки: make lint; make test (4 passed, 14 skipped); карта;
292 локальные ссылки; маршрут чтения и карта в Chromium.
Живой ETL не запускался.

docs/dag_execution_order.md

@@ -1,35 +1,56 @@
-# Порядок запуска DAG (Cross-DAG Dependencies)
+# Порядок запуска DAG
 
-В этом стенде пайплайны разделены на несколько DAG-ов по слоям DWH (STG, ODS, DDS, DM). 
-Они настроены с `schedule=None`, так как это учебный проект.
+Все загрузочные DAG в стенде запускаются вручную (`schedule=None`).
+Завершение одного слоя не запускает следующий автоматически.
+Подготовка Docker и источника находится в [быстром старте](../README.md#быстрый-старт-основной-сценарий-bookings--stg--ods--dds--dm).
 
-Чтобы данные корректно прошли от источника до витрин, запускать DAG-и нужно в определённом порядке.
+## Создание таблиц
 
-## 1. DDL-скрипты (выполняются один раз)
+Перед первой загрузкой выполните по порядку:
 
-Для создания структуры таблиц в аналитических слоях:
-1. Запустите `bookings_stg_ddl` — создаст STG-таблицы и внешние `*_ext` через PXF.
-2. Запустите `bookings_ods_ddl` — создаст таблицы ODS (типизированные, SCD1).
-3. Запустите `bookings_dds_ddl` — создаст таблицы для измерений и фактов в слое DDS.
-4. Запустите `bookings_dm_ddl` — создаст таблицы витрин в слое DM.
+1. `bookings_stg_ddl` создает STG и внешние таблицы `*_ext` для чтения через PXF.
+2. `bookings_ods_ddl` создает типизированные таблицы ODS.
+3. `bookings_dds_ddl` создает измерения и факт DDS.
+4. `bookings_dm_ddl` создает витрины DM.
 
-*(Технический шорткат: `make ddl-gp` применяет DDL для всех 4 слоёв сразу).*
+Альтернатива четырем запускам: `make ddl-gp`.
+DDL создает структуру; для наполнения нужны отдельные загрузки.
+В заданиях таблицы и задачи уже подготовлены, поэтому перед каждым
+повторным запуском загрузки применять DDL не требуется.
 
-## 2. Ежедневная загрузка (ETL)
+## Проход данных по слоям
 
-Для прогрузки новой порции данных (или полного перерасчёта) соблюдайте следующую цепочку:
+Запускайте следующий DAG после успешного завершения всех задач предыдущего.
+Эта последовательность показывает зависимости загрузок; связи строк и зерно
+объектов смотрите на [карте](design/architecture-map.html), открытой
+[локально](design/db_schema.md#как-открыть-карту).
 
-1. **`bookings_to_gp_stage`** 
-   - Извлекает новые данные из демо-БД PostgreSQL и сохраняет их в `stg`-схему в Greenplum.
-   - Генерирует `stg_batch_id` для текущей загрузки.
-2. **`bookings_to_gp_ods`**
-   - Берёт последний согласованный `stg_batch_id` из STG-слоя.
-   - Выполняет нормализацию и SCD1-UPSERT в слой ODS.
-3. **`bookings_to_gp_dds`**
-   - Читает очищенные данные из ODS.
-   - Обновляет измерения (SCD1, SCD2) и инкрементально догружает новые рейсы в таблицу фактов `dds.fact_flight_sales`.
-4. **`bookings_to_gp_dm`**
-   - Читает новые факты из DDS.
-   - Обновляет агрегированные витрины (использует HWM-инкрементальность по `_load_ts` или полный перерасчёт).
+| Порядок | DAG и руководство | Что меняется в данных |
+|---|---|---|
+| 1 | [bookings_to_gp_stage](bookings_to_gp_stage.md) | Генератор добавляет учебный день в Bookings; STG получает инкременты транзакций и полные снимки справочников с `_load_id = run_id` STG |
+| 2 | [bookings_to_gp_ods](bookings_to_gp_ods.md) | Resolver выбирает общий STG-батч справочников; их снимки заменяются целиком. Транзакционные загрузки читают дельту STG по `_load_ts` и обновляют строки по бизнес-ключу |
+| 3 | [bookings_to_gp_dds](bookings_to_gp_dds.md) | Сначала выполняются загрузки измерений, затем факт: вставляются новые пары `(ticket_no, flight_id)`, у существующих обновляются цена, место и признак посадки |
+| 4 | [bookings_to_gp_dm](bookings_to_gp_dm.md) | `sales_report` пересчитывает полные агрегаты дат, затронутых изменениями факта; поведение остальных витрин задано в ТЗ |
 
-> **💡 Архитектурная заметка:** В реальном production-окружении (Airflow) эти связи между DAG-ами обычно настраиваются автоматически через `TriggerDagRunOperator`, `ExternalTaskSensor` или механизмы Data-Aware Scheduling (Datasets/Data Assets). В учебных целях мы оставили их ручными, чтобы вы могли проинспектировать каждый слой после его загрузки.
+На исходной `main` готовы весь STG, семь таблиц ODS, календарь, аэропорты,
+тарифы, факт и `sales_report`. Загрузки и DQ остальных объектов являются
+[заданиями](assignment/README.md). Успех этих задач с `SELECT 1;` оставляет
+таблицы пустыми. У факта до реализации измерений могут быть `NULL` в
+`passenger_sk`, `route_sk` и `airplane_sk`.
+
+## Повторный запуск и проверка задания
+
+Чтобы получить следующий учебный день, повторите цепочку STG → ODS → DDS → DM.
+Когда проверяете правку SQL своего слоя на уже загруженных источниках,
+начните с этого слоя; новый STG запустит генератор еще раз.
+Подробности выбора батча и повторного запуска находятся в руководстве слоя.
+
+После реализации измерений обычный повтор DDS не заполнит старые SK факта.
+Выполните [пересчет по ТЗ](assignment/analyst_spec.md#пересчёт-факта-после-реализации-измерений),
+затем обновите DM.
+
+Для самопроверки задания откройте
+[«Запуск и проверка»](assignment/README.md#запуск-и-проверка).
+`bookings_validate` запускайте отдельно от загрузок: дождитесь всего DAG
+и успешного `validate_dds.scd2_restore` перед следующей записью в хранилище.
+Тест SCD2 временно меняет данные и восстанавливает их из копии.