Номер записи имеет смысл внутри своего источника. Разбираем, как сопоставлять клиентов из разных систем и сохранять основание принятого решения.
Два одинаковых номера могут вести к разным людям
Представим условный магазин с сайтом и отдельной программой поддержки. На сайте клиенту присвоили номер 42. В программе поддержки номер 42 появился у другого человека: записи там создавались независимо. Если объединить покупки и обращения только по этим числам, история одного покупателя окажется у другого. Оба источника при этом могут правильно различать собственных клиентов.
Идентификатор — обозначение, по которому система находит запись. Сначала нужно узнать, кто его выдал и какой объект он обозначает. Номер обращения, учётной записи и покупателя — разные вещи. Даже одинаковое название поля не подтверждает одинаковый смысл. При переносе данных полезно сохранять источник вместе с исходным номером, чтобы эта информация не потерялась.
Источник входит в описание записи
В руководстве Oracle по индексу персон исходная запись описана парой: система и локальный идентификатор. Несколько исходных записей могут относиться к одному общему профилю. Это пример устройства конкретного продукта, который помогает увидеть общий принцип: местный номер не становится общим только потому, что его скопировали.
В нашем магазине сохраним отдельно «сайт, клиент 42» и «поддержка, клиент 42». Такая запись ещё не связывает двух людей, зато не смешивает сведения раньше проверки. Как номер отличает строки внутри одной базы, объясняет материал о первичном и внешнем ключах. При объединении источников добавляется задача установить соответствие между их записями.
Соответствие нужно подтвердить
Допустим, в обращении клиент вошёл через подтверждённую учётную запись сайта, и поддержка сохранила её номер. Для нашего примера это явное основание связать две записи. Таблица соответствий может хранить исходную систему, местный номер, общий профиль и причину связи. Она отвечает на вопрос, почему обращения отнесли к конкретной истории покупок.
В документации Microsoft Dataverse при интеграции отдельно рассматриваются внешние идентификаторы и альтернативные ключи. Последние позволяют находить запись по согласованному уникальному признаку или их сочетанию. Назначение механизма связано с обменом между системами; наличие одинаковых чисел само по себе таким согласованием не является.
Сомнительная связь должна оставаться сомнительной
Для нашего процесса заранее предусмотрим случай, когда надёжного основания пока нет. Например, в двух карточках совпало имя, но остальная информация отсутствует. Оставим их отдельными и отметим необходимость проверки. Принудительное объединение ради красивого отчёта скроет неопределённость, а позднее будет трудно понять, откуда появилась чужая покупка.
Не стоит автоматически объявлять адрес почты вечным идентификатором человека. Для условного проекта сначала выясним, может ли адрес измениться, использоваться совместно или повторяться в разных типах аккаунтов. Правило сопоставления должно учитывать устройство конкретного источника. Если связь исправили, полезно сохранить прежнее решение и объяснение изменения, а не просто затереть историю.
Правильная связь проверяется на последствиях
Возьмём небольшой вымышленный набор: у первого клиента две покупки и одно обращение, у второго одна покупка. После объединения проверим принадлежность каждого события, а затем число связанных и несвязанных записей. Общая сумма покупок может остаться правильной даже при ошибочном распределении между людьми. Поэтому одного совпадения итоговой суммы для такой проверки недостаточно.
Результат сопоставления стоит обсуждать вместе с проверкой полноты переноса. Сначала выясняют, все ли нужные записи получены, затем — к кому они относятся. На программе Data Engineer для начинающих можно продолжить изучение задач объединения данных. Первый полезный шаг — словами описать надёжное основание связи и случай, в котором объединение нужно отложить.
