Объединение данных из дублирующихся записей клиента

#sql #ms-access

#sql #ms-access

Вопрос:

У меня есть база данных Access, которая содержит две таблицы: client и eventAttendance. Клиент сохраняет данные при первой регистрации клиента. EventAttendance содержит идентификатор события, ClientID и дату, когда клиент посетил мероприятие. В таблице клиента существуют дублирующиеся записи. Многие клиенты имеют несколько идентификаторов клиентов. Эти идентификаторы клиентов используются для регистрации событий, поэтому один и тот же отдельный клиент мог зарегистрироваться для восьми разных событий с восемью разными идентификаторами клиентов.

Я идентифицировал клиентов в таблице client с несколькими идентификаторами клиентов, но я не уверен в том, как теперь объединить записи в таблице eventAttendance. Кто-нибудь может порекомендовать, как мне справиться с этой ситуацией?

Табличный клиент

 ClientID  Name   Email
1         Jack   Jack@gmail.com
2         Jill   Jill@gmail.com
3         Jack   Jack@gmail.com
  

Соответствие событий таблицы

 EventID   ClientID   AttendanceDate
1         1          6/1/2000
1         3          6/1/2001
  

Ответ №1:

Звучит как проблема с непоследовательными данными.

Вам нужно будет иметь уникальный идентификатор для одного клиента, который вы можете отобразить в таблице EventAttendance, чтобы создать 1-миллионную связь. Поскольку вы определили сходство между дублирующимися записями в clientid, создание уникального идентификатора не составит проблемы. Создайте новый столбец в таблице client и присвоите уникальный номер каждой дублирующейся записи клиента для одного и того же клиента. Теперь вам нужно написать инструкцию update, в которой вы можете обновить столбец ClientID таблицы EventAttendance новым идентификатором. Это один из способов сделать это.

после обновления вы можете удалить дублирующиеся записи клиентов, кроме первой, и присвоить ей уникальный идентификатор, а также удалить столбец уникального идентификатора, который был создан для идентификации одного клиента и ссылки на него в таблице EventAttendance в качестве внешнего ключа.

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

Комментарии:

1. Я не уверен, что предположение о том, что адрес электронной почты является ключом-кандидатом, является правильным. У меня есть проект, который представляет собой именно такую ситуацию, то есть с регистрационными данными конференции, и многие компании предоставляют один адрес электронной почты для нескольких владельцев регистрации. И отдельный человек может зарегистрироваться с другим адресом электронной почты для разных событий. Но, конечно, это зависит от бизнес-правил в конкретном приложении.

Ответ №2:

Во-первых, я несколько лет не пользовался MS-Access, поэтому я постараюсь сохранить свой SQL универсальным. Я бы рассмотрел этот псевдокод, целью которого является передача шагов для достижения вашей цели удаления дублирующих клиентов.

Шаг 1. Обновите идентификатор клиента в таблице посещаемости событий, чтобы он соответствовал минимальному идентификатору клиента из дублирующихся записей клиента

Единственная хитрость здесь заключается в группировании всех клиентов и использовании MIN агрегатной функции для определения идентификатора клиента с наименьшим значением для каждого клиента.

 UPDATE EventAttendance set ClientID = C2.ClientID
FROM
  EventAttendance as E
  INNER JOIN Clients as C1 on C1.ClientID = E.ClientID
  -- Re-Join with Clients to obtain the Minimum ClientID per Client
  INNER JOIN (Select Min(ClientID) as MinClientID FROM Clients GROUP BY ClientName) as C2 on C1.ClientName = C2.ClientName
  

Шаг 2. Удалите все записи клиента, кроме первой, для каждого клиента

На шаге 1 удалены все ссылки на дублирующие клиенты, поэтому мы можем свободно удалять дублирующие.

 DELETE FROM Clients 
WHERE ClientID not in 
  -- If the current record's ClientID is not in the following, then it is a dupe that is OK to be deleted
  (Select Min(ClientID) as MinClientID FROM Clients GROUP BY ClientName)
  

Примечания

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