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

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

1 голос
/ 26 марта 2010

Я использую 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 Ответ

4 голосов
/ 26 марта 2010

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

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

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

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

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

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

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

EDIT

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

UPDATE:

Сначала загрузите 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) комбинацию перед загрузкой или оставить ее до первичного ключа для защиты от дубликатов - ваш выбор В любом случае убедитесь, что попытка перезагрузить те же данные в таблицу фактов не удалась.

...