Вставьте обновления и удалите записи флагов источника в цель с помощью informatica

Я реализовал отображение, как показано ниже. может кто-нибудь подсказать, что это хороший подход или нет.

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

Источник данных:

col1   col2 col3  DML_FLAG
1      a    123   NULL(old record)
2      b    456   I
3      c    678   U

Отображение:

Source...>SQ...>exp...>lkp(on target to identify new or update)
       ..>exp..>...>RTR(for insert and update)-->upd(for update)...>target

При первой загрузке мне нужно загрузить все записи, т.е. полную загрузку (старые записи (DML_flag имеет значение null) и новые записи

Со 2-го прогона мне нужно фиксировать только измененные записи из источника, для этого я использую переменные сопоставления

Здесь у меня есть вопрос, например, у нас уже есть флаги I и U, которые снова доступны в источнике. Я использую LKP, без поиска, я могу использовать DML_FLAG с двумя группами I и U в RTR.

Но мне нужно обновлять данные каждые 30 минут, при этом через 30 минут одна вставленная запись (I) и одна и та же запись была обновлена, а затем флаг изменился на 'U' в источнике, такая же запись недоступна в цели, в этом случае можно как Могу ли я захватить эту новую запись с флагом «U» без lkp.

может кто-нибудь подсказать, как я могу это сделать без поиска?




Ответы (1)


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

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

person Daniel Machet    schedule 15.06.2018
comment
Спасибо, Даниэль, да, мне нужно вставить запись с флагом «U». Мне нужно обновлять данные каждые 30 минут, при этом через 30 минут вставляется одна запись (I), и такая же запись обновляется, а затем флаг изменен на «U» в источнике такая же запись недоступна в целевом. - person Jyo; 15.06.2018
comment
Я не понимаю, почему вам нужно, чтобы запись уже была в цели, если вы не выполняете обновление. В этом случае используйте целевой план загрузки, как уже упоминалось, который сначала обработает все вставки, а затем запись будет там, когда придет время выполнить обновление. - person Daniel Machet; 15.06.2018
comment
Спасибо, Даниэль, записи нет в цель. мой исходный поток - Source ETL Target Run 3 (8:00) EMP No Name Location Flag Timestamp EMP No Name Location 5 John CA I 6/11/2018 7:30 INSERT (I) 4 John NJ 5 John NJ U 6/11 / 2018 7:31 ОБНОВЛЕНИЕ (U) Если запись была ВСТАВЛЕНА, а та же запись была ОБНОВЛЕНО при следующем обновлении, тогда ETL захватит только ОБНОВЛЕННУЮ запись и вставит в цель - person Jyo; 15.06.2018
comment
Хорошо ... если вы хотите вставить только запись обновления, вы можете добиться этого, используя сортировщик на основе общего ключа из двух записей и возрастающего флага. За ним следует агрегатор только по общему ключу, и вуаля проходит запись с пометкой update, пока вставка фильтруется агрегатором. Сообщите мне, соответствует ли это вашим требованиям - person Daniel Machet; 16.06.2018