ETL Operation - Return Primary Key

Question

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

Как я уже говорил, мой p_key является auto 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, чтобы возвращаемый ключ возвращался после вставки?

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

Answer 1

Возможно, я неправильно вас проблемой, однако:

1. Таблица фактов может или не может иметь автоинкрементный ПК, как правило, ПК в таблице фактов является составным из нескольких FKS ссылающихся таблиц измерений ,

2. Таблица размеров должна иметь автоинкрементный ПК.

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

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

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

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

EDIT

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

UPDATE:

нагрузки dimCustomer первый, решение о BusinessKey - так размер будет выглядеть следующим образом:

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

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