Voyager_lan,

Про расплату можно подробнее? Кроме серьезных требований к железу, для построения витрин, какие еще последствия?

Ivan Durak,

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

Ivan Durak,

Вопрос был не праздный. Разница в костах на изменение модели хранилища при DV/Anchor в сравнении с 3NF/Звезда очевидна.
А вот при построении витрины, после того как в само ХД изменения уже внесены - с первого взгляда я не вижу. Для витрины принципиально изменение логической модели данных, а способ ее физического представления на входе принципиального значения не имеет. Какие будут аргументы за усложнение перестроения витрин при Anchor модели?

essbase.ru,

Ну, например, при Anchor добавление/удаление показателя не требует переработки ранее реализованного функционала ETL и модификации структур существующих таблиц. Фактически, в большинстве случаев можно обойтись внесением изменений в метаданные. В том случае, когда изменения требуются, они более четко локализованы, что также упрощает процесс изменения.

Критик,

Стоп :) Речь шла об изменении модели самого хранилища (или точнее, детального слоя данных), а не витрин. Про витрины я спрашивал выше. По моему мнению, изменение витрин стоит сопоставимо при любой физической модели самого детального слоя. Если есть аргументы, почему это не так, было бы очень полезно их услышать.

Дедушка,

В целом придерживаюсь того же мнения.

Касательно частностей
Дедушкаесли вы решаете собирать именно "классическую" витрину поверх DV, то трудозатраты выше чем сборка поверх "классического" ХД.
это проистекает из-за того, что в DV бизнес сущность размазана на много таблиц каждая из которых может содержать свои временные диапазоны версий и собрать всё это вместе не просто особенно если у вас слабое железо или реляционная платформа.

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

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

Выбор стар как мир - что лучше, один раз "день потерять, потом за 5 минут долететь" или "посадить сто человек с Excel, пусть считают".
Как инженер, я за первый подход, но для бизнеса часто второй бывает выгодней ;)

Поэтому к перечисленным Дедушкой критериям использовать или нет DV/AM я бы добавил еще, будете ли вы реализовывать еще подобного рода проекты в будущем или это разовая разработка.