Вот узнал на форуме и даже пример в Adventure Works пример нашел работоспособный, но не совсем такой как мой, и что то у меня не получается на моем примере ни в какую. :-(

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

Получается, что надо строить вьюху на всем множестве таблиц (первый напряг для админа или ISV), а при добавлении новых талиц (разделов в куб) надо эту вьюху еще и обновлять (перманентный напряг для амина/ еще больший напряг для ISV).

А в сущности, то решение в AS было бы до нкльзя простое - добавили новый раздел к кубу, в котороом есть дегенерированное измерение, даем знать этому иззмерению, что источник для него изменился.
Ну не лазить же в production environment в DSV с помощью AMO и править DSV вьюхи при добавлении новых разделов.

За ранее прошу прощения, если для кого то мои строки звучат резко.

net_ratТак а в чем вопрос то, каким способом дополнять таблицы измерений не вызывая перестройки куба? Если да, то ИМХО никак, поскольку даже если Вы напишите job'у по обнавлению таблицы измерениц, независимую от AS, измерени не будут фигурировать в кубе до перестройки.

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

Fact_2005_01
..
Fact_2005_12
Fact_2006_01
...
и строить view на union этих таблиц ни желания ни возможности у меня нет.