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

Проверка данных критически необходима, если вы и ваша аудитория хотите быть уверенными в своих выводах. Основной подход достаточно прост: у вас есть поля с данными, и каждое из этих полей имеет ожидаемые значения. Например, возраст должен быть от 0 до 120 лет (а чаще всего, до 80 лет). Даты транзакций должны относиться к недавнему прошлому, чаще всего одного-двух лет, особенно если вы имеете дело только с онлайн-ресурсом данных, как, например, лента Твиттера. Несмотря на свою простоту и важность, проверка данных − довольно сложная задача, поскольку существует множество разных ошибок в данных, или у нас могут быть правильные данные, но в неподходящем для нас формате.

Когда делать проверку

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

• Поле ТипНомераТелефона объединяет коды и текст;
• В поле возраста 0 имеет значение «неизвестно», что не очень хорошо для вычисления среднего значения, а 112 вряд ли является настоящим возрастом.

Основное правило проверки данных − проверять как можно раньше и как можно чаще. Проверяя на начальном этапе, когда данные только введены, вы можете немедленно их исправить. Например, если поле «Новый клиент» предполагает ответы ДА или НЕТ, а пользователь вводит что-то другое, например А или пробел, то можно попросить самого пользователя исправить данные. Если на этом этапе не была осуществлена проверка, то эти неверные значения попадут в базу данных; вы будете знать, что они неправильные, но ничего не сможете исправить, не обратившись к пользователю за информацией. Иногда можно сравнить некорректно заполненные поля с другими связанными базами данных и использовать эту информацию, чтобы исправить оригинальные данные. Это может быть сложно и может привести к дальнейшим проблемам, поскольку придется решать, какой источник данных правильный.

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

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

Таким образом, ваша система будет вынуждена пропускать на этапе ввода только качественные данные. Хотя этот подход не идеален. Классический пример – система, вынуждающая вас ждать подтверждения вводимых вами данных до момента отправки формы и затем сообщающая, что в самом начале формы была ошибка. Вариант получше − проверять каждое поле при вводе, но и этот подход имеет свои слабые стороны, поскольку создать такой сайт может быть сложнее, кроме того, проверка каждого поля может вылиться в непрерывный поток проверочных запросов, отсылаемых серверу, и потенциальных сообщений об ошибке, возвращаемых пользователю. В качестве компромисса, кое-какая простая проверка и валидация может выполняться браузером, в то время как более сложная работа останется для обработки сервером. Это может быть необходимо, так как для некоторых проверок будут требоваться данные или процессы, доступные только на самом сервере. Такое часто происходит при проверке значений, с защищенным доступом, например, при верификации кредитных карт.

Другие методы планирования отчетов с целью минимизации времени на подготовку данных предлагают:

• Заранее решить, в каком виде вы хотите вводить имена. Могут ли люди добавлять после своих имен всякие сокращения типа Jr (младший), DVM (доктор ветеринарной медицины), PhD (доктор наук), CPA (дипломированный бухгалтер) или их необходимо хранить отдельно от самих имен? И хотите ли вы, чтобы профессиональные обозначения находились отдельно от окончаний наподобие Jr (младший), II, III? Должны ли имя и фамилия находиться в разных полях?
• Настроить формы так, чтобы телефонные номера и даты можно было вводить только в том формате, в котором вы хотите сохранить их в базе данных (больше о датах читайте ниже). Решить, хотите ли вы собирать внутренние офисные номера. Если да, задайте для них отдельное поле.

Никому не доверяйте

Независимо от того, насколько хорошо вы разработали форму и сколько проверок установили для входящих данных, золотое правило − никогда не доверяйте пользовательским данным. Если их вводил человек, где-нибудь обязательно будет ошибка. Даже если есть внешние клиентские проверки, всегда должны быть и внутренние или серверные проверки − они выполняются уже после того, как данные были введены и сохранены. Этому есть много уважительных причин. Возможно, разрабатывали инструменты для сбора данных не вы, и тогда у вас могут быть различные внешние приложения, поставляющие вам данные. Какие-то из них прекрасно справляются с внешними клиентскими проверками, другие − нет. Неочищенные или непроверенные данные могут поступать в вашу систему из-за интегрирования данных из разных сервисов или приложений. У базы данных телефонных номеров из нашего примера было слишком много владельцев и мало контроля, что привело к неряшливому набору данных. Немного дополнительных усилий, приложенных в начале проекта, сохранили бы время и нервы, обеспечив нас чистыми данными.

Второе золотое правило − использовать текстовые поля только там, где это необходимо. Например, в некоторых странах адреса обычно собираются в несколько полей − Строка1, Строка2, Город, Штат, Страна, Индекс. Но в Великобритании очень часто просят только индекс и номер дома, поскольку по этим двум фрагментам информации можно узнать точный адрес. В этом случае индекс проверяется и подтверждается автоматически, и адресные данные получаются чистыми, поскольку вводятся не пользователем. В других странах мы вынуждены использовать текстовые поля, и в этом случае данные нужно тщательно проверять.

Запятые в данных могут вызвать целый ряд проблем, поскольку многие файлы данных имеют формат CSV (Comma-Separated Values — значения, разделённые запятыми). Дополнительная запятая создает непредвиденное дополнительное поле, и каждое последующее поле будет сдвинуто вправо. По этой причине не стоит вырезать/вставлять данные из приложения; лучше сохранить их в файл и открыть в другом приложении.

Дополнительная запятая во второй записи сдвинула данные вправо. Человек легко заметит такую проблему, но большинству автоматизированных систем она доставит хлопоты. Легкий способ проверить – посмотреть, есть ли дополнительные данные после последнего поля (“Страна”). Этот пример подчеркивает важность совмещения компьютеризированных и ручных подходов к проверке данных. Иногда быстрое визуальное сканирование данных может определить результат!

Форматы данных и проверка

Когда вы имеете дело с числами, приходится проверять много моментов. Понятны ли числа? Если вы работаете с деньгами, действительно ли цена составляет $1,000,000 или же кто-то ввел неверное значение? Аналогично, если цена − ноль или отрицательное число, значит ли это, что продукт был отдан бесплатно или кому-то доплатили, чтобы избавиться от него? В бухгалтерском учете многие источники данных должны учитывать отрицательные цены, чтобы правильно вывести сальдо.

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

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

Даты также представляют нам широкий ряд задач по проверке. Прежде всего, это проблема различий международного формата дат. Если вы видите дату 1/12/2013 – это 12 января 2013 года в Америке, но в Великобритании это − 1 декабря. Если вам повезет, вы получите данные в международном формате по типу 2014-01-12. В качестве бонуса, даты в этом стандартизированном формате (http://whatis.techtarget.com/definition/ISO-date-format) можно сортировать, даже если они сохранены как текст. Однако, вам может и не повезти, поэтому важно проверить и убедиться, что вы понимаете, как читать даты, особенно если получаете данные от респондентов из разных стран с разными форматами дат. Если вы разрабатываете форму ввода данных, то хорошим решением будет создание раздела даты в виде кнопки с календарем, где пользователь выбирает дату в календаре, а не вводит ее вручную. Или же вы можете указать формат рядом с ячейкой ввода в качестве инструкции для пользователя.

Еще одна задача при проверке − анализ и оценка правильности работы других людей с целью убедиться, что визуализации и числа действительно имеют смысл. Это может происходить в рабочей ситуации, когда вам необходимо проверить чужую работу, или онлайн, где публичные визуализации иногда предлагают исходные данные, которые вы можете попробовать проанализировать сами. В обоих случаях, первое, что нужно сделать, чтобы проверить, − пересчитать итоговые цифры. После этого взгляните на визуализацию критически: имеют ли цифры смысл, подтверждают ли они текст или противоречат ему? Проверка не должна быть направлена только на поиск ошибок. Она также нужна для понимания. Это даст вам хороший опыт, когда вы перейдете к проверке ваших собственных данных, и будет первым вашим действием, когда кто-то сдаст вам отчет.

Версии данных

Еще один большой источник проблем с проверкой данных − версия этих данных.

Поскольку приложения и системы меняются с годами, добавляются и убираются поля, и, что самое проблематичное, меняется их назначение. Например, австралийский почтовый индекс состоит из 4 цифр и хранится в поле на четыре знака. Некоторые системы были изменены и используют теперь более точный 5-значный идентификатор под названием SLA. Если объединить данные из этих систем, 5-значные значения обрежутся, чтобы уместиться в поле почтового индекса. Проверить поля на наличие таких изменений может быть довольно сложно, хоть таблицы соответствий почтовых индексов и SLA и есть в открытом доступе, потребуется дополнительное исследование, почему 4-значное число в поле местоположения не соответствует ни индексу, ни SLA.

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

Здесь вы видите эффект от добавления к существующему источнику данных двух новых полей − ИдСервера и ДатаСоздания. Похоже, что изменения были внесены 03/01/2013 (1 марта 2013 года), поэтому если ваш анализ охватывает только время после этой даты, вы можете отследить продажи/сервер. Однако более ранних данных в этом источнике нет, поэтому, если вы хотите увидеть, что происходило 1 января 2013 года, нужно где-то найти дополнительные данные.

Одна из самых важных проблем при проверке заключается в том, что назначения полей и значений в них могут со временем меняться. В идеальном мире каждое изменение было бы как следует задокументировано, и вы бы точно знали, что эти данные означают. Но реальность такова, что эти перемены редко документируют в полном объеме. Самый лучший способ узнать, что на самом деле представляют данные в поле – поговорить с администраторами и пользователями системы.

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