MSAS2000 sp4
Хранилище Oracle 9
2 XEON 1.9 HT, 6 Gb RAM, 4 по 60 SCSI не в рейде.
Клиент OWC 10

5 удаленных БД одна из которых центральная (находится в головном офисе)
В хранилище информация заливается отдельно - справочники и таблицы фактов.

Проблема состоит в создании или нет суррогатных ключей для измерений.

На примере товара - в базах по сути на 90% товары одинаковые по мнемокодам(если есть различия в свойствах товара, то ими можно пренебречь и брать из центральной базы). Все справочники товаров заливаются в один с добавлением поля REGION со значениями (1..5). ID на уровне баз для одного и того же мнемокода разные в каждой базе.
Как делается сейчас: строится мат претставление на указанный месяц в которую уже зашиваются все нужные наименования измерений. И по этому представлению расчитываются партиции кубов. Все строится на одной таблице за исключением нескольких hrent-child измерений, которые приводятся к центральному региону. Что в этом случае получаем понятно. Ключами измерений являются наименования измерения, которые представлены в виде строки иногда размерами по 100 символов. Работа с измерениями в несколько тысяч мемберов всегда жутко медленное.

Что можно сделать в таком случае: можно сосздать ещё одну таблицу в которую группировать справочник по указанным полям и сгенерировать суррогатный ключ. В этом случае данные в эту таблицу должны только добавляться, т.к. по ней уже будут расчитаны партиции или же обновляться поля справочника по которым не делается группировка.
Но возникает ряд проблем: поля группировки так же могут быть изменены. Придется в таблах фактов обновлять поля ID для измерения на полученный суррогатный ключ (что нереально на миллионы записей). Ну да ладно обновим, а насколько ускорит работу прилжения клиента такая структура, когда поля индексов для измерений будут числовыми?

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

Многие говорят об измерениях в сотни тысяч, а тут и на десяти нет 5 секунд отклика.

backfire, спасибо за участие.
Я и не спорю что тут задача DWH при построении таблиц измерений.
1. Я создаю суррогатные ключи на таблицы измерений
2. Строю по ним измерения
3. По реальным ID таблиц измерений связываемся с таблицей фактов.
4. Все отпроцессили и все счастливы?
5. Не тут то было. С измерениями [Товары] 37000 или [Лицевые счета] 20000 как и прежде работать надо с завидным терпением.

Что не в порядке, я не могу понять. Это owc себя так ведет(если нужен другой клиент, то какой) или дизайн не верный? 5 секунд отклика при участии больших измерений в запросе клиента - это мечта.