Речь идет об историческоих данных.
Если сменился адрес,
то если он исползуется как отдельное измерение
то надеюсь у вас суррогатный ключ?
если просто как реквизит у клиента, то проще.
А дальше в зависимости от ТРЕБОВАНИЙ БИЗНЕСА, то есть конечных пользователей необходимо хранить либо текущие данные либо историю изменений.

Во всяких умных книжках по ХД приводится масса примеров, когда на заре ХД разработчики насоздавали кучу ненужных функциональностей от которых потом эти ХД и умерли(

2Константин Лисянский

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

При всем уважении позвольте с Вами не согласиться.

Рассмотрю это на личном примере:
Появилось требование разработки Куба с Измерением по контрагенту и допустим с properties адрес.
Итак, первое что не должен забывать разработчик ХД - это пожелания пользователей.
Что делаю: опрашиваю пользователей ХД(70 чел): аналитиков (10 чел), руководство (5 чел), активных(query tuples>1000/неделю) и прочих кому это понадобится + отдел стратегического планирования, который имеет перед собой план развития компании до 2008 года.
Вопрос один: нужно ли хранить историю адреса клиента?.

Если мне все пользователи отвечают, что НЕТ, а отдел стратегического планирования добавляет, что это не понадобиться до 2008 года. То зачем я буду это делать?
Во-первых, затрата времени (когда же мы его научимся ценить?)(а);
Во-вторых, затрата ресурсов на хранение, обработку
В-третьих, большая вероятность ошибок, так как сложность больше.

По пункту а можно добавить? что необходим будет дальнейший анализ о том где хранить историю, как?(см slowly changing dimension)

Если рассмотреть далее что возникает ситуация когда в связи со сложившимися рыночными условими будет необходим такой анализ и срочно.
Получается что
1) ошиблись 70 человек
2) делаю срочные переработки во времени /ресурсам ХД за которые требую доп. премии.
3) пункт №1 бывает не часто