Наши хранилища данных все больше и больше направлены на отслеживание детальных транзакций клиентов в почти реальном времени. Как указывает Patricia Seybold в своей замечательной книге Customers.com (Time Business, 1998), управление взаимоотношениями с клиентами означает наличие доступа к данным от всех процессов в организации, которые имеют дело с ними.

Хранение детальной информации обо всех процессах, которые взаимодействуют с клиентами, вкупе с обеспечением в то же самое время единого представления о них является интересной задачей для архитектора ETL. Предположим, перед нами типичный сложный бизнес, ориентированный на клиента, который имеет пятнадцать или более систем, взаимодействующих с клиентом, включая продажи в магазинах и через Интернет, поставки, платежи, кредитование, контракты на послепродажную поддержку, звонки в сервисную службу, а также различные формы маркетинговых коммуникаций. Многие из этих приложений создают свой собственный естественный ключ для каждого клиента, и некоторые из них не очень хорошо справляются с задачей отбраковки дубликатов записей, относящихся к одному и тому же клиенту. Может не существовать надежной единой системы идентификации клиентов, используемой для всех приложений, имеющих дело с ними.

Перед архитектором ETL встает непростая задача удаления дубликатов записей о клиенте, приходящих из каждой системы-источника, сопоставления клиентов по всем системам, сохранения жизни лучшим и наиболее надежным группам описательных атрибутов, тщательно отобранных из каждой системы. Я описываю подробности процесса удаления дубликатов, сопоставления и сохранения жизни в подсистеме ETL #8 в моих лекциях и книге по ETL.

Проблема для архитектора ETL заключается в том, что даже после того, как идеальная целевая единственная запись о клиенте будет получена, конечный пользователь-аналитик может быть не в состоянии проследить путь назад из хранилища данных к набору интересующих его транзакций клиента, содержащихся в одной из систем-источников. Шаги по удалению дубликатов и «сохранению жизни», выполняемые при подготовке конечных очищенных основных клиентских данных, могут вносить в имена, адреса и атрибуты клиентов малозаметные изменения, которые разрывают связь между хранилищем данных и исходными «грязными» транзакциями в системах-источниках.

В последнее время сообщество пользователей стало требовать, чтобы вся детальная информация об операциях, совершаемых клиентами, была доступна в хранилище данных. Это означает, что нам надо каким-то образом перенести все «родные» идентификаторы клиента из источников в целевое измерение с основными клиентскими данными. Более того, если в системе-источнике имелись записи-двойники для того же самого клиента (которые мы найдем и удалим на этапе ETL), нам нужно также перенести все дублирующиеся идентификаторы из источников в измерение с основными клиентскими данными. Только при помощи хранения и поддержания полного набора обратных указателей на исходные идентификаторы клиента мы сможем обеспечить тот уровень возможностей по обратному отслеживанию (из хранилища в источники), который требуют конечные пользователи.

Я рекомендую создание таблицы - единого справочника, которая будет хранить все исходные идентификаторы клиента. Эта таблица содержит следующие поля:

  • Data Warehouse Natural Customer Key
  • Source System Name (название системы-источника)
  • Source System Customer ID (идентификатор клиента в системе-источнике)

Data Warehouse Natural Customer Key – это специальный естественный ключ, созданный хранилищем данных! Нам потребуется подобный постоянный, неизменяемый ключ в измерении с основными клиентскими данными для того, чтобы мы могли однозначно определять версии медленно меняющегося измерения типа 2 для данного клиента.

К этой таблице можно обращаться напрямую, ограничиваясь в запросе по полю Data Warehouse Natural Customer Key (в условии where), или при помощи операции соединения (join) по этому полю с измерением, содержащим основные клиентские данные. В обоих случаях в результате выполнения запроса в поле Source System Customer ID будет содержаться полный список обратных указателей (т.е. исходных идентификаторов в системах-источниках).

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

Материал опубликован с разрешения компании Ralph Kimball Associates
Автор оригинала: Ralph Kimball
Перевод на русский язык: Олег Кузьменко
Источник: здесь


Для удобства отслеживания новых публикаций рекомендуем подписаться на рассылку или на канал RSS.

Читайте также: