В последнее время собираю остатки информации за начало 90-х годов для загрузки в хранилище. Фирматогда была еще молодая и данных мало.

Схема такая: архив старой БД-копия архива в MSSQL(А)-Хранилище данных(Б)
Данные обновляются каждую ночь.
Из пути А в Б есть два варианта трансформации, в связи с тем что измерения часто меняются. Есть три варианта решения.
1. Делать трансформацию каждый день.
Плюсы: меньше кода, меньше работы
Минусы: логически думаю некрасиво
2. Делать перетрансформацию только изменившихся измерений
Плюсы: быстрее
Минусы: больше кода, больше работы
3. Создать уник коды и ежедневно привязывать уник коды к требуемым листьям.
Так советует Макрософт делать для больших таблиц фактов. Поэтому данный вариант можно не рассматривать в силу того что таблицы фактов маленькие.

Склоняюсь к варианту 1, но понимаю что ежели в будущем будет необходимо еще часоне обновление, то придется переписывать в 2 или 3. Но еще часное в ближайшие 6 месяцев точно не надо будет.

А как вы бы поступили?

сорри,
еще часоне = ежечасное
два варианта трансформации=три варианта трансформации

Меняются измерения.

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

И по части измерений необходимо исторические данные тоже подгонять под текущее положение их в иерархии.

Ты прав, именно так и указывает делать Майкрософт.
Но тогда получается необходим дополнительный уровень иерархии
то есть Реальный объект - Уникальные коды его в различных таблицах фактов.

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

Просто считай хранилище всего лишь пока 25Гб, и таблицы факты которых необходимо перекрыживать более чем на 2,5Гб не встречаются.
И думаю что прирост перекрыживаемых таблиц фактов для этих кубов будет макс 0,5Гб в год.

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

По той статье сделал еще несколько измерений в которых хранится история.
ТО есть Ветка1-Листок1_20030101; Ветка2_Листок1_20040101 итп

2GoodLeo
Спасибо, буду думать в таком измерении. Но немного не то так как
уникальный код у меня в виде Fullpath,
( а не просто id, поэтому при процессинге строится заново, но поиск в старых идет по его "shortpath",заодно сортируются ошибки дублирования.)
так проще понимается, но видимо придется получше это рассмотреть.