Ситуация. Есть набор данных, допустим view A:

1. A_ID
2. A_NAME
3. A_PROPX

В хранилище этому будет соответствовать таблица/измерение X:

1. X_ID
2. X_NAME
3. X_PROPX

X_ID, A_ID - суррогатные ключи
Ясно, что X_ID <> A_ID, в общем случае, т.к. может быть n источников. Выход - делать маппинг с использованием Key lookup, чтобы проверять, есть ли перелитые данные или нет, и если есть - не стоит ли их обновить?(случай с slowly changing dimension). Так вот вопрос. подрузамевает ли эта схема еще 1 маппинг, типа view A - Key lookup table T, или можно извернутся 1 маппингом? X_ID берем из сиквенса.

Короче схема такая -
1. Берем запись A_ID, проверяем есть ли она в key lookup table
2. Есть - берем X_ID для A_ID и делаем update значений.
3. Нет. Берем из sequence X_ID, вставляем соответсвие в key lookup, вставляем данные в X.

Как это проще сделать в Oracle Warehouse Builder?

Моя тупая придумка:
1) Запускать маппинг между A и key lookup T, для вставки новых пар A_ID-X_ID
2) После этого 100% всех A_ID есть в lookup - делаем merge в X через key lookup.

Что не нравится? Между 1 и 2 может добавится запись, и писец.



"The CBO without stats is like a morning without coffee." T.Kyte

почитал. У меня простейший вариант SCM - 1 тип. Смотрите разницу между моим примером и тем:

B GEO_DIM включены натуральные ключи источника, т.к. это часть данных. В моем примере и измерение и таблица источника используеют суррогатные ключи. Хранить в измерении суррогатные ключи всех источников - совсем неинтересно. Интересно иметь таблички Key lookup, чтобы иметь соответствие между суррогатным ключом хранилища и суррогатными ключами источников.

Получается этакая двуступенчатая заливка - сначала обновляем keylookup, потом делаем update/insert для измерения.

Кстати, а можно ли сделать, чтобы данные только дозаливались? т.е. такой update/insert в котором ничего не апдейтится :-) update/insert хочет по крайней мере 1 поле для такого действия



"The CBO without stats is like a morning without coffee." T.Kyte

А вот и нет, _достоверных_ натуральных ключей нет. Да и некорректно к ним цеплятся..

"The CBO without stats is like a morning without coffee." T.Kyte

Angel13Тогда я ничего другого не вижу, кроме как хранить A_ID либо в таблице с измерением, либо отдельно в "Key lookup table". И тогда да, будет 2 маппинга, хотя как-то странно...

т.к. может быть n источников.
А если A_ID будет не уникальным ?

Primary Key constraint. У другого источника - другая таблица по идее должна быть, ну я уже это реализовал, вроде работает