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