junixarНе представляю, как можно денормализовать справочники, чтобы избавиться от start/end_date. Что вообще имеется в виду?

Сейчас подразумеватся - появляется новый филиал в справочнике. Заводится запись в таблице филиалов со значением start_date=время открытия филиала. Год работает, потом закрывается. Или изменяются свойства филиала - это значит что реально в справочнике старый филиал будет закрыт датой end_date и создан новый с таким же именем. Чтобы факты того старого филиала с его свойствами так и ссылались на тот старый филиал.
Вообще смутился... Я не понял - у Вас первичны факты или справочники?!
Предположим, РЕАЛЬНО открылся какой-то филиал в феврале... А закрылся так же РЕАЛЬНО в августе. Скажите тогда - откуда у Вас в Хранилище могут быть данные за январь или ноябрь, например??? Тогда с какого перепуга нужно связывать факты с тем же справочником не только по ключу склада, но и по дате факта/периоду работы склада? Или Вам хочется проверить сервер на предмет производительности при обработке ненужных условий?
Например, у меня возникает необходимость хранить некоторые исторические признаки. Именно через даты начала и конца действия признака (например, цена товара). Но для этого я использую отдельные таблицы, где хранится ссылка на товар, цена и ее период действия. Но это вызвано только тем, что, например, нужно просуммировать продажи за период, расценив их по данной цене. И эти справочники используются не всегда, а только если интересует цена... У нас когда-то была ситуация, когда при изменении одного из параметров справочника просто создавалась новая запись - и все новые факты ссылались уже на нее. Но и здесь период действия нужен только в момент загрузки данных для корректной привязки к справочникам, но не при снятии отчетов. Не зная Вашей специфики, ничего утверждать не возьмусь - но у нас этот подход себя не оправдал. Остановились на отдельном хранении изменяющихся фактов с указанием периодов действия. Тоже есть свои минусы - но пока работает.
Возможно, Вы просто привели неверный пример - не буду спорить. Но выбранный пример я абсолютно не понял!
Насчет постоянности фактов Вам уже говорили. В Хранилищах требуется больше аналитика, а не 100%ное соответствие каким-то печатным документам. Приведу гипертрофированный пример, но все же... Предположим, у Вас был склад. Назывался "Крайний Север". Но потом Вы открыли склад еще севернее - в связи с чем пришла необходимость переименовать существующий склад просто в "Север" (пусть даже имя нового склада будет "Крайнейший Север", т.е. не совпадет с использованными раньше). Тогда при модели Вашего архитектора в аналитике Вы получите, что был склад "Крайний Север", потом вдруг исчез, но появился склад "Север". Соответственно, продажи за период по этому ФИЗИЧЕСКОМУ складу будут биться по двум "виртуальным" и т.п. И у Вас тогда есть очень "нетрудоемкий" выход - обновлять всю таблицу фактов. А при использовании справочника Вы бы могли изменить ТОЛЬКО название в справочнике! Более того - при желании сохранить исторические данные в справочник можно добавить поле типа "старое название склада". Добавлять такое же в факты - не хватит дисков. А как уже сказал softwarer - необходимость что-то изменить возникает ВСЕГДА.
И присоединюсь к общему мнению о странном выборе архитектора для задачи такого масштаба.
Пусть это IMHO, но Вы задумайтесь...