Проверка на уникальность данных

И речь совсем не о проверке на антиплагиат. Кстати, сталкивались с этим или получили диплом раньше? Хотя, в целом и антиплагиат о том же – проверке на уникальность. Её еще называют проверка на дубли.

Зачем это нужно? Чтобы потребители и пользователи увидели и могли использовать корректную информацию. Например, поиск по адресу, и пять домов с одинаковым номером, и только к одному из них подтягиваются номера квартир. Или номера транспортных маршрутов. Как вам 1, 1а, 1к, 1д и другие «единички» с мелкими приписанными буквами? Они идут в разные места, но часть маршрута общая. Иногда, подстраиваясь под дорожную обстановку, они меняют на лету таблички. Можно сесть в 1д, а оказаться в 1к и думать «я не внимателен или поменяли?» Но тут хотя бы есть разница в буквах. А представьте вашего полного тёзку? Может быть, даже родственника. Вы живёте в одном городе, на одной улице, в одной квартире. Как почтальону или звонящему по телефону различить, кто есть кто? Дублирование и отсутствие уникальности на лицо! 😊 А 100500 одинаковых файлов в разных папках?

Перед настройкой этой проверки стоит проверить, в каких таблицах какие атрибуты должны быть уникальными. Это может быть ключ таблицы, а может быть и нет. Вполне возможно, что уникальными должно быть сочетание полей, но не всех, а лишь некоторых (как в случае с тёзкой, людей можно различить по разным датам рождения).

Способы реализации проверки данных на дубли могут быть разные. Это и использование в скриптах HAVING count(*) > 1, и фильтрация выгрузки в эксель, и проверка на отсутствие дублей в коде, и ограничения UNIQUE, CHECK или специальные программы.

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

#качестводанных #dataquality