docs(labs): упрощен язык учебных заданий

- Зачем: начинающим трудно читать задания из-за необъясненных терминов и неестественных формулировок.
- Что: переработаны вводная и 21 задание, названы темы разделов, объяснены термины и сокращены повторы; согласованы правила учебного текста и ссылки.
- Проверка: сохранены 25 блоков SQL и команд и таблицы состава колонок; проверены 153 локальные ссылки и 32 входящие ссылки на разделы; git diff --check прошел.

docs/labs/optional/missing-purchases.md

@@ -1,21 +1,24 @@
 # Куда пропали покупки
 
-**Чему учит:** проверить полноту данных по независимому источнику и выбрать
-источник для витрины заказов.
+Вы сравните покупки из событий сайта с заказами магазина. Найденные
+расхождения помогут выбрать источник для полной витрины заказов.
 
 Факультатив доступен после ступени 1. В DBeaver подключитесь пользователем
 `analyst` по [инструкции](../../../README.md#подключиться-из-dbeaver).
 Дождитесь завершения `etl_pipeline`; на время расследования оставьте
 `world_live` на паузе и дождитесь уже начатых прогонов.
 
-## Выберите день
+## Выбор дня
 
 Можно ли построить полную витрину заказов по событиям `purchase`?
 Проверьте это на одном дне: сначала сопоставьте события сайта, затем сверьте
 номера заказов с выгрузкой магазина.
 
-Возьмите день, для которого уже получен последний слепок семидневного окна.
-Запрос показывает самую позднюю подходящую дату:
+Слепок заказов содержит их состояние на конец модельного дня. Состояние
+заказа может меняться семь дней, поэтому для окончательного сравнения нужны
+все слепки за этот период. Возьмите день, для которого уже получен последний
+из них. Такой день называется закрытым. Запрос показывает самую позднюю
+подходящую дату:
 
 ```sql
 SELECT max(snapshot_date) - 6 AS last_closed_day
@@ -27,7 +30,7 @@ FROM ods.order_v;
 Сравнивайте все заказы дня, включая отмененные: сейчас вопрос в том,
 зарегистрировал ли магазин заказ, а не в том, был ли он оплачен.
 
-## Найдите разрыв в событиях
+## События оформления заказа
 
 При оформлении заказа посетитель видит страницу подтверждения, а трекер
 отправляет событие покупки. Просмотр страницы и покупка — отдельные события.
@@ -42,7 +45,7 @@ FROM ods.order_v;
 заказа пришло ровно по одному событию каждого вида? Что можно предположить
 по вашему результату и чего эти два числа еще не доказывают?
 
-## Сверьте с магазином
+## Сверка с заказами магазина
 
 В событии номер заказа находится в `purchase_id[1]`, в заказах — в `order_id`.
 Соберите список заказов выбранного дня, для которых нет события покупки.
@@ -72,7 +75,7 @@ FROM ods.order_v;
 
 Если в выбранном дне повторов нет, возьмите другой закрытый день.
 
-## Сопоставьте вывод с готовой сверкой
+## Сравнение с готовой витриной
 
 Найдите свои заказы без события в `dm.purchase_vs_orders_v` по `order_id`.
 Сравните их `status` и `mismatch_class`. Витрина присваивает заказу один класс,
@@ -83,7 +86,7 @@ FROM ods.order_v;
 Возьмите один заказ из своего списка и сохраните два запроса: первый находит
 его в магазине, второй показывает отсутствие покупки в трекере.
 
-## Выберите источник и условие проверки
+## Выбор источника для витрины
 
 По результатам сверки укажите источник для витрины, в которой должен быть
 каждый зарегистрированный заказ. Обоснуйте выбор найденными номерами.
@@ -93,7 +96,7 @@ FROM ods.order_v;
 Позволяет ли отсутствие события в `dds.event_v` установить место потери —
 до приема в хранилище или при обработке? Какие данные нужны, чтобы это выяснить?
 
-## Что должно получиться
+## Результат работы
 
 - [ ] сохранен запрос сверки по дате, возвращающий заказы без события;
 - [ ] оба равенства сходятся, влияние повторного просмотра объяснено;