Как находить пропуски, дубли и невозможные значения

Проверку таблицы начинают не с удаления пустых строк и не с автоматического «исправления» значений. Сначала записывают, для чего нужен набор, что обозначает одна строка и какие правила действуют для каждого критичного поля. После этого отдельно ищут пропуски, кандидаты в дубли, нарушения формата, диапазона, справочника и связей между полями.

Каждая находка сначала остаётся кандидатом на ошибку. Исходное значение сохраняют, основание проверки записывают в журнал, а изменение принимают только после подтверждения по независимому источнику или ясному правилу владельца данных. Автоматический флаг показывает несоответствие заданному условию, но сам по себе не доказывает, что запись неверна.

Сначала определить назначение и единицу наблюдения

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

В коротком паспорте набора стоит зафиксировать: какую задачу решает таблица, за какой период собраны данные, откуда они получены, что обозначает одна строка и какие поля должны различать наблюдения. Формулировка единицы наблюдения должна быть буквальной. Например: «одна строка — одна заявка», «одна строка — одно изменение статуса» или «одна строка — один объект на дату выгрузки».

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

Сохранить исходник и открыть проверочную копию

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

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

Составить словарь полей до подсчёта пропусков

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

Пустое поле не имеет одного универсального значения. Оно может означать ошибочно не заполненное обязательное значение, допустимое отсутствие, неприменимость к этой строке или факт, который пока неизвестен. Эти состояния нельзя бездумно объединять, потому что у них разные причины и разные последствия для расчётов.

Как различить виды отсутствия

• Обязательный пропуск. Поле должно быть заполнено для записи этого типа, но значения нет.
• Допустимое отсутствие. Значение не требуется по правилу процесса, хотя поле существует.
• Неприменимость. Сам вопрос не относится к данной строке, поэтому значение не должно появляться.
• Неизвестный факт. Значение применимо, но источник его не сообщил или оно ещё не установлено.

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

Разделить правила, чтобы не смешивать причины

Проверки лучше формулировать по одной причине на правило. Тогда видно, что именно сработало, и можно пересчитать результат после исправления. В одном условии не стоит одновременно проверять пустоту, формат и диапазон: иначе непонятно, какое несоответствие обнаружено.

• Полнота. Есть ли ожидаемая запись или значение там, где оно обязательно.
• Уникальность. Не повторяется ли одна и та же сущность в пределах заданной единицы наблюдения.
• Формат. Соответствует ли запись ожидаемой структуре, например типу даты или кода.
• Диапазон. Попадает ли значение в пределы, определённые предметной областью, единицами, периодом и назначением набора.
• Справочник. Входит ли код или категория в согласованный перечень для этой версии данных.
• Межполевые связи. Не противоречат ли друг другу значения одной строки.

Эти проверки описывают разные стороны качества. Полная таблица может содержать ошибочные значения. Уникальные строки могут неверно представлять реальные объекты. Формально допустимая дата может относиться не к тому событию. Поэтому успешное прохождение правил не доказывает точность или репрезентативность набора.

Проверить пропуски в контексте строк

Сначала считают пустые значения по каждому полю, но итоговый список нужно разложить по правилам применимости. Поле может быть обязательным только для определённого типа записи. Если смешать все строки, допустимое отсутствие будет выглядеть как дефект.

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

Отдельно проверяют необычные обозначения отсутствия: пробелы, служебные слова, повторяющиеся знаки или значения, которые выглядят как обычные данные. Их нельзя автоматически превращать в пустоту, пока не установлено, что именно так источник кодировал отсутствие.

Искать точные дубли отдельно от похожих записей

Точный дубль — это совпадение выбранного набора полей, значимых для единицы наблюдения. Сначала нужно явно назвать эти поля. Полное совпадение всех видимых столбцов удобно как технический сигнал, но даже оно не всегда доказывает ошибочное повторение: две операции могут законно иметь одинаковые атрибуты.

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

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

Проверять невозможные значения несколькими классами правил

Невозможное значение — это не просто «необычная цифра». Сначала проверяют форму записи, затем допустимый диапазон, затем справочник и только после этого связи с другими полями. Такой порядок помогает не спутать ошибку разбора с содержательным противоречием.

Формат

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

Диапазон

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

Справочник

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

Связи между полями

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

Создать список кандидатов и журнал решений

Результат автоматической проверки — не очищенная таблица, а перечень кандидатов. Для каждой находки журнал должен сохранять идентификатор строки, поле, исходное значение, сработавшее правило, дату проверки, доступное подтверждение, принятое решение и новое значение, если оно появилось.

Решения удобно разделять на подтверждённую ошибку, допустимый случай, нерешённую находку и ошибку самого правила. Такое разделение показывает, почему часть флагов остаётся после проверки. Оно также помогает искать первопричину: повторяется ли проблема из-за одного этапа ввода, одного источника или разовой ситуации.

Четыре этапа одной находки

В журнале не следует объединять наблюдаемый флаг, подтверждение, решение владельца данных и повторную проверку в одно поле «исправлено». У каждого этапа свой вопрос и собственное основание.

• Наблюдаемый флаг. Записывает только то, что конкретная строка или ячейка не прошла конкретное правило. На этом этапе не делают вывода о причине и не меняют исходное значение.
• Подтверждение. Показывает, найдено ли независимое основание считать случай ошибкой, допустимым исключением или нерешённой находкой. Само повторение автоматического сигнала подтверждением не становится.
• Решение владельца данных. Отдельно фиксирует, какое действие принято: оставить запись, исправить значение, объединить кандидатов или сохранить вопрос открытым. Техническая проверка не подменяет это решение.
• Повторная проверка. После изменения заново применяет исходное правило и связанные с ним проверки, чтобы увидеть результат и не скрыть новое противоречие.

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

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

Исправлять только по проверяемому основанию

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

Особой осторожности требуют регистр, даты, разделители, коды и обозначения отсутствия. То, что выглядит как косметическое выравнивание, может объединить разные категории, изменить дату или убрать значимую часть идентификатора. Перед массовой заменой нужно просмотреть кандидатов и проверить обратимость преобразования.

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

Пересчитать проверки и определить критерий остановки

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

Работу можно остановить, когда все критичные правила выполнены повторно, каждое принятое изменение имеет основание и запись в журнале, а оставшиеся кандидаты классифицированы. Нулевое число флагов не является обязательной целью: допустимые исключения и нерешённые случаи могут сохраниться. Критерий остановки — не «таблица стала чистой», а «по текущим правилам больше нет неподтверждённых изменений, которые можно обоснованно внести».

Короткая последовательность аудита

1. Записать назначение набора, период и единицу наблюдения.
2. Сохранить неизменяемый исходник и создать проверочную копию.
3. Составить словарь критичных полей, включая правила отсутствия.
4. Сформулировать отдельные проверки полноты, дублей, формата, диапазона, справочника и связей.
5. Получить списки кандидатов без автоматического удаления и слияния.
6. Проверить кандидатов по независимому основанию или решению владельца данных.
7. Протоколировать исходное значение, решение и исправление.
8. Повторно выполнить проверки и описать оставшиеся ограничения.

Что сообщить вместе с результатом

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

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