Операция ETL - возврат первичного ключа

Я использую Talend для заполнения хранилища данных. Моя работа заключается в записи данных клиентов в таблицу измерений и данных транзакций в таблицу фактов. Суррогатный ключ (p_key) в таблице фактов автоматически увеличивается. Когда я вставляю нового клиента, мне нужна таблица фактов, отражающая идентификатор соответствующего клиента.

Как я уже упоминал, мой p_key автоматически auto_incrementing, поэтому я не могу просто вставить произвольное значение для p_key.

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

Больше информации:

Что делать, если входящие данные не нормализованы? Например, у меня есть CSV со следующими данными:

order #   date        total customer# first_name last_name
111       1/2/2010    500    101      John        Smith     
222       1/3/2010    600    101      John        Smith

Очевидно, я хочу, чтобы информация о клиенте появлялась в таблице измерений, а данные о транзакциях - в таблице фактов:

dimension
101  john smith

fact
111       1/3/2010
222       1/3/2010

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

Кроме того, если данные клиента дедуплицированы (как указано выше), как вы обрабатываете ключи?

1 ответ

Решение

Я, возможно, неправильно понял вашу проблему, однако:

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

  2. Таблица измерений должна иметь автоматическое увеличение PK.

  3. Новый клиент должен "приземлиться" в таблице измерений клиента до того, как факт транзакции достигнет DW (или, по крайней мере, таблицы фактов).

  4. Таблица измерений должна иметь BusinessKey, который однозначно идентифицирует клиентскую электронную почту, полное имя + пин-код или подобное.

  5. В строке входящей транзакции также должно быть поле клиента BusinessKey - так мы идентифицируем клиента.

  6. Используйте BusinessKey для поиска клиента PrimaryKey из таблицы измерений клиента перед вставкой транзакции в таблицу фактов.

РЕДАКТИРОВАТЬ

Если ваши новые данные о клиентах связаны с транзакцией, найдите способ извлечь данные о клиенте и направить их в DW до транзакции.

ОБНОВИТЬ:

Сначала загрузите dimCustomer, выберите BusinessKey, чтобы измерение выглядело следующим образом:

CustomerKey = 12345 (auto-incremented)
CustomerBusinessKey = john_smith_101 (must uniquely identify the John Smith)
CustomerFirstName = John
CustomerLastName = Smith

В процессе загрузки измерений вы должны разделить входящие строки на два потока, существующих и новых клиентов. Строки из потока "существующий клиент" обновляют таблицу затемнения (тип 1 SCD), в то время как строки из потока "новый клиент" вставляются. В потоке вставляемых строк не должно быть дубликатов; Вы можете сделать это, вставив их в промежуточную таблицу и удалив там дубликаты, непосредственно перед последней вставкой в ​​таблицу измерений. Вы также можете извлечь дубликаты и направить их обратно в процесс загрузки, чтобы обновить записи клиентов; они могут содержать более новые данные - например, обновленные номера телефонов или аналогичные.

Как только клиент вошел, загрузите факты.

Таблица фактов должна выглядеть примерно так:

DateKey     (PK)
CustomerKey
OrderNumber (PK)
Total

Я использовал составной первичный ключ DateKey и OrderNumber, позволяя время от времени сбрасывать последовательность номеров заказов.

В процессе загрузки измените запись факта, чтобы она выглядела примерно так:

DateKey CustomerBusinessKey OrderNumber Total
20100201  john_smith_101       111       500
20100301  john_smith_101       222       600

На этом этапе нам нужно заменить CustomerBusinessKey на CustomerKey из таблицы измерений, используя поиск. Итак, после поиска поток будет выглядеть так:

DateKey CustomerKey OrderNumber Total
20100201 12345       111         500
20100301 12345       222         600

Теперь это можно вставить в таблицу фактов.

Я также немного обманул - не искал ключ даты из dimDate и не искал существующие строки в таблице фактов. При загрузке таблицы фактов вы можете искать существующую (DateKey, OrderNumer) комбинацию перед загрузкой или оставить ее до первичного ключа для защиты от дубликатов - ваш выбор. В любом случае убедитесь, что попытка перезагрузить те же данные в таблицу фактов не удалась.

Другие вопросы по тегам