← Все курсы · Все руководства · Серия «Миграция данных»
Этап 4. Очистка и устранение дублирования
Очистка — это когда вы исправляете то, что можно исправить автоматически, а все остальное передаете клиенту. Выходные данные — это источник, который будет принят целевой системой, и список исключений, в котором каждая строка имеет решение. В этой статье рассматривается различие между ними и способы дедупликации без уничтожения реальных записей.
Краткая версия. Если правило может исправить это безопасно, исправьте его. Если человек должен принять решение, он попадает в список исключений, а этот список представляет собой ворота, которые закрываются только тогда, когда в каждой строке есть ответ.
Что может исправить правило
Что из этого, по вашему мнению, более рискованно автоматизировать: обрезку пробелов или стандартизацию даты? Пусть ответ будет перед списком.
Безопасно исправить по правилу, поскольку намерение не вызывает сомнений: начальные и конечные пробелы, несогласованное использование заглавных букв в кодах, однозначный формат даты, номер телефона, написанный с разной пунктуацией, название страны, которое появляется в двух вариантах написания.
По правилам это небезопасно, потому что вы можете догадываться о значении: дата, которая может быть 4 марта или 3 апреля, строка статуса, которую никто не узнает, пробел в обязательном поле, две записи, которые выглядят одинаково, но могут быть двумя реальными людьми.
Первое свидание — это ловушка. 04.03.24 является неоднозначным, и правило, которое выбирает сторону, автоматически преобразует тысячи строк в неправильный день. Проверьте настройку исходной системы, подтвердите ее значением, которое вы можете проверить независимо, а затем примените правило.
Каждое правило предварительно просматривается
Никогда не запускайте преобразование, которое вы не просмотрели, в реальных строках. Покажите оригинал и результат рядом, двадцать строк, и прочитайте их.
Это улавливает то, чего не будет ни в одном сообщении об ошибке. Правило, удаляющее суффикс и случайно изобретающее несуществующее значение, будет без проблем работать в сотнях тысяч строк. Единственная защита — это смотреть на результат. руководство по разрешению объектов приводится реальный пример, когда два раунда предварительного просмотра выявили два отдельных дефекта в одном правиле.
Дедупликация без ущерба
В новой системе один клиент превращается в два — это ошибка, которую пользователи замечают в первую очередь. Слияние двух реальных людей в одного еще хуже, и его труднее отменить.
Работайте в три прохода.
Сначала точные дубликаты. Тот же идентификатор, то же имя, та же дата рождения. Они безопасны и обычно являются основной причиной проблемы.
Рядом матч второй. Тот же человек, другое написание. Это кандидаты, а не решения. Составьте список, отсортируйте его так, чтобы наиболее важные были вверху, и прочитайте его.
Неоднозначные случаи для клиента. Отец и сын с одинаковым именем и по одному и тому же адресу не являются дубликатами, и никакое правило не скажет вам об этом. Клиент знает. Просить.
Представьте перед собой две записи: одно и то же имя, один и тот же адрес, даты рождения с разницей в два года. Скажите, что бы вы сделали, прежде чем читать дальше. Ответ в том, что не вы это решаете. Эта строка попадает в список исключений.
Список исключений — это ворота, а не документ
Отформатируйте его так, чтобы с ним мог работать нетехнический человек. Одна строка на каждую проблему, идентификатор записи, что не так в словах, варианты и пустой столбец решения.
Отправляйте его партиями с указанием даты. Список из четырехсот строк, пришедший в одном электронном письме, ничего не получает обратно. Пятьдесят строк с крайним сроком в пятницу получат ответы.
Этап закрывается, когда в каждой строке принимается решение. «Оставить это пока» — это не решение, это отложенная проблема, которая всплывает на поверхность во время пользовательское тестирование когда уже не остается времени. Рядом с каждой строкой запишите, кто и когда решил.
Что ты не чистишь
Не чините вещи, которые просто неопрятны. Данные клиента не обязательно должны быть хорошими, они должны быть приемлемыми для целевой системы и соответствовать тому, что у них было.
Очистка после этого момента требует времени, сопряжена с риском и изменяет записи, которые клиент никогда не просил вас изменить. Если вы обнаружите настоящие проблемы с качеством, выходящие за рамки рассмотрения, запишите их как ограничение и передайте в ближайшее время. Это подарок клиенту, а не провал. Документирование ограничений рассказывает, как их писать, чтобы они были полезны.
Шпаргалка
| Ситуация | Правило или исключение |
|---|---|
| Завершающие пробелы, коды смешанного регистра | Правило |
| Однозначное переформатирование даты | Правило после подтверждения исходного формата |
| Неоднозначная дата | Exception |
| Пустое обязательное поле | Exception |
| Точный дубликат | Правило |
| Почти дубликат | Exception |
| Нераспознанное значение статуса | Exception |
| Неопрятные, но достоверные данные | Оставьте это, обратите внимание на это в конце |
Одна привычка
Предварительный просмотр каждого правила в реальных строках, прежде чем запускать его в масштабе. Данные не скажут вам, когда правило неверно.
Какое правило уборки, по вашему мнению, приносит больше всего вреда?
Подсчет строк, группировка для поиска дубликатов и объединение для поиска потерянных строк покрывает большую часть того, что требует от вас миграция. Курс SQL обучает этим движениям по порядку, имея данные перед вами.
Откройте набор SQL →Или сразу начните вводить: открыть SQL-практикум, тринадцать запросов, каждый из которых добавляет что-то одно к последнему.
Вы переносите записи клиента в новую систему, и вас беспокоит та неделя, когда клиент замолкает. Руководство по миграции данных это все восемь этапов по порядку, 63 страницы, от первой стартовой встречи до гиперпомощи, так что вы можете пройти один, не опоздав на три недели с важным вопросом.
Руководство по миграции данных, 29 долларов США →Ссылки
- Феллеги, И.П. и Сантер, А.Б. (1969). Теория связи записей. Журнал Американской статистической ассоциации, 64.(328), 1183–1210. doi:10.1080/01621459.1969.10501049
- Ван, Р.Ю., и Стронг, Д.М. (1996). За пределами точности: что качество данных означает для потребителей данных. Журнал информационных систем управления, 12(4), 5–33.
- Маттес Ф., Шульц К. и Халлер К. (2011). Тестирование и обеспечение качества в проектах миграции данных. 27-я Международная конференция IEEE по сопровождению программного обеспечения (ICSM), 438–447.