Подобное дублирование данных случается чаще, чем вы думаете. Если вы не знаете, что в ваших данных встречается продублированная информация, это может повлиять на ваши показатели. Но хуже всего, что в какой-то момент времени это все равно обнаружится. А если качество данных будет поставлено под сомнение хотя бы однажды, это снизит доверие к выводам аналитиков, и эти выводы не будут учитываться в процессе принятия бизнес-решений.
При загрузке информации в базу данных часть ее может потеряться (Anderson → anders или 5456757865 → 54567578). В лучшем случае можно лишиться пары символов в форме обратной связи. В худшем может произойти усечение и объединение идентификационных данных двух разных клиентов и вы непреднамеренно объедините данные двух разных клиентов или заказов в один.
Как такое может произойти? В обычных реляционных базах данных при создании таблицы задаются название и тип каждого поля: например, должен быть столбец под названием «Фамилия» с ячейками, содержащими до 32 символов, или столбец «ID клиента» с целым числом в диапазоне от 0 до 65535. Проблема в том, что не всегда заранее известно максимальное количество символов или максимальное значение идентификатора, с которыми вам придется столкнуться. Возможно, вы получите образец данных, рассчитаете длину ячейки и для подстраховки увеличите это значение в два раза. Но вы никогда не узнаете наверняка, достаточно ли этого, пока не начнете работать с реальными данными. Более того, в базах ошибки с усечением данных, как правило, относятся к категории предупреждений: появляется оповещение, но процесс загрузки данных не прекращается. В результате такие проблемы легко не заметить. Один из способов предотвратить это — изменить настройки в базе данных, чтобы предупреждения отображались как полноценные ошибки и заметить их было легче.
Еще один источник проблем с качеством данных — несовпадение единиц измерения, особенно когда речь идет о международных командах и наборах данных. CNN сообщает[35]:
Агентство NASA потеряло орбитальный аппарат по исследованию Марса стоимостью 125 млн долл. из-за того, что команда технических специалистов корпорации Lockheed Martin использовала при расчетах английские единицы измерения [фунт-секунда], в то время как специалисты самого агентства пользовались более привычной метрической системой [ньютон-секунда] для управления аппаратом.
Да, это действительно настолько важно. Единственный способ избежать подобного — иметь четко налаженную систему коммуникации. Разработайте нормативный документ, утверждающий процедуру всех проводимых измерений, то, как они должны выполняться, и в каких единицах измерения должен указываться результат. Необходимо, чтобы документ был однозначным и не допускал иных толкований, а итоговая база данных сопровождалась подробным словарем базы данных.
Другая область, где единицы измерения имеют критическое значение, — денежные валюты. Представим сайт для электронной коммерции, на котором размещен заказ стоимостью 23,12. В США по умолчанию будет считаться, что это 23,12 долл., в то время как во Франции это будет 23,12 евро. Если заказы из разных стран окажутся объединены в одну базу данных учета информации по валютам, то итоговый анализ будет иметь отклонения в сторону более слабой валюты (поскольку в числовом выражении цена за тот же предмет будет выше) и фактически окажется бесполезен.
Базы данных должны обеспечивать столько метаданных и контекста, сколько необходимо, чтобы избежать подобного недопонимания.
Кроме того, можно просто принять метрическую систему и придерживаться ее (проснись, Америка!).
Следующая проблема с данными, которую в некоторых случаях бывает сложно отследить, это значения по умолчанию (рис. 2.3A и D). Пропущенные данные могут отражаться в базе данных как NULL, но также может использоваться определенное значение, которое можно задать. Например, 1 января 1900 года — стандартная дата по умолчанию. С ней могут быть разные проблемы. Во-первых, если вы забудете о том, что эта дата появляется по умолчанию, результаты анализа могут вас весьма озадачить. Предположим, вы оставили это значение по умолчанию в ячейке с датой рождения. Аналитиков может смутить тот факт, что столько людей в вашей базе данных старше 100 лет. Во-вторых, при неудачном значении по умолчанию есть риск перестать различать пропущенные и актуальные данные. Например, если вы устанавливаете «0» как значение по умолчанию для пропущенных данных, а значение актуальных данных тоже может быть равным 0, впоследствии вы не сможете определить, в какой ячейке отражены результаты измерения, а в какой просто пропущены данные. Отнеситесь к выбору значений по умолчанию внимательно.