0 Fork 0

Files

T

ddadminandClaude Fable 5 4a04a2caf6 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>

2026-07-20 14:56:42 +03:00

4.5 KiB

Raw Blame History

Как читать пайплайн по скрипту загрузки

Большую схему не нужно запоминать. Связи любой таблицы уже записаны в блоке FROM ... JOIN ... её файла *_load.sql. Обычно каждая прочитанная таблица даёт одно входящее ребро. Если одна таблица читается под разными псевдонимами, как dim_airports, её можно показать одним узлом.

Метод

INNER JOIN показывает обязательную часть основного потока. Если входной строки нет, целевая строка не появится. LEFT JOIN к измерениям решает две задачи. Факт может прийти раньше измерения: это опаздывающее измерение (late-arriving dimension). Эталонный факт также не должен зависеть от того, успел ли студент реализовать свои измерения. Поэтому строка факта сохраняется, а её суррогатный ключ пока может быть NULL.

В этом CTE есть и другие LEFT JOIN. ods.routes даёт эталонный путь к аэропортам, а ods.boarding_passes содержит необязательные seat_no и признак посадки.

Если в загрузчике несколько SQL-операторов, смотрите на источник INSERT. Именно он задаёт полный список входящих связей для новых строк. Например, в fact_flight_sales_load.sql блок FROM у UPDATE читает только изменяемые поля, а полный список находится в CTE fact_src перед INSERT.

Пример: `fact_flight_sales`

Откройте sql/dds/fact_flight_sales_load.sql и пройдите fact_src сверху вниз:

FROM ods.segments задаёт зерно (ticket_no, flight_id) и поле price.
JOIN ods.tickets обязателен для book_ref и passenger_id.
JOIN ods.bookings обязателен для book_date.
JOIN ods.flights обязателен для расписания и route_no.
LEFT JOIN ods.routes находит аэропорты по route_no. Этот эталонный путь не зависит от студенческого dim_routes.
LEFT JOIN dds.dim_routes ищет point-in-time версию маршрута и route_sk.
LEFT JOIN dds.dim_calendar даёт calendar_sk по дате вылета.
Два LEFT JOIN dds.dim_airports дают ключи аэропортов вылета и прилёта. На схеме их можно показать одним узлом dim_airports.
LEFT JOIN dds.dim_airplanes даёт airplane_sk через найденную версию маршрута.
LEFT JOIN dds.dim_tariffs даёт tariff_sk.
LEFT JOIN dds.dim_passengers даёт passenger_sk.
LEFT JOIN ods.boarding_passes даёт seat_no и признак is_boarded.

Так список связей превращается в схему «Как собирается факт?»: четыре обязательных входа рисуются сплошными стрелками, а остальные пунктирными.

Как проверить свой слой

Выпишите все таблицы из FROM и JOIN своего *_load.sql.
Сравните список с эталонной схемой или дизайн-документом этого слоя.
Проверьте служебные и SCD-поля по naming_conventions.md.
Убедитесь, что рядом есть *_dq.sql и он покрывает нужные классы DQ-проверок.

Шаблон схемы одной таблицы

Скопируйте шаблон и замените имена таблиц и полей:

graph LR
    MAIN["schema.main_input"] -->|"grain, metric"| TARGET["schema.target"]
    LOOKUP["schema.lookup"] -.->|"lookup_key"| TARGET

4.5 KiB Raw Blame History Unescape Escape