Заказ может содержать адрес и список товаров, а не только отдельные значения. Объясняем вложенность JSON, выбор строки отчёта и риск повторного подсчёта.
Заказ — это больше, чем набор ячеек
В привычной таблице хочется видеть одну строку на заказ: номер, дату, покупателя и сумму. Но у заказа есть ещё адрес доставки и несколько товаров. Адрес состоит из частей, а количество товаров в разных заказах неодинаково. Такую запись не всегда удобно представить одной строкой с заранее фиксированным числом простых ячеек.
JSON — текстовый формат передачи структурированных данных. Он может описывать и отдельные значения, и более сложное устройство записи. Поэтому полученный файл не обязан сразу выглядеть как готовая таблица для отчёта. Для понимания вложенности не нужно изучать синтаксис: достаточно разобраться, что находится внутри одной бизнес-записи и какие отношения между частями важно сохранить.
Объект внутри объекта и список внутри заказа
Согласно RFC 8259, объект JSON объединяет названия и соответствующие им значения. Значением может быть и другой объект. В нашем условном заказе адрес можно представить отдельной группой: город, улица и дом. Эта группа находится внутри записи заказа — отсюда слово «вложенный».
Массив — упорядоченный список значений. Список товаров в заказе может содержать несколько объектов, каждый со своим названием и количеством. Порядок свойств объекта не стоит путать с порядком элементов списка: стандарт описывает эти структуры по-разному. При этом порядок товаров в сообщении ещё не означает их важность для бизнеса. Такой смысл должен быть задан отдельной договорённостью.
Сначала решить, что означает строка
Перед подготовкой отчёта задайте вопрос: одна строка будет описывать заказ или отдельную товарную позицию? Это решение задаёт смысл подсчётов. Если человеку нужен список заказов, товары можно предварительно свести к нужным показателям. Если нужен анализ товаров, каждую позицию удобнее рассматривать отдельно, сохраняя её связь с заказом.
Это два разных представления одних исходных сведений, а не две конкурирующие версии факта. В первом случае строка отвечает на вопрос об оформленной покупке. Во втором — о входящих в неё позициях. Ошибка начинается, когда после изменения устройства таблицы человек продолжает считать строки так, будто их смысл остался прежним.
Условный пример, где итог удваивается
Допустим, один вымышленный заказ на 900 рублей содержит две товарные позиции. После переноса каждой позиции в отдельную строку рядом с обеими оставили общую сумму заказа. Если теперь сложить этот столбец, получится 1800 рублей: 900 рублей учтены дважды. Реальная сумма заказа в примере не изменилась.
Поэтому после разворачивания списка полезно отдельно проверить число заказов, число позиций и смысл денежных показателей. Общая сумма заказа и стоимость одной позиции относятся к разным уровням. Это авторский пример ошибки подсчёта, а не сообщение о дефекте формата JSON. Формат сохранил связь частей; потерять её можно при неудачном преобразовании для отчёта.
Почему не всегда нужно делать плоскую таблицу
Некоторые аналитические системы поддерживают вложенные и повторяющиеся данные непосредственно. Например, документация BigQuery описывает вложенные записи и повторяющиеся поля. Поэтому требование «любую вложенность обязательно разнести по отдельным таблицам» не является универсальным.
Выбор зависит от инструмента и вопросов читателя. Для небольшого отчёта может подойти заранее подготовленное плоское представление. В другой системе удобнее сохранить вложенность и обращаться к нужным частям при анализе. В обоих случаях нужно понимать связь между родительской записью и её элементами. Поддержка формата сама по себе не выбирает правильный уровень итогового показателя.
Проверки для пустых и неодинаковых записей
Возьмите несколько условных примеров: заказ с одним товаром, с двумя товарами и с пустым списком. Заранее объясните, должен ли последний заказ оставаться в выбранном отчёте. Затем проверьте запись с неполным адресом. Отсутствующее поле, явно указанное пустое значение и пустой список могут означать разное; значение нужно уточнять у владельца источника.
Для обсуждения с инженером достаточно короткого описания: что означает одна исходная запись, какие группы вложены, где находятся списки и что должна означать строка результата. Дополните его контрольными итогами по нескольким вымышленным записям. Такая подготовка помогает заметить потерю связи или повторный подсчёт раньше, чем большой отчёт начнёт выглядеть убедительно. Сам по себе аккуратный вид таблицы ещё не подтверждает правильность её смысла.
Следующий шаг
Курс «Data Engineer для начинающих» поможет познакомиться с задачами подготовки данных. Полезный навык на старте — объяснять, какие связи между исходными сведениями должны сохраниться после преобразования.
