Доводка стилистики документации

docs/internal/bookings_stg_design.md

@@ -8,6 +8,10 @@ _Внутренний документ для учебного стенда. П
 - Цель: показываем путь данных от операционной БД до сырого слоя DWH в Greenplum.
 - В этом документе описываем только часть `src (bookings-db) → STG (Greenplum)`. Слои ODS/DDS/DM студент проектирует сам по статье про моделирование DWH.
 
+Примечание: в текущей версии стенда слой `stg` содержит не только `bookings`, но и остальные таблицы потока
+(`tickets`, `airports`, `airplanes`, `routes`, `seats`, `flights`, `segments`, `boarding_passes`).
+Ниже логика разобрана на примере `bookings`, потому что на нём проще показать принципы инкремента и батчей.
+
 Логика на уровне слоёв (по статье):
 
 - `src`: оперативная система (`bookings-db`, схема `bookings`).
@@ -20,8 +24,8 @@ _Внутренний документ для учебного стенда. П
 
 - Используем одну схему `stg` в Greenplum.
 - В этой схеме будут:
-  - внешняя таблица PXF для чтения из `bookings-db`;
-  - внутренняя таблица STG для долговременного хранения «сырых» данных.
+  - внешние таблицы PXF `*_ext` для чтения из `bookings-db`;
+  - внутренние таблицы STG `stg.*` для долговременного хранения «сырых» данных.
 
 ### 2.2. Внешняя таблица (PXF)
 
@@ -31,6 +35,8 @@ _Внутренний документ для учебного стенда. П
   - можем использовать «родные» типы из `bookings.bookings` (включая даты/числа);
   - задача внешней таблицы — корректно читать данные из источника, не заниматься приведением типов.
 
+В текущей реализации аналогично созданы внешние таблицы `*_ext` и для остальных сущностей (см. `sql/stg/*_ddl.sql`).
+
 DDL будет добавлен в `sql/ddl_gp.sql` в блоке DDL для Greenplum (примерно по шаблону из `docs/internal/pxf_bookings.md`), с `LOCATION ('pxf://bookings.bookings?PROFILE=JDBC&SERVER=bookings-db')`.
 
 ### 2.3. Внутренняя таблица STG
@@ -46,7 +52,7 @@ DDL будет добавлен в `sql/ddl_gp.sql` в блоке DDL для Gre
 
 - `src_created_at_ts TIMESTAMP` — дата/время из источника, приведённая к TIMESTAMP:
   - используется как опорная колонка для инкрементальной загрузки;
-  - заполняется из исходной даты/времени (`created_at` или аналог).
+  - заполняется из опорной даты/времени, принятой для конкретной сущности (например, для `bookings` — из `book_date`).
 - `load_dttm TIMESTAMP NOT NULL DEFAULT now()` — когда запись была загружена в STG.
 - `batch_id TEXT NOT NULL` — идентификатор «пачки» (например, `{{ ds_nodash }}` или `run_id` Airflow).
 - при необходимости позже можно добавить `src_system TEXT`, если появятся другие источники.
@@ -59,8 +65,8 @@ DDL будет добавлен в `sql/ddl_gp.sql` в блоке DDL для Gre
 
 - Опорная колонка: `src_created_at_ts` (внутреннее имя в STG).
 - Источник значения:
-  - берём из соответствующей колонки в `bookings.bookings` (например, `book_date`/`created_at` — будет уточнено при реализации);
-  - при чтении через `stg.bookings_ext` приводим к `TIMESTAMP`.
+  - для `bookings` используем `book_date` из `bookings.bookings` (в демо‑БД это поле естественно “шагает” по дням);
+  - при чтении через `stg.bookings_ext` приводим к `TIMESTAMP` и сохраняем в `stg.bookings.src_created_at_ts`.
 
 ### 3.2. Правила определения full/delta
 
@@ -79,8 +85,8 @@ DDL будет добавлен в `sql/ddl_gp.sql` в блоке DDL для Gre
 - `dag_id`: `bookings_stg_ddl` (реализован в `airflow/dags/bookings_stg_ddl.py`).
 - Назначение: один раз (или при изменении схемы) создать необходимые объекты в Greenplum:
   - схему `stg` (если её ещё нет);
-  - внешнюю таблицу `stg.bookings_ext` (PXF → `bookings-db`);
-  - внутреннюю таблицу `stg.bookings` с текстовыми колонками и тех.полями.
+  - внешние таблицы `*_ext` и внутренние таблицы слоя `stg` для всех сущностей потока
+    (см. `sql/stg/*_ddl.sql`).
 - Этот DAG не загружает данные, только подготавливает структуру.
 - Вся DDL‑логика (CREATE/ALTER/DROP) сосредоточена здесь; рабочие DAG’и занимаются только DML (INSERT/SELECT).
 
@@ -115,7 +121,8 @@ DDL будет добавлен в `sql/ddl_gp.sql` в блоке DDL для Gre
      - количество строк в `stg.bookings_ext` с `book_date` позже «старого» максимума,
      - количество строк в `stg.bookings` для текущего `batch_id`;
    - при расхождении выполняет `RAISE EXCEPTION` с понятным текстом ошибки.
-4. `finish_summary`
+4. Далее — загрузка и DQ для остальных таблиц потока (tickets, справочники, транзакции).
+5. `finish_summary`
    - PythonOperator, который логирует итог выполнения DAG и напоминает, где смотреть детальные логи.
 
 Таким образом, вся бизнес‑логика инкремента и проверок живёт в SQL‑скриптах, а DAG отвечает за оркестрацию и подключение к нужным БД. Для менти это хороший пример разделения ответственности между SQL и Python.