Вы открыли таблицу с результатами опроса. В столбце «Группа» кто-то написал « a », «B», « b», «A». В столбце «Часы» стоят 2, –99, 0 и 70. Нужно привести записи к единому виду — и не потерять исходник. Если просто исправить всё в Excel, через месяц уже не вспомнить, какое значение было до правки и почему вы так решили. Чтобы работа была прозрачной, ведут журнал очистки — по одной записи на каждую изменённую или сомнительную ячейку.

На конкретном примере разберём, как построить такой журнал. Вы получите готовый шаблон и увидите, чем журнал решений отличается от автоматической истории инструмента (например, OpenRefine).

Все данные — полностью вымышленные. Никакого настоящего исследования за ними нет. Пример нужен, чтобы показать саму механику учёта.

Что должно быть в журнале очистки данных

Журнал — это таблица, в которой каждая строка описывает одно решение об изменении или пометке конкретной ячейки. Минимальный набор полей такой:

  • ID записи — уникальный номер строки в исходных данных;
  • Поле — название столбца, в котором находится ячейка;
  • Было — исходное значение до любых правок;
  • Стало — значение после обработки;
  • Действие — что именно вы сделали: заменили, очистили, пометили на проверку и т.д.;
  • Основание — на каком правиле вы приняли это решение.

Если значение не изменяется, а только помечается флагом (например, «нужно уточнить»), в колонке «Стало» остаётся исходное число, а в «Действии» пишется «помечено».

Пошаговый пример с учебным файлом

Представим, что с сервера скачан CSV-файл с именем raw.csv. В нём четыре строки. Вот его содержимое:

IDgrouphours
P01" a "2
P02"B"-99
P03" b"0
P04"A"70
Учебный журнал:3изменённыеячейки и однонеизменённоезначение70сфлагомreview.4исходныестрокисохранены.
Авторская учебная схема, не интерфейс OpenRefine. Данные и правила набора вымышлены. Код −99 означает пропуск только в этом примере; 70 сохранено для уточнения.

Я намеренно показал значения group в кавычках, чтобы были видны пробелы. В CSV кавычки могут отсутствовать — важно понимать, что строки « a » и « b» начинаются или заканчиваются пробелом.

Правила обработки для этого учебного набора:

  • метки групп записываются латинскими прописными буквами без краевых пробелов (допустимы только A и B);
  • hours означает часы учёбы за сутки, допустимый диапазон — от 0 до 24;
  • код –99 по той кодировочной книге, которая прилагается к этому гипотетическому набору, означает пропуск (missing).

После применения правил должна получиться рабочая таблица working.csv. Вот она:

IDgrouphoursstatus
P01A2ok
P02Bпустоmissing
P03B0ok
P04A70review

Теперь разберём каждую запись отдельно.

Журнал решений: 4 записи

В этом примере журнал содержит четыре записи: для каждого ID есть ровно одно изменение или отметка. Если в одной строке принимаются решения по нескольким ячейкам, выбранный формат журнала потребует отдельных записей с тем же ID.

IDПолеБылоСталоДействиеОснование
P01group" a "AзаменаУдалены краевые пробелы, значение приведено к прописной латинской A — метка группы.
P02hours-99пустоочищеноКод -99 интерпретируется как пропуск по кодировочной книге набора.
P03group" b"BзаменаУдалён начальный пробел, значение приведено к прописной латинской B — метка группы.
P04hours7070помечено (review)Значение 70 выходит за допустимый диапазон 0–24. Автоматическая замена на 7 или обнуление не допускается. До уточнения источника оставлено без изменения.

Проверим контрольные числа:

  • исходных строк — 4, рабочих строк — 4;
  • уникальных ID — 4 (P01, P02, P03, P04);
  • изменённых ячеек — 3: P01.group, P02.hours, P03.group;
  • ячеек, помеченных без изменения, — 1: P04.hours;
  • из 4 значений hours два допустимых (2 и 0), один пропуск (–99 → пусто), одно неопределённое (70, «review»).

Обратите внимание: ноль у P03 — это конкретное значение «0 часов учёбы за сутки», а не пропуск. Журнал это нигде не путает. В этом учебном примере значение 70 до уточнения не используют как допустимое число часов; исходная запись при этом сохраняется.

А что насчёт истории OpenRefine?

OpenRefine сохраняет историю изменений вместе с проектом: выход из программы сам по себе её не стирает. Вкладка Undo/Redo показывает последовательность действий. Это помогает проследить обработку данных.

Обычный экспорт CSV или TSV и архив проекта — разные результаты. Многие варианты экспорта данных учитывают текущие фильтры и фасеты. Полный архив проекта сохраняет данные и историю; его можно импортировать в другую установку OpenRefine. Экспорт CSV не удаляет историю из сохранённого проекта, но сам файл CSV её не содержит.

Не все действия можно извлечь как операции для повторного применения. В частности, документация приводит правку отдельной ячейки как действие, которое нельзя извлечь для такого повторения. Это не означает невозможность повторить правку вручную.

Архив проекта может содержать конфиденциальные данные из предыдущих шагов. Перед передачей проверьте его состав и допустимость раскрытия. Для нашего учебного набора журнал отдельно фиксирует основание замены, правило кодирования и причину отметки review. Так читатель увидит не только действие, но и решение автора.

Как это использовать в реальной работе

  1. Сохраняйте исходный файл. Назовите его raw.csv и не трогайте. Любая правка — в копии.
  2. Заведите журнал. Подойдёт такая же таблица, как в примере выше. Можно вести её в отдельном CSV или в Google Sheets.
  3. Перед любой правкой записывайте ID, поле, значение «было» и основание. Потом вносите изменение.
  4. Если значение не меняется (как 70), всё равно запишите его в журнал: «было = 70, стало = 70, действие = помечено, основание = выходит за диапазон, источник не уточнён».
  5. Сверьте число строк, уникальные ID и сами идентификаторы до и после обработки. В нашем примере исключение строк не предусмотрено: их должно остаться четыре. Если результат отличается, выясните причину и отдельно зафиксируйте обоснованные исключения, если они есть.
  6. Не поддавайтесь соблазну «исправить» непонятное число. 70 не обязательно опечатка. Возможно, это часы за несколько дней, или формат данных другой. Пока нет основания, значение остаётся как есть, а в журнале — флаг review.

Для глубокого понимания того, как описывать переменные до начала анализа, рекомендую прочитать статью о кодировочной книге анкеты — там показано, как заранее задать допустимые коды и избежать путаницы с пропусками.

Если нужна помощь с подготовкой данных к расчёту, можно обсудить статистический анализ исследования. Заранее согласуйте исследовательский вопрос, состав материалов и объём консультации.

Границы метода

  • Выберите формат журнала, который смогут прочитать участники проекта. Согласованность исходной таблицы, рабочей версии и журнала можно сверять вручную или настроить отдельную автоматическую проверку.
  • В разных вузах могут быть свои правила документирования первичных данных — уточните на кафедре.
  • Архив OpenRefine не защищает данные от просмотра. Не передавайте его без проверки состава.
  • Выберите понятное место для оснований решений: журнал, протокол или комментарии к коду. В нашем примере использован отдельный журнал; важно связать пояснение с конкретной ячейкой.

Построчный журнал очистки не гарантирует, что данные станут безупречными, но он даёт возможность в любой момент вернуться к исходной строке, увидеть, что именно было сделано, и объяснить это другому исследователю или проверяющему. В рассмотренном примере 4 строки, 3 изменённые ячейки, 1 отметка «review» — и на каждое решение есть основание.

Источники

Фото: Pexels / Pixabay